LA POLITICA DE LAS TELECOMUNICACIONES EN EL MUNDO

Se trata de una regulación sectorial, fijada por los estados, para una actividad en que
actúan sujetos públicos y privados. Dicha regulación ha estado sujeta a cambios, en
virtud del avance tecnológico de las últimas décadas en el ámbito de las
telecomunicaciones.
¿Por qué contar con una política de comunicaciones?
La política involucra los parámetros que servirán de referencia para el planteamiento de
estrategias y planes de comunicación, así como la creación de medios institucionales y
planes de formación en competencias comunicativas e incluso estructuras de
comunicación.
¿Por qué aplicar una política de comunicaciones?
• Plantea estrategias y planes de comunicación.
• Crea medios institucionales y planes de formación en competencias
• Señala qué aprueba la organización y qué rechaza.
• Detecta las implicaciones sobre las decisiones que toma la organización.
Una política de comunicaciones cuenta generalmente con lo siguientes elementos:
• Propósitos
• Principios
• Protocolos
• Atribuciones
• Alcances
• Elementos sancionatorios
Los principios asociados más frecuentes dentro de una política de comunicaciones son:

• Comunicación abierta
• Trato
• Transparencia
• Participación
• Respeto
• Veracidad
• Diligencia
• Colaboración
 GESTIÓN DE PROYECTOS Y LEGISLACIÓN DE TELECOMUNICACIONES

METODOLOGÍA EN CASCADA
También conocido como modelo clásico, modelo tradicional o modelo lineal secuencial. Él método de
la cascada es considerado como el enfoque clásico para el ciclo de vida del desarrollo de sistemas, se
puede decir que es un método puro que implica un desarrollo rígido. está es una secuencia de
actividades (o etapas) que consisten en el análisis de requerimientos, él diseño, la implementación,
la integración y las pruebas.

• El análisis de requerimientos consiste en reunir las necesidades del producto y casi siempre
su salida es texto.
• El diseño describe la estructura interna del producto y suele representarse con diagramas y
texto.
• La implementación significa programación. Producto de esta etapa es el código en cualquier
nivel, incluido el producido por sistemas de generación automática.
• La integración es el proceso de integración es el proceso de ensamblar las partes para
completar el producto.

Es caracterizado por ordenar de manera rigurosa las etapas del ciclo

de vida de software, dado que el comienzo de cada etapa debe esperar
a la finalización de la inmediata anterior. Cuando la revisión determina
que el proyecto no está listo para pasar a la siguiente etapa, permanece
en la etapa actual hasta que esté preparado. Y debido a que el proceso
está planeado es más fácil determinar costos y los plazos. Esté modelo
puede ser visto como un modelo con forma de cascada de agua con
varios saltos, en la que cada salto representa cada una de las fases del
ciclo de vida.

La metodología en cascada es esencialmente:

1. El inicio y el alcance del proyecto
2. La planificación del proyecto (calendario, recursos necesarios, costo)
3. Definición de las necesidades del negocio y el análisis en detalle dela solución
4. La creación de la solución
5. Prueba que la solución funciona. La entrega de la solución a su público objetivo
6. Cierre del proyecto.

Ventajas:
• Permite la departamentalización y control de gestión.
• El horario se establece con los plazos normalmente adecuados para cada etapa de
desarrollo.
• Este proceso conduce a entregar el proyecto a tiempo.
• Es sencilla y facilita la gestión de proyectos.
• Permite tener bajo control el proyecto.
• Limita la cantidad de interacción entre equipos que se produce durante el desarrollo.
 CICLO DE VIDA DE UN PROYECTO MODELO V

El modelo en v se desarrolló para terminar con algunos de los problemas que se

