Metodología de desarrollo de software

TRES DEFINICIONE

1. son un conjunto de procedimientos, técnicas y ayudas para el desarrollo de productos software. En si pasos naturales o logicos para la construccion de software 

2. se definen  como un con junto de pasos  como analicis diseño desarollo implementacion pruevas y implantacion llamados ciclo de vida como una definicion general

3. Es conjunto ordenado de pasos a seguir para llegar a la solución de un problema u obtención de un producto osea el software, son tambien los pasos generales que sigue el proceso de desarrollo de un producto software Las metodologías de desarrollo de software son un conjunto de procedimientos, técnicas y ayudas a la documentación para el desarrollo de productos software

En esta ocasión me gustaría hacer énfasis en la importancia que tiene el uso de metodologías de desarrollo de software a un nivel de introducción básica. Tenemos a continuacion el clásico chiste acerca de la implementación de soluciones de cómputo:

Pero la contra al chiste clásico de la implementación de soluciones de cómputo puede lograrse utilizando metodologías de ingeniería y arquitectura de software, logrando que los proyectos lleguen finalmente a ser exitosos desde los puntos de vista de objetivos de negocio, costos, funcionalidad, sencillez y capacidad de soporte.

En general las metodologías llevan a cabo una serie de procesos comunes que son buenas prácticas para lograr los objetivos antes mencionados independientemente de cómo hayan sido diseñadas. Las fases que agrupan estos procesos son las siguientes:

Análisis

Especificación

Diseño

Programación

Prueba

Documentación

Mantenimiento

Reingeniería

Así mismo las diferentes metodologías tienen diversos ciclos de vida del desarrollo de software, los modelos más comúnmente utilizados son los siguientes:

Modelo en cascada

Modelo en espiral

Modelo de prototipos

Método en V

Desarrollo por etapas

Escribiré más adelante acerca de cada una de las metodologías mencionadas a continuación de forma más extensa posteriormente, por lo pronto dejaré abierta la investigación a los lectores acerca de los diferentes marcos de trabajo y metodologías formales de desarrollo de software. Las metodologías a tratar desde el punto de vista de la arquitectura de software y la administración de proyectos serán las siguientes:

PROCESOS DE PRODUCCION COMERCIAL

Metodologías tradicionales

Capability Maturity Model (SW-CMM)

Capability Maturity Model Integration for Development (CMMI-DEV)

Big Design Up Front (BDUF)

Cleanroom Software Engineering

Rational Unified Process (RUP)

Su objetivo es garantizar la producción de alta calidad • software que satisfaga las necesidades de sus usuarios finales, dentro de un calendario y el presupuesto previsible. software que satisfaga las necesidades de sus usuarios finales, dentro de un calendario y el presupuesto previsible

Essential Unified Process for Software Development (EssUP)

Fusebox Lifecycle Process (FLiP)

Software Process Improvement and Capability dEtermination (SPICE)

Introducción a Microsoft Solutions Framework

El Microsoft Solutions Framework proporciona un sistema de modelos, principios, y pautas para dar soluciones a empresas que diseñan y desarrollan de una manera que se asegure de que todos los elementos de un proyecto, tales como gente, procesos, y herramientas, puedan ser manejados con éxito.

Modelo de Proceso MSF

El modelo de proceso MSF combina los mejores principios del modelo en cascada y del modelo en espiral. Combina la claridad que planea el modelo en cascada y las ventajas de los puntos de transición del modelo en espiral.

El Modelo de proceso MSF consta de cinco fases distintas:

Previsión

Planeamiento

Desarrollo

Estabilización

Implementación

Métrica 3:

es una Metodología de Planificación, Desarrollo y Mantenimiento de Sistemas de Información.Puede ser utilizada libremente con la única restricción de citar la fuente de su propiedad intelectual: el Ministerio de Administraciones Públicas. Este Ministerio, desde el Consejo Superior de Informática, ofrece así un instrumento para la sistematización de las actividades que dan soporte al ciclo de vida del software en el desarrollo de Sistemas de Información. Su aplicación pretende los siguientes objetivos:

