Métodos tradicionales y de diseño

 

1°. Métodos tradicionales y de peso completo -CMM, UPM.

En 1991, el instituto de ingeniería de software (SEI) publicó el modelo de capacidad de madurez (CMM) dicho modelo está orientado a la mejora de los procesos relacionados con el desarrollo de software para lo cual contempla la consideradas mejores prácticas de ingeniería de software y de dirección.

A mediados de la década del 90, el SEI decide unificar los modelos de ingeniería de software (SW-CMM), de ingeniería de sistemas (SE-CMM) y de su desarrollo integrado de productos (IPD- CMM) embarcándose en un esfuerzo que culmina en el año 2002 dando origen a una nueva generación llamada CMMI (Capability Maturity Model Integration). El nuevo CMMI brinda un marco con una estructura común para todas las disciplinas (ingeniería de software, ingeniería de sistemas etc.) E incorpora una forma de representación llamada Continua (tomada de IPD-CMM y SE-CMM), orientada a medir la mejora en los procesos de manera individual en vez de hacerlo de manera conjunta como la representación por niveles del modelo original.

El modelo Capability Maturity Model (CMM), también denominado CMM-SW, fue desarrollado por el SEI como marco de referencia de procesos software.

mejora continua del servicio el modelo de madurez de capacidad para software, también conocido como cmm y sw-cmm, es un modelo utilizado para identificar las mejores prácticas para ayudar a aumentar la madurez del proceso cmm fue desarrollado en ingeniería de software

Se actualizo como CMMI (Modelo de Integración de Madurez de la Capacidad). El SEI ha dejado de mantener el modelo SW-CMM, sus métodos asociados de evaluación y material de formación.

2°. Métodos de análisis y diseño en el ciclo de vida.

Los sistemas de software requieren un tiempo y esfuerzo considerable para su desarrollo y deben permanecer en uso por un periodo mucho mayor. Durante este tiempo de desarrollo y uso, desde que se detecta la necesidad de construir un sistema de software hasta que este es retirado. Se identifican varias etapas que en conjunto se denominan el ciclo de vida del software y en cada caso, en función de cuales sean las características del proyecto, se configurará el ciclo de vida de forma diferente. Usualmente se consideran las etapas:

Especificación y análisis de requisitos

Diseño del sistema

Implementación del software

Aplicación y pruebas, entrega y mantenimiento.

Un aspecto esencial dentro de las tareas del desarrollo del software es la documentación de todos los elementos y especificaciones en cada fase. Dado que esta tarea siempre estará influida por la fase del desarrollo en curso, se explicará de forma distribuida a lo largo de las diferentes fases como un apartado especial para recalcar su importancia en el conjunto del desarrollo del software.

El objetivo de este flujo de trabajo es Traducir los requisitos a una especificación que describe Cómo implementar el sistema.

Los objetivos del análisis y diseño son:

* transformar los requisitos al diseño del futuro sistema.

* adaptar el diseño para que sea consistente con el entorno de implementación, diseñado para el rendimiento.

El análisis consiste en obtener una visión del sistema que se preocupa de ver qué hace, de modo que solo se interesa por los requisitos funcionales. Por otro lado, el diseño es un refinamiento del Análisis que tiene en cuenta los requisitos no funcionales, En definitiva, como cumple el sistema sus objetivos.

Al principio de esta fase de elaboración hay que definir una arquitectura candidata: crear un esquema inicial de la arquitectura del sistema, identificar clases de análisis y actualizar las relaciones de los casos de uso con las interacciones de las clases de análisis. Durante la fase de elaboración se va refinando esta arquitectura hasta llegar a su forma definitiva. En cada iteración hay que analizar el comportamiento para diseñar componentes. Además, si el sistema usará una base de datos, habrá que diseñarla también,  obteniendo un modelo de datos.

El resultado final más importante de este flujo de trabajo será el modelo de diseño. Consiste en colaboraciones de clases, que pueden ser agregadas en paquetes y subsistemas.

Otro producto importante de este flujo es la documentación de la arquitectura del software que captura varias vistas arquitectónicas del sistema

Análisis: durante el análisis. Analizamos los requisitos que se describieron en la captura de requisito refinándolos y estructurándolos. El objetivo de hacerlo es conseguir una comprensión más precisa de los requisitos y una descripción de los mismos que sea fácil de mantener y que nos ayude a estructurar el sistema entero incluyendo su arquitectura.

El lenguaje que utilizamos en el análisis se basa en un modelo de objetos conceptual que llamamos modelo de análisis. El modelo de análisis nos ayuda a refinar los requisitos.

 Diseño: Durante el diseño modelamos el sistema y su arquitectura para que soporte los requisitos funcionales y no funcionales. Una entrada esencial al diseño es el modelo de análisis.

3°. Arquitectura basada en escenarios (FAAM, ALMA).

