martes, 24 de julio de 2012


Documentación
La documentación es la debilidad más frecuente en productos e instalaciones informáticos. Los actores que intervienen en el ciclo de vida del software desempeñan diversos roles. Arquitectos, diseñadores, analistas, programadores, implementadores, administradores o auditores son quienes explicitan distintos aspectos de los productos y procesos.

El código fuente del software, la estructura de datos y los enlaces de comunicaciones constituyen en conjunto el paradigma de la documentación informática. Sin embargo, cuando los modelos de arquitectura, estructuras y especificaciones de diseño no los vinculan, sólo pueden acceder a éstos dificultosamente los iniciados. Hay buenas prácticas para escribir código fuente pero, las condiciones y circunstancias de cada programa y sistema son tan diversas que, las exigencias habituales se reducen a que funcione razonablemente.

Artefactos

 De acuerdo con RUP, es una pieza de información producida, modificada o utilizada por un proceso. Artefacto son los productos tangibles del proyecto, las cosas que los proyectos producen o utilizan mientras se trabaja hacia el producto final. Los artefactos son insumos utilizados para realizar actividades y, son los resultados de estas actividades.

Son artefactos entregables como ejecutables, el código fuente, manuales, planes y proyectos. Productos intermedios, como documentos de arquitectura y diseño, especificaciones de requerimientos, modelos de negocios y casos de uso. De igual forma, son artefactos los elementos que componen los modelos y productos, como glosarios y diccionarios, gráficos, clases o subsistemas. También, en negocios regulados, son artefactos los instrumentos y evidencias de la gestión informática.

Documentación
La documentación es la debilidad más frecuente en productos e instalaciones informáticos. Los actores que intervienen en el ciclo de vida del software desempeñan diversos roles. Arquitectos, diseñadores, analistas, programadores, implementadores, administradores o auditores son quienes explicitan distintos aspectos de los productos y procesos.

El código fuente del software, la estructura de datos y los enlaces de comunicaciones constituyen en conjunto el paradigma de la documentación informática. Sin embargo, cuando los modelos de arquitectura, estructuras y especificaciones de diseño no los vinculan, sólo pueden acceder a éstos dificultosamente los iniciados. Hay buenas prácticas para escribir código fuente pero, las condiciones y circunstancias de cada programa y sistema son tan diversas que, las exigencias habituales se reducen a que funcione razonablemente.

Artefactos

 De acuerdo con RUP, es una pieza de información producida, modificada o utilizada por un proceso. Artefacto son los productos tangibles del proyecto, las cosas que los proyectos producen o utilizan mientras se trabaja hacia el producto final. Los artefactos son insumos utilizados para realizar actividades y, son los resultados de estas actividades.

Son artefactos entregables como ejecutables, el código fuente, manuales, planes y proyectos. Productos intermedios, como documentos de arquitectura y diseño, especificaciones de requerimientos, modelos de negocios y casos de uso. De igual forma, son artefactos los elementos que componen los modelos y productos, como glosarios y diccionarios, gráficos, clases o subsistemas. También, en negocios regulados, son artefactos los instrumentos y evidencias de la gestión informática.

Estándares de Calidad del Software
La obtención de un software de calidad, implica la utilización de metodologías o procedimientos estándares, para el diseño, análisis, diseño, programación y prueba del software.
Los Estándares de Calidad ISO para Desarrollo de Software

El Estándar de Calidad ISO 9001

El estándar, que ha sido adoptado por más de 130 países para su uso, se está convirtiendo en el medio principal con el que los clientes pueden juzgar la competencia de un desarrollador de software. Uno de los problemas con el estándar ISO 9001 está en que no es específico de la industria: está expresado en términos generales, y puede ser interpretado por los desarrolladores de diversos productos como secadores de pelo, automóviles, equipamiento deportivo, televisores, así como por los desarrolladores de software. Se han realzado muchos documentos que relacionan el estándar con la industria del software, pero no entran en una gran cantidad de detalles.
Para la industria del software los estándares relevantes son:
•  ISO 9001: este es un estándar que describe el sistema de calidad utilizado para mantener el desarrollo de un producto que implique diseño.
•  ISO 9000-3: este es un documento específico que interpreta el ISO 9001 para el desarrollador de software.
•  ISO 9004-2: este documento proporciona las directrices para el servicio de facilidades del software como soporte de usuarios.
Los requisitos se agrupan bajo 20 títulos:
•  Responsabilidad de la gestión
•  Inspección, medición y equipo de pruebas
•  Sistema de calidad
•  Inspección y estado de pruebas
•  Revisión de contrato
•  Acción correctiva
•  Control de diseño
•  Control de producto no aceptado
•  Control de documento
•  Tratamiento, almacenamiento, empaquetamiento y entrega
•  Compras
•  Producto proporcionado al comprador
•  Registros de calidad
•  Identificación y posibilidad de seguimiento del producto
•  Auditorías internas de calidad
•  Formación
•  Control del proceso
•  Servicios
•  Inspección y estado de pruebas
•  Técnicas estadísticas.

