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 procesos

La 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 datos

Son 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 objeto

La 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 real

Procesan 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

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 una
estructura 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 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

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 procesos

La 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 datos

Son 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 objeto

La 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 real

Procesan 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 una
estructura 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 software
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