Designing Pleasurable Products

Capítulos 1 y 2

Cuando se va ha realizar el diseño de un producto debemos tener en cuenta que el diseño muchas veces es influido por la concepción de los diseñadores y que actualmente el diseño no se ve como una ventaja, ademas nosotros como clientes queremos que todo producto sea económico y que satisfaga mis necesidades al 100% lo que es imposible de realizar.

como hemos visto que existen unos factores de calidad en este capitulo se aclaran mucho mas algunos son:

• Funcionalidad: si un producto no cumple con su función va a causar insatisfacción para lo cual seria inútil su creación.
• Usabilidad: si el producto cumple con su función el usuario debe estar en la capacidad de usarlo facil y de la mejor manera.
• Placer: la usabilidad y funcionalidad no son suficientes se debe tener algo adicional en este producto para que el usuario no se "canse" del producto en uso que tenga algo adicional.

Teniendo en cuenta los "tres conceptos básicos" debemos saber que complacer a una persona no es fácil por eso se hace referencia a los cuatro placeres que se deben tener en cuenta para que no fracasemos con el diseño e implementación de productos.

• Físico: Es el que se encuentra enfocado hacia nuestros órganos,sentidos como oler,tacto.
• Social: satisfación en la sociedad por medio del producto.
• Psicológica: reacciones emocionales que se pueden generar a partir del producto.
• Ideologica: el contexto, lo que puede llegar a imaginar o pensar el usuario acerca de la elaboracion o concepcion del producto.

Los cuatros placeres son una forma de tener un "estructura" para que podamos identificar y poder hacer del trabajo de diseño de productos una tarea mas fácil.

Podemos decir que el diseño de objetos aveces es necesario pero algunas veces el diseñador en enfoca mas en los diseños y en muchas ocasiones perdemos en si la funcionalidad del producto. Enfocándonos en la arquitectura de software podemos identificar que el arquitecto de software debe realizar un diseño que este a las expectativas del problema y que de la solución mas optima.

Cuando un diseñador comienza a crear las maquetas de  un nuevo producto, se necesita estudiar y analizar las demandas y gustos que puedan tener los usuarios potenciales.  Como sabemos hoy en día las exigencias y gustos de las personas que consumen un determinado producto han cambiado vertiginosamente,  el consumidor no valora únicamente  la funcionalidad, usabilidad, seguridad y precio de los productos, sino que  también presta mucha atención a  las emociones y los sentimientos que despiertan en el. Pensamos que  un buen producto debería satisfacer todas las expectativas del consumidor, pero especialmente la de provocar una respuesta emocional positiva. El placer es un factor muy importante tal como afirma Patrick Jordan.

Para que un producto, servicio o experiencia produzca estos efectos en los usuarios, es necesario que abarque un estudio minucioso de los gustos , de manera que el usuario se sienta unido a ello, no  siempre se identifica con uno sólo, y es posible que así sea en la mayor parte de los casos, asimismo, también sería dificilísimo abarcar todos estos significados a la vez en un mismo producto o servicio.

Como se menciona en la  lectura los factores humanos entran a jugar un papel importante en el diseño y planificación de un producto. Donde se tiene que llegar a una buena funcionalidad,  usabilidad y que le genere cierto tipo placer al usuario.  En proyectos  de desarrollo de software  es un poco  complejo alcanzar estos tres niveles,  porque es un proyecto de alta complejidad, donde están involucradas empresas, modelos de negocios, procesos y personas  que tienen diferentes formas de pensar, de sentir, y mirar un producto. En un proyecto de software la funcionalidad y usabilidad la puede proporcionar el sistema, pero que genere cierto placer  es un reto porque está condicionado a lograr un  beneficio mutuo entre los participantes del sistema.

Chapter 5. Achieving Qualities

5.1 Introduccing Tactics

En todo proyecto que desee desarrollar ya sea a nivel de software, o de cualquier otra area, siempre habra que utilizar tacticas a la hora de enfrentar las condiciones que nos exige tal proyecto.

Por eso es importante utilizar tacticas de diseño, las cuales son una decision que influye en el control de una respuesta de un atributo de calidad del proyecto. Las tacticas en el area de la arquitectura de software son decisiones que aseguran el logro de la funcionalidad del sistema en su totalidad.