Factores de calidad ISO 9126

El estándar ISO 9126 ha sido desarrollado en un intento de identificar los atributos clave de calidad para el software. El estándar identifica 6 atributos clave de calidad:
•  Funcionalidad: el grado en que el software satisface las necesidades indicadas por los siguientes subatributos: idoneidad, corrección, interoperatividad, conformidad y seguridad.
•  Confiabilidad: cantidad de tiempo que el software está disponible para su uso. Está referido por los siguientes subatributos: madurez, tolerancia a fallos y facilidad de recuperación.
•  Usabilidad: grado en que el software es fácil de usar. Viene reflejado por los siguientes subatributos: facilidad de comprensión, facilidad de aprendizaje y operatividad.
•  Eficiencia: grado en que el software hace óptimo el uso de los recursos del sistema. Está indicado por los siguientes subatributos: tiempo de uso y recursos utilizados.
•  Facilidad de mantenimiento: la facilidad con que una modificación puede ser realizada. Está indicada por los siguientes subatributos: facilidad de análisis, facilidad de cambio, estabilidad y facilidad de prueba.
•  Portabilidad: la facilidad con que el software puede ser llevado de un entorno a otro. Está referido por los siguientes subatributos: facilidad de instalación, facilidad de ajuste, facilidad de adaptación al cambio.


Estándares de Calidad del Software
La obtención de un software de calidad, implica la utilización de metodologías o procedimientos estándares, para el diseño, análisis, diseño, programación y prueba del software.
Los Estándares de Calidad ISO para Desarrollo de Software

El Estándar de Calidad ISO 9001

El estándar, que ha sido adoptado por más de 130 países para su uso, se está convirtiendo en el medio principal con el que los clientes pueden juzgar la competencia de un desarrollador de software. Uno de los problemas con el estándar ISO 9001 está en que no es específico de la industria: está expresado en términos generales, y puede ser interpretado por los desarrolladores de diversos productos como secadores de pelo, automóviles, equipamiento deportivo, televisores, así como por los desarrolladores de software. Se han realzado muchos documentos que relacionan el estándar con la industria del software, pero no entran en una gran cantidad de detalles.
Para la industria del software los estándares relevantes son:
•  ISO 9001: este es un estándar que describe el sistema de calidad utilizado para mantener el desarrollo de un producto que implique diseño.
•  ISO 9000-3: este es un documento específico que interpreta el ISO 9001 para el desarrollador de software.
•  ISO 9004-2: este documento proporciona las directrices para el servicio de facilidades del software como soporte de usuarios.
Los requisitos se agrupan bajo 20 títulos:
•  Responsabilidad de la gestión
•  Inspección, medición y equipo de pruebas
•  Sistema de calidad
•  Inspección y estado de pruebas
•  Revisión de contrato
•  Acción correctiva
•  Control de diseño
•  Control de producto no aceptado
•  Control de documento
•  Tratamiento, almacenamiento, empaquetamiento y entrega
•  Compras
•  Producto proporcionado al comprador
•  Registros de calidad
•  Identificación y posibilidad de seguimiento del producto
•  Auditorías internas de calidad
•  Formación
•  Control del proceso
•  Servicios
•  Inspección y estado de pruebas
•  Técnicas estadísticas.

Factores de calidad ISO 9126