Proporcionar o definir Sistemas de Información que ayuden a conseguir los fines de la Organización mediante la definición de un marco estratégico para el desarrollo de los mismos.- Dotar a la Organización de productos software que satisfagan las necesidades de los usuarios dando una mayor importancia al análisis de requisitos.- Mejorar la productividad de los departamentos de Sistemas y Tecnologías de la Información y las Comunicaciones, permitiendo una mayor capacidad de adaptación a los cambios y teniendo en cuenta la reutilización en la medida de lo posible.- Facilitar la comunicación y entendimiento entre los distintos participantes en la producción de software a lo largo del ciclo de vida del proyecto, teniendo en cuenta su papel y responsabilidad, así como las necesidades de todos y cada uno de ellos.- Facilitar la operación, mantenimiento y uso de los productos software obtenidos.

Jackson System Development (JSD)

Joint Application Development (JAD)

Open Unified Process (OpenUP)

http://elbotondereset.blogspot.com/2008/09/modelo-de-reutilizacion-de-software.html

http://elbotondereset.blogspot.com /trabajos51/programacion-extrema/programacion-extrema.shtml

Metodologías ágiles

Extreme Programming (XP)

PROGRAMACIÓN EXTREMA XP (eXtreme Programming)

Metodología ágil basada en cuatro principios: simplicidad, comunicación, retroalimentación y valor. Además, orientada por pruebas y refactorización, se diseña e implementan las pruebas antes de programar la funcionalidad, el programador crea sus propios tests de unidad.

Este método es típicamente atribuido a Kent Beck, Ron Jeffries y Ward Cinningham. El objetivo de Xp son grupos pequeños y medianos de construcción de software en donde los requisitos aún son muy ambiguos, cambian rápidamente o son de alto riesgo. Xp busca la satisfacción del cliente tratando de mantener durante todo el tiempo su confianza en el producto. Además, sugiere que el lugar de trabajo sea una sala amplia, si es posible sin divisiones (en el centro los programadores, en la periferia los equipos individuales). Una ventaja del espacio abierto es el incremento en la comunicación y el proporcionar una agenda dinámica en el entorno de cada proyecto.

Actividades de Xp

Codificar

Es necesario codificar y plasmar nuestras ideas a través del código. En programación, el código expresa la interpretación del problema, así podemos utilizar el código para comunicar, para hacer comunes las ideas, y por tanto para aprender y mejorar.

Hacer pruebas

Las características del software que no pueden ser demostradas mediante pruebas simplemente no existen. Las pruebas dan la oportunidad de saber si lo implementado es lo que en realidad se tenía en mente. Las pruebas nos indican que nuestro trabajo funciona, cuando no podemos pensar en ninguna prueba que pudiese originar un fallo en nuestro sistema, entonces habremos acabado por completo.

Diseñar

El diseño crea una estructura que organiza la lógica del sistema, un buen diseño permite que el sistema crezca con cambios en un solo lugar. Los diseños deben de ser sencillos, si alguna parte del sistema es de desarrollo complejo, lo apropiado es dividirla en varias. Si hay fallos en el diseño o malos diseños, estos deben de ser corregidos cuanto antes.

Resumiendo las actividades de Xp: Tenemos que codificar porque sin código no hay programas, tenemos que hacer pruebas por que sin pruebas no sabemos si hemos acabado de codificar, tenemos que escuchar, porque si no escuchamos no sabemos que codificar ni probar, y tenemos que diseñar para poder codificar, probar y escuchar indefinidamente.

Scrum

Agile Modeling Adaptive Software Development (ASD)

Crystal Clear

Dynamic Systems Development Method (DSDM)

Feature Driven Development (FDD)

Lean Software Development (LSD)

Agile Unified Process (AUP)

Software Development Rhythms

Agile Documentation

ICONIX Process

Microsoft Solutions Framework (MSF)

Modelo de Reutilizacion de Software

Descripción

Surge formalmente en 1968 (Dough McIlroy). La idea principal era producir componentes de software como si de componentes electrónicos se tratara.

La Reutilización de Software aparece como una alternativa para desarrollar aplicaciones y sistemas SW de una manera más eficiente, productiva y rápida. La idea es reutilizar elementos y componentes de Software en lugar de tener que desarrollarlos desde el principio.

Inicialmente, se basaba en la simple combinación de componentes de código almacenados en una biblioteca pero con el tiempo se fueron utilizando código de programas enteros.

Características

Funcionalidad

Es más probable que se reutilice un componente de software que exhiba unas prestaciones que se puedan aplicar en muchos contextos, es decir que realice tareas comunes a muchas aplicaciones.