vieron utilizando el enfoque de cascada tradicional. Los defectos estaban siendo
encontrados demasiado tarde en el ciclo de vida, ya que las pruebas no se
introducían hasta el final del proyecto.
El Modelo V aporta opciones de evaluación del software en cada etapa de
manera inversa.
En cada etapa, se crea la planificación de las pruebas y los casos de pruebas
para verificar y validar el producto según los requisitos de la etapa. Por ejemplo,
en la etapa de recogida de requisitos, el equipo de evaluadores prepara las
pruebas de caso correspondientes a los requisitos. Más tarde, cuando el
producto se desarrolla y está preparado para ser evaluado, las pruebas de caso
en esta etapa verifican el software y su validez según sus requisitos.
Esto hace que tanto la verificación como la validación vayan en paralelo. Este
modelo también se conoce como modelo de validación y verificación.
En cada etapa, se crea la planificación de las pruebas y los casos de pruebas
para verificar y validar el producto según los requisitos de la etapa. Por ejemplo,
en la etapa de recogida de requisitos, el equipo de evaluadores prepara las
pruebas de caso correspondientes a los requisitos. Más tarde, cuando el
producto se desarrolla y está preparado para ser evaluado, las pruebas de caso
en esta etapa verifican el software y su validez según sus requisitos.
Modelo V (Modelo de desarrollo secuencial)

Los cuatro niveles que se utilizan en este programa de estudio son los siguientes:
1. Pruebas de componentes (unidades).
2. Pruebas de integración.
3. Pruebas de sistemas.
4. Pruebas de aceptación.
En la práctica, un modelo V puede tener más, menos o diferentes niveles de
desarrollo y pruebas, en función del proyecto y del producto de software. Así, por
ejemplo, pueden realizarse las pruebas de integración de componentes a
continuación de las pruebas de componente, y las pruebas de integración de
sistemas después de las pruebas de sistemas.
Los productos de trabajo de software como, por ejemplo: escenarios, casos de
uso, especificaciones de requerimientos, documentos de diseño y código - que
se elaboran en la fase de desarrollo a menudo conforman la base de las pruebas
en uno o más niveles de pruebas. Las referencias a productos de trabajo
genéricos incluyen el Capability Maturity Model Integration (CMMI) o "Procesos
del ciclo de vida del software" (IEEE/IEC 12207). La verificación y validación (y
el diseño de pruebas temprano) pueden realizarse durante el desarrollo de los
productos de trabajo de software.
Estrategia de aplicación de las pruebas
• Se comienza en la prueba de cada módulo, que normalmente la realiza el
propio personal de desarrollo en su entorno.
• Con el esquema del diseño del software, los módulos probados se
integran para comprobar sus interfaces en el trabajo conjunto (prueba de
integración).
• El software totalmente ensamblado se prueba como un conjunto para
comprobar si cumple o no tanto los requisitos funcionales como los
requisitos de rendimientos, seguridad, etc. (prueba funcional o de
validación).
• El software ya validado se integra con el resto del sistema (por ejemplo,
elementos mecánicos, interfaces electrónicas, etc.) para probar su
funcionamiento conjunto (Prueba del sistema).
• Por último, el producto final se pasa a la prueba de aceptación para que
el usuario compruebe en su propio entorno de explotación si lo acepta
como está o no (prueba de aceptación.).
Proceso para la integración incremental descendente.
• Comienza por el módulo de control principal y va incorporando módulos
subordinados progresivamente.
• No hay un orden adecuado de integración, pero unos consejos son los
siguientes:
• Si hay secciones críticas (especialmente complejas) se deben integrar lo
antes posible.
• EL orden de integración debe incorporar cuanto antes los módulos de
entrada/salida para facilitar la ejecución de pruebas.
Etapas fundamentales de la integración descendente.
• El módulo raíz es el primero: Se escriben módulos ficticios que simulan
los subordinados.
• Una vez probado el módulo raíz (sin detectarse ya ningún defecto), se
sustituye uno de los subordinados ficticios por el módulo correspondiente
según el orden elegido.
• Se ejecutan las correspondientes pruebas cada vez que se incorpora un
módulo nuevo.
• Al terminar cada prueba, se sustituye un ficticio por su correspondiente
real.
• Conviene repetir algunos casos de prueba de ejecuciones anteriores para
asegurarse de que no se ha introducido ningún defecto nuevo.
Integración No Incremental
Para cada módulo que tiene que ser probado necesita lo siguiente:
• Un módulo impulsor, que transmite o "impulsa" los datos de prueba al
módulo y muestra los resultados de dichos casos de prueba.
• Uno o más módulos ficticios que simulan la función de cada módulo
subordinado llamado por el módulo que se va a probar.
Una vez probado cada módulo por separado, se ensamblan todos de una vez y
se prueban en conjunto.
VENTAJAS
• La relación entre las etapas de desarrollo y los distintos tipos de pruebas
facilitan la localización de fallos.
• Es un modelo sencillo y de fácil aprendizaje.
• Hace explícito parte de la iteración y trabajo que hay que revisar.
• Especifica bien los roles de los distintos tipos de pruebas a realizar.
• Involucra al usuario en las pruebas.