El estándar ISO 9126 ha sido desarrollado en un intento de identificar los atributos clave de calidad para el software. El estándar identifica 6 atributos clave de calidad:
•  Funcionalidad: el grado en que el software satisface las necesidades indicadas por los siguientes subatributos: idoneidad, corrección, interoperatividad, conformidad y seguridad.
•  Confiabilidad: cantidad de tiempo que el software está disponible para su uso. Está referido por los siguientes subatributos: madurez, tolerancia a fallos y facilidad de recuperación.
•  Usabilidad: grado en que el software es fácil de usar. Viene reflejado por los siguientes subatributos: facilidad de comprensión, facilidad de aprendizaje y operatividad.
•  Eficiencia: grado en que el software hace óptimo el uso de los recursos del sistema. Está indicado por los siguientes subatributos: tiempo de uso y recursos utilizados.
•  Facilidad de mantenimiento: la facilidad con que una modificación puede ser realizada. Está indicada por los siguientes subatributos: facilidad de análisis, facilidad de cambio, estabilidad y facilidad de prueba.
•  Portabilidad: la facilidad con que el software puede ser llevado de un entorno a otro. Está referido por los siguientes subatributos: facilidad de instalación, facilidad de ajuste, facilidad de adaptación al cambio.




DESARROLLO BASADO EN COMPONENTES
Un componente es una pieza de código preelaborado que encapsula alguna funcionalidad expuesta a través de interfaces estándar. Es algo muy similar a lo que podemos observar en el equipo de música que tenemos en nuestra sala. Cada componente de aquel aparato ha sido diseñado para acoplarse perfectamente con sus pares, las conexiones son estándar y el protocolo de comunicación está ya preestablecido. Al unirse las partes, obtenemos música para nuestros oídos. 
En tal sentido se puedes decir que un componente es una parte no trivial, casi independiente, y reemplazable de un sistema que llena claramente una funcionalidad dentro de un contexto en una arquitectura bien definida. Un componente se conforma y provee la realización física por medio de un conjunto de interfaces
El desarrollo basado en componentes (CBD) es un área nueva y poco explorada. Uno de los principales problemas que enfrenta esta área es el de definir las tareas a desarrollar y las técnicas a aplicar para la producción de software de buena calidad.
En tal sentido cabe destacar que la complejidad de los sistemas computacionales actuales nos ha llevado a buscar la reutilización del software existente. El desarrollo de software basado en componentes permite reutilizar piezas de código preelaborado que permiten realizar diversas tareas, conllevando a diversos beneficios como las mejoras a la calidad, la reducción del ciclo de desarrollo y el mayor retorno sobre la inversión.
Características de componentes
v Identificable: Debe tener una identificación que permita acceder fácilmente a sus servicios y que permita su clasificación.
v Auto contenido: Un componente no debe requerir de la utilización de otros para finiquitar la función para la cual fue diseñado. 
v Puede ser remplazado por otro componente: Se puede remplazar por nuevas versiones u otro componente que lo remplace y mejore.
v Con acceso solamente a través de su interfaz: Debe asegurar que estas no cambiaran a lo largo de su implementación.
v Sus servicios no varían: Las funcionalidades ofrecidas en su interfaz no deben variar, pero su implementación sí.
v Bien Documentado: Un componente debe estar correctamente documentado para facilitar su búsqueda si se quiere actualizar, integrar con otros, adaptarlo, etc.
v Es genérico: Sus servicios debe servir para varias aplicaciones.
v Reutilizado dinámicamente: Puede ser cargado en tiempo de ejecución en una aplicación.
v Independiente de la plataforma: Hardware, Software, entro otros.