Independencia

Un componente sólo será reutilizable si es suficientemente independiente de cualquier aplicación particular.

Robustez

Su incorporación a muchos entornos diferentes no debe comprometer su corrección ni su eficiencia.

El diseñador del componente debe controlar completamente su conexión con las otras unidades externas.

Seguridad frente a fallos

Agile Data Method

Database Refactoring

LeanCMMI

Metodologías de desarrollo de software

Definición

Una metodología de desarrollo de software es un conjunto de pasos y procedimientos que deben seguirse para desarrollar software. Una metodología está compuesta por:

Cómo dividir un proyecto en etapas.

Qué tareas se llevan a cabo en cada etapa.

Qué restricciones deben aplicarse.

Qué técnicas y herramientas se emplean.

Cómo se controla y gestiona un proyecto.

2  Clasificación de las metodologías

Las metodologías se clasifican de la siguiente forma:

Estructuradas.

Orientadas a procesos

Orientadas a datos

Mixtas

No estructuradas.

Orientadas a objetos

Sistemas de tiempo real

Metodologías estructuradas

Se basan en la forma top-down

Metodologías orientadas a procesosLa ingeniería del software se basa en el modelo básico de entrada/proceso/salida de un sistema.

Está compuesta por:

Diagrama de flujo de datos (DFD).

Diccionario de datos.

Especificaciones de proceso. Ejemplos: metodologías de DeMarco, Gene y Sarson, Yourdon.

Metodologías orientadas a datosSon metodologías basadas en la información. Primero se definen las estructuras de datos y, a partir de éstos, se derivan los componentes procedimentales.

Ejemplos: metodologías de Jackson, Warnier, Warnier-Orr.

Metodologías no estructuradas

Metodologías orientadas a objetoLa orientación a objetos unifica procesos y datos encapsulándolos en el concepto de objetos.

Tiene dos enfoques distintos:

Revolucionario, puro u ortodoxo. Rompen con las metodologías tradicionales. Ejemplos: metodologías OOD de Booch, CRC/RDD de Wirfs-Brock.

Sintetista o evolutivo. Toman como base los sistemas estructurados y conforman elementos de uno y otro tipo.

Ejemplos: metodología OMT de Rumbourgh.

4.2  Sistemas de tiempo realProcesan información orientada al control más que a los datos.

Se caracterizan por concurrencia, priorización de procesos, comunicación entre tareas y acceso simultáneo a datos comunes.

Definición TGS

La teoría general de sistemas (TGS) o teoría de sistemas o enfoque sistemico es un esfuerzo de estudio interdisciplinario que trata de encontrar las propiedades comunes a entidades, los sistemas, que se presentan en todos los niveles de la realidad, pero que son objeto tradicionalmente de disciplinas académicas diferentes

La meta de la Teoría General de los Sistemas no es buscar analogías entre las ciencias, sino tratar de evitar la superficialidad científica que ha estancado a las ciencias.

La TGS no busca solucionar problemas o intentar soluciones prácticas, pero síproducir teorías y formulaciones conceptuales que pueden crear condiciones de aplicaciónen la realidad empírica

ciclo de vida del software

El término ciclo de vida del software describe el desarrollo de software, desde la fase inicial hasta la fase final. El propósito de este programa es definir las distintas fases intermedias que se requieren para validar el desarrollo de la aplicación

Diseño general: requisitos generales de la arquitectura de la aplicación.

Diseño en detalle: definición precisa de cada subconjunto de la aplicación.

Programación (programación e implementación): es la implementación de un lenguaje de programación para crear las funciones definidas durante la etapa de diseño.

Prueba de unidad: prueba individual de cada subconjunto de la aplicación para garantizar que se implementaron de acuerdo con las especificaciones.

Integración: para garantizar que los diferentes módulos se integren con la aplicación. Éste es el propósito de la prueba de integración que está cuidadosamente documentada.

Prueba beta (o validación), para garantizar que el software cumple con las especificaciones originales.

Documentación: sirve para documentar información necesaria para los usuarios del software y para desarrollos futuros.

Implementación

Mantenimiento: para todos los procedimientos correctivos

MODELO:

EL MODELO LINEAL (O MODELO EN CASCADA) :