Al hacer uso de una buena tactica puede que se le de beneficio a  un atributo de calidad en particular pero tambien puede que se afecte otro  atributo de calidad, como se indica en el ejemplo del libro si se queiere añadir mas disponibilidad al sistema se tendra que recrurrir a la redundancia lo cual sacrificaria el rendimiento al tener dicha redundancia.

Como se puede observar a veces tales decisiones generan conflicto entre si y habra que  elegir la que mejor le  convenga al sistema. Tambien se pueden ver que los requerimientos del sistema entran en tal conflicto como por ejemplo se pueden elevar los costos del presupuesto pronosticado si se modifica un atributo de calidad, asi como tambien el teimpo de entrega.

En conclusión creemos que una buena arquitectura es  aquella en la cual se combina tacticas que no permitan al sistema satisfacer todas sus necesidades.

5.2 Availability Tactics

Las tácticas de disponibilidad son las que nos llevan a la detección y prevención de fallos y a su recuperación. En la parte de detección de fallos es importante saber como detectarlos en un sistema distribuido que no es fácil ya que tenemos recursos compartidos, debemos hacerlos de una forma que no ocupemos mucho ancho de banda y su procesamiento sea de poco consumo, otra forma es una interrupción de comunicación.

En la parte de recuperación de errores debe ser lo mas rápida posibles y es adaptable o utilizable de acuerdo a la arquitectura planteada o el caso especifico donde se presente los fallos, en esta parte de recuperación generalmente se tiene redundancia de datos, comunicaciones, información e inclusive de mensajes, como también es super importante tener una bueno y constante sincronizacion del sistema.

Por ultimo la prevención de fallos la cual es una tarea importante y una de las mas complicadas, tratar de que un sistema no tenga fallos es muy complicado, así su porcentaje sea menos de 1%, un sistema siempre aparecerá con un fallo que tal vez nunca pensaríamos que llegara a pasar, algunas medidas son reinicio de sistema para evitar fallos, perdidas de memoria y/o datos, otras recurren a revisar las transacciones y volver a enviar donde fallo y hacer seguimientos de los mismos.

CHAPTER 3. VIEWPOINTS AND VIEWS DEL LIBRO SOFTWARE SYSTEM ARCHITECTURE

En la arquitectura tradicional de estructuras los planos constituyen el elemento mas importante para dar una visión anticipada y detallada de una estructura determinada, asi como es de importante los planos en la arquitectura también lo es en la arquitectura de software, dichos planos tienen por nombre “vistas”, la cual muestra una visión e interaccion de una parte del sistema.

Una vista en términos básicos, de acuerdo a la definición del estándar 1471 de la IEEE, es la siguiente:

‘Una vista es una representación de un sistema completo  desde la perspectiva de un conjunto de concerns relacionados’

 Con el pasar de los años los sistemas de software han sido más complejos  y  la necesidad de anticiparse a la especificación detallada del sistema y de tener un mayor aprovechamiento de los  recursos se hace más evidente, estos aspectos entre otros son capturados por las vistas arquitectonicas. 

El análisis de  las  vistas que  contribuye a mejorar esas decisiones tempranas del diseño, lo cual se materializa en la gestión de los modelos de las  estructuras arquitectónicas

En resumen una vista es una representación de uno o más aspectos  que muestran como la arquitectura se ocupa de uno o más de los intereses de los stakeholders.

El objetivo principal  de un tipo de vista es proporcionar una librería de plantillas y patrones que puedan ser usados como la guía para la creación de vistas, ya que no sería práctico que cada vez que se definiera una vista se tuviera que especificar el tipo de contenido, guías, principios y modelos para su elaboración.

Un catálogo de los tipos de vistas puede ser el siguiente:

• Funcional: Permite describir los elementos funcionales del sistema en su totalidad, sus responsabilidades, interfaces e interacciones .

• Información: Muestra la manera en la que la arquitectura guarda, manipula, administra y distribuye la  información en el sistema.

• Concurrencia: Describe la funcionalidad y comportamiento de la  concurrencia de un sistema e identifica los elementos que se pueden ejecutar concurrentemente y la manera en que son coordinados y ejecutados.

• Desarrollo: Permite describir la arquitectura que soporta el proceso de desarrollo de software.

