FICHA DE IDENTIFICACIÓN DE TRABAJO DE INVESTIGACIÓN

Título
Nombres y Apellidos Código de estudiantes

Autor/es

Fecha dd/mm/aaaa

Carrera
Asignatura
Grupo
Docente
Periodo Académico
Subsede
Copyright © (AGREGAR AÑO) por (NOMBRES). Todos los derechos reservados.
.
 Título:
Autor/es:

Tabla De Contenidos
Capítulo 2. Marco Teórico................................................................................................4
1.- Definición De Los Sistemas De Información Y Su Contextualización En Los
Organizaciones................................................................................................................ 4
1.1 ¿Qué es un sistema de información?La primera cuestión que tenemos que
pensar con relación a ese asunto es que un sistema de información no está restricto
a un hardware o software.............................................................................................4
1.2 ¿Cuáles son las características de este sistema?.........................................4
1.3 ¿Cuáles son los tipos de sistema de información?........................................5
1.4 ¿Cómo el sistema de información ayuda el funcionamiento de la empresa?....7
2.- El Modelo Estructurado O Cascada.......................................................................7
2.1 ¿Qué Es El Modelo En Cascada?......................................................................7
2.2 ¿Cómo Funciona El Modelo En Cascada?........................................................8
2.3 Procedimientos Alternativos Al Modelo En Cascada.......................................12
3. Modelo De Prototipo..............................................................................................12
3.1 Ventajas del modelo de prototipos:..................................................................12
3.2 Desventajas del modelo de prototipos:............................................................13
4. Modelo DRA...........................................................................................................13
4.1 Características del Modelo...............................................................................14
4.2 Fases................................................................................................................14
4.3 Ventajas........................................................................................................... 15
4.4 Desventajas......................................................................................................15
5. Modelo Basado En Componentes.........................................................................16
5.1 Desarrollo Basado en Componentes: Mejorando la Eficiencia y Reusabilidad 16
5.2 Entendiendo el Desarrollo Basado en Componentes.......................................16
5.3 Las Ventajas del Desarrollo Basado en Componentes....................................17
5.4 Medidas Preventivas para un Desarrollo Basado en Componentes Efectivo. .17
6. Modelo Evolutivo....................................................................................................18
6.1 MODELO EVOLUTIVO....................................................................................18

Asignatura:
Carrera: Página 15 de 15
 Título:
Autor/es:

Capítulo 2. Marco Teórico

1.- Definición De Los Sistemas De Información Y Su Contextualización En Los

Organizaciones.
1.1 ¿Qué es un sistema de información?La primera cuestión que tenemos que
pensar con relación a ese asunto es que un sistema de información no está restricto a
un hardware o software.
Este es un concepto bastante común y que asusta algunas personas, pero que
necesita ser desmitificado, ya que estos sistemas son de alcance mucho mayor.En
realidad, el objetivo de los sistemas de información es entender y analizar cómo ocurre
el impacto de la adopción de las tecnologías de información en los procesos de
decisión gerenciales y administrativos de las empresas.
Por eso, como ya afirmamos, su elemento principal es la información, ya que es esto lo
que guiará las tomas de decisiones. ¿Pero de dónde surge esta información?
Básicamente, de la interacción que ocurre entre procedimientos, personas y
tecnologías, que trabajan en conjunto con los sistemas de información para alcanzar
las metas definidas por la empresa.En este sentido, necesitamos destacar que el
sistema el dividido en subsistemas.
Uno de ellos es social (incluyendo personas, informaciones, procesos y documentos) y
el otro, automatizado (compuesto por máquinas, redes de comunicación y
ordenadores).
Eso demuestra que realmente las personas son fundamentales para esta herramienta.
1.2 ¿Cuáles son las características de este sistema?
El sistema de información puede trabajar con diversos elementos. Entre ellos
están software, hardware, base de datos, sistemas especialistas, sistemas de apoyo a
la gerencia, entre otros.
Es decir, están inclusos todos los procesos informatizados, que pueden disponibilizar la
información correcta y hacer la empresa funcionar de manera adecuada.
Sin embargo, existen algunas características inherentes a este sistema que deben ser
llevadas en consideración. Ve cuáles son.
Relevancia
El sistema debe generar informaciones relevantes y necesarias a la empresa, que
deben ser generadas a tiempo y ser confiables.
Así, esas informaciones tienen un costo cercano al estimado por la organización y
atienden a los requisitos de gestión y operación de la empresa.
Integración

Asignatura:
Carrera: Página 15 de 15
 Título:
Autor/es:

Hay que tener una integración entre el sistema de información y la estructura de la