Es el más antiguo de todos los modelos de Ingeniería del Software. El modelo lineal presenta unaestructura secuencial (de ahí el nombre de Modelo en cascada) formada por seis fases o etapas:− Análisis del Sistema− Análisis de Requisitos de Software− Diseño

en cascada: Se denomina modelo en cascada porque su característica principal es que no se comienza con un paso hasta que no se ha terminado el anterior.

Prototipos: Consiste en iterar en la fase de análisis tantas veces como sea necesario, mostrando prototipos al usuario para que pueda indicarnos de forma mas eficiente los requisitos del sistemaevolutivo En el modelo evolutivo se asume que los requisitos pueden cambiar en cualquier momento del ciclo de vida y no solo en la etapa de análisis. Incremental: Es una aproximación muy parecida a la evolutiva. En este modelo se desarrolla el sistema para satisfacer un subconjunto de los requisitos especificados y en posteriores versiones se incrementa el programa con nuevas funcionalidades que satisfagan mas requisitos.

En espiral: Toma las ventajas del modelo de desarrollo en cascada y el de prototipos añadiéndole el concepto de análisis de riesgo

http://elbotondereset.blogspot.com/2008/09/modelo-de-reutilizacion-de-software.html

http://elbotondereset.blogspot.com /trabajos51/programacion-extrema/programacion-extrema.shtml

Contenido 

¿Qué son los Modelos de Proceso?

Modelo en Cascada.

Modelo en Espiral

¿Como funciona el modelo del MSF?

Modelo de Proceso MSF

¿Qué son los Modelos de Proceso?

Para maximizar el éxito de los proyectos de una empresa. Microsoft ha puesto a disposición una guía para un efectivo diseño, desarrollo y funcionamiento de soluciones, incluyendo las tecnologías de Microsoft.

Este conocimiento se deriva de la experiencia ganada dentro de Microsoft con sus clientes y vendedores en proyectos de grande desarrollo de software y de prestación de servicios, la experiencia de los grandes consultores de Microsoft y el mejor conocimiento de la industria mundial de Tecnologías de Información.

Un modelo de proceso así pues, dirige el orden de las actividades del proyecto y representa el ciclo de vida de dicho proyecto.

Históricamente, algunos modelos de proceso eran estáticos y otros no permitían puntos de comprobación. Dos de estos modelos de proceso son el modelo de cascada y el modelo espiral.

Estos modelos proporcionan diversas aproximaciones al ciclo de vida de un proyecto.  

Modelo en Cascada.

Este modelo utiliza tramos como puntos de transición y de carga. Al usar el modelo de cascada, se necesitaría completar un conjunto de tareas en forma de fase para después continuar con la fase próxima. El modelo en cascada trabaja perfectamente para los proyectos en los cuales los requisitos del proyecto se encuentran definidos claramente y no son obligados a futuras modificaciones. Ya que este modelo esta compuesto por puntos de transición entre fases, se puede monitorear fácilmente ya que asigna responsabilidades definidas.

Modelo en Espiral

Este modelo se basa en la necesidad continua de refinar los requerimientos para un determinado proyecto. El modelo espiral es eficaz cuando se utiliza para el rápido desarrollo de proyectos muy pequeños. Esta logra consigo el acercamiento entre el equipo de desarrollo y el cliente porque el cliente es implicado en todas las etapas proporcionando la regeneración de proyecto y la aprobación del mismo. De cualquier forma, el modelo en espiral no incorpora puntos de comprobación claros. Por lo tanto, el proceso de desarrollo puede llegar a ser caótico.  

¿Como funciona el modelo del MSF?

El modelo de proceso MSF, propone una secuencia generalizada de actividades para la construcción de soluciones empresariales. Este proceso es flexible y se puede adaptar al diseño y desarrollo de una amplia gama de proyectos de una empresa.

El modelo MSF esta basado también basado en fases, puntos de transición y de carga de forma iterativa que se puede aplicar en el desarrollo de aplicaciones tradicionales, soluciones empresariales para comercio electrónico  así como aplicaciones Web distribuidas.

Metodología de desarrollo de software

Las metodologías de desarrollo de software son un conjunto de procedimientos, técnicas y ayudas a la documentación para el desarrollo de productos software

TRES DEFINICIONE

1. son un conjunto de procedimientos, técnicas y ayudas para el desarrollo de productos software. En si pasos naturales o logicos para la construccion de software 

2. se definen  como un con junto de pasos  como analicis diseño desarollo implementacion pruevas y implantacion llamados ciclo de vida como una definicion general