• Deployment: Nos da informacion acerca del ambiente dentro del cual el sistema será instalado.

• Operacional: Se refiere a la manera en la que el sistema será operado, administrado y soportado cuando sea lanzado en el ambiente de producción.

Esta figura  muestra las diferentes  relaciones entre los tipos de vistas de una arquitectura de software.

Fuentes:

http://standards.ieee.org/findstds/standard/1471-2000.html

http://web.cs.du.edu/~snarayan/sada/architecture/SW-SystemsArch-WorkingwithStakeholdersUsi.pdf

Chapter 4 ARCHITECTURAL PERSPECTIVES

Perspectivas Arquitectónicas

Como sabemos la seguridad es uno de los perspectivas mas importantes por que por medio de esta podemos hacer buenas autenticaciones de usuarios, tener una buena protección contra intrusos, pero como sabemos es uno de los aspectos mas duros y complejos pero interesantes a mi punto de vista. Otro aspecto importante de la seguridad es que debe controlar el acceso al CRUD (create, read, update, delete), también debe hacer buena distribucion y control de claves de acceso y contraseñas; y que la seguridad siempre varia de acuerdo a las aplicabilidades del sistemas y su configuracion arquitectonica.

Las perspectivas arquitectónicas hacen referencia a las capas o sub-capas de una arquitectura y algunas de estas son la seguridad, escalabilidad, rendimiento, disponibilidad, evolución regulación, las cuales se relacionan con unos puntos de vista que el arquitecto de software tiene que identificarlos segun sea las necesidades y arquitectura del sistema.

tomado de: http://www.kaltenbach.com/files/software_komb.jpg

Cuando aplicamos una perspectiva arquitectónica es para hacer una mejora en los aspectos de calidad o hacer cambios modelos a desarrollar.

Uno de los aspectos importantes y esenciales para que la arquitectura, la estructura funcione son las relaciones o las interrelaciones entre los componentes del sistemas; es aquí donde la comunicación entre los elementos se fundamenta y complementan unos con otros para que la arquitectura en conjunto con las vistas, perspectivas, y puntos de vista conforme el sistema para cumplir el objetivo para el cual fue desarrollado y el modo por el cual se desarrollo.

Relaciones de los Elementos del sistemas. Sacado del libro Sofware System Arquitecture. Chapter 4. Pagina 48.

En conclusión podemos decir que es beneficioso el uso de perspectivas en las arquitecturas debido a que  podemos ver todos los puntos de vistas del sistema, podemos ver los posibles fallos y describir acciones del sistema, como rendimiento, también para demostrar que el sistema cumple con los requisitos para los cuales fue creado y que en si todo el sistemas incluyendo la arquitectura va a funcionar adecuadamente o si no realizar las correcciones o cambios que lleven a la mejora.

Atributos de Calidad!!

¿¿Funcionalidad - Arquitectura - Atributos - Escenarios??

Conseguir un rendimiento extremadamente rápido no es posible, lo que si es posible diseñar una arquitectura que cumpla con su funcion para la cual fue creada de una forma rapida, eficiente y eficaz en donde varios componentes o sub-sistemas interrelacionados colaboren en la realización de la función.

Los atributos de calidad debemos tenerlos en cuenta al momento de diseñar una arquitectura de software pero es aquí donde esos atributos son diferentes de acuerdos a las prioridades y necesidades del proyecto y/o servicio para la cual se hace uso del sistema.

Cuando nos refiramos a los atributos de calidad tenemos que tener en cuenta que estos siguen una determinadas "reglas" o pasos que no siempre se pueden cumplir según sea el escenario donde se van a aplicar estos atributos de calidad, también tenemos que tener en cuenta que dependiendo de cada estimulo se puede tener diferentes soluciones lo cual me parece que el arquitecto tiene que darse cuenta de este tipo de situaciones.

En mi opinión el arquitecto nunca va ha seguir unos pasos determinados para hacer escenarios y añadir atributos de calidad pero si debe tener en cuenta algunos detalles que se especifiquen según las modificabilidades o funciones de cada sistema.