empresa.
De esta manera, es más fácil coordinar los departamentos, sectores, divisiones y otros
tipos de unidades de organización.
Además, este proceso de integración facilita y agiliza la toma de decisiones.
Flujo independiente
Esa característica es bastante diferenciada, porque, al mismo tiempo en que hay un
flujo de procesamiento de datos, que ocurre de manera interna y externa, también hay
un flujo independiente de los sistemas de información.
Está integrado a los subsistemas existentes y, por eso, actúa de manera más rápida y
con menos costos.
Control
No es obligatorio, pero los sistemas de información pueden contener herramientas de
control interno, cuya finalidad es asegurar que las informaciones generadas son
confiables y actuar de manera a proteger los datos controlados.
Directrices
Sirven para garantizar que los objetivos de la empresa serán atingidos de manera
objetiva, eficiente y directa.
1.3 ¿Cuáles son los tipos de sistema de información?
Como existen diferentes tipos de información y ellas son categorizadas en nivel,
también hay diferentes tipos de sistemas.
Cada uno de ellos tiene especificidades y particularidades, vueltos para el suministro
de determinado tipo de información.
Estos diversos tipos de sistemas trabajan de manera integrada, atendiendo a intereses
empresariales diversificados. Ellos actúan en los niveles estratégico, operacional, de
conocimiento y táctico.
Para simplificar, existen 4 sistemas de información principales. Ellos son bastante
conocidos y utilizados en las organizaciones del mundo todo. Ve cuáles son.
ERP
Los sistemas Enterprise Resource Planning (o Planeamiento de Recursos de la
Empresa) son softwares que integran diferentes procesos y datos de la empresa,
reuniéndolos en un solo lugar.
De esta manera, los datos de todos los departamentos de la organización son
integrados y almacenados.
Los datos brindados por los softwares ERP ayudan a traer más agilidad a los procesos
y permiten cumplir la producción por demanda, también llamada de just in time.
El objetivo es reducir los stocks hasta eliminarlos, evitando los costos de
almacenamiento.

Asignatura:
Carrera: Página 15 de 15
 Título:
Autor/es:

Un ejemplo de funcionamiento de software ERP es en el momento de la venta de una

mercancía.
Mientras la venta es realizada, los departamentos de producción y de compras son
automáticamente alertados.
Así, es posible verificar si hay todos los productos o si será necesario adquirir algo.
Además, es posible identificar la necesidad de reponer los estoques.

CRM
Los softwares Customer Relationship Management (o Gestión de Relación con el
Cliente) automatizan todas las funciones relativas al contacto con los clientes,
permitiendo que las organizaciones recolecten y almacenen los datos de contacto, las
preferencias de los clientes, el histórico de compras de ellos, entre otros.
Así, la empresa puede contactar los clientes para estrategias específicas, con el
objetivo principal de atender a las necesidades de los consumidores de manera
anticipada.
SCM
Ya los sistemas Supply Chain Management (o Administración de la Cadena de
Suministro) integran los diferentes procesos relativos a los proveedores de servicios,
productos e informaciones.
La finalidad es crear valor para el consumidor, satisfaciéndolo cuando él adquiere un
producto o servicio.
Así, ese tipo de software integra los datos relativos a fabricantes, proveedores y puntos
de venta, garantizando que los productos sean entregues en las cantidades necesarias
y en el plazo correcto, evitando la falta de mercancía o el exceso de stock.
Así, se alcanza un buen nivel de servicio al mismo tiempo que los gastos son
reducidos.
Es importante resaltar que este software es compuesto por los sistemas de gestión de
suministros y componentes, de la cadena de suministros, de la estructura de producto,
del rastreo de origen y uso y de control de la cadena de suministros.
De esta manera, se consigue hacer desde la previsión de ventas, inventario y
clasificación de productos hasta reducir el costo de manipulación y creación de piezas.
SIG
Los Sistemas de Información Gerenciales son dirigidos hacia el apoyo a la toma de
decisiones y actúan en los niveles estratégico, operacional y táctico.
Las informaciones pueden ser reportadas por medio de gráficos, hojas de cálculo o, los
habituales informes.

Asignatura:
Carrera: Página 15 de 15
 Título:
Autor/es:

En el caso de los informes, ellos pueden ser categorizados en 4 tipos, como verás
ahora.
Informes programados
Son una de las formas más tradicionales para la visualización de informaciones. Como
el propio nombre afirma, ellos son programados, o sea, son generados de acuerdo a
una programación.
Algunos ejemplos de informes programados son los de ventas por día y por semana y
las demostraciones financieras mensuales, por ejemplo.
Informes de excepción
Son generados en situaciones excepcionales con la finalidad de obtener informaciones
específicas.
Por ejemplo, un informe enfocado en la lista de deudas por cobrar o uno que presente
a los clientes que sobrepasan el límite de crédito ofertado.
Informes y respuestas por solicitación
Presentan las informaciones de acuerdo con la solicitación del emprendedor. Por eso,
no informan datos específicos, pero sí una visión general para que el gestor pueda
analizar los datos rápidamente y encontrar soluciones inmediatas.
Informes en pilas
Las informaciones son puestas en pilas en el área de trabajo en red del gestor o
emprendedor. Así, él puede acceder al informe siempre que quiera o necesite.
1.4 ¿Cómo el sistema de información ayuda el funcionamiento de la empresa?
Como vimos, los sistemas de información tienen diferentes niveles y funcionalidades.
Por eso, es evidente que estos softwares ayudan a la empresa a funcionar de manera
más adecuada.
Por medio de la adopción de estos sistemas, el gestor consigue reunir una serie de
informaciones importantes, que pueden impactar tanto en el servicio al cliente como en
los procesos internos.Además, la obtención de estos datos permite que el gestor o el
emprendedor analice los datos y pueda interpretarlos.De esta manera, las
informaciones pueden ser usadas para la toma de decisiones estratégica, controlando
las informaciones y los datos y asegurando que la empresa esté funcionando con el
máximo de eficiencia.Con esto, el resultado es un ganancia de competitividad, ya que
el emprendedor consigue identificar fallas y oportunidades, atendiendo a demandas no
satisfechas y a nichos específicos de mercado y diferenciándose de la competencia.

2.- El Modelo Estructurado O Cascada

2.1 ¿Qué Es El Modelo En Cascada?
El desarrollo en cascada (en inglés, waterfall model) es un procedimiento lineal que
se caracteriza por dividir los procesos de desarrollo en sucesivas fases de proyecto. Al

Asignatura:
Carrera: Página 15 de 15
 Título:
Autor/es:

contrario que en los modelos iterativos, cada una de estas fases se ejecuta tan solo
una vez. Los resultados de cada una de las fases sirven como hipótesis de partida para
la siguiente. El waterfall model se utiliza, especialmente, en el desarrollo de software.

2.2 ¿Cómo Funciona El Modelo En Cascada?

El desarrollo del modelo se atribuye al teórico de la informática Winston W. Royce. Sin
embargo, Royce no es el inventor de este modelo. Muy al contrario, en su ensayo de
1970 titulado Managing the Development of Large Software Systems, el teórico
presenta una reflexión crítica acerca de los procedimientos lineales. A modo de
alternativa, Royce presenta un modelo iterativo incremental en el que cada una de las
fases se basa en la anterior y verifica los resultados de esta.
Royce propone un modelo compuesto por siete fases que se ha de ejecutar en diversas
vueltas (iteraciones):
1. Requisitos de sistema
2. Requisitos de software
3. Análisis
4. Diseño
5. Implementación
6. Prueba
7. Servicio
El procedimiento popularmente conocido como waterfall model se basa en las fases
definidas por Royce, pero solo prevé una iteración.
En el ensayo publicado por Royce, el término no aparece en ningún momento.
Hecho
El modelo en cascada se popularizó a través de la norma estadounidense DoD-STD-
2167. Esta norma se basa en una versión extremadamente simplificada del
procedimiento desarrollado por Royce, que no fue lo suficientemente analizado por los
autores. Tal y como reconoció con el paso del tiempo David Maibor, uno de sus
autores, el motivo fue la falta de compresión de los modelos iterativos incrementales.
En la práctica, se aplican diversas versiones del modelo. Los más habituales son los
modelos que dividen los procesos de desarrollo en cinco fases. En ocasiones, las fases
1, 2 y 3 definidas por Royce se integran en una sola fase de proyecto a modo de
análisis de los requisitos.
1. Análisis: planificación, análisis y especificación de los requisitos.
2. Diseño: diseño y especificación del sistema.
3. Implementación: programación y pruebas unitarias.
4. Verificación: integración de sistemas, pruebas de sistema y de integración.
5. Mantenimiento: entrega, mantenimiento y mejora.

Asignatura:
Carrera: Página 15 de 15
 Título:
Autor/es:

La siguiente imagen explica por qué el procedimiento lineal se denomina metodología