3. Es conjunto ordenado de pasos a seguir para llegar a la solución de un problema u obtención de un producto osea el software, son tambien los pasos generales que sigue el proceso de desarrollo de un producto software Las metodologías de desarrollo de software son un conjunto de procedimientos, técnicas y ayudas a la documentación para el desarrollo de productos software

En esta ocasión me gustaría hacer énfasis en la importancia que tiene el uso de metodologías de desarrollo de software a un nivel de introducción básica. Tenemos a continuacion el clásico chiste acerca de la implementación de soluciones de cómputo:

En general las metodologías llevan a cabo una serie de procesos comunes que son buenas prácticas para lograr los objetivos antes mencionados

independientemente de cómo hayan sido diseñadas. Las fases que agrupan estos procesos son las siguientes:

Análisis Especificación

Diseño

Programación

Prueba

Documentación

Mantenimiento

Reingeniería

Así mismo las diferentes metodologías tienen diversos ciclos de vida del desarrollo de software, los modelos más comúnmente utilizados son los

siguientes:

Modelo en cascada Modelo en espiral

Modelo de prototipos

Método en V

Desarrollo por etapas

Escribiré más adelante acerca de cada una de las metodologías mencionadas a continuación de forma más extensa posteriormente, por lo pronto dejaré abierta la investigación a los lectores acerca de los diferentes marcos de trabajo y metodologías formales de desarrollo de software. Las

metodologías a tratar desde el punto de vista de la arquitectura de software y la administración de proyectos serán las siguientes:

Metodologías tradicionales

Capability Maturity Model (SW-CMM) Capability Maturity Model Integration for Development (CMMI-DEV)

Big Design Up Front (BDUF)

Cleanroom Software Engineering

Rational Unified Process (RUP)

Essential Unified Process for Software Development (EssUP)

Fusebox Lifecycle Process (FLiP)

Software Process Improvement and Capability dEtermination (SPICE)

Métrica

Jackson System Development (JSD)

Joint Application Development (JAD)

Open Unified Process (OpenUP)

Metodologías ágiles

Extreme Programming (XP) Scrum

Agile Modeling Adaptive Software Development (ASD)

Crystal Clear

Dynamic Systems Development Method (DSDM)

Feature Driven Development (FDD)

Lean Software Development (LSD)

Agile Unified Process (AUP)

Software Development Rhythms

Agile Documentation

ICONIX Process

Microsoft Solutions Framework (MSF)

Agile Data Method

Database Refactoring

LeanCMMI

Metodologías de desarrollo de software

  Definición

Una metodología de desarrollo de software es un conjunto de pasos y procedimientos que deben seguirse para desarrollar software. Una metodología está compuesta por:

Cómo dividir un proyecto en etapas. Qué tareas se llevan a cabo en cada etapa.

Qué restricciones deben aplicarse.

Qué técnicas y herramientas se emplean.

Cómo se controla y gestiona un proyecto.

Clasificación de las metodologías

Las metodologías se clasifican de la siguiente forma:

Estructuradas. o Orientadas a procesos

o Orientadas a datos

o Mixtas

No estructuradas.

o Orientadas a objetos

o Sistemas de tiempo real

  Metodologías estructuradas

Se basan en la forma top-down

  Metodologías orientadas a procesosLa ingeniería del software se basa en el modelo básico de entrada/proceso/salida de un sistema.

Está compuesta por:

Diagrama de flujo de datos (DFD). Diccionario de datos.

Especificaciones de proceso.

Ejemplos: metodologías de DeMarco, Gene y Sarson, Yourdon.

Metodologías orientadas a datosSon metodologías basadas en la información. Primero se definen las estructuras de datos y, a partir de éstos, se derivan los componentes procedimentales.

Ejemplos: metodologías de Jackson, Warnier, Warnier-Orr.

Metodologías no estructuradas

  Metodologías orientadas a objetoLa orientación a objetos unifica procesos y datos encapsulándolos en el concepto de objetos.

Tiene dos enfoques distintos:

Revolucionario, puro u ortodoxo. Rompen con las metodologías tradicionales.

Ejemplos: metodologías OOD de Booch, CRC/RDD de Wirfs-Brock.

Sintetista o evolutivo. Toman como base los sistemas estructurados y conforman elementos de uno y otro tipo.