Como ya sabemos existen varios escenarios de calidad y que cada uno de estos pueden ser tan importante como cualquier otro pero su importancia depende de las necesidades del sistemas, los requerimientos, la disposición, la modificabilidad, el rendimiento, la seguridad, usabilidad pero todo esto no es posible si no existe una comunicación clara y exacta entre los escenarios que es otro de los aspectos que debe tener en cuenta un arquitecto de software, ademas que cada escenario interactua con diferente y muchos atributos ademas recordemos que cada tipo de escenario usa su modo de comunicación para interactuar con los atributos que a su vez son las mismas funcionalidades básicas, intermedias y avanzadas que puede hacer el sistema.

Por nuestra parte algo que nos gusto y nos llamo la atención es que el uno de los capítulos dice "otros atributos de calidad" es algo que el arquitecto de software pueda usar e implementar dependiendo las necesidades del sistemas porque los atributos convencionales no siempre llegan a cumplir o cubrir con todo lo que pide el sistema en desarrollo.

La arquitectura de software se tiene que centrar y apuntar hacia el negocio y este a la vez  debe poseer unas cualidades que la hagan un producto de calidad.

Por ejemplo si se analiza el caso de Twitter. ¿Por qué es tan sencillo y lo utilizan muchas personas? Básicamente, porque es usable (en este caso amigable y simple) y tiene un corto tiempo de respuesta para el usuario (performance). ¿Qué pasa con la disponibilidad? ¿Twitter funciona 24 horas los siete días de la semana? La respuesta es no.

Cuando queremos hacer algo que pone en riesgo el rendimiento de Twitter, aparece una pantalla con un mensaje que nos explica que “Twitter sobrepasó su capacidad”), lo cual indica que el sitio no se cayó, pero, en ese momento, no se puede operar. No obstante, no hay dudas de que, cuando está bien, es rápido y usable. Ahora, ¿qué pasaría si Twitter permitiera 50.000 caracteres en vez de 140? ¿Qué impacto cree que tendría en la performance? ¿En la disponibilidad? ¿Y en la facilidad de uso?

Para crear una aplicación de tal magnitud y que cumpla estas características se pensó y enfoco en el negocio unas cualidades muy fundamentales como:

Tiempo de comercialización: El tiempo de desarrollo es un elemento crucial a lo hora de tener un producto con calidad.

Costo y beneficio: No se debe superar los costos presupuestados.

Vida proyectada del sistema: Si el sistema va a tener una vida útil larga, debe cumplir con los siguientes parámetros: modificabilidad, escalabilidad y portabilidad.

Mercado de destino: Determinar para quien va dirigido el producto.

Plan de puesta en servicio: En particular, el sistema debe construirse con la facilidad de expansión y contracción en mente.

                  Fuente:  http://www.ieee.org.ar/downloads/2006-Naveda-Arquitecturas.pdf

Además de las cualidades del sistema y cualidades relacionadas con negocio de  la organización en el que se está desarrollando el sistema, también hay cualidades directamente relacionados con la arquitectura que son importantes para alcanzar.

       

Integridad Conceptual: Es la consideración más importante durante la fase de desarrollo, por lo cual tiene que ser correcto y unificar o integrar el diseño del sistema en todos los niveles.

Exactitud e integridad: Son elementos  muy importantes para la arquitectura para que todos los requisitos del sistema deban cumplirse

Edificabilidad: Siempre estar abierto a cambios y que sean de fácil aplicación.

¿Qué es la Arquitectura de Software?

Siempre que escuchamos la palabra arquitectura imaginamos una estructura, un conjunto de componentes, no es errónea pero si una idea vaga, la arquitectura es diseño, interrelación entre todos sus componente, la comunicaciones entre todos, para que la infraestructura funcione, pero también es importante destacar que no siempre podemos seguir las reglas al pie de la letra, porque el momento de modelar, diseñar y relacionar, un arquitecto de software tiene que hacerlo de acuerdo a las necesidades o criterios para que en el momento de ejecución todo funcione con los mínimos errores.

La arquitectura de software se define como los elementos que la componen, estos elementos no siempre siguen una estructura u orden, podemos decir que cada componente, cada elemento es un mini-sistemas que está en la capacidad de saber, conocer, interactuar con los otros elementos para poder hacer de un sistemas un sistema eficiente, eficaz y que cumpla con los objetivos para los cuales fue realizado.