en cascadaEl modelo en cascada de cinco niveles, basado en las propuestas de
Winston W. Royce, divide los procesos de desarrollo en las siguientes fases de
proyecto: análisis, diseño, implementación, verificación y mantenimiento. El gráfico
incluye una de las ampliaciones del modelo planteadas por Royce: la verificación de los
resultados de cada una de las fases tomando en consideración las exigencias y
especificaciones formuladas en el paso anterior.
En las ampliaciones de la metodología en cascada se añaden funciones iterativas al
modelo básico como, por ejemplo, los saltos hacia atrás, que permiten comparar los
resultados de cada una de las fases con las hipótesis obtenidas en la fase anterior, de
modo que se puedan verificar.
Las fases del desarrollo en cascada
En este modelo, las diferentes fases de un proceso de desarrollo se suceden una
detrás de otra como en una cascada. Cada una de las fases concluye con
un resultado provisional (hito) como, por ejemplo, un catálogo de requisitos en forma
de pliego de condiciones, la especificación de una arquitectura de software o una
aplicación a nivel alfa o beta.
Análisis
Todo proyecto de software comienza con una fase de análisis que incluye un estudio
de viabilidad y una definición de los requisitos. En el estudio de viabilidad se evalúan
los costes, la rentabilidad y la factibilidad del proyecto de software. El estudio de
viabilidad da como resultado un pliego de condiciones (una descripción general de los
requisitos), un plan y una estimación financiera del proyecto, así como una propuesta
para el cliente, si fuera necesario.
A continuación, se realiza una definición detallada de los requisitos, incluyendo un
análisis de la situación de salida y un concepto. Mientras que los análisis de salida se
encargan de describir la problemática en sí, el concepto ha de definir qué funciones y
características debe ofrecer el producto de software para cumplir con las
correspondientes exigencias. La definición de los requisitos da como resultado un
pliego de condiciones, una descripción detallada de cómo se han de cumplir los
requisitos del proyecto, así como un plan para la prueba de aceptación, entre otros.
Por último, la primera fase del waterfall model incluye un análisis de la definición de
los requisitos en el que los problemas complejos se dividen en pequeñas tareas
secundarias y se elaboran las correspondientes estrategias de resolución.
Diseño
La fase de diseño sirve para formular una solución específica en base a las exigencias,
tareas y estrategias definidas en la fase anterior. En esta fase, los desarrolladores de
software se encargan de diseñar la arquitectura de software, así como un plan de

Asignatura:
Carrera: Página 15 de 15
 Título:
Autor/es:

diseño detallado del mismo, centrándose en componentes concretos, como

interfaces, entornos de trabajo o bibliotecas. La fase de diseño da como resultado un
borrador preliminar con el plan de diseño del software, así como planes de prueba para
los diferentes componentes.
Implementación
La arquitectura de software concebida en la fase de diseño se ejecuta en la fase de
implementación, en la que se incluye la programación del software, la búsqueda de
errores y las pruebas unitarias. En la fase de implementación, el proyecto de software
se traduce al correspondiente lenguaje de programación. Los diversos componentes se
desarrollan por separado, se comprueban a través de las pruebas unitarias y se
integran poco a poco en el producto final. La fase de implementación da como
resultado un producto de software que se comprueba por primera vez como producto
final en la siguiente fase (prueba alfa).
Prueba
La fase de prueba incluye la integración del software en el entorno seleccionado. Por
norma general, los productos de software se envían en primer lugar a los usuarios
finales seleccionados en versión beta (pruebas beta). Las pruebas de
aceptación desarrolladas en la fase de análisis permiten determinar si el software
cumple con las exigencias definidas con anterioridad. Aquellos productos de software
que superan con éxito las pruebas beta están listos para su lanzamiento.
Servicio
Una vez que la fase de prueba ha concluido con éxito, se autoriza la aplicación
productiva del software. La última fase del modelo en cascada incluye la entrega,
el mantenimiento y la mejora del software.
Pros y contras del modelo en cascada
Esta metodología permite estructurar la organización de forma clara en aquellos
proyectos de desarrollo en los que las diversas fases de proyecto se diferencian
claramente entre sí. Como cada una de las fases concluye con un hito, el proceso de
desarrollo es muy fácil de comprender. El punto clave del modelo reside en la
documentación de todos y cada uno de los pasos de proceso. Los conocimientos
adquiridos se registran en pliegos de requisitos o borradores preliminares.
En teoría, el desarrollo en cascada pretende crear los requisitos previos para una
ejecución rápida y rentable de los proyectos a través de una cuidada planificación
previa. Sin embargo, la utilización del modelo en la práctica es controvertida. Por
una parte, en el desarrollo de software las fases de proyecto no suelen estar
claramente diferenciadas entre sí. Es precisamente en los proyectos de software más
complejos donde los desarrolladores se suelen enfrentar al hecho de que los diversos
componentes de una misma aplicación se encuentran en diferentes fases de desarrollo

Asignatura:
Carrera: Página 15 de 15
 Título:
Autor/es:

al mismo tiempo. Por otra parte, la secuencia lineal del waterfall model no suele
coincidir con la realidad.
En sentido estricto, el modelo en cascada no prevé la realización de ajustes a lo largo
del proyecto. Sin embargo, un proyecto de software en el que todos los detalles del
desarrollo se definieran al comienzo, solo podría concluir con éxito si desde el principio
se invirtiera una gran cantidad de tiempo y dinero en análisis y diseño. A todo esto, se
añade que los proyectos de software de más envergadura se suelen prolongar durante
varios años y, de no adaptarse a los avances más actuales, obtendrían resultados que
ya estarían obsoletos en el momento de su aplicación.
Resumen de las ventajas y desventajas del modelo en cascada