Architecture Level Modifiability Analysis (ALMA)

El atributo de calidad que analiza ALMA, es la facilidad de modificación. Esto se refiere a la capacidad de un sistema para ser ajustado debido a cambios en requerimientos, o en el entorno, así como la adición de nueva funcionalidad

Existen tres para las que se puede usar:

•Predicción del costo de mantenimiento.

•Evaluación de riesgos.

•Selección de un conjunto de arquitecturas.

FAAM

FAAM es una Organización que nace en 1987 con objeto de coordinar el trabajo de distintas asociaciones y trabajar para conseguir la inclusión y normalización de las personas con discapacidad física y orgánica en todos los ámbitos de la sociedad. En FAAM identifican tres áreas de actuación: la atención social, la comunicación y el fortalecimiento de su tejido asociativo.

Con más de 30 años de historia, la Federación ha ido creciendo y evolucionando en su actividad. Sin embargo, la anterior web no reflejaba las fortalezas de su Organización ni muestra, de una forma sencilla e intuitiva, los proyectos y entidades a las que da soporte.

Desde el punto de vista funcional, se ve necesario trabajar la narrativa y estructura (arquitectura de información) para que, de una manera sencilla la web comunique la actividad, los proyectos y sus líneas de negocio.

Los objetivos identificados son:

1.          Construir una web que sirva de repositorio y traslade la imagen real de FAAM, que trabaje al servicio del área de Comunicación de la Federación.

2.          Diseñar una solución que favorezca la escalabilidad y la incorporación de nuevas asociaciones, formaciones, proyectos, noticias y otras actividades de la Federación.

3.          Asegurar la autonomía del departamento de Sistemas y Comunicación con la nueva web.

4.          Desde el punto de vista técnico, construir la web bajo protocolos de seguridad, con criterios de posicionamiento orgánico, de usabilidad y de accesibilidad. Asegurar la transición de la web actual a la nueva, a través de una estrategia de posicionamiento y redireccionamiento SEO. Una web que esté preparada para Google y los buscadores de Internet.

4°. Diseño arquitectónico en el ciclo de vida ABD.

ABD Arquitectura e Ingeniería se ha puesto como meta diseñar hoy la arquitectura de mañana. Conjugamos un diseño moderno e inconfundible, la gestión profesional de los proyectos y la experiencia de muchos años. El éxito obtenido en numerosos proyectos y la calidad de nuestras competencias nos avala.

El factor diferencial de ABD Arquitectura e Ingeniería

Construir con nosotros, es una apuesta por:

Una clara comprensión de la arquitectura

Un equipo creativo y experimentado

Bases flexibles y adaptadas a cada proyecto

Una amplia oferta de servicios

Gestión de la calidad comprobada

El aprendizaje basado en el diseño (ABD o DBL, Design-based learning), es una forma de enseñanza reflexiva, o pedagogía, basada en la integración del pensamiento propio del diseño y del proceso de diseño en la sala de clases. Espacios de aprendizajes basados en el diseño pueden ser encontrados a través de varias disciplinas, incluyendo aquellas tradicionalmente asociadas al diseño (e.g. artes, arquitectura, ingeniería, diseño de interiores, diseño gráfico), como también aquellas que no son normalmente relacionadas con el diseño (ciencia, tecnología, negocios, humanidades). ABD, como también aprendizaje basado en proyectos y aprendizaje basado en problemas, es usada para enseñar habilidades tales como comunicación y colaboración y fomentar el aprendizaje profundo.

El aprendizaje profundo es fomentado cuando los estudiantes diseñan y crean un artefacto que requiere comprensión y aplicación del conocimiento. El ABD apoya el proceso de Iteración mientras los estudiantes crean, evalúan, y rediseñan sus proyectos. La complejidad del trabajo a menudo requiere colaboración y roles especializados, proveyendo a los estudiantes con la oportunidad de convertirse en "expertos" en un área particular. El diseño de proyectos requiere que los estudiantes establezcan metas y restricciones, generen ideas, y creen prototipos a través de un Guion gráfico u otras técnicas de representación. Las competencias de Robótica en escuelas son una popular actividad de aprendizaje basado en el diseño, en las cuales los equipos de estudiantes diseñan, construyen y luego controlan a sus robots en retos competitivos.

El aprendizaje basado en el diseño fue desarrollado en los 1980s por Doreen Nelson, profesor perteneciente a la Universidad Estatal Politécnica de California y al Art Center College of Design. Sus descubrimientos sugieren que la resolución de problemas kinésicos ayudan a los estudiantes a adquirir, retener y sintetizar información en formas prácticas.

5°. Intermediate Design ARID.

