El documento describe la ingeniería de software basada en componentes, la cual surge a finales de los 90 como un enfoque basado en la reutilización. Este paradigma involucra definir, implementar e integrar sistemas débilmente acoplados mediante la composición de componentes de software reutilizables. Algunas ventajas son mayor reutilización, pruebas y mantenimiento simplificados, y mejor calidad a largo plazo.

1. Page 1

2. Es el proceso de definir, implementar e integrar o
componer en sistemas independientes débilmente
acoplados.
La ingeniería del software basada en componentes
surgió a finales de los 90 como una aproximación
basada en la reutilización al desarrollo de sistemas de
software.
Page 2

3. Construir aplicaciones mediante ensamblado de
módulos software reutilizables, que han sido
diseñados previamente con independencia de las
aplicaciones en las que van a ser Utilizados, y
generar un mercado de componentes software
reutilizables.
Page 3

4. El paradigma de ensamblar componentes y escribir código para hacer
que estos componentes funcionen se conoce como Desarrollo de
Software Basado en Componentes. El uso de este paradigma posee
algunas ventajas:
1,Reutilización del software: Nos lleva a alcanzar un mayor nivel de
reutilización de software.
2,Simplifica las pruebas: Permite que las pruebas sean ejecutadas probando
cada uno de los componentes antes de probar el conjunto completo de
componentes ensamblados.
3,Simplifica el mantenimiento del sistema: Cuando existe un débil
acoplamiento entre componentes, el desarrollador es libre de actualizar y/o
agregar componentes según sea necesario, sin afectar otras partes del sistema.
4,Mayor calidad: Dado que un componente puede ser construido y luego
mejorado continuamente por un experto u organización, la calidad de una
aplicación basada en componentes mejorará con el paso del tiempo.
Page 4

5. De la misma manera, el optar por comprar componentes de
terceros en lugar de desarrollarlos, posee algunas ventajas:
Ciclos de desarrollo más cortos. La adición de una pieza dada
de funcionalidad tomará días en lugar de meses ó años.
Mejor ROI. Usando correctamente esta estrategia, el retorno
sobre la inversión puede ser más favorable que desarrollando los
componentes uno mismo.
Funcionalidad mejorada. Para usar un componente que
contenga una pieza de funcionalidad, solo se necesita entender su
naturaleza, más no sus detalles internos. Así, una funcionalidad
que sería impráctica de implementar en la empresa, se vuelve ahora
completamente asequible.
Page 5

6. Que es un componente?
Un componente es una unidad de software
independiente que puede estar compuesta por
otros componentes y que se utiliza para crear un
sistema de software.
Existen componentes con estado y sin estado.
Que un componente no tenga estado
externamente observable significa que las copias de
componentes son indistinguibles, estos son más
sencillos de implementar.
Page 6

7. • Ciudades-Casas de Software:
Las ciudades evolucionaron gradualmente como lugares para hacer
comercio y manufactura. En estas ciudades existían edificios con
poca o ninguna conexión entre ellos. Las ciudades tenían un
contacto muy limitado con sus ciudades aledañas y desarrollaron su
propia cultura, estilo y forma de hacer cosas. De la misma forma,
las casas de software evolucionaron gradualmente mientras nuevas
aplicaciones fueron construidas y luego extendidas. Cada
aplicación separada e independiente de sus similares en la misma
casa de software. Cada casa de software tenía su propia cultura,
estilo y forma de hacer las cosas:
Page 7

8. Etapas del Modelo Basado en
Componentes
La “Ingeniería de Software Basada en Componentes” (ISBC)
incorpora muchas de las características del Modelo en
Espiral. Es evolutivo por naturaleza, y por ello exige también un
enfoque iterativo para la creación del software.
Pero reemplaza las fases de Ingeniería y Construcción y Acción de
éste modelo por una sola fase de Construcción y adaptación de la
Ingeniería:
comunicación con el cliente- las tareas requeridas para
establecer comunicación entre el desarrollador y el cliente.
planificación- las tareas requeridas para definir recursos, el
tiempo y otra información relacionadas con el proyecto.
Page 8

9.  análisis de riesgos- las tareas requeridas para evaluar riesgos
técnicos y de gestión.
 construcción y adaptación de la Ingeniería
 evaluación del cliente- las tareas requeridas para obtener la
reacción del cliente según la evaluación de las
representaciones del software creadas durante la etapa de
ingeniería e implementada durante la etapa de instalación.
Page 9

10. • http://www.elgolem.com.ar/images/archivos/tutoriales/Metodolo
gia_de_Sistemas/Metodologia_de_Desarrollo_de_Software_Ba
sada_en_Componentes.pdf
• http://msdn.microsoft.com/es-co/library/bb972268.aspx
• http://www.slideshare.net/martincito123/modelo-componentes
Page 10