Ventajas Inconvenientes
Por norma general, los proyectos más
Una estructura sencilla gracias a unas
complejos o de varios niveles no
fases de proyecto claramente
permiten su división en fases de proyecto
diferenciadas.
claramente diferenciadas.
Buena documentación del proceso de Poco margen para realizar ajustes a lo
desarrollo a través de unos hitos bien largo del proyecto debido a un cambio en
definidos. las exigencias.
El usuario final no se integra en el
Los costes y la carga de trabajo se pueden
proceso de producción hasta que no
estimar al comenzar el proyecto.
termina la programación.
Aquellos proyectos que se estructuran en
En ocasiones, los fallos solo se detectan
base al modelo en cascada se pueden
una vez finalizado el proceso de
representar cronológicamente de forma
desarrollo.
sencilla.
La metodología en cascada se suele emplear, especialmente, en aquellos proyectos
cuyos requisitos y procesos se pueden describir de forma precisa durante la fase de
planificación, en los que cabe suponer que las hipótesis no van a sufrir una gran
variación durante el transcurso del proyecto. Los procedimientos estrictamente lineales
se adaptan, así, especialmente bien a proyectos de software pequeños, sencillos y
claramente estructurados. A esta misma conclusión llegó Royce en los años 1970.
Por este motivo, la alternativa al procedimiento lineal que propuso, y que más tarde se
conocería como waterfall model, incluía tres ampliaciones principales:
Verificación tras cada fase de proyecto
Según Royce, los resultados de cada una de las fases de proyecto se deben comparar
y verificar inmediatamente con los documentos elaborados previamente. Es decir,

Asignatura:
Carrera: Página 15 de 15
 Título:
Autor/es:

inmediatamente después de desarrollar un módulo, por ejemplo, se debería garantizar

que este cumple con las exigencias definidas con anterioridad sin esperar a que
concluya el proceso de desarrollo.
Al menos, dos iteraciones
Según Royce, el modelo se debería ejecutar en, al menos, dos ocasiones: primero
para elaborar un prototipo y, a continuación, para desarrollar el producto de
software en sí.
Pruebas que incluyen al usuario final
La tercera ampliación del modelo en cascada propuesta por Royce en su ensayo es
una medida que, a día de hoy, se ha convertido en un procedimiento estándar en el
desarrollo de productos: la inclusión del usuario final en el proceso de producción.
Royce propone incluir al usuario en tres momentos diferentes del proceso de desarrollo
de software: durante la planificación del software en la fase de análisis, entre el diseño
del software y su implementación y en la fase de prueba que precede al lanzamiento
del software.
2.3 Procedimientos Alternativos Al Modelo En Cascada
Debido a la secuencia estrictamente lineal de las fases sucesivas de proyecto, el
modelo en cascada se adaptaría, en el mejor de los casos, a proyectos de software de
poca envergadura. Por el contrario, los procesos complejos de varios niveles serían
difícilmente representables con este modelo. Por este motivo, con el paso del tiempo
han ido surgiendo enfoques alternativos.
Mientras que algunos modelos, como el modelo en espiral o el modelo en V, se
consideran una evolución del waterfall model clásico, algunos métodos, como la
programación extrema, el desarrollo ágil de software o el desarrollo iterativo, se centran
en un enfoque completamente diferente y suelen permitir una adaptación a los cambios
más recientes o a las exigencias más actuales.

3. Modelo De Prototipo
El modelo de prototipos es un enfoque de desarrollo de software que se centra en la
creación de prototipos funcionales del sistema antes de desarrollar la versión final. Este
modelo permite a los desarrolladores y clientes obtener una comprensión más clara de
los requisitos del sistema, validar las funcionalidades y realizar ajustes antes de pasar a
la fase de desarrollo completo. Es un enfoque iterativo que puede adaptarse a los
cambios en los requisitos y las expectativas del cliente.
3.1 Ventajas del modelo de prototipos:
1. Facilita la comunicación entre los desarrolladores y el cliente, ya que
proporciona una representación visual y funcional del sistema.

Asignatura:
Carrera: Página 15 de 15
 Título:
Autor/es:

2. Permite la detección temprana de errores y problemas, lo que ayuda a reducir

los costos y los riesgos asociados con el desarrollo de software.
3. Facilita la incorporación de cambios en los requisitos y las expectativas del
cliente, lo que aumenta la satisfacción del cliente y la probabilidad de éxito del
proyecto.
4. Los prototipos pueden ser reutilizados en la fase de desarrollo, lo que puede
acelerar el proceso y reducir el tiempo total de desarrollo.
3.2 Desventajas del modelo de prototipos:
1. Puede consumir más tiempo y recursos en comparación con otros modelos de
desarrollo, ya que requiere la creación y revisión de múltiples prototipos.
2. Existe el riesgo de que los desarrolladores se centren en la creación de
prototipos en lugar de abordar los aspectos fundamentales del sistema.
3. Los clientes pueden tener expectativas poco realistas respecto al tiempo y los
recursos necesarios para desarrollar el producto final, ya que los prototipos
pueden dar una impresión de progreso rápido.
4. Puede haber una falta de documentación y planificación adecuadas, lo que
puede afectar la calidad y la estabilidad del producto final.