Desventajas:

• Es difícil que el cliente exponga explícitamente todos los requisitos.

• El cliente debe tener paciencia pues obtendrá el producto al final del ciclo de
vida.
• Las pruebas pueden ser caras y, a veces, no lo suficientemente efectivas.
• El producto final obtenido puede que no refleje todos los requisitos del
usuario.
 Metodología RAD

PRINCIPIOS BÁSICOS

• Desarrollo rápido y de alta calidad de un sistema de bajo costo de inversión.

• Intenta reducir los errores reduciendo el proyecto desfragmentándolo.
• Tiene mayor importancia la necesidad comercial a la ingeniería tecnológica o la
excelencia.
• Si se retrasa el proyecto se reducen los requisitos y no se amplía el tiempo de entrega.

Fases del RAD

1. Modelado de Gestión.
2. Modelado de Datos.
3. Modelado de Procesos.
4. Generación de Aplicaciones.
5. Pruebas de Entrega.

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 PROCESO

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.
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). En todos los casos se utilizan
herramientas automáticas para facilitar la construcción del software.

VENTAJAS DE RAD

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

• El desarrollo se realiza a un nivel de abstracción mayor.
• Visibilidad temprana.
• 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.

DESVENTAJAS DE RAD

• Comprar puede ser más caro que construir.

• Costo de herramientas integradas y equipo necesario.
• Progreso más difícil de medir.
• Menos eficiente.
• Menor precisión científica.
• Riesgo de revertirse a las prácticas sin control de antaño.
• Más fallas (por síndrome de “codificar a lo bestia”).
• Prototipos pueden no escalar, un problema mayúsculo.
• Funciones reducidas (por “timeboxing”).
• Dependencia en componentes de terceros: funcionalidad de más o de menos,
problemas legales.

RESUMEN- CICLO DE VIDA ITERATIVO INCREMENTAL

Ciclo de vida iterativo.

Responde a la alta incertidumbre del proyecto realizando iteraciones, que no son más que una división
del proyecto en fases cíclicas en las que el proyecto va avanzando progresivamente. A cada uno de estos
ciclos se le denomina iteración y al inicio de cada uno de ellas debe planificarse el trabajo a realizar en la
misma.

Este ciclo de vida permite ir detallando el plan conforme avanza el proyecto y se va conociendo más sobre
el mismo (disminuye la incertidumbre).

Ciclo de vida modelo incremental

Es una particularización del anterior, mediante la cual cada ciclo que se realiza va obteniendo una porción
de producto, servicio o resultado completa. A cada porción generada en una iteración se le
denomina incremento.

Es decir, vamos produciendo porciones del resultado del proyecto que están acabadas al 100% e iteramos
hasta tener todas las porciones, esto es, todo el resultado esperado.

Características

- Los incrementos son pequeños.

- Permite una fácil administración de las tareas en cada iteración.

- La inversión se materializa a corto plazo.

- Es un modelo propicio a cambios o modificaciones.

- Se adapta a las necesidades que surjan.

Ventajas

• Se basa en la entrega de un producto operacional con cada incremento, permitiendo

utilizar en menor tiempo una versión incompleta.
 • Los clientes no deben esperar hasta obtener el sistema completo se entregue para sacar