Fundamentos del Enfoque Orientado a Objetos
(EEO)
El Enfoque Orientado a Objeto se basa en cuatro principios que constituyen la base de todo desarrollo orientado a objetos. Estos principios son: la Abstracción, el Encapsulamiento, la Modularidad, la Herencia y el Polimorfismo.
Ø Abstracción:
Es el principio de ignorar aquellos aspectos de un fenómeno observado que no son relevantes, con el objetivo de concentrarse en aquellos que si lo son. Una abstracción denota las características esenciales de un objeto (datos y operaciones), que lo distingue de otras clases de objetos. Decidir el conjunto correcto de abstracciones de un determinado dominio, es el problema central del diseño orientado a objetos.
Los mecanismos de abstracción son usados en el EOO para extraer y definir del medio a modelar, sus características y su comportamiento. Dentro del EOO son muy usados mecanismos de abstracción: la Generalización, la Agregación y la clasificación.
§  La generalización es el mecanismo de abstracción mediante el cual un conjunto de clases de objetos son agrupados en una clase de nivel superior (Superclase), donde las semejanzas de las clases constituyentes (Subclases) son enfatizadas, y las diferencias entre ellas son ignoradas. En consecuencia, a través de la generalización, la superclase almacena datos generales de las subclases, y las subclases almacenan sólo datos particulares. La especialización es lo contrario de la generalización. La clase Médico es una especialización de la clase Persona, y a su vez, la clase Pediatra es una especialización de la superclase Médico.
§  La agregación es el mecanismo de abstracción por el cual una clase de objeto es definida a partir de sus partes (otras clases de objetos). Mediante agregación se puede definir por ejemplo un computador, por descomponerse en: la CPU, la ULA, la memoria y los dispositivos periféricos.
§  La clasificación consiste en la definición de una clase a partir de un conjunto de objetos que tienen un comportamiento similar. La ejemplificación es lo contrario a la clasificación, y corresponde a la instanciación de una clase, usando el ejemplo de un objeto en particular.
Ø Encapsulamiento:
Es la propiedad del EOO que permite ocultar al mundo exterior la representación interna del objeto. Esto quiere decir que el objeto puede ser utilizado, pero los datos esenciales del mismo no son conocidos fuera de él.
La idea central del encapsulamiento es esconder los detalles y mostrar lo importante. Permite el ocultamiento de la información separando el aspecto correspondiente a la especificación de la implementación; de esta forma, distingue el "qué hacer" del "cómo hacer". La especificación es visible al usuario, mientras que la implementación se le oculta.
El encapsulamiento en un sistema orientado a objeto se representa en cada clase u objeto, definiendo sus atributos y métodos con los siguientes modos de acceso:
§  Público (+) Atributos o Métodos que son accesibles fuera de la clase. Pueden ser llamados por cualquier clase, aun si no está relacionada con ella.
§  Privado (-) Atributos o Métodos que solo son accesibles dentro de la implementación de la clase.
§  Protegido (#): Atributos o Métodos que son accesibles para la propia clase y sus clases hijas (subclases).
Los atributos y los métodos que son públicos constituyen la interfaz de la clase, es decir, lo que el mundo exterior conoce de la misma.
Normalmente lo usual es que se oculten los atributos de la clase y solo sean visibles los métodos, incluyendo entonces algunos de consulta para ver los valores de los atributos. El método constructor (Nuevo, New) siempre es Público.
         Modularidad:
Es la propiedad que permite tener independencia entre las diferentes partes de un sistema. La modularidad consiste en dividir un programa en módulos o partes, que pueden ser compilados separadamente, pero que tienen conexiones con otros módulos. En un mismo módulo se suele colocar clases y objetos que guarden una estrecha relación. El sentido de modularidad está muy relacionado con el ocultamiento de información.
Ø Herencia:
Es el proceso mediante el cual un objeto de una clase adquiere propiedades definidas en otra clase que lo preceda en una jerarquía de clasificaciones. Permite la definición de un nuevo objeto a partir de otros, agregando las diferencias entre ellos (Programación Diferencial), evitando repetición de código y permitiendo la reusabilidad.
Las clases heredan los datos y métodos de la superclase. Un método heredado puede ser sustituido por uno propio si ambos tienen el mismo nombre.
La herencia puede ser simple (cada clase tiene sólo una superclase) o múltiple (cada clase puede tener asociada varias superclases). La clase Docente y la clase Estudiante heredan las propiedades de la clase Persona (superclase, herencia simple). La clase Preparador (subclase) hereda propiedades de la clase Docente y de la clase Estudiante (herencia múltiple).
Ø Polimorfismo:
   Es una propiedad del EOO que permite que un método tenga múltiples implementaciones, que se seleccionan en base al tipo objeto indicado al solicitar la ejecución del método.
El polimorfismo operacional o Sobrecarga operacional permite aplicar operaciones con igual nombre a diferentes clases o están relacionados en términos de inclusión. En este tipo de polimorfismo, los métodos son interpretados en el contexto del objeto particular, ya que los métodos con nombres comunes son implementados de diferente manera dependiendo de cada clase.
Características
  • Abstracción: Denota las características esenciales de un objeto, donde se capturan sus comportamientos. Cada objeto en el sistema sirve como modelo de un "agente" abstracto que puede realizar trabajo, informar y cambiar su estado, y "comunicarse" con otros objetos en el sistema sin revelar cómo se implementan estas características. Los procesos, las funciones o los métodos pueden también ser abstraídos y cuando lo están, una variedad de técnicas son requeridas para ampliar una abstracción.
  • Encapsulamiento: Significa reunir a todos los elementos que pueden considerarse pertenecientes a una misma entidad, al mismo nivel de abstracción. Esto permite aumentar la cohesión de los componentes del sistema. Algunos autores confunden este concepto con el principio de ocultación, principalmente porque se suelen emplear conjuntamente.
  • Modularidad: Se denomina Modularidad a la propiedad que permite subdividir una aplicación en partes más pequeñas (llamadas módulos), cada una de las cuales   tan independiente como sea posible de la aplicación en sí y de las restantes partes. Estos módulos se pueden compilar por separado, pero tienen conexiones con otros módulos. Al igual que la encapsulación, los lenguajes soportan la Modularidad de diversas formas.
  • Principio de ocultación: Cada objeto está aislado del exterior, es un módulo natural, y cada tipo de objeto expone una interfaz a otros objetos que específica cómo pueden interactuar con los objetos de la clase. El aislamiento protege a las propiedades de un objeto contra su modificación por quien no tenga derecho a acceder a ellas, solamente los propios métodos internos del objeto pueden acceder a su estado. 
  • Polimorfismo: Comportamientos diferentes, asociados a objetos distintos, pueden compartir el mismo nombre, al llamarlos por ese nombre se utilizará el comportamiento correspondiente al objeto que se esté usando. 
  • Herencia: Las clases no están aisladas, sino que se relacionan entre sí,   jerarquía de clasificación. Los objetos heredan las propiedades y el comportamiento de todas las clases a las que pertenecen. 
  • Recolección de basura: La recolección de basura o garbage collector es la técnica por la cual el entorno de objetos se encarga de destruir automáticamente, y por tanto desvincular la memoria asociada, los objetos que hayan quedado sin ninguna referencia a ellos. Esto significa que el programador no debe preocuparse por la asignación o liberación de memoria, ya que el entorno la asignará al crear un nuevo objeto y la liberará cuando nadie lo esté usando.
  • Clase: Definiciones de las propiedades y comportamiento de un tipo de objeto concreto. La instanciación es la lectura de estas definiciones y la creación de un objeto a partir de ellas.
  • Objeto: Entidad provista de un conjunto de propiedades o atributos (datos) y de comportamiento o funcionalidad (métodos) los mismos que consecuentemente reaccionan a eventos. Se corresponde con los objetos reales del mundo que nos rodea, o a objetos internos del sistema (del programa). Es una instancia a una clase.
  • Método: Algoritmo asociado a un objeto (o a una clase de objetos), cuya ejecución se desencadena tras la recepción de un "mensaje". Desde el punto de vista del comportamiento, es lo que el objeto puede hacer. Un método puede producir un cambio en las propiedades del objeto, o la generación de un "evento" con un nuevo mensaje para otro objeto del sistema.
  • Evento: Es un suceso en el sistema (tal como una interacción del usuario con la máquina, o un mensaje enviado por un objeto). El sistema maneja el evento enviando el mensaje adecuado al objeto pertinente. También se puede definir como evento, a la reacción que puede desencadenar un objeto, es decir la acción que genera.

Proceso de desarrollo de software
Un proceso define quien está haciendo que, cuando, y como alcanzar un determinado objetivo. En la Ingeniería del Software  el objetivo es construir un producto software o mejorar uno existente. Un proceso efectivo proporciona normas para el desarrollo eficiente de software de calidad. Captura y presenta las mejores prácticas que el estado actual de la tecnología permite. En consecuencia, reduce el riesgo y hace el proyecto más predecible.
Un proceso de desarrollo de software  tiene como propósito la producción eficaz y eficiente de un producto software que reúna los requisitos del cliente.
Hay varios modelos a seguir para el establecimiento de un proceso para el desarrollo de software, cada uno de los cuales describe un enfoque diferente para diferentes actividades que tienen lugar durante el proceso. 
Existen diferentes metodologías para llevar a cabo un proceso de desarrollo de software, las más utilizadas son RUP y ICONIX.
METODOLOGÍA RUP
El Proceso Unificado Racional, Rational Unified Process en inglés, y sus siglas RUP, es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. El RUP no es un sistema con pasos firmemente establecidos, sino que trata de un conjunto de metodologías adaptables al contexto y necesidades de cada organización, donde el software es organizado como una colección de unidades atómicas llamados objetos, constituidos por datos y funciones, que interactúan entre sí.
RUP es un proceso para el desarrollo de un proyecto de un software que define claramente quien, cómo, cuándo y qué debe hacerse en el proyecto. El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son los productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el código fuente, etc.) y roles (papel que desempeña una persona en un determinado momento, una persona puede desempeñar distintos roles a lo largo del proceso).
Características:
§  Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo)
§  Pretende implementar las mejores prácticas en Ingeniería de Software
§  Desarrollo iterativo
§  Administración de requisitos
§  Uso de arquitectura basada en componentes
§  Control de cambios
§  Modelado visual del software
§  Verificación de la calidad del software
Fases
  • Inicio (también llamado Incepción o Concepción).
  • Elaboración.
  • Desarrollo (también llamado Implementación, Construcción).
  • Cierre (también llamado Transición).