¿En qué proyectos sería ideal utilizar el modelo de prototipos?

Un proyecto en el que sería ideal utilizar este modelo de ciclo de vida de desarrollo del
software sería el desarrollo de una aplicación móvil innovadora para una empresa que
busca expandirse en nuevos mercados. Dado que el éxito de la aplicación depende en
gran medida de la satisfacción del usuario y de adaptarse a sus necesidades
cambiantes, el modelo de prototipos sería óptimo en este caso.
El modelo de prototipos permitiría a los desarrolladores y al cliente obtener
retroalimentación temprana de los usuarios y realizar ajustes rápidos en las
funcionalidades de la aplicación. Además, el enfoque iterativo facilitaría la adaptación a
los cambios en los requisitos y las expectativas del cliente, lo cual es esencial en un
mercado en constante evolución. En resumen, el modelo de prototipos ayudaría a
garantizar que la aplicación móvil se desarrolle de manera eficiente y se ajuste a las
necesidades específicas de los usuarios y el mercado objetivo.

4. Modelo DRA
Es el proceso de desarrollo de software diseñado para facilitar y acelerar la creación de
aplicaciones, que permite construir sistemas utilizables en poco tiempo, normalmente
de 60 a 90 días. En conclusion, es una adaptación a "Alta velocidad" en el que se logra
el desarrollo rápido utilizando un enfoque de construcción basado en componentes. Si
se comprenden bien los requisitos y se limita el ámbito del proyecto, el proceso DRA

Asignatura:
Carrera: Página 15 de 15
 Título:
Autor/es:

permite al equipo de desarrollo crear un "sistema completamente funcional" dentro de

periodos cortos de tiempo.

4.1 Características del Modelo

Debido a que el software o aplicación se requiere lo más pronto posible no existe una
especificación del sistema detallada.
-El software no se desarrolla y utiliza en su totalidad, sino en una serie de incrementos,
donde en cada incremento se incluyen nuevas funcionalidades al sistema.
-A menudo se desarrollan las interfaces de usuario del sistema utilizando un sistema de
desarrollo interactivo que permite que el diseño de la interfaz se cree rápidamente
dibujando y colando iconos en la interfaz.
-Para su desarrollo se utilizan herramientas de desarrollo visual para agilizar el
proceso.
-Se necesitan equipos compuestos por alrededor de seis personas, incluyendo
desarrolladores y usuarios de tiempo completo, así como aquellas personas
involucradas en los requisitos.
-Las funciones secundarias son eliminadas como sea necesario para cumplir con el
calendario.

4.2 Fases
• Modelado de Gestión

El flujo de información entre las funciones de gestión se modela de forma que responda
a las siguientes preguntas: ¿Qué información conduce el proceso de gestión? ¿Qué
información se genera? ¿Quién la genera? ¿A dónde va la información? ¿Quién la
proceso?.

• Modelado de Datos

El flujo de información definido como parte de la fase de modelado de gestión se refina

como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen
las características (llamadas atributos) de cada uno de los objetos y las relaciones
entre estos objetos.

• Modelado de Procesos

Los objetos de datos definidos en la fase de modelado de datos quedan transformados

para lograr el flujo de información necesario para implementar una función de gestión.

Asignatura:
Carrera: Página 15 de 15
 Título:
Autor/es:

Las descripciones del proceso se crean para añadir, modificar, suprimir, o recuperar un
objeto de datos. Es la comunicación entre los objetos.

• Generación de Aplicaciones

El DRA asume la utilización de técnicas de cuarta generación. En lugar de crear

software con lenguajes de programación de tercera generación, el proceso DRA trabaja
para volver a utilizar componentes de programas ya existentes (cuando es posible) o a
crear componentes reutilizables (cuando sea necesario).

• Pruebas de Entrega

Como el proceso DRA enfatiza la reutilización, ya se han comprobado muchos de los

componentes de los programas. Esto reduce tiempo de pruebas.
Sin embargo, se deben probar todos los componentes nuevos y se deben ejercitar
todas las interfaces a fondo.

4.3 Ventajas

-Los entregables pueden ser fácilmente trasladados a otra plataforma.