provecho del mismo ya que el primer incremento satisface los requerimientos más
urgentes.

• Siendo que los requerimientos críticos son los primeros en entregarse, son los que son
puestos bajo más pruebas, logrando así que no se encuentren fallos en funcionamientos
del software en sus partes más importantes.

• Los usuarios pueden utilizar los incrementos iniciales como prototipos y obtener
experiencia sobre los requerimientos de los incrementos posteriores del sistema.

En ambos casos la estrategia es dividir el proyecto en ciclos que van construyendo el resultado
del proyecto poco a poco, conforme se va descubriendo más sobre el mismo. La diferencia
fundamental es que en el ciclo de vida incremental ese trabajo va construyendo producto final
utilizable.

MODELO ESPIRAL DE BOEHM

INTRODUCCION

Boehm, ideó y promulgó un modelo desde un enfoque distinto al tradicional en Cascada: El Modelo
Evolutivo Espiral. Su Modelo de Ciclo de Vida en Espiral tiene en cuenta fuertemente el riesgo que aparece
a la hora de desarrollar software. Para ello, se comienza mirando las posibles alternativas de desarrollo, se
opta por la de riesgo más asumible y se hace un ciclo de la espiral. Si el cliente quiere seguir haciendo
mejoras en el software, se vuelve a evaluar las distintas nuevas alternativas y riesgos y se realiza otra vuelta
de la espiral, así hasta que llegue un momento en el que el producto software desarrollado sea aceptado y
no necesite seguir mejorándose con otro nuevo ciclo.

HISTORIA

El creador del modelo en espiral fue Barry Boehm quien recibió su grado de B.A. de Harvard en 1957, y sus
grados de M.S. y de Ph.D. de UCLA en 1961 y 1964, todo en matemáticas.
Barry Boehm era un Programador-Analista en General Dynamics entre 1955 y 1959, sus intereses actuales
de la investigación incluyen modelar de proceso del software, ingeniería de requisitos del software, las
arquitecturas del software, métrica del software y los modelos del coste, los ambientes de la tecnología de
dotación lógica, y tecnología de dotación lógica basada en el conocimiento.

DEFINICION

El MODELO en espiral, es un modelo de proceso de software evolutivo donde se conjuga la naturaleza de

construcción de prototipos con los aspectos controlados y sistemáticos del MODELO LINEAL y SECUENCIAL.
Proporciona el potencial para el desarrollo rápido de versiones incrementales del software que no se basa
en fases claramente definidas y separadas para crear un sistema.

En el modelo espiral, el software se desarrolla en una serie de versiones incrementales. Durante las
primeras iteraciones la versión incremental podría ser un modelo en papel o un prototipo, durante las
últimas iteraciones se producen versiones cada vez más completas del sistema diseñado.

EL modelo en espiral se divide en un número de actividades de marco de trabajo, también llamadas

REGIONES DE TAREAS , Cada una de las regiones están compuestas por un conjunto de tareas del trabajo
llamado CONJUNTO DE TAREAS que se adaptan a las características del proyecto que va a emprenderse en
todos los casos se aplican actividades de protección.

TIPOS
El modelo espiral tuvo varias modificaciones que son:

• Modelo Original de Boehm.

• Modelo Tipico de Seis Regiones.
• Modelo WINWIN.

MODELO ORIGINAL DE BOEHM

No hay un número definido de iteraciones. Las iteraciones debe decidirlas el equipo de gestión de proyecto

Cada vuelta se divide en 4 sectores:

• Planeación : determinación de los objetivos, alternativas y restricciones

• Análisis de riesgo : análisis de alternativas e identificación/resolución de riesgos
• Ingeniería: desarrollo del producto hasta "el siguiente nivel".
• Evaluación: valoración por parte del cliente de los resultados obtenidos.

El movimiento de la espiral, ampliando con cada iteración su amplitud radial, indica que cada vez se van
construyendo versiones sucesivas del software, cada vez más completas.