Fase de Inicio: Esta fase tiene como propósito definir y acordar el alcance del proyecto con los patrocinadores, identificar los riesgos asociados al proyecto, proponer una visión muy general de la arquitectura de software y producir el plan de las fases y el de iteraciones posteriores.
Fase de elaboración: En la fase de elaboración se seleccionan los casos de uso que permiten definir la arquitectura base del sistema y se desarrollaran en esta fase, se realiza la especificación de los casos de uso seleccionados y el primer análisis del dominio del problema, se diseña la solución preliminar.
Fase de Desarrollo: El propósito de esta fase es completar la funcionalidad del sistema, para ello se deben clarificar los requisitos pendientes, administrar los cambios de acuerdo a las evaluaciones realizados por los usuarios y se realizan las mejoras para el proyecto.
Fase de Cierre: (debe decir FASE DE TRANSICION) El propósito de esta fase es asegurar que el software esté disponible para los usuarios finales, ajustar los errores y defectos encontrados en las pruebas de aceptación, capacitar a los usuarios y proveer el soporte técnico necesario. Se debe verificar que el producto cumpla con las especificaciones entregadas por las personas involucradas en el proyecto.

METODOLOGÍA ICINIX
 El proceso ICONIX es un proceso de modelado de objetos, basado en casos de uso. Toma ideas de otros modelos como el Proceso Unificado de Rational (RUP), Programación Extrema (XP),Desarrollo Ágil de Software, aunque presenta algunas diferencias: es más liviano que el RUP porque utiliza solo cuatro diagramas del UML y, a diferencia del XP y el desarrollo ágil, provee de suficiente documentación de requerimientos y de diseño.

Características:
·                     Iterativo e incremental: Suceden iteraciones entre el desarrollo de modelo del dominio y la identificación de los casos de uso. El modelo estático es incrementalmente refinado por los modelos dinámicos.
·                     Trazabilidad: Cada paso está referenciado por algún requisito. Se debe considerar a la trazabilidad como la capacidad de seguir una relación entre los diferentes artefactos producidos.  
·                      Dinámica del UML: Uso dinámico de UML en los diagramas de caso de uso, diagramas de secuencia y de colaboración.
Faces
·         ·         Análisis de requisitos
·         1)      Modelo de dominio
·         2)      Prototipación rápida
·         3)      Modelo de casos de uso
·         ·         Análisis y diseño preliminar
·         1)      Descripción de casos de uso
·         2)      Diagrama de robustez
·         ·         Diseño
·         1)      Diagrama de secuencia
·         2)      Completar el modelo estático
·         ·         Implementación
·         1)      Utilizar un diagrama de componentes
·         2)      Escribir / Generar código
·         3)      Realización de pruebas