-El desarrollo se realiza a un nivel de abstracción mayor.
-Entrega temprana al cliente.
-Compromiso del cliente con el sistema.
-Mayor flexibilidad.
-Menor codificación manual.
-Mayor involucramiento de los usuarios.
-Posiblemente menos fallas.
-Posiblemente menor costo.
-Ciclos de desarrollo más pequeños.
-Interfaz gráfica estándar.

4.4 Desventajas

-Tiene inconvenientes para proyectos grandes, necesita suficientes recursos humanos

para crear el número correcto de equipos.
-Si los desarrolladores y clientes no se comprenden con las actividades necesarias
para completar el sistema, los proyectos fallarán.

Asignatura:
Carrera: Página 15 de 15
 Título:
Autor/es:

-Un alto costo de herramientas integradas y equipo necesario.

-Progreso más difícil de medir.
-Menos eficiente y con menor precisión científica.

5. Modelo Basado En Componentes

5.1 Desarrollo Basado en Componentes: Mejorando la Eficiencia y Reusabilidad
El Desarrollo Basado en Componentes (CBD, por sus siglas en inglés) es un
paradigma de ingeniería de software que revoluciona el proceso de creación de
programas informáticos mediante la utilización de componentes de software
reutilizables. Permite a los desarrolladores construir aplicaciones ensamblando
módulos independientes y autónomos, lo que resulta en una mayor eficiencia de
desarrollo, reducción del tiempo de comercialización, mejora de la calidad del código y
mayor mantenimiento.
5.2 Entendiendo el Desarrollo Basado en Componentes
Los principios clave del Desarrollo Basado en Componentes implican la creación,
catalogación, ensamblaje e integración de componentes de software. Al seguir estos
principios, los desarrolladores pueden construir aplicaciones complejas combinando
componentes existentes, en lugar de desarrollarlo todo desde cero. Exploremos el
proceso con más detalle:
1. Desarrollo de Componentes Independientes: En el Desarrollo Basado en
Componentes, los componentes de software se diseñan como módulos
individuales y autónomos que realizan funciones o tareas específicas. Estos
componentes son entidades independientes que se pueden entender, probar y
reutilizar fácilmente.
2. Catálogo de Componentes: Una vez desarrollados, estos componentes se
catalogan y almacenan en un repositorio o biblioteca de componentes. Este
catálogo sirve como una ubicación centralizada donde los desarrolladores
pueden explorar y acceder fácilmente a componentes reutilizables para sus
aplicaciones.
3. Ensamblaje y Configuración: Al construir una aplicación, los desarrolladores
pueden seleccionar los componentes necesarios del catálogo y ensamblarlos
para crear la funcionalidad deseada. Estos componentes se pueden configurar y
conectar para trabajar juntos sin problemas. Este enfoque modular simplifica el
proceso de desarrollo y permite una mayor flexibilidad en la adaptación de los
componentes a requisitos específicos.
4. Integración y Pruebas: Después de seleccionar y ensamblar los componentes,
se integran en la estructura general de la aplicación. Se llevan a cabo pruebas
rigurosas para asegurar la compatibilidad, fiabilidad y rendimiento de los

Asignatura:
Carrera: Página 15 de 15
 Título:
Autor/es:

componentes ensamblados en el nuevo contexto. Este paso ayuda a identificar y

solucionar cualquier problema o conflicto que pueda surgir durante la
integración.

5.3 Las Ventajas del Desarrollo Basado en Componentes

El Desarrollo Basado en Componentes ofrece varios beneficios que contribuyen a su
popularidad y adopción generalizada. Exploremos algunas ventajas clave:
 Reusabilidad: Al usar componentes preexistentes, los desarrolladores pueden
reducir el trabajo redundante y ahorrar tiempo y esfuerzo. Reutilizar
componentes en múltiples aplicaciones promueve la consistencia y reduce las
posibilidades de reinventar la rueda.
 Modularidad: La naturaleza modular de los componentes simplifica el
mantenimiento, las actualizaciones y la corrección de errores. Los componentes
se pueden actualizar de manera independiente sin afectar a toda la aplicación,
haciéndola más adaptable a los cambios.
 Consistencia y Estandarización: Los componentes están diseñados con
interfaces bien definidas, lo que promueve la consistencia y las prácticas de
desarrollo estandarizadas. Esto asegura que el mismo componente se comporte
de manera consistente en diversas aplicaciones, reduciendo la curva de
aprendizaje para los desarrolladores y mejorando la calidad del código.
 Escalabilidad: El Desarrollo Basado en Componentes permite una fácil
escalabilidad al agregar o reemplazar componentes. Esta flexibilidad permite
que las aplicaciones se adapten a requisitos cambiantes y necesidades
empresariales en evolución.
 Tiempo de Desarrollo Reducido: Reutilizar componentes existentes acelera el