Ejemplos: metodología OMT de Rumbourgh.

Sistemas de tiempo realProcesan información orientada al control más que a los datos.

Se caracterizan por concurrencia, priorización de procesos, comunicación entre tareas y acceso simultáneo a datos comunes.

Definición     TGS

La teoría general de sistemas (TGS) o teoría de sistemas o enfoque sistemico es un esfuerzo de estudio interdisciplinario que trata de encontrar las propiedades comunes a entidades, los sistemas, que se presentan en todos los niveles de la realidad, pero que son objeto tradicionalmente de disciplinas académicas diferentes

La meta de la Teoría General de los Sistemas no es buscar analogías entre las ciencias, sino tratar de evitar la superficialidad científica que ha estancado a las ciencias.

La TGS no busca solucionar problemas o intentar soluciones prácticas, pero sí

         producir teorías y formulaciones conceptuales que pueden crear      condiciones de aplicación en la realidad empírica   ciclo de vida del software   El término ciclo de vida del software describe el desarrollo de software, desde la fase inicial hasta la fase final. El propósito de este programa es definir las distintas fases intermedias que se requieren para validar el desarrollo de la

aplicación  

·         Diseño general: requisitos generales de la arquitectura de la aplicación.

·         Diseño en detalle: definición precisa de cada subconjunto de la aplicación.

·         Programación (programación e implementación): es la implementación de un lenguaje de programación para crear las

funciones definidas durante la etapa de diseño.

·         Prueba de unidad: prueba individual de cada subconjunto de la aplicación para garantizar que se implementaron de

acuerdo con las especificaciones.

·         Integración: para garantizar que los diferentes módulos se integren con la aplicación. Éste es el propósito de la prueba

de integración que está cuidadosamente documentada.

·         Prueba beta (o validación), para garantizar que el software cumple con las especificaciones originales.

·         Documentación: sirve para documentar información necesaria para los usuarios del software y para desarrollos futuros.

·         Implementación

·         Mantenimiento: para todos los procedimientos correctivos

 os modelos

en cascada: Se denomina modelo en cascada porque su característica principal es que no se comienza con un

paso hasta que no se ha terminado el anterior.

Prototipos: Consiste en iterar en la fase de análisis tantas veces como sea necesario, mostrando prototipos al

usuario para que pueda indicarnos de forma mas eficiente los requisitos del sistema

evolutivo En el modelo evolutivo se asume que los requisitos pueden cambiar en cualquier momento del ciclo de vida y

no solo en la etapa de análisis.

Incremental: Es una aproximación muy parecida a la evolutiva. En este modelo se desarrolla el sistema para

satisfacer un subconjunto de los requisitos especificados y en posteriores versiones se incrementa el

programa con nuevas funcionalidades que satisfagan mas requisitos.

En espiral: Toma las ventajas del modelo de desarrollo en cascada y el de prototipos añadiéndole el

concepto de análisis de riesgo

EL MODELO LINEAL (O MODELO EN CASCADA) :Es el más antiguo de todos los modelos de Ingeniería del Software. El modelo lineal presenta unaestructura secuencial (de ahí el nombre de Modelo en cascada) formada por seis fases o etapas:− Análisis del Sistema− Análisis de Requisitos de Software− Diseño

Modelo de Reutilizacion de softwareSurge formalmente en 1968 (Dough McIlroy). La idea principal era producir componentes de software como si de componentes electrónicos se tratara.

La Reutilización de Software aparece como una alternativa para desarrollar aplicaciones y sistemas SW de una manera más eficiente, productiva y rápida. La idea es reutilizar elementos y componentes de Software en lugar de tener que desarrollarlos desde el principio.

Inicialmente, se basaba en la simple combinación de componentes de código almacenados en una biblioteca pero con el tiempo se fueron utilizando código de programas enteros.CaracterísticasFuncionalidad

Es más probable que se reutilice un componente de software que exhiba unas prestaciones que se puedan aplicar en muchos contextos, es decir que realice tareas comunes a muchas aplicaciones.

IndependenciaUn componente sólo será reutilizable si es suficientemente independiente de cualquier aplicación particular.

Robustez• Su incorporación a muchos entornos diferentes no debe comprometer su corrección ni su eficiencia.• El diseñador del componente debe controlar completamente su conexión con las otras unidades externas.Seguridad frente a fallos