Uno de los puntos más interesantes del modelo, es la introducción al proceso de desarrollo a las actividades
de análisis de los riesgos asociados al desarrollo y a la evaluación por parte del cliente de los resultados del
software.

MODELO TIPICO DE SEIS REGIONES

A diferencia del modelo de proceso clásico que termina cuando se entrega el software, el modelo en espiral
puede adaptarse y aplicarse a lo largo de la vida del software de computadora. Una visión alternativa del
modelo en espiral puede ser considerada examinando el eje de punto de entrada en el proyecto.
Las regiones de tareas que componen este modelo son:

• 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 otras informaciones
relacionadas con el proyecto. Son todos los requerimientos.
• Análisis de riesgos: las tareas requeridas para evaluar riesgos técnicos y otras informaciones
relacionadas con el proyecto.
• Ingeniería: las tareas requeridas para construir una o más representaciones de la aplicación.
• Construcción y adaptación: las tareas requeridas para construir, probar, instalar y proporcionar
soporte al usuario.
• 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
implementación durante la etapa de instalación.

MODELO WINWIN

El modelo en espiral WINWIN de Boehm, define un conjunto de actividades de negociación al principio de

casa paso alrededor de la espiral. Más que una simple actividad de comunicación con el cliente se definen
las siguientes actividades:

• Identificación del sistema o subsistemas clave de los directivos.

• Determinación de las condiciones de victoria de los directivos.
• Negociación de las condiciones de victoria de los directivos para reunirlas en un conjunto de
condiciones para todos los afectados (incluyendo el equipo del proyecto de software).

El modelo en espiral WINWIN introduce tres hitos en el proceso, llamados puntos de fijación que ayudan a
establecer la completitud de un ciclo alrededor del espiral y proporcionan hitos de decisión antes de
continuar el proyecto de software.

VENTAJAS

• El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de

computadora.
• Como el software evoluciona a medida que progresa el proceso, el desarrollador y el cliente
comprenden y reaccionan mejor ante riesgos en cada uno de los nivele evolutivos.
• El modelo en espiral permite a quien lo desarrolla aplicar el enfoque de construcción de
prototipos en cualquier etapa de evolución del producto.
 • El modelo en espiral demanda una consideración directa de los riesgos técnicos en todas las
etapas del proyecto y si se aplica adecuadamente debe reducir los riesgos antes de que se
conviertan en problemas.
• En la utilización de grandes sistemas ha doblado la productividad.

DESVENTAJAS

• El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de

computadora.
• Como el software evoluciona a medida que progresa el proceso, el desarrollador y el cliente
comprenden y reaccionan mejor ante riesgos en cada uno de los nivele evolutivos.
• El modelo en espiral permite a quien lo desarrolla aplicar el enfoque de construcción de
prototipos en cualquier etapa de evolución del producto.

METODO AGIL

ASD (ADAPTIVE SOFTWARE DEVELOPMENT)

1. INTRODUCCION
La técnica de Adaptive software Development fue desarrollada por Jim Highsmith
y Sam Bayer a comienzos de 1990. Esta metodología se adapta al cambio en
lugar de luchar contra él. Se basa en la adaptación continua a circunstancias
cambiantes. En ella no hay un ciclo de planificación-diseño-construcción del
software, sino un ciclo especular colaborar-aprender.
2. DEFINICION
El método ágil ASD (Adaptive Software Development) traducido en español
significa Desarrollo Adaptable de Software es un modelo de implementación de
patrones ágiles para desarrollo de software. Al igual que otras metodologías
ágiles, su funcionamiento es cíclico y reconoce que en cada iteración se
producirán cambios e incluso errores.

El desarrollo de software adaptable (Adaptive Software Development - ASD) es

una metodología de desarrollo que hace énfasis en aplicar las ideas que se
originaron en el mundo de los sistemas complejos, adaptación continua del
proceso al trabajo.
3. CARACTERISITICAS
Sus principales características del ASD son:

• Iterativo.
 • Orientado a los componentes de software (la funcionalidad que el
producto va a tener, características, etc.) más que a las tareas en las que
se va a alcanzar dicho objetivo.
• Tolerante a los cambios.
• Guiado por los riesgos
• La revisión de los componentes sirve para aprender de los errores y volver
a iniciar el ciclo de desarrollo.
4. CICLO DE VIDA
ASD utiliza un "cambio orientado hacia el ciclo de vida", que tiene tres
componentes que son: especular colaborar y aprender.

Especular

Una primera fase de iniciación para establecer los principales objetivos y metas
del proyecto en su conjunto y comprender las limitaciones (zonas de riesgo) con
las que operará el proyecto.
En ASD se realizan estimaciones de tiempo sabiendo que pueden sufrir
desviaciones. Sin embargo, estas son necesarias para la correcta atención de
los trabajadores que se mueven dentro de plazos de forma que puedan priorizar
sus tareas.
Se decide el número de iteraciones para consumir el proyecto, prestando
atención a las características que pueden ser utilizadas por el cliente al final de
la iteración. Son por tanto necesarios, marcar objetivos prioritarios dentro de las
mismas iteraciones.
Estos pasos se puede volver a examinar varias veces antes de que el equipo y
los clientes están satisfechos con el resultado.
Colaborar

Es la fase donde se centra la mayor parte del desarrollo manteniendo una

componente cíclica. Un trabajo importante es la coordinación que asegure que
lo aprendido por un equipo se transmite al resto y no tenga que volver a ser
aprendido por los otros equipos.
Aprender

La última etapa termina con una serie de ciclos de colaboración, su trabajo

consiste en capturar lo que se ha aprendido, tanto positivo como negativo. Es un
elemento crítico para la eficacia de los equipos.
Jim Highsmith identifica cuatro tipos de aprendizaje en esta etapa:

• Calidad del producto desde un punto de vista del cliente.

• Calidad del producto desde un punto de vista de los desarrolladores.
• La gestión del rendimiento.
• Situación del proyecto.
VENTAJAS Y DESVENTAJAS
Ventajas

• La tercera fase del ciclo de vida, revisión de los componentes, sirve para
aprender de los errores y volver a iniciar el ciclo de desarrollo.
• Apunta hacia el Rapid Application Development (RAD), el cual enfatiza
velocidad de desarrollo para crear un producto de alta calidad, bajo
mantenimiento involucrando al usuario lo más posible.
• Utiliza información disponible acerca de cambios para mejorar el
comportamiento del software.
Desventajas

• Aunque el ciclo entre el aprendizaje y la especulación es bueno

permitiéndonos entregar productos con alta calidad, la prolongación de
dicho ciclo por errores o cambios que no son detectados en reuniones
anteriores afecta tanto a la calidad del producto como a su costo total.
• Dado a que es una metodología ágil implica no realizar procesos que son
requeridos en las metodologías tradicionales o por lo menos no realizarlos
en procesos diferentes, lo cual implica que empresas grandes las cuales
necesitan llevar un mayor control a procesos y personas, tener tareas
asignadas a un estado o proceso especifico, y en las cuales dicho
incremento de procesos no afectan en gran medida al costo final del
producto, para dichas empresas el elegir una metodología tradicional
resulta mucho más rentable tanto por el gran volumen de personal, de
productos, y de costos que se manejan y para los cuales se tendrá un
mayor control.

5. CONCLUSION
Es un concepto que se puede usar en las empresas cambiantes como lo son las
vendedoras de productos al menudeo, que donde cada día están rotando sus
necesidades de acuerdo a la oferta y demanda, en este tipo de desarrollo es
probable que el cliente este pidiendo adecuaciones continuamente, el ciclo de
vida de esta metodología es dirigible y fácil de implementar
Usado de manera adecuada esta metodología (Adaptive Software Development)
se puede alcanzar excelentes resultados pero debido a las características que
maneja es más factible usarla para proyectos pequeños y medianos, para
adquirir práctica y experiencia para así poder llegar al Rapid Application
Development (RAD) en donde tendremos productos de alta calidad.

FDD