proceso de desarrollo, ya que los desarrolladores pueden centrarse en
ensamblar y configurar componentes en lugar de desarrollarlos desde cero. Esta
reducción en el tiempo de desarrollo puede ser significativa, llevando a un
tiempo de comercialización más rápido y una competitividad incrementada.
5.4 Medidas Preventivas para un Desarrollo Basado en Componentes Efectivo
Aunque el Desarrollo Basado en Componentes aporta numerosos beneficios, se deben
considerar ciertas medidas preventivas para garantizar su implementación exitosa:
 Control de Versiones: Un control de versiones adecuado es crucial para
asegurar que se utilicen versiones más recientes y mejoradas de los
componentes. Los componentes obsoletos pueden contener vulnerabilidades o
carecer de mejoras necesarias. Mantener el control de versiones permite a los
desarrolladores rastrear y actualizar fácilmente los componentes, mitigando así
los riesgos de seguridad y mejorando el rendimiento del sistema.

Asignatura:
Carrera: Página 15 de 15
 Título:
Autor/es:

 Pruebas de Seguridad: Antes de integrar componentes en una aplicación, se

deben realizar pruebas de seguridad exhaustivas. Estas pruebas ayudan a
identificar y abordar cualquier vulnerabilidad o debilidad potencial en los
componentes, asegurando un producto final robusto y seguro.

Términos Relacionados
Para mejorar aún más tu comprensión del Desarrollo Basado en Componentes, es
importante explorar términos y conceptos relacionados. Aquí hay dos términos
estrechamente relacionados:
 Arquitectura Orientada a Servicios (SOA): Similar al Desarrollo Basado en
Componentes, SOA se centra en construir sistemas de software utilizando
servicios o componentes reutilizables y con bajo acoplamiento. SOA enfatiza las
interacciones y colaboraciones de servicios, permitiendo la interoperabilidad
entre sistemas heterogéneos.
 Microservicios: Los microservicios son un estilo arquitectónico que estructura
una aplicación como una colección de servicios autónomos y con bajo
acoplamiento. Aunque similar al Desarrollo Basado en Componentes, los
microservicios generalmente se refieren a servicios más pequeños y granulares
que se comunican a través de protocolos ligeros.
En conclusión, el Desarrollo Basado en Componentes proporciona un enfoque
poderoso para el desarrollo de software, permitiendo la creación eficiente de
aplicaciones complejas mediante la reutilización de componentes de software
independientes y reutilizables. Al seguir los principios de desarrollo, catalogación,
ensamblaje y pruebas, los desarrolladores pueden mejorar su productividad, calidad del
código y mantenimiento del sistema.

6. Modelo Evolutivo
6.1 MODELO EVOLUTIVO
El desarrollo evolutivo consta del desarrollo de una versión inicial que luego de
exponerse se va refinando de acuerdo de los comentarios o nuevos requerimientos por
parte del cliente o del usuario final. Las fases de especificación, desarrollo y validación
se entrelazan en vez de separarse.
Existen dos tipos de desarrollo evolutivo:
desarrollo exploratorio:
donde el objetivo del proceso es trabajar con el cliente para explorar sus
requerimientos y entregar un sistema final. El desarrollo empieza con las partes del
sistema que se comprenden mejor. El sistema evoluciona agregando nuevos atributos

Asignatura:
Carrera: Página 15 de 15
 Título:
Autor/es:

propuestos por el cliente.

prototipos desechables:
donde el objetivo del proceso de desarrollo evolutivo es comprender los requerimientos
del cliente y entonces desarrollar una definición mejorada de los requerimientos para el
sistema. El prototipo se centra en experimentar con los requerimientos del cliente que
no se comprenden del todo.
Desde el punto de vista de desarrollo de sistema el enfoque evolutivo suele traer más
ventajas en comparación con un enfoque en cascada ya que el sistema se va
ajustando a las necesidades del cliente, a la vez que él mismo entiende mejor sus
propios requerimientos. Sin embargo el enfoque evolutivo desde una perspectiva de
ingeniería y gestión suele tener dos grandes problemas:

.proceso no visible : Los administradores tienen que hacer entregas regulares para
medir el progreso. Si los sistemas se desarrollan rápidamente, no es rentable producir
documentos que reflejen cada versión del sistema.

A menudo los sistemas tienen una estructura deficiente. Los cambios continuos
tienden a corromper la estructura del software. Incorporar cambios en él se convierte
cada vez más en una tarea difícil y costosa.
Aunque supone grandes ventajas el desarrollo evolutivo solo es recomendado para
sistemas pequeños y medianos. En los sistemas grandes, los constantes cambios en el
desarrollo solo dificultan la estabilidad y la integración de los avances de los distintos
grupos de trabajo que puedan existir. La mayoría de las empresas que desarrollan
grandes sistemas usan un modelo mixto que usa las mayores fortalezas de los
enfoques evolutivos y de cascada.

Asignatura:
Carrera: Página 15 de 15