De los métodos de evaluación de arquitectura de software existente el ARID, es conveniente para realizar la evaluación de diseños parciales en las etapas tempranas del desarrollo. En ocasiones, es necesario saber si un diseño propuesto es conveniente, desde el punto de vista de otras partes de la arquitectura. ARID es un híbrido entre Revisión Activa del Diseño (Active Design Review, ADR) y ATAM.

Por su parte el ADR es utilizado para la evaluación de diseños detallados de unidades de software como los componentes o módulos. Las preguntas giran en torno a la calidad y completitud de la documentación y la suficiencia, el ajuste y la conveniencia de los servicios que provee el diseño propuesto.

Tanto ADR como ATAM proveen características útiles para el problema de la evaluación de diseños preliminares, dado que ninguno por sí solo es conveniente. En el caso de ADR, los involucrados reciben documentación detallada y completan cuestionarios, cada uno por separado. En el caso de ATAM, está orientado a la evaluación de toda una arquitectura.

Ante esta situación, y la necesidad de evaluación en las fases tempranas del diseño; la utilización de las características que proveen tanto ADR como ATAM por separado. De ADR, resulta conveniente la fidelidad de las respuestas que se obtiene de los involucrados en el desarrollo.

Así mismo, la idea del uso de escenarios generados por los involucrados con el sistema es tomada del ATAM. De la combinación de ambas filosofías surge ARID, para efecto de la evaluación temprana de los diseños de una arquitectura de software.

Funcionamiento

El método ARID consta de los siguientes pasos:

Fase1: Actividades Previas.

1. Identificación de los encargados de la revisión. Los encargados de la revisión son los ingenieros de software que se espera que usen el diseño, y todos los involucrados en el diseño. En este punto, converge el concepto de encargado de revisión de ADR e involucrado del ATAM.

2. Preparar el informe de diseño. El diseñador prepara un informe que explica el diseño. Se incluyen ejemplos del uso del mismo para la resolución de problemas reales. Esto permite al facilitador anticipar el tipo de preguntas posibles, así como identificar áreas en las que la presentación puede ser mejorada.

3. Preparar los escenarios base. El diseñador y el facilitador preparan un conjunto de escenarios base. De forma similar a los escenarios del ATAM y el SAAM, se diseñan para ilustrar el concepto de escenario, que pueden o no ser utilizados para efectos de la evaluación.

4. Preparar los materiales. Se reproducen los materiales preparados para ser presentados en la segunda fase. Se establece la reunión, y los involucrados son invitados.

Fase 2: Revisión.

5. Presentación del ARID. Se explica los pasos del ARID a los participantes.

6. Presentación del diseño. El líder del equipo de diseño realiza una presentación, con ejemplos incluidos. Se propone evitar preguntas que conciernen a la implementación o argumentación, así como alternativas de diseño. El objetivo es verificar que el diseño es conveniente.

7. Lluvia de ideas y establecimiento de prioridad de escenarios. Se establece una sesión para la lluvia de ideas sobre los escenarios y el establecimiento de prioridad de escenarios. Los involucrados proponen escenarios a ser usados en el diseño para resolver problemas que esperan encontrar. Luego, los escenarios son sometidos a votación, y se utilizan los que resultan ganadores para hacer pruebas sobre el diseño.

8. Aplicación de los escenarios. Comenzando con el escenario que contó con más votos, el facilitador solicita el pseudo-código que utiliza el diseño para proveer el servicio, y el diseñador debe ayudar en esta tarea.

Este paso continúa hasta que ocurra alguno de los siguientes eventos:

•           Se agota el tiempo destinado a la revisión.

•           Se han estudiado los escenarios de más alta prioridad.

El grupo se siente satisfecho con la conclusión alcanzada. Puede suceder que el diseño presentado sea conveniente, con la exitosa aplicación de los escenarios, o por el contrario, no conveniente, cuando el grupo encuentra problemas o deficiencias.

6°. Quality Attribute workshops QAW QASAR.

El QAW es un método facilitado que incorpora a los involucrados en un sistema de manera temprana en el ciclo de vida para descubrir los requerimientos que controlan los atributos de calidad de un sistema intensivo en software. Los puntos clave acerca del QAW son que es centrado en el sistema enfocado a los involucrados utilizado antes que la arquitectura de software sea creada basado en escenarios Controladores de Negocio Plan arquitectónico QAW.

Atributos de Calidad y Arquitectura El grado para el cual un sistema cumple sus requerimientos de atributos de calidad es dependiente de las decisiones arquitectónicas. Arquitectura del Sistema: La estructura fundamental y unificante del sistema en términos de elementos del sistema, interfaces, procesos, restricciones y comportamientos. Arquitectura del Software: La estructura de estructuras del sistema, la cual comprende elementos de software, las propiedades externamente de aquellos elementos y las relaciones entre ellos.

Fases del QAW El QAW ocurre en tres fases Nos enfocaremos en la fases

1 Fase 0: Preparación Fase 1:

Conducción Fase 2: Reporte

Duración: varía Junta: principalmente por teléfono, correo electrónico Duración: 1 a 1.5 días Junta: por lo regular conducida en el sitio del cliente Duración: varía Junta: principalmente por teléfono, correo electrónico.

Ejemplo de una Agenda de QAW Tiempo 8:30 AM 10:30 AM 12:00 AM 1:00 PM 1:30 PM 4:30 PM 5:00 PM Bienvenida y presentaciones Presentación del QAW Presentación del Negocio/Misión Presentación del Plan arquitectónico Identificación de los controladores Arquitectónicos Identificación de escenarios por lluvia de ideas Comida de trabajo Consolidación de escenarios Priorización de escenarios Refinamiento de escenarios Cierre Revisión de escenarios Elementos de acción Fin Actividad.

Roles de QAW Conductor del QAW: El conductor facilita la discusión y asegura que el método sea llevado a cabo en una forma oportuna y que sean producidos los artefactos del QAW. Anotador del QAW: El anotador registra los escenarios preliminares, su priorización, los escenarios refinados y cualquier aspecto relevante que surja durante el taller. Involucrados: Los involucrados proponen escenarios, analizan escenarios propuestos por otros, proponen consolidación, priorizan y refina escenarios. Representantes del Negocio: Los representantes del negocio presentan los controladores de negocio/misión y asignan metas de negocio a los escenarios refinados. Arquitectos: Los arquitectos presentan los planes arquitectónicos y discuten el enfoque arquitectónico conforme sea necesario.

7°. Attribute driven design ADD.

Attribute Driven Design (ADD) es un método que mediante el análisis de los atributos de calidad definidos en la fase de requerimientos, obtiene una arquitectura inicial del sistema, identificando módulos, componentes y conectores.

El método ADD es un enfoque a la definición de una arquitectura de software en el que se basa el proceso de diseño de los requisitos del software de atributos de calidad. ADD es un proceso de diseño recursivo que descompone un sistema o elemento del sistema mediante la aplicación de tácticas arquitectónicas [Bass 03] y los patrones que satisfacen los drivers. ADD sigue esencialmente el ciclo “Plan, Do, and Check”: Este proceso se repite hasta que todos los requisitos de gran importancia arquitectónica se cumplen.

Paso 1: Confirmar que existe suficiente información sobre los requerimientos

 ¿Que se hace en el paso 1?

En el primer paso, usted confirma que hay suficiente información acerca de los requisitos para proceder con el paso 2. En esencia, se asegura que los stakeholders han dado prioridad a los requisitos de acuerdo a los objetivos de negocio y a la misión. También debe confirmar que se dispone de información suficiente sobre los atributos de calidad para proceder.

Como arquitecto, se debe priorizar la lista de requerimientos para determinar en qué elementos del sistema se deben concentrarse durante el diseño. Se deben considerar los requisitos y su impacto potencial en la estructura de la arquitectura, en orden descendente de importancia para los stakeholders. Los requisitos que no han sido priorizadas deberán ser marcados y devueltos a para su clasificación.

Además, se debe determinar si existe suficiente información acerca de los atributos de calidad del sistema. Cada atributo de calidad debe ser expresado de la forma "estímulo-respuesta", de la misma manera como escenarios de atributos de calidad [Bass 03]. Each requirement should be described as the system’s measurable quality attribute response to a specific stimulus with the following made explicit:

• Estímulo fuente

• Estímulo

• Artefacto

• Entorno

• Respuesta

• Respuesta de medida

Conocer esta información para cada atributo de calidad ayuda al arquitecto para seleccionar varios patrones de diseño y tácticas para lograr esos requisitos. Si esta información no está disponible, usted debe crear requisitos derivados o trabajar con los interesados para aclarar los requisitos. En cualquier caso, los escenarios de atributos de calidad se puede utilizar para documentar estos requisitos.

¿Qué decisiones de diseño se toman durante el paso 1?: No se toman decisiones de diseño durante este paso.

Paso 2: Seleccionar un elemento del sistema para descomponer

¿Qué se hace en el paso 2?

En este segundo paso, se debe elegir qué elemento del sistema será el enfoque de diseño en los pasos subsiguientes (el elemento con el cual se va a trabajar). Se puede llegar a este paso en una de las siguientes dos maneras:

•           Caso 1: Primera iteración. Si se accede por primera vez a la Etapa 2 como parte de una "nueva creación" de desarrollo. El único elemento que puede descomponerse es el propio sistema. Por defecto, todos los requisitos son asignados a ese sistema.

•           Caso 2: Más de una iteración. Se están perfeccionando un sistema parcialmente diseñado y se ha visitado el paso 2 anteriormente. En este caso, el sistema se ha dividido en dos o más elementos, y los requisitos han sido asignados a estos elementos.

Autor: Eliezer Braca