La arquitectura de software es una representación de lo que puede hacer o es realmente un sistema real, por eso desde mi punto de vista es muy importante que en el momento del análisis se realicen todas las consultas y averiguaciones posibles para que nuestra arquitectura no haga del sistema un sistema aislado, antes de empezar con el diseño y modelamiento de nuestro software eso es lo que espero que podamos realizar más adelante, o al menos a comprender y tratar de entender la complejidad de la arquitectura de software.

Saber que el diseño de una arquitectura está relacionado con un conjunto de unidades de módulo de muchos módulos, que también posee sistemas de estructura, conectores y que el sistema se relaciona con las diferentes estructuras y modelos para hacer un buen sistemas, por tal razón hay que hacer uso de unas “guias”, documentación y tipos de organización para hacer de nuestras estructura arquitectónica de software un buen conjunto de sistema.




Aquí les dejo un video que nos parecio interesante....

Capitulo 3 del libro System Architecture in Practice CASO Avionics.

Nos parece que el caso de estudio que se expone en el capítulo 3 del libro, es un buen ejemplo para  poder estudiar y analizar con detalles  las principales estructuras arquitectónicas aplicadas  a una problemática real que en este caso es relacionada con  el área de la aviación.

Las personas que se involucraron en  el desarrollo del software A-7E utilizaron una táctica muy buena  a nuestro parecer, ya que  desmenuzaron y analizaron el problema planteado desde tres partes fundamentales. La primera de ellas fue descomponer el problema en módulos, luego analizaron los usos y sus procesos. Estas 3 estructuras se complementan entre sí pare entregar una imagen  completa de cómo funciona el sistema, sus principales módulos, interacciones, funciones y  escalabilidad. Para esto se basaron en estrategias utilizadas en la ingeniería de software para obtener óptimos resultados en plazos establecidos.

Entre los principales requisitos exigidos para desarrollar el software,   fueron los siguientes:

• Ayudar al piloto con la navegación, control de armas  del avión así como  ubicación exacta de objetivos a distancia.

• El software debe alimentarse de las lecturas de  los sensores del avión para entregar una información entendible al piloto en la cabina.

• Debe poseer un diseño modular, para que en futuros cambios, sea  fácil realizarlo sin comprometer a todo el sistema.

Este equipo de desarrolladores equilibraban su tiempo entre la invención de nuevos métodos de ingeniería de software, el  conocimiento en el campo de la aviación, documentación de los procesos llevados a cabo y producción del software.

Aunque ya han pasado muchos años desde que se aplico esta forma de enfrentar un problema relacionado con el desarrollo de una aplicación de esta magnitud, creemos que estos señores fueron  pioneros y sentaron  las bases de la arquitectura de software,  al poder definir subconjuntos de forma rápida y sencilla para organizar y diagramar el sistema. Otra parte interesante fue la fase de ejecución del  software, en el cual inicialmente se implemento un pequeño subconjunto de la aplicación y verificar su óptimo funcionamiento, para luego implementarle subconjuntos más grandes  y así poder obtener el sistema en su totalidad.

Creemos que para realizar una buena arquitectura de software se tiene que pensar en dividir el trabajo en unidades  más pequeñas o módulos y analizar cómo van a interactuar,  Una de las más grandes, es poder brindar una arquitectura correcta para solucionar el problema que se está desarrollando. Esto conlleva a definir y documentar la misma, asegurándose que este en relación con el sistema que se desea, y a la vez que sea la mejor forma de brindar soporte y evolución del mismo.

Otro tipo de responsabilidad es la de asegurarse que todas las personas involucradas estén  utilizando la arquitectura proporcionada y que el desarrollo del proyecto marche bien. Esto  es para poder resolver cualquier tipo de inquietud  que surja, que esté relacionada con la  selección de herramientas en cada uno de los ambientes de desarrollo.  Uno de los factores positivos de las responsabilidades, es resolver conflictos y a la vez ayudar a generar acuerdos, manteniendo una moral en el grupo que abarca a los designados a la arquitectura

Fuentes:

http://www.tec.url.edu.gt/boletin/URL_19_SIS02_COMPETENCIAS.pdf

http://www.acis.org.co/index.php?id=537

http://www.acis.org.co/memorias/JornadasGerencia/IJNGP/estamosLocos.pdf