Libro-Modelos de Procesos de Desarrollo de Software

Modelos de Procesos
De Desarrollo de
Software
Universidad Distrital
Correo electrónico: Tel.: [3239300]
[espingsoftware@udistrital.edu.co] Carrera 7 No. 40B - 53,
Sitio web: [www.udistrital.edu.co] Bogotá D.C., República
de Colombia 11021
2
Modelo de
Prototipos
Capítulo 1
3
TABLA DE CONTENIDO
Autores________________________________________________________ 2
MODELO DE PRÓTOTIPOS ______________________________________ 5
Definición _____________________________________________________________ 5
Prototipo Desechable __________________________________________________ 6

Prototipo Evolutivo ____________________________________________________ 7
Características _________________________________________________________ 9
Personajes ___________________________________________________________ 10
Antecedentes del Modelo de Prototipos ____________________________________ 11
Etapas General del Modelo de Prototipo ____________________________________ 12
Comunicación _______________________________________________________ 12
Plan rápido _________________________________________________________ 12
Modelo diseño rápido _________________________________________________ 13
Construcción del prototipo _____________________________________________ 13
Desarrollo, entrega y retroalimentación ___________________________________ 13
Tipos de Modelo de Prototipo ____________________________________________ 14

Ventajas y Desventajas Modelo de Prototipo ________________________________ 14
Ejemplos de Éxito ____________________________________________________ 15
Preguntas ____________________________________________________________ 16
BIBLIOGRAFIA _______________________________________________________ 18
4
AUTORES
Ing. Stephania Moreno Vidal
Correo: stefiluna@gmail.com
Cód.: 20192099016
Ing. Harold David Hurtado Cortes

Correo: harolddavidhurtado@gmail.com
Cód.: 20192099011
Ing. Jhonattan Alexander Diaz Duarte

Correo: jhonalex123@gmail.com
Cód.: 20192099009
Ing. Mauricio Sandoval Parra

Correo: maosanpar@gmail.com
Cód.: 20192099022
Ing. Jorge Eliecer Sierra Torres

Correo: eliecer_2323@ hotmail.com
Cód.: 20141020140
Evaluador: MSc. Alexandra Abuchar Porras

Asignatura: Ingeniería de Software I
Posgrado: Especialización en ingeniería de Software
5
MODELO DE PRÓTOTIPOS
Definición
El modelo de procesos de desarrollo de software basado en prototipos forma parte de los
modelos lineales o secuenciales, los cuales ofrecen grandes facilidades para controlar el
progreso de un proyecto, proponiendo un enfoque sistemático y secuencial para el
desarrollo de software.
Es por esto por lo que se usa un prototipo como modelo auxiliar experimental de un sistema
o de un componente de un sistema que permite realizar pruebas de soluciones parciales
de los requisitos de un sistema. Son un medio eficaz para aclarar los requisitos de los
usuarios e identificar las características que deben cambiar o añadirse y asegurar que el
producto final cumpla con las expectativas previstas. A diferencia de otros modelos de
proceso, el objetivo del modelo basado en prototipos es entender los requerimientos del
usuario y trabajar para mejorar la calidad de estos, comenzando por definir los requisitos
que no están claros para el usuario y usar un prototipo para experimentar con ellos,
permitiendo así ayudar a terminar de definir los requerimientos.
Figura 1. Tipos de Prototipo y su Definición [1]

6
Prototipo Desechable
Figura 2. Prototipo Desechable [1]
Figura 3. Modelo Prototipado Desechable [1]

7
Prototipo Evolutivo
Figura 4. Prototipo Evolutivo. [1]
Figura 5. Modelo Prototipado Evolutivo [1]
Los modelos de prototipado interactivo tiene la bondad de:
 Los desarrollos orientados a objetos se ajustan a un modelo de proceso iterativo e

incremental.
 Se puede argumentar lo mismo para los desarrollos basados en componentes.
 Las tareas de cada fase se llevan a cabo de una forma iterativa.
 A la vez que existe un ciclo de desarrollo análisis-diseño, implementación-análisis

que permite hacer evolucionar al sistema.
8
 En el desarrollo incremental el sistema se divide en un conjunto de Particiones.
 Cada una se desarrolla de forma completa hasta que se finaliza el sistema.
Esta idea de interactividad máxima propia de la orientación a objetos ha sido equiparada

por autores como James Rumbaugh (1992) o L. B. S. Raccoon (1995) a los fractales o la
teoría del caos.
Figura 6. Dimensión Incremental – Evolutivo [1]

9
Figura 7. Dimensión Iterativo – Evolutivo [1]
Características
El modelo de prototipo se caracteriza por:
Figura 8. Características del Prototipo [1]

10
Personajes
 Hassan Gomaa: s profesor de ciencias de la computación e ingeniería de software en la
Universidad George Mason. Gomaa tiene más de treinta años de experiencia en
ingeniería de software, tanto en la industria como en el mundo académico. Ha publicado
más de 170 documentos técnicos y es autor de tres libros: Diseño de líneas de productos
de software con UML; Diseño de aplicaciones concurrentes, distribuidas y en tiempo
real con UML; y métodos de diseño de software para sistemas concurrentes y en tiempo
real. [2]
 Kristen Nygaard: (Nacido el 27 de agosto de 1926, Oslo, Nor., Fallecido el 10 de agosto

de 2002, Oslo), matemático noruego e informático que inventó, con su compañero de
trabajoOle-Johan Dahl, el lenguaje de programación de computadoras SIMULA, que
utilizaba módulos de datos, llamados "objetos", para procesar datos de manera más
eficiente de lo que era posible con instrucciones de software complejas anteriores.
Mientras trabajaba en el Centro de Computación de Noruega (NCC) en la década de

1960, sentó las bases para el resto de la programación orientada a objetos, incluyendo
los lenguajes de programación como C ++ y Java y las interfaces gráficas de usuario,
tales como Apple Inc. 's Mac OS y Microsoft Corporation ‘s del sistema operativo
Windows. [3]
 Donald Chamberlin: (Nacido el 12 de octubre de 1931, Mandal, Nor., Fallecido el 29 de

junio de 2002, Asker), informático noruego que fue cocreador del primer lenguaje de
programación orientado a objetos, con su colega de toda la vida Kristen Nygaard. Dahl
y Nygaard fueron creados comandantes de la Orden de San Olav en 2000, y
compartieron el Premio AM Turing 2001, el más alto honor en informática, y la Medalla
John Von Neumann del Instituto de Ingenieros Eléctricos y Electrónicos de 2002. [3]
11
Figura 9. Personajes que influyeron en el modelo de Prototipo [2] [3] [4]
Antecedentes del Modelo de Prototipos
Durante la década de los 70 se daba respuesta a proyectos grandes y con requisitos

establecidos a la exactitud, pero la ingeniería de los 80 se relacionó con proyectos de
requisitos poco claros y dinámicos que daban lugar a la creación de prototipos.
El modelo de ciclo de vida de prototipos fue propuesto por Gomaa en 1984. Un prototipo es
un mecanismo para identificar los requisitos del software.[3]
12
Etapas General del Modelo de Prototipo

El modelo de prototipos consta de las siguientes etapas [5]:
Figura 10. Etapas del modelo de prototipo [5]
Comunicación
En esta etapa inicial se tiene una interacción con el cliente para evaluar la petición del
software y determinar si el programa a desarrollar es un buen candidato para construir un
prototipo. Debido a que el cliente debe interaccionar con el prototipo para determinar el
refinamiento del proyecto. [5]
En esta etapa lo esencial es determinar el problema y su ámbito, la importancia y los efectos

potenciales que tendrán sobre la organización, identificar una idea general de la solución
para realizar un estudio de factibilidad que determine la factibilidad de una solución
software. [5]
Plan rápido
Cuando se tienen que los resultados de un proyecto son aceptables, se procede a

desarrollar una representación abreviada de los requerimientos. Antes de que pueda
13
comenzar la construcción de un prototipo, en este se debe representar los dominios

funcionales y de información del programa. La aplicación de estos principios de análisis
fundamentales, pueden realizarse mediante los métodos de análisis de requerimientos. [5]
Modelo diseño rápido
Después de que se haya revisado la representación de los requerimientos, se crea un

conjunto de especificaciones de diseño abreviadas para el prototipo. El diseño debe ocurrir
antes de que comience la construcción del prototipo. Sin embargo, el diseño de un prototipo
se enfoca normalmente hacia la arquitectura a nivel superior y a los aspectos de diseño de
datos. [5]
Construcción del prototipo
El software del prototipo se crea, se prueba y se corrigen idealmente todos los posibles
errores, los bloques de construcción de software preexisten se utilizan para crear el
prototipo de una forma rápida y se determina si un prototipo es funcional o no.
Para las aplicaciones interactivas con el usuario, es posible frecuentemente crear un
prototipo en papel que describa la interacción hombre-máquina. [5]
Desarrollo, entrega y retroalimentación
Una vez que el prototipo ha sido probado, se presenta al cliente, el cual "conduce la prueba"
de la aplicación y sugiere modificaciones. Este paso es el núcleo del método de
construcción de prototipo. Es aquí donde el cliente puede examinar una representación
implementada de los requerimientos del programa, sugerir modificaciones que harán al
programa cumplir mejor las necesidades reales. [6]
14
Tipos de Modelo de Prototipo

Los modelos de prototipo se caracterizan en siete tipos, los cuales son:
Figura 11. Tipos de Modelos Prototipados [6]
Ventajas y Desventajas Modelo de Prototipo
Las ventajas que encontramos al implementar el modelo de desarrollo de software

basado en prototipos son:
Ventajas Desventajas
El conocimiento adquirido al Al desarrollar por prototipos, los

desarrollar por prototipos puede desarrolladores se arriesgan a no
llevar a reducciones en el costo de comprender totalmente el
producción a futuro cuando se funcionamiento del sistema y aun así
desarrolle el software. se debe realizar la entrega del
producto.
Se ajusta mejor al cambio, cuando Cuando se desarrolla por prototipos,

los requerimientos sufren se realiza un énfasis mayor en la
variaciones. interfaz del usuario y se debe
realizar el desarrollo en un tiempo
15
reducido (También se puede omitir

procesos de calidad y
mantenimiento).
Al realizar la integración entre el A veces se quiere proyectar el

equipo de desarrollo y el usuario desarrollo del producto final,
final, se logra que las tomando como base el prototipo
especificaciones del proyecto se (Omitiendo los procesos de calidad
acerquen mucho más a lo esperado y mantenimiento que requiere un
al final del proyecto. producto de software completo).
Al presentarse un prototipo, no se Erróneamente, el usuario puede

hace necesario que el sistema se tan creer que el prototipo es el sistema
grande ni robusto como pudiera final.
esperarse, adicional se reduce la
probabilidad de construir productos
que no satisfagan las necesidades
especificadas.
Se realiza el desarrollo en una A veces se piensa que,

cantidad de tiempo menor, desarrollando prototipos, se pierden
reduciendo los costos de producción esfuerzos valorados en tiempo y
y aumentando la probabilidad de costos.
éxito del producto.
Figura 12. Tipos de Modelos Prototipados [7] [8] [9]
Ejemplos de Éxito
Google Glass
Google no es una empresa que carece de recursos. Cuando

preguntaron a las personas cuánto tiempo creen que le tomó a
Google crear un prototipo de su Google Glass (es cierto que
ahora está archivado), la respuesta más común es un par de
meses. Pero Tom Chi, jefe de Google X, reveló que el equipo
construyó un prototipo de Google Glass en solo un día, usando
una percha, una pieza de plexiglás y un pico proyector
conectado a una computadora portátil.
El propósito del prototipo era simplemente probar cuál es la

experiencia de tener información digital superpuesta en el
16
mundo físico, al estilo de un "informe minoritario". No era

particularmente ergonómico, ni era atractivo, pero hizo el único
trabajo de forma rápida y económica con trozos y piezas por
todas partes.
Preguntas
1. El modelo de prototipo es una modelo auxiliar experimental de un sistema o de un

componente de un sistema que permite realizar pruebas de soluciones parciales de los
requisitos de un sistema.
a. Verdadero.
b. Falso.
2. Que personajes influyeron o crearon el modelo de prototipo.

a. Hassan Gomaa.
b. Kristen Nygaard.
c. Ole-Johan Dahl.
d. Todas las anteriores.
3. En qué año se fue propuesto el modelo de prototipo.

a. 1960
b. 1984
c. 1991
d. Ninguna de las anteriores
4. Cuáles de estas fases no corresponden a las fases del modelo de prototipo.

a. Recolección y Refinamiento de Requisitos y Diseño Rápido.
b. Construcción del Prototipo y Evolución del Prototipo por el Cliente.
c. Refinamiento del Prototipo y Producción de Ingeniería.
d. Pruebas del Prototipo.
5. En qué fase se realiza la retroalimentación del modelo de prototipo.

a. Evolución del prototipo por el cliente.
b. Construcción del prototipo.
c. Refinamiento del prototipo.
d. Ninguna de las anteriores.
17
6. Los modelos de prototipo se caracterizan en siete tipos.

a. Verdadero.
b. Falso.
7. El modelo de prototipo no reduce la probabilidad de construir productos que no

satisfagan las necesidades especificadas.
a. Verdadero.
b. Falso.
8. El modelo de prototipo tiene la desventaja de que erróneamente, el usuario puede

creer que el prototipo es el sistema final.
a. Verdadero.
b. Falso.
9. Cuales son los tipos de modelo de prototipo:

a. Prototipos Rápidos
b. Prototipos Evolutivo
c. Ninguna de las anteriores.
10. El modelo de prototipo es mucho más efectivo que el modelo en cascada, ya que de
forma casi inmediata cumple con los requisitos del cliente.
a. Verdadero.
b. Falso.
Respuestas:
1. Verdadero.
2. Todas las anteriores.
3. 1984.
4. Pruebas del Prototipo.
5. Refinamiento del prototipo.
6. Verdadero.
7. Falso.
8. Verdadero.
9. Todas las anteriores.
10. Verdadero.
18
BIBLIOGRAFIA
[1] F. José and G. Peñalvo, “Ingeniería de software i,” 2019.

[2] George Mason University, “Hassan Gomaa | George Mason Department of Computer
Science,” 2019. [Online]. Available: https://cs.gmu.edu/directory/detail/15/. [Accessed: 06-
Oct-2019].
[3] History MCS, “Kristen Nygaard (1926-2002),” 2019. [Online]. Available: https://www-
history.mcs.st-andrews.ac.uk/Biographies/Nygaard.html. [Accessed: 06-Oct-2019].
[4] J. Palme, “Uses of the SIMULA process concept,” Softw. Pract. Exp., vol. 12, no. 2, pp. 153–
161, Feb. 1982.
[5] Grupo 7, “~ MODELOS DE PROCESOS DEL SOFTWARE.” [Online]. Available:
http://inf162grupo7.blogspot.com/2016/03/5deff3f0871a486jpg.html. [Accessed: 06-Oct-
2019].
[6] Segundo modelo, “MODELO DE CONSTRUCCION DE PROTOTIPOS.” [Online]. Available:
http://segundomodelo.blogspot.com/2013/05/modelo-de-prototipos-este-modelo-
no.html?m=1. [Accessed: 06-Oct-2019].
[7] EcuRed, “Modelo de prototipos - EcuRed,” 2019. [Online]. Available:
https://www.ecured.cu/Modelo_de_prototipos. [Accessed: 06-Oct-2019].
[8] MindMeister, “CICLO DE VIDA MODELO EN PROTOTIPO | MindMeister Mapa Mental,”
2019. [Online]. Available: https://www.mindmeister.com/es/743817444/ciclo-de-vida-
modelo-en-prototipo. [Accessed: 06-Oct-2019].
[9] D. Gutierrez, “Métodos de Desarrollo de Software,” Univ. los Andes, pp. 2–107, 2011.
19
Modelo DRA
Capítulo 2
20
TABLA DE CONTENIDO
Autores_______________________________________________________ 21
Definición ____________________________________________________________ 22
Fases Del Modelo De Desarrollo Rápido De Aplicaciones ______________________ 23
Características ________________________________________________________ 24
Personajes ___________________________________________________________ 26
Ejemplos ____________________________________________________________ 27
Casos De Estudio _____________________________________________________ 27
Herramientas _________________________________________________________ 29
Ventajas y Desventajas _________________________________________________ 30
Ventajas ___________________________________________________________ 31
Desventajas ________________________________________________________ 32
PREGUNTAS _________________________________________________________ 34
BIBLIOGRAFÍA ________________________________________________ 37
21
AUTORES
Ing. Jorge Mario Perez /osorio
Correo: jmperezosorio17@gmail.com
Cód.: 20192099018
Ing. Oscar Eduardo Calderón

Correo: oecproyecto@gmail.com
Cód.:

22
MODELO DE DESARROLLO RÁPIDO DE

APLICACIÓNES - DRA
Definición
Es un modelo de desarrollo de software incremental que enfatiza en que el ciclo de

desarrollo es extremadamente corto. El modelo RAD es una adaptación de la modelo línea
secuencial en cual el desarrollo rápido de aplicaciones es logrado usando componentes
reutilizables. Si los requerimientos están claros y el alcance del proyecto está definido el
modelo RAD permite que el equipo de desarrollo crear un sistema totalmente funcional en
periodo aproximadamente 60 a 90 días [20].
Este modelo prioriza la rápida implementación de un prototipo y rápida retroalimentación

durante largos ciclos de desarrollo y pruebas. Con rápidos y frecuentes despliegues los
desarrolladores pueden hacer múltiples interacciones y actualizaciones del software sin la
necesidad de iniciar el desarrollo desde cero cada vez [21].
Fig. 12: modelo de desarrollo rápido de aplicaciones.
RAD se enfatiza en la entrega del proyecto en pequeñas piezas, entre más grande sea
proyecto es dividido en una serie de pequeños proyectos, unas principales características
es que se enfoca en el rehusó de plantillas, herramientas procesos y código [22].
23
Fig. 13: proceso del modelo de desarrollo rápido de aplicaciones.
Fases Del Modelo De Desarrollo Rápido De Aplicaciones

El modelo de Desarrollo Rápido de Aplicaciones se caracteriza por el cumplimiento de
ciertas fases que se describen a continuación [23]
Fig. 14: Fases de desarrollo rápido de aplicaciones.

24
Características
Las características del Modelo RAD pueden categorizarse así [5]:
Fig. 15: Características RAD

25
Iterar hasta acabar
Fig. 16: Flujo iterativo de RAD
Herramientas Especializadas
Fig. 17: Herramientas comunes.

26
Personajes
Los personajes principales que se destacan en el desarrollo del Modelo de Desarrollo

Rápido de Aplicaciones se presentan en la siguiente figura:
Fig. 18: Personajes destacados.
Las ideas de Martin fueron desarrolladas y mejoradas por pioneros de RAD como James
Kerr y Richard Hunter, quienes juntos escribieron el libro seminal sobre el tema, Inside RAD,
que siguió el viaje de un gerente de proyecto RAD mientras conducía y refinaba el RAD
Metodología en tiempo real en un proyecto RAD real. Estos profesionales, y aquellos como
ellos, ayudaron a RAD a ganar popularidad como una alternativa a los enfoques de ciclo de
vida de proyectos de sistemas tradicionales [23, 24].
27
Ejemplos
El enfoque RAD ofrece grandes beneficios a un equipo que está familiarizado con la filosofía
ágil, tiene un proyecto relativamente pequeño para implementar y tiene clientes o usuarios
dispuestos a comprometerse a ser parte de todo el proyecto de desarrollo [25].
 Empresa necesita implementar un proyecto de desarrollo de software a mayor

escala: asegura el compromiso de sus usuarios para brindar una participación profunda.
 Orden de compra: Recopilar datos para pedidos de compra y aprobarlos como un
proceso que le brinde más que una funcionalidad básica.
 Solicitud de viaje: El último ejemplo de RAD que veremos es Solicitud de viaje. Esta
puede ser utilizada de manera más amplia por toda la compañía cada vez que alguien
viaja por negocios oficiales.
Más recientemente, el término y sus siglas se han utilizado en un sentido genérico más
amplio que abarca una variedad de técnicas destinadas a acelerar el desarrollo de
aplicaciones, como el uso de marcos de aplicaciones web y otros tipos de marcos de
software [26].
Casos De Estudio
Fig. 19: Casos de estudio de aplicación del Modelo RAD
El desarrollo rápido de aplicaciones es particularmente útil para las pequeñas empresas

que necesitan que el software se realice rápidamente, mientras que tienen una gran
28
cantidad de información durante el proceso de desarrollo. Dentro de estos casos de

estudios se encuentran:
Centric Consulting
Un desarrollador familiarizado con el desarrollo rápido de aplicaciones y las metodologías
de desarrollo ágil, solucionando un requerimiento de un software para que una empresa
interactuara con sus clientes, el cual tenía más de 35,000 empleados, para adquisiciones,
facturación y pago. Centric Consulting pudo utilizar metodologías de desarrollo de
aplicaciones ágiles y rápidas para comprender rápidamente lo que el cliente necesitaba,
acelerar el proceso de desarrollo y mantener los costos bajos con la infraestructura de
código abierto. A lo largo del proceso de desarrollo, el cliente pudo proporcionar información
sobre las funcionalidades requeridas. Todas esas funcionalidades se agregaron
rápidamente a medida que se exigían, y finalmente, el producto se entregó al cliente [26].
D. Dinadasa
El Desarrollo rápido de aplicaciones (RAD) utilizado originalmente para describir un
proceso de desarrollo de software desarrollado por primera vez e implementado con éxito
a mediados de la década de 1970 por D. Dinadasa en el Centro de Desarrollo de Sistemas
de Getahetta Telephone Co bajo la dirección de Dan Gielan. Tras una serie de
implementaciones notablemente exitosas de este proceso, Gielan dio numerosas
conferencias en varios foros sobre la metodología, la práctica y los beneficios de este
proceso [27].
BT/Face
El proyecto se llevó a cabo en el contexto de una gran empresa de servicios públicos
privados en el Reino Unido. El sistema constaba de un diario, un módulo de gestión de
proyectos y un "manual" de gestión de proyectos. Al aplicar RAD, este proyecto fue, por lo
tanto, inusual al usar editores HTML y el lenguaje de script PERL UNIX como herramientas
de desarrollo primarias en comparación con el lenguaje de cuarta generación, ingeniería de
software asistida por computadora (CASE), sistema de administración de bases de datos
(DBMS) tipo de kit de herramientas [28].
Barclays
Es una institución financiera del Reino Unido que dirige un gran centro de desarrollo en el
Reino Unido con 3000 empleados. En este centro, si bien el centro de desarrollo tenía
control general sobre grandes proyectos de desarrollo, carecía de control sobre proyectos
29
de pequeña a mediana escala. Por lo tanto, los miembros del nuevo grupo de tecnología
dentro del centro de desarrollo de Barclays propusieron RAD como una posible forma de
corregir este problema. Esencialmente, el equipo de desarrollo utilizó una herramienta de
procesamiento analítico en línea (OLAP) para desarrollar un sistema de información
ejecutiva (EIS) [28].
UGCS
Este proyecto se realizó en el contexto de una pequeña organización comercial que emplea
aproximadamente a cuarenta personas. El negocio principal de la empresa es vender y
ofrecer cursos de capacitación para el comercio y la industria. Antes de este proyecto, la
organización no tenía experiencia interna en TI. La intención de este proyecto era
desarrollar un sistema de información para apoyar el trabajo del equipo de ventas y
marketing de la organización. Cuando se llevó a cabo el proyecto, ambos miembros del
equipo de desarrollo no tenían experiencia previa en RAD. Lo interesante de este proyecto
es, la forma en que el proyecto falló en algunos aspectos clave de idoneidad para RAD. Por
ejemplo, el equipo de desarrollo no tenía experiencia previa en métodos o herramientas
RAD, los requisitos no estaban claros y el grupo de usuarios estaba inicialmente mal
definido. Además los representantes de los usuarios se comprometieron con el proceso de
revisión y comentarios del usuario muy pronto en el proceso [28].
Universidad de Glamorgan
Este proyecto se realizó en el contexto de una universidad del Reino Unido. La universidad
utiliza sistemas de información poco sistemáticos para apoyar los procesos organizativos
básicos de enseñanza, investigación y consultoría. El equipo de desarrollo estaba formado
por dos desarrolladores y dos representantes de usuarios. A pesar de que algunos
miembros del proyecto tenían experiencia previa en RAD (experiencia en el uso de
prototipos y herramientas de desarrollo rápido), el proyecto satisfizo las necesidades de la
Universidad [28].
Herramientas
En la actualidad se utiliza para referirse al desarrollo rápido de interfaces gráficas de

usuario, entornos de desarrollo integrado completos [29]. Algunas de las plataformas
conocidas, incluso en el área de la autoría multimedia que proveen plataformas de
30
desarrollo rápido de aplicaciones, dentro de ciertos límites. Otros ejemplos de software de

desarrollo rápido de aplicaciones (RDA) son [30, 31]:
Fig. 20: Herramientas comunes
En la actualidad se utiliza para referirse al desarrollo rápido de interfaces gráficas de

usuario, entornos de desarrollo integrado completos. Algunas de las plataformas
conocidas, incluso en el área de la autoría multimedia que proveen plataformas de
desarrollo rápido de aplicaciones, dentro de ciertos límites [31].
Ventajas y Desventajas
En los entornos modernos de tecnología de la información, muchos sistemas ahora se

construyen utilizando cierto grado de desarrollo rápido de aplicaciones (no necesariamente
el enfoque de James Martin). Además del método de Martin, los métodos ágiles y el proceso
unificado racional se utilizan a menudo para el desarrollo de RAD [32].
31
Fig. 21: Ventajas y desventajas del Modelo RAD.
Ventajas
 Mejor calidad. Al hacer que los usuarios interactúen con prototipos en evolución, la
funcionalidad empresarial de un proyecto RAD a menudo puede ser mucho mayor. El
software puede ser más utilizable y tiene una mejor oportunidad de enfocarse en
problemas críticos para los usuarios finales en lugar de problemas técnicos de interés
para los desarrolladores.
 Control del riesgo. Aunque gran parte de la literatura sobre RAD se centra en la
velocidad y la participación del usuario, una característica crítica de RAD realizada
correctamente es la mitigación de riesgos. Un enfoque RAD puede enfocarse temprano
en los factores de riesgo clave y ajustarse a ellos con base en la evidencia empírica
recolectada en la primera parte del proceso.
 Más proyectos terminados a tiempo y dentro del presupuesto. Al centrarse en el
desarrollo de unidades incrementales, se reducen las posibilidades de fallas
32
catastróficas. En el modelo RAD, la información se puede descubrir antes en el proceso

de análisis y desarrollo que requería un replanteamiento radical de todo el sistema [33].
 Menor codificación manual.
 Adecuado para entornos de TI en expansión. RAD facilita un entorno de desarrollo
uniforme de bajo código en la que los departamentos funcionales y desarrolladores de
aplicaciones trabajan juntos. Una vez que los usuarios están expuestos a las diversas
funcionalidades, puede realizar ajustes sin proporcionar ningún esfuerzo/capacitación
adicional.
Desventajas
Al igual que con otros tipos de creación de prototipos, las dificultades con RAD surgen
debido a que los analistas de sistemas tratan de apurar demasiado el proyecto [34]. Otras
de las desventajas de RAD incluyen:
 El riesgo de un nuevo enfoque. Para la mayoría de empresas, RAD supone un nuevo

enfoque que requería profesionales experimentados para repensar la forma en que
trabajaban. Los desarrolladores son casi siempre reacios a lo diferente y cualquier
proyecto emprendido con nuevas herramientas o métodos, y tendrá más probabilidades
de fracasar la primera vez simplemente por el requisito de que el equipo aprenda.
 Falta de énfasis en los requisitos no funcionales, que a menudo no son visibles para el
usuario final en el funcionamiento normal.
 Requiere un gran número de recursos. Una cosa que prácticamente todos los enfoques
de RAD tienen en común es que hay mucha más interacción a lo largo de todo el ciclo
de vida entre usuarios y desarrolladores [34]. En RAD, los usuarios participan desde el
principio y prácticamente a través de todo el proyecto.
 Menos control. Una de las ventajas de RAD es que proporciona un proceso flexible y
adaptable. Lo ideal es poder adaptarse rápidamente tanto a los problemas como a las
oportunidades. Hay una compensación inevitable entre flexibilidad y control, más de uno
significa menos del otro.
 Mal diseño. El enfoque en los prototipos puede llevarse demasiado lejos en algunos
casos, lo que resulta en una metodología de "pirateo y prueba" en la que los
desarrolladores realizan constantemente cambios menores en los componentes
individuales e ignoran los problemas de la arquitectura del sistema que podrían dar
como resultado un mejor diseño general. [35, 36].
 Falta de escalabilidad. RAD normalmente se enfoca en equipos de proyectos pequeños
a medianos. Los otros problemas citados anteriormente (menos diseño y control)
presentan desafíos especiales cuando se utiliza un enfoque RAD para sistemas a gran
escala [37, 38, 39].
33
 No todos los tipos de aplicaciones son apropiados para DRA. Si un sistema no se puede
modularizar adecuadamente, la construcción de los componentes necesarios para DRA
será problemático. Si está en juego el alto rendimiento, y se va a conseguir el
rendimiento convirtiendo interfaces en componentes de sistemas, el enfoque DRA
puede que no funcione. DRA no es adecuado cuando los riesgos técnicos son altos.
Esto ocurre cuando una nueva aplicación hace uso de tecnologías nuevas, o cuando el
software nuevo requiere un alto grado de interoperatividad con programas de
computadora ya existentes [40, 41].
Tabla. Ventajas y desventajas del modelo RAD
Ventajas Desventajas
Flexible y adaptable a los cambios. No se puede utilizar para proyectos más
pequeños.
Es útil cuando tiene que reducir el riesgo No todas las aplicaciones son compatibles
general del proyecto. con RAD
Es adaptable y flexible a los cambios. Cuando el riesgo técnico es alto, no es
adecuado.
Es más fácil transferir entregas a medida Si los desarrolladores no se comprometen
que se utilizan scripts, abstracciones de a entregar el software a tiempo, los
alto nivel y códigos intermedios. proyectos RAD pueden fallar
Debido a los generadores de código y la Funciones reducidas debido al tiempo de
reutilización del código, hay una reducción boxeo, donde las funciones se envían a una
de la codificación manual. versión posterior para finalizar un
lanzamiento en un período corto
Debido a la creación de prototipos en la La escalabilidad reducida ocurre porque
naturaleza, existe la posibilidad de defectos una aplicación desarrollada por RAD
menores. comienza como un prototipo y evoluciona
hacia una aplicación terminada
Cada fase en RAD ofrece la funcionalidad El progreso y los problemas
de mayor prioridad al cliente. acostumbrados son difíciles de rastrear, ya
que no hay documentación que demuestre
lo que se ha hecho.
Con menos personas, la productividad se Requiere diseñadores o desarrolladores
puede aumentar en poco tiempo. altamente calificados
34
PREGUNTAS
1. Del Modelo RAD es correcto decir:

a. Es un modelo de desarrollo de software incremental que enfatiza en que el
ciclo de desarrollo es extremadamente corto.
b. El modelo RAD es una adaptación de la modelo línea secuencial en cual el
desarrollo rápido de aplicaciones es logrado usando componentes
reutilizables.
c. Este modelo prioriza la rápida implementación de un prototipo y rápida
retroalimentación durante largos ciclos de desarrollo y pruebas.
2. Seleccione cuál de los siguientes Principios Básicos no corresponde al Modelo RAD:
a. La participación activa de los usuarios es imprescindible.
b. Iterativamente realiza la producción de software, en lugar de enfocarse en un
prototipo.
c. Produce la documentación necesaria para facilitar el futuro desarrollo y
mantenimiento.
d. El método comprende el desarrollo NO ITERATIVO.
3. En La etapa de Modelado de gestión se basa en dar respuesta a algunas preguntas.
Seleccione cuál no corresponde a la mencionada etapa:
a. ¿Qué información conduce el proceso de gestión?
b. ¿Qué información genera?
c. ¿Quién tiene la información?
d. ¿Quién la procesa?
4. ¿Cuál de los siguientes autores no realizó por sus aportes a la construcción del
Modelo RAD?
a. Edsger Dijkstra
b. James Kerr
c. Richard Hunter
d. James Martin
5. Una de las siguientes Herramientas Especializadas no corresponde al Modelo RAD.
Seleccione la opción:
a. Desarrollo "visual".
b. Creación de prototipos falsos (simulación pura).
c. Creación de prototipos no funcionales.
35
d. Múltiples lenguajes.
6. El proceso de Iteración en el Modelo RAD satisface una serie de actividades hasta
acabar. Seleccione cuál actividad no corresponde al modelo en cuestión:
a. Los desarrolladores construyen y depuran el prototipo basado en los
requisitos actuales.
b. Los diseñadores no revisan el prototipo.
c. Los clientes prueban el prototipo, depuran los requisitos.
d. Los clientes y desarrolladores se reúnen para revisar juntos el producto,
refinar los requisitos y generar solicitudes de cambios.
7. ¿Cuál de las siguientes herramientas de Software, conocidas por su implementación
del Modelo RAD, no hace parte de este grupo?
a. Glade
b. Visual Studio
c. OutSystems
d. Java
8. ¿Por qué se considera como una ventaja del Modelo RAD, respecto a sus similares,
que proporciona Mejor calidad?
a. Debido a que al hacer que los usuarios interactúen, el software puede ser más
utilizable y tiene una mejor oportunidad de enfocarse en problemas
comerciales que son críticos para los usuarios finales.
b. Porque excluye otras categorías de lo que generalmente se conoce como
requisitos no funcionales que incluyen seguridad y portabilidad.
c. Se enfoca en problemas comerciales que son críticos para los problemas
técnicos de interés para los desarrolladores.
d. No se puede utilizar para proyectos más pequeños.
9. ¿Es el Modelo RAD caracterizado por dar prioridad a la mitigación de riesgos?
a. Aunque gran parte de la literatura sobre RAD se centra en la velocidad y la
participación del usuario, una característica de RAD no es la mitigación de
riesgos.
b. Un enfoque RAD puede enfocarse temprano en los factores de riesgo clave y
ajustarse a ellos con base en la evidencia empírica recolectada en la primera
parte del proceso.
c. La complejidad de crear prototipos de algunas de las partes más complejas
del sistema, no garantiza la mitigación de riegos según la confiabilidad del
modelo.
d. Ninguna de las anteriores.
10. ¿Cuál de las siguientes es una desventaja del Modelo RAD?
36
a. No se puede utilizar para proyectos más grandes.

b. Ninguna de las aplicaciones son compatibles con RAD.
c. Cuando el riesgo técnico es alto, no es adecuado.
d. Si los desarrolladores no se comprometen a entregar el software a tiempo, los
proyectos RAD no pueden fallar.
PREGUNTA RESPUESTA
1 D
2 D
3 C
4 A
5 C
6 B
7 D
8 A
9 B
10 C
37
BIBLIOGRAFÍA
[1] I. Pilar Alexandra Moreno, I. Alexandra Aparicio Revisado Editado, and I. Jairo Martínez,
“Ingeniería de Software,” 2012.
[2] J. A. Millán Goméz, “Definición Ténicas de Cuarta Generación.” Universidad Distrital,
Bogota,Colombia, p. 1, 2019.
[3] N. X. Ceferino Orjuela, “Categorías Técnicas de Cuarta Generación.” Universidad Distrital,
[4] N. X. Ceferino Orjuela, “Caracteristicas Técnicas de Cuarta Generación.” Universidad
Distrital, p. 1, 2019.
[5] J. A. M. Gomez, “Personajes Técnicas de Cuarta Generación.” Universidad Distrital,
[6] J. A. Millán Goméz, “Antecedentes Técnicas de Cuarta Generación.” Universidad Distrital,
[7] E. Gómez Vargas, “Ingeniería de Software.” Universidad Distrital, Bogota,Colombia, p. 94,
2016.
[8] J. A. Millán Goméz, “Etapas Técnicas de Cuarta Generación.” Universidad Distrital,
[9] J. A. Millán Goméz, “Ventajas y Desventajas Técnicas de Cuarta Generación.” Universidad
Distrital, Bogota,Colombia, p. 1, 2019.
[10] J. Pradel Miquel and J. Raya Matos, “Introducción a la ingeniería de software.” UNISTMO,
Mexico, p. 84, 2011.
[11] J. A. Millán Goméz, “Ejemplos Ténicas de Cuarta Generación.” Universidad Distrital,
[12] F. Phillips, “Review: Wolfram Mathematica 7,” MacWorld, 2009. [Online]. Available:
https://www.macworld.com/article/1138219/mathematica_7.html.
[13] F. A.Morteo and B. L.E, UN ENFOQUE PRACTICO DE SQL, Primera. Argentina: Ediciones
Cooperativas, 2004.
[14] J. Sadd, “OpenEdge Development : Progress 4GL Handbook,” EE.UU, 2005.
[15] P. Lannigan, “PowerBuilder History, Powersoft History,” lannigan, 2014. [Online]. Available:
http://www.lannigan.org/powersoft_powerbuilder_history.htm.
[16] G. Rifkin, “Sybase To Acquire Powersoft,” The New York Times, 1994. [Online]. Available:
https://www.nytimes.com/1994/11/15/business/sybase-to-acquire-powersoft.html.
[17] V. Ashlee, “SAP to Buy Sybase, Ally in Software,” The New York Times, 2010. [Online].
Available:
https://www.nytimes.com/2010/05/13/technology/13sap.html?mtrref=www.google.com&gwh
=7AE51C1CFF7DFF82E21B14F95420B74F&gwt=pay&assetType=REGIWALL.
[18] M. Berner, “Appeon Signs Agreement with SAP to Bring Major Innovations to PowerBuilder,”
Cision, 2016. [Online]. Available: https://www.prnewswire.com/news-releases/appeon-signs-
agreement-with-sap-to-bring-major-innovations-to-powerbuilder-300291905.html.
[19] A. Iglesias Fraga, “Cuando un ERP falla: 5 escenarios de caos motivados por errores de
implementación,” TICbeat, 2017. [Online]. Available:
https://www.ticbeat.com/tecnologias/cuando-un-erp-falla-5-escenarios-de-caos-motivados-
por-errores-de-implementacion/.
[20] J. Martin, Rapid application development. Macmillan Pub. Co., 1991.
[21] “Rapid Application Development: Definition, Steps, Advantages and Case Study.” [Online].
Available: https://kissflow.com/rad/rapid-application-development/. [Accessed: 22-Sep-
2019].
[22] “What is RAD Model? Advantages & Disadvantages.” [Online]. Available:
https://www.guru99.com/what-is-rad-rapid-software-development-model-advantages-
disadvantages.html. [Accessed: 22-Sep-2019].
[23] “DRA :: Modelos.” [Online]. Available: https://modelosdesoftware.webnode.es/dra/.
[Accessed: 22-Sep-2019].
[24] Martin, James (1991). Rapid Application Development. Macmillan. ISBN 0-02-376775-8.
[25] J.M. Kerr; R. Hunter(1993). Inside RAD: How to Build a Fully Functional System in 90 Days
or Less. McGraw-Hill. ISBN 0-07-034223-7.
[26] Kissflow.com. Rapid Application Development: How Developers Work. Tomado
38
de: https://kissflow.com/rad/rapid-application-development/, 2018.

[27] Wikipedia contributors. Rapid application development. In Wikipedia, the Free Encyclopedia.
Retrieved September, 2019,
from https://en.wikipedia.org/w/index.php?title=Rapid_application_development.
[28] P. Beynon-Davies, C. Carne, H. Mackay and D. Tudhope. Rapid application development
(RAD): An empirical review. European Journal of Information Systems. 8.
10.1057/palgrave.ejis.3000325, 1999.
[29] A. Begel and N. Nagappan. "Usage and Perceptions of Agile Software Development in an
Industrial Context: An Exploratory Study, Microsoft Research" (PDF), 2008.
[30] FO. RAD: Examples of Rapid Application Development Software. Tomado de: https://rapid-
application-development.financesonline.com/#types, 2018.
[31] E. M. Maximilian and L. Williams. "Assessing Test-driven Development at IBM". Proceedings of
International Conference of Software Engineering, Portland, OR, pp. 564-569, 2003.
[32] “Metodologia RAD - Inicio.” [Online]. Available: http://metodologiarad.weebly.com/.
[33] K. Beck. Extreme Programming Explained. Addison Wesley. pp. 3–7. ISBN 0201616416, 2000.
[34] K. Kendall and J. Kendall. Análisis y Diseño de Sistemas, Octava Edición. Prentice Hall, 2011.
[35] G. Pantaleo and L. Rinaudo. Ingeniería de Software. Editorial Alfaomega Grupo Editor, 2015.
[36] A. Gerber, A. Van Der Merwe and R. Alberts. "Practical Implications of Rapid Development
Methodologies". Proceedings of the Computer Science and Information technology Education
Conference, CSITEd-2007. Computer Science and IT Education Conference. Mauritius. pp.
233–245. ISBN 978-99903-87-47-6, 2007.
[37] Andrew Begel, Nachiappan Nagappan. "Usage and Perceptions of Agile Software
Development in an Industrial Context: An Exploratory Study" (PDF).
doi:10.1109/esem.2007.12. Retrieved 15 November 2008.
[38] Maximilien, E.M.; Williams, L. (2003). "Assessing test-driven development at IBM". 25th
International Conference on Software Engineering, 2003. Proceedings. pp. 564–569.
doi:10.1109/icse.2003.1201238. ISBN 0-7695-1877-X.
[39] Stephens, Matt; Rosenberg, Doug (2003). Extreme Programming Refactored: The Case
Against XP. doi:10.1007/978-1-4302-0810-5. ISBN 978-1-59059-096-6.
[40] R. S. Pressman. Ingeniería Del Software: Un Enfoque Practico (5a. Ed.). Madrid: Mcgraw-Hill
Interamericana, 2002.
[41] M. Stephens and D. Rosenberg. "Extreme Programming Re factored: The Case Against XP".
Apress, 2003.
39
Modelo Evolutivo
Capítulo 3
40
MODELO EVOLUTIVO ______________________________________________ 42

1. DEFINICIÓN ............................................................................................................ 42
2. CARACTERÍSTICAS ............................................................................................... 43
3. HISTORIA ................................................................................................................. 43
4. PERSONAJES ........................................................................................................... 45
5. FASES ....................................................................................................................... 46
5.1 Modelo por prototipos ........................................................................................ 46

5.2 Modelo Espiral ................................................................................................... 47
5.3 Modelo incremental ............................................................................................ 47
6. VENTAJAS Y DESVENTAJAS .............................................................................. 48
6.1 Modelo por Prototipos ........................................................................................ 48

6.2 Modelo Espiral ................................................................................................... 49
6.3 Modelo Concurrente ........................................................................................... 50
7. EJEMPLOS................................................................................................................ 50
8. CASOS EXITOSOS .................................................................................................. 51
8.1 IFX Networks S.A.S ........................................................................................... 51

8.2 Skandia ............................................................................................................... 51
8.3 Consorcio HGC .................................................................................................. 51
9. PREGUNTAS MODELO EVOLUTIVO.................................................................. 52

10. RESPUESTAS A PREGUNTAS FORMULADAS .............................................. 53
41
AUTORES
Ing. Niddya Yazmín Peña cañón

Correo: nidiapc129@gmail.com
Cód.: 20192099017
Ing. Andrés Calderón

Correo: calderonacr@gmail.com
Cód.: 20192099003
Ing. Edwar Giovanny Castillo

Correo: edwarshiro@gmail.com
Cód.: 20192099005
Ing. Leonardo Sebastián Ruiz Rodríguez

Correo: heraldocoild@gmail.com
Cód.: 20192099021
Ing. Cristhian Alirio Torres Rojas

Correo: cristhiant92@gmail.com
Cód.: 20191099020

42
MODELO EVOLUTIVO
1. DEFINICIÓN
El Modelo Evolutivo está diseñado explícitamente para adaptarse a un producto que evoluciona con
el tiempo. Los modelos evolutivos son iterativos; genera en cada iteración una versión final cada vez
más completa del software. [1]
Figura 1. Definición de Modelo Evolutivo
Figura 2.
Flujo de proceso evolutivo
43
2. CARACTERÍSTICAS
El Modelo de Proceso Evolutivo se caracteriza por:
Figura 3. Características del Modelo Evolutivo
3. HISTORIA
La década de los 40 marca el inicio de la primera generación de computadoras y con ellas la serie
de programas y sistemas que éstas requieren para funcionar, las primeras prácticas de desarrollo
se basaban únicamente en desarrollar de cualquier forma con tal de cumplir los requerimientos del
cliente sin seguir una metodología, esto acarreaba una gran cantidad de problemas de costos,
tiempos, talento humano. Posterior a esto surgen los lenguajes de programación, en tres
generaciones diferentes, una primera generación es lenguaje de máquina, la segunda lenguaje
ensamblador. La tercera lenguajes de programación de alto nivel. A pesar de que en ese momento
se empieza a hablar de analistas programadores y de sistemas, no se tenía una manera clara de
controlar los avances de los proyectos, no existían fases especificas durante el mismo. A finales de
los 60, marca el inicio de una concienciación sobre la necesidad de establecer controles para el
correcto avance de los sistemas, así como la necesidad de documentación. El primer modelo
conocido como “Code and Fix” o codificar y corregir el cual se consideró como una base inicial
para la fabricación del Software, en cuanto al diseño, codificación, la depuración y los métodos de
prueba, hasta el entregable.
En 1968, tras una conferencia en Garmisch (Alemania) surge el término “Ingeniería del Software”
pero los métodos de desarrollo aún eran informales. En 1972 Edsger Dijkstra, presenta su trabajo
titulado “The Humble Programmer” y junto a otros autores publicaría luego el artículo “Go to
44
statement considered harmful”, junto a su libro “Discipline of Programming”, y sienta las bases
para la creación de las metodologías tradicionales conocidas y aún usadas hasta hoy, además, de
ciertos parámetros para el desarrollo del Software de forma exitosa que, algunos de sus postulados
son:
 El coste del desarrollo inicial debe ser relativamente bajo.
 El software debe ser fácil de mantener.
 Cualquier desarrollo debe de ser portable a nuevo hardware.
 El software debe hacer lo que el cliente quiere.
 El desarrollo de programas mediante top-down y en contraposición a bottom-up.
 El desarrollo debe seguir un conjunto de pasos formales para descomponer los
problemas grandes (lema divide y vencerás).
En 1975 reconocen el clico de vida del desarrollo del Software, como un consenso formal para la
construcción de sistemas, así que define los estados por los que debe pasar un producto de desarrollo
desde su inicio a partir de un requerimiento, hasta su finalización luego de su mantenimiento. Las
fases son: Necesidades, Diseño, Desarrollo, Prueba, Lanzamiento, y Mantenimiento
Para finales de los 70, la ingeniería del Software se refuerza mediante la implementación de
“modelos” que dividen el proyecto en etapas: inicio, desarrollo, pruebas, lanzamiento y
mantenimiento. Para cada etapa se crean normativas y parámetros. Aparecen entre 1970 y 1988 los
“modelos tradicionales de desarrollo de software.” (Cascada, desarrollo evolutivo, componentes)
[5].
Modelos de DS Metodologías Tradicionales de DS
Modelo de Cascada  RUP (Rational Unified Process)
Modelo Cascada en “V”  RAD (Rapid Application Development)
Modelo de Desarrollo Evolutivo (Espiral)  MSF (Microsoft Solution Framework)
Modelo de Desarrollo Evolutivo por Prototipo Ingeniería de la información
 Structured System Analysis and Design
Desarrollo Evolutivo por etapas o Incremental Method (SSADM)
Desarrollo Evolutivo Iterativo  Win-Win Spiral Model
Modelo Basado en Componentes  Iconix
 Desarrollo de sistemas de Jackson
(JSD).
Tabla 1. Modelos DS y Metodologías Tradicionales de DS
MODELO ESPIRAL: 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,
en matemáticas. Uno de sus aportes fue el modelo espiral del proceso del software. El cual
lo dio a conocer en 1986 en su artículo “A Spiral Model of Software Development and
Enhancement” Boehm.
45
 MODELO DE DESARROLLO CONCURRENTE: Este modelo de desarrollo surge debido

a las críticas que tenía el modelo de desarrollo de cascada por lo restrictivo y rígido que era
dificultando el desarrollo de proyectos de software moderno. Es propuesto por David Sitaram
principalmente para aplicaciones cliente/servidor y su concurrencia.
 MODELO INCREMENTAL: Propuesto por lls en 1980. Sugirió el enfoque como un método
para reducir la repetición del trabajo durante el proceso de desarrollo y de esta forma
retrasar la toma de decisiones en los requisitos para adquirir experiencia con el sistema.
4. PERSONAJES
 Roger S Preesman: Es una de las autoridades internacionales en el mejoramiento del proceso de

software y en las tecnologías de la ingeniería del mismo. Especializando en la creación de
aplicaciones de ingeniería y fabricación avanzada como CAD/CAM.
A su vez ha tenido posiciones responsables en el desarrollo de aplicaciones científicas y de
sistemas, cuando recibió el título en su doctorado en ingeniería en la universidad de Connecticut
se convirtió en maestro del programa Bullard de la universidad de Bridgeport y director del centro
de diseño y fabricación asistido por computadora de la misma [6].
 Frederick Phillips Brooks Jr: Científico informático estadounidense y ganador del premio AM
tuning en 1999, que es el más alto honor en informática por su hito contribuciones a la
arquitectura de computadoras, sistemas operativos e ingeniería de software”. En 1956 recibió su
doctorado en matemáticas aplicadas en la universidad de Harvard donde fue pionero de la
computadora Howard Aiken. Después de recibir su título se unió a IBM para trabajar en el IBM
7030 (conocido como Stretch), ordenada por la Agencias Nacional de Seguridad de los Estados
Unidos[7].
 Barry W. Hoehm: Es un distinguido profesor de informática, matemáticas, ingeniería industrial,
ingeniería de sistemas y aeronáutica en la universidad del sur de California, también es director
fundador del centro de Ingeniería de sistemas y software de la USC. Recibió su licenciatura en la
universidad de Harvard en 1957, su maestría y doctorado. Grados de la UCLA. Estando en la
USC dicto un curso de proyectos de ingeniería de software para clientes reales con el cual ha
podido completar alrededor de 200. Debido a su perfil de investigación obtuvo 25 becas en
empresas industriales y ha educado a las de 2000 estudiantes en un enfoque hacia la ingeniería
del software [8].
 Ian Sommerville: Nació en Glasgow, escocia y estudio en la universidad de Strathclyde (BSc
Physics) y la universidad St Andrews. en 1975 – 78 ejerció la docencia en informática Heriot-
Watt, Edimburgo, en 1978 – 1986 en la universidad de Strathclyde, Glasgow, en 1986 – 2006 se
dedicó a enseñar ingeniería del software en el departamento de computación en la universidad de
46
Lancaster Inglaterra. En el año de 2006 se unió a la universidad de Andrews y se retiró en 2014

[9].
 Harlan D Mills: Fue reconocido por sus aportes a las matemáticas y al desarrollo de software.
Antes de su muerte era el director del instituto de sistemas de información en Vero Beach, Florida.
Trabajo en IBM desde 1964 – 1987 como director de ingeniería y tecnología de software. A su
vez se le conoció por ser el creador de la transferencia de tecnología de sala limpia y el concepto
del equipo programador, aplico también el desarrollo incremental y estadística a las pruebas de
software con lo cual pudo plantear las pruebas estadísticas de uso y certificado de calidad [10].
5. FASES
Entre los modelos de proceso evolutivo, como se mencionó anteriormente se encuentran el modelo
por prototipos y el modelo espiral. Cada uno de estos modelos tiene sus propias fases como se muestra
a continuación:
5.1 Modelo por prototipos
Figura 4. Fases modelo por prototipos [1] - [4]

47
5.2 Modelo Espiral
Figura 5. Fases modelo espiral [1]
5.3 Modelo incremental
Figura 6. Fases Modelo Incremental [2].

48
6. VENTAJAS Y DESVENTAJAS
6.1 Modelo por Prototipos
Figura 7. Ventajas y Desventajas Modelo por Prototipos[1]. Fuente: Autor

49
6.2 Modelo Espiral
Figura 8. Ventajas y Desventajas Modelo Espiral[4].Fuente: Autor

50
6.3 Modelo Concurrente
Figura Ventajas y Desventajas Modelo Concurrente. Fuente: Autor
Figura 9. Ventajes y desventajas del modelo concurrente[1]. Fuente: Autor
7. EJEMPLOS
Creación de interfaces para la generación de reportes.

Sistemas Operativos- Que generen actualizaciones sobre el mismo para mejorar la
experiencia y corregir errores
Interfaces de utilización del humano para una actividad específica.
Formularios de ingreso y salida de información del sistema.
Entregables de utilidad para el cliente y vitales para el mismo Parches de corrección de
errores.
Tabla 2. Ejemplos de modelos evolutivos
51
8. CASOS EXITOSOS
8.1 IFX Networks S.A.S

Empresa del sector de las telecomunicaciones que ofrece servicios de Cloud Computing y telefonía
en varios países de Sudamérica y Estados Unidos. Esta empresa en su área de TI desarrolla aplicativos
para la gestión interna, los cuales utilizan el modelo evolutivo e incremental para su desarrollo [11].
8.2 Skandia
Un grupo experto en el mercado de servicios financieros. El área de sistemas de Skandia, se encarga

de desarrollar y mantener funcionalidades para uso propio de sus sistemas de información. El
desarrollo de estos aplicativos se da mediante la utilización del modelo evolutivo e incremental, ya
que los requerimientos internos de Skandia necesitan que estos aplicativos se desarrollen
constantemente con entregas con soluciones funcionales para satisfacer las necesidades internas [11].
8.3 Consorcio HGC

En consorcio HGC se tiene una comunicación frecuente con el cliente y con los usuarios del sistema,
lo que permite tener una retroalimentación constante de los requerimientos, en búsqueda de la mejora
del software.
En esta compañía se han implementado los modelos por prototipo y el modelo incremental-evolutivo
gracias a que tienen proyectos de licitación con Fonade y la agencia nacional de minería [11].
52
9. PREGUNTAS MODELO EVOLUTIVO
1. ¿Quién el creador del modelo en espiral?

A. Roger S Pressman
B. Barry Boehm
C. Edsger Dijkstra
D. Charles Babage
2. ¿En qué año se reconoce el ciclo de vida del desarrollo del Software?
A. 1976
B. 1981
C. 1975
D. 1973
3. El Modelo Evolutivo está diseñado para:

A. Entregar versiones incompletas del producto final, que permiten al usuario evaluar su
funcionalidad
B. Generar en cada iteración una versión final cada vez más completa del software.
C. Adaptar a un producto que evoluciona con el tiempo o que cambia en sus requerimientos.
D. A y B son correctas.
E. Todas las anteriores
4. En un flujo del Proceso Evolutivo las actividades se realizan en forma lineal y secuencial,
permitiendo llevar a una versión más completa del software.
A. Verdadero
B. Falso
5. ¿Cuál de las siguientes no es una frase del Modelo por Prototipos?

A. Comunicación
B. Construcción del Prototipo
C. Despliegue
D. Plan Rápido
6. ¿Cuál es la fase inicial del Modelo espiral?
A. Modelado
B. Despliegue
C. Planeación
D. Comunicación
7. Son ventajas del Modelo por Prototipos:

A. Ajustar costos según la retroalimentación
B. Se pueden ejecutar diferentes actividades simultáneamente
C. A y D son correctas
D. Reducción del riesgo
8. En el Modelo Espiral se puede llegar a perder tiempo al iniciar nuevamente con una iteración
A. Verdadero
B. Falso
9. ¿Qué Modelo es utilizado en IFX Networks?

A. Espiral
B. Cascada
C. Incremental
D. Concurrente
53
10. Relacione el tipo del modelo que corresponde al enfoque reducir la repetición del trabajo en el
proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta
adquirir experiencia con el sistema.
A. Modelo por Prototipos
B. Modelo Espiral
C. Modelo Incremental
10. RESPUESTAS A PREGUNTAS FORMULADAS
PREGUNTA RESPUESTA
1 B
2 C
3 E
4 B
5 C
6 D
7 C
8 A
9 C
10 C
11. REFERENCIAS
[1] Roger S. Pressman. (2010). Ingeniería Del Software I, un enfoque práctico. México D.F.
McGraw-Hill.
[2] Ingeniería de Software (2011), Modelos de procesos evolutivos de software. Recuperado de
https://ingenieriasoft.webcindario.com.
[3] Ingeniería de Software I. (2010, Agosto 16). Recuperado de
http://jorgetrejos.blogspot.com/2010/08/modelo-evolutivo.html
[4] Recuperado de https://sites.google.com/site/is11801/contenido/modelos-de-proceso-evolutivo
[5] Evolución de las Metodologías y Modelos utilizados en el Desarrollo de Software - Johanna
Patricia Zumba Gamboa Cecibel Alexandra León Arreaga - Universidad de Guayaquil - INNOVA
Research Journal 2018, Vol 3, No. 10, 20-33
[6] R. S. Pressman, Ingenieria del Software. Un Enfoque Practico. 2010.

[7] Britannica, “Fred Brooks | Biography, A.M. Turing Award, & Facts | Britannica.com.”
[Online]. Available: https://www.britannica.com/biography/Fred-Brooks. [Accessed: 02-Oct-
2019].
[8] C. for S. and S. E. Engineering, “Barry W. Boehm - CSSE.” [Online]. Available:
https://csse.usc.edu/new/barry-w-boehm. [Accessed: 03-Oct-2019].
54
[9] I. Sommerville, “Sobre mí - Sistemas, software y tecnología.” [Online]. Available:

https://iansommerville.com/systems-software-and-technology/about-me/. [Accessed: 03-Oct-
2019].
[10] I. C. Society, “Sobre Harlan D. Mills | IEEE Computer Society.” [Online]. Available:
https://www.computer.org/volunteering/awards/mills/about-mills. [Accessed: 04-Oct-2019].
[11] Quintero G., González H., Ariza S. (2014). Estudio del modelo de desarrollo implementado en
las empresas: IFX Networks S.A.S., Consorcio HGC, Skandia. Recuperado de
https://revistas.udistrital.edu.co/index.php/tia/article/view/4978.
55
Métodos formales
Capítulo 4
56
TABLA DE CONTENIDO
Autores_______________________________________________________ 57
METODOS FORMALES _________________________________________ 58
1. Definición __________________________________________________________ 58
2. Historia ____________________________________________________________ 59
3. ¿Para qué métodos formales? __________________________________________ 60
4. Personajes _________________________________________________________ 60
Robert Floyd ________________________________________________________ 60

Charles Antony Richard Hoare__________________________________________ 61
Edsger Dijkstra ______________________________________________________ 62
5. Métodos de especificación formal _______________________________________ 62
a) Especificaciones formales:___________________________________________ 62
b) Pruebas formales: _________________________________________________ 63
c) Comprobación de modelo: ___________________________________________ 63
d) Abstracción: ______________________________________________________ 63
6. Características ______________________________________________________ 63
7. Ventajas y desventajas _______________________________________________ 64
8. Casos de éxito y no éxito ______________________________________________ 65
Seguridad de un aeropuerto ____________________________________________ 65

La calidad de normas. ________________________________________________ 65
Chip de firmware para incrustación de teléfonos móviles: _____________________ 65
Dispositivos de firma digital de seguros ___________________________________ 65
Sistema de metro en parís controlado por software __________________________ 66
Casos de no éxito _____________________________________________________ 66

Bibliografía ___________________________________________________________ 68
57
AUTORES
Ing. Carlos Alberto Beltrán Melo
Correo: cbeltranm16@gmail.com
Cód.: 20192099002
Ing. Daniel Mayorga Valbuena

Correo: daniel.m.mayorga.v@gmail.com
Cód.: 20192099014
Ing. Maritza Celis Baracaldo

Correo: marcee14@hotmail.com
Cód.: 20192099007
Ing. John Fredy Castellanos

Correo: john.castellanos@tecnofcatory.com.co
Cód.: 20192099004
Ing. Raul Chaparro Reyes

Correo: xxcelux4@gmail.com
Cód.: 20192099008
Ing. Edwin Yesid Hernández Salazar

Correo: edwin.hs182@gmail.com
Cód.: 20192099010

58
METODOS FORMALES
1. Definición
En su libro Software Quality Engineering: A Practitioner’s Approach, Pressman define los
métodos formales como:
El modelo de métodos formales agrupa actividades que llevan a la especificación
matemática formal del software de cómputo. Los métodos formales permiten especificar,
desarrollar y verificar un sistema basado en computadora por medio del empleo de una
notación matemática rigurosa.
Cuando durante el desarrollo se usan métodos formales, se obtiene un mecanismo para
eliminar muchos de los problemas difíciles de vencer con otros paradigmas de la
ingeniería de software. Lo ambiguo, incompleto e inconsistente se descubre y corrige con
más facilidad, no a través de una revisión ad hoc sino con la aplicación de análisis
matemático. Si durante el diseño se emplean métodos formales, éstos sirven como base
para la verificación del programa, y así permiten descubrir y corregir errores que de otro
modo no serían detectados [1].
Aunque el modelo de los métodos formales no es el más seguido, promete un software
libre de defectos y ha ganado partidarios entre los desarrolladores que deben construir
software de primera calidad en seguridad (por ejemplo, control electrónico de aeronaves y
equipos médicos), y entre los desarrolladores que sufrirían graves pérdidas económicas si
ocurrieran errores en su software.
Ejemplo:
59
2. Historia
El uso de las matemáticas para la resolución de problemas cotidianos del hombre se
remonta a las primeras civilizaciones de la humanidad, de igual manera los métodos
formales tienen sus orígenes en la antigua Grecia a continuación, se describe una breve
historia de los métodos formales.
Los métodos formales se remontan a la antigua Grecia con Euclides quien definió la
geometría a través de un método axiomático, donde se comienza con un axioma o
postulado, que tomamos como evidente, y usamos la lógica para razonar hacia nuestro
teorema usando "reglas" que previamente habían demostrado ser verdaderas. Si siempre
aplicamos solo las transformaciones lógicas permitidas, entonces la conclusión a la que
llegamos al final, nuestro teorema, debe ser correcta.
Los métodos formales para la ingeniería de sistemas informáticos funcionan de la misma
manera.
En ciencias de la computación, los métodos formales comenzaron, sobre una base
teórica, a fines de los años sesenta y principios de los setenta, cuando el uso
generalizado de la informática todavía estaba en pañales. Los matemáticos teóricos
observaban la programación de computadoras, todavía relativamente simple en ese
momento, y observando su estructura matemática vieron la opción de aplicar la teoría de
conjuntos.
A Tony Hoare se le atribuye generalmente la introducción de métodos formales a la
informática con su artículo An Axiomatic Basis for Computer Programming y su invención
de la lógica Hoare. La lógica Hoare y métodos formales similares funcionan de manera
muy similar al álgebra. Incluso hacen uso de leyes algebraicas, como las propiedades
asociativas, conmutativas y distributivas. Aplica la misma transformación en ambos lados
del signo igual, y ambos lados de la ecuación permanecen iguales.
Los métodos formales no ganaron mucha acogida con la industria hasta la década de
1990. Antes de eso, las computadoras y los programas de computadora eran
relativamente simples, mientras que los métodos formales eran primitivos y difíciles de
aplicar. Las pruebas siguieron siendo el medio más eficiente de verificación del sistema.
Luego, los errores de programación comenzaron a poner a las empresas en serios
problemas.
La aplicación de los métodos formales ha tardado en madurar. De hecho, todavía están
evolucionando. Por ahora, es bastante difícil aplicar métodos formales al código fuente
completo de aplicaciones integradas a
60
gran escala. Convertir archivos fuente grandes y complejos, como un programa de control
de vuelo, por ejemplo, en un lenguaje de métodos formales sigue siendo una tarea
desalentadora, ardua y que consume mucho tiempo [3].
3. ¿Para qué métodos formales?
Figura 1 Métodos Formales [4]
4. Personajes
Robert Floyd
Fue un científico informático de natalidad estadounidense que durante su vida realizo
numerosas investigaciones que sirvieron de gran influencia en la industria del
software,fue quien propuso utilizar el “método de aserciones intermedias” como
herramienta para analizar y estudiar propiedades de software, a su vez le brindo
importancia de definir la semántica de las operaciones.(“Professor
Robert W. Floyd | Stanford Computer Science,” n.d.)
61
Charles Antony Richard Hoare

Es un científico británico de computación, es más conocido en el mundo informático como
Tony Hoare, es reconocido por la invención de “QuickSort” que es un algoritmo de
ordenamiento y es ampliamente utilizado, consiste en ordenar listas de elementos en
donde de un problema grande divide a pequeños problemas que se resuelven uno tras
otro. Le intrigaba el poder de la lógica matemática y su exactitud para la resolución de
cualquier problema, fue quien perfecciono las Ideas de Robert Floyd en Métodos
Formales.
(“Computer Pioneers - Charles Antony Richard Hoare,” n.d.)
62
Edsger Dijkstra
Fue un científico en computación de los países bajos, siempre considero realizar una
carrera en derecho y representar a su país en las naciones unidas, pero en 1965 dios sus
primeros pasos profesionales en las ciencias de la computación, creador del algoritmo de
Dijkstra, la rotación polaca inversa y el relacionado algoritmo shutingYard, en 1976
Presento algo denominado “Precondición más débil” el cual es un método formal con
base a la transformación de predicados.(“Edsger Dijkstra | IEEE
Computer Society,” n.d.)
5. Métodos de especificación formal
a) Especificaciones formales:
 Traducción de una descripción no matemática
(diagramas, tablas, texto) a un lenguaje de especificación forma
 Descripción concisa del comportamiento de alto
nivel y las propiedades de un sistema
63
 Una semántica de lenguaje bien definida admite

la deducción formal sobre la especificación.
b) Pruebas formales:
 Argumento completo y convincente para la validez
de alguna propiedad de la descripción del sistema.
 Construido como una serie de pasos, cada uno de
los cuales se justifica a partir de un pequeño conjunto de reglas.
 Elimina la ambigüedad y la subjetividad
inherentes al extraer conclusiones informales.
 Puede ser manual pero generalmente construido
con asistencia automatizada.
c) Comprobación de modelo:
 Operativo en lugar de analítico
 El modelo de máquina de estado de un sistema se
expresa en un lenguaje adecuado.
 El verificador de modelos determina si el modelo
de máquina de estado finito determinado satisface los requisitos expresados
como fórmulas en un método lógico dado.
 El objetivo es explorar todas las rutas
accesibles en un árbol computacional derivado del modo de máquina de estado.
d) Abstracción:
 Simplifique e ignore los detalles irrelevantes.
 Enfoque y generalice las propiedades y características centrales importantes.
 Evite el compromiso prematuro con las opciones de diseño e implementación.
6. Características
El modelo de métodos formales agrupa actividades que llevan a la
especificación matemática:
 Permitir especificar, desarrollar y verificar los sistemas en forma sistemática.
 Reducir considerablemente la cantidad de errores mientras el Software se diseña y
construye.
 Describe las propiedades del Sistema.
 Consistencia, completitud y falta de ambigüedad.
64
 Interpretar los requerimientos o el diseño sólo en una forma, lo que elimina la

ambigüedad que con frecuencia ocurre cuando un lector debe interpretar un
lenguaje natural.
 Permiten un enunciado claro de los requerimientos.
 Conducir al software a una calidad notablemente alta.
 Usa la especificación de estructura de cajas para el análisis y el modelado del
diseño, y enfatiza la verificación de la exactitud, en lugar de las pruebas, como el
mecanismo primario para encontrar y remover errores.
 Uso de cajas negras para representar el comportamiento externamente observable
de un sistema.
 Uso de cajas de estado para encapsular los datos y operaciones de estado.
 Uso caja clara para modelar el diseño procedural que se implica mediante los
datos y operaciones de una caja de estado
 No enfatiza las pruebas de unidad o de integración.
 Usar las facilidades descriptivas de la teoría de conjuntos y la notación lógica para
permitir que un ingeniero de software cree un enunciado claro de los
hechos(Requerimientos).
7. Ventajas y desventajas
A continuación se detallan las ventajas y desventajas que presenta el uso del método
formal.
65
Figura 2 Ventajas y desventajas del método formal [5]
8. Casos de éxito y no éxito

Los casos de éxito son aplicados en su gran mayoría en sistemas de transporte, sistemas
de información, telecomunicaciones, plantas de energía o protocolo de seguridad, es
decir, en todos los proyectos donde prevalezca la seguridad y la vida de las personas.
Algunos de los casos de éxito desarrollados e implementados haciendo uso de métodos
formales son:
Seguridad de un aeropuerto
La seguridad en la aviación civil se rige por normas internacionales y practicas
recomendadas. Un elemento clave en la seguridad de la aviación es la seguridad del
aeropuerto, que impide que puedan llevarse a bordo de un avión, armas y otros objetos
peligrosos. La calidad de la seguridad de los aeropuertos depende de:
La calidad de normas.
La conformidad de un aeropuerto dado a estas normas.
El nombre que recibió este proyecto fue EDEMOI, su objetivo es la aplicación de técnicas
de modelado de la comunidad de ciencias de la computación para abordar los problemas,
se basa en modelos gráficos UML y métodos formales, se centra en el modelado de las
normas de todos los aeropuertos internacionales de la aviación comercial, Los métodos
formales ayudaron a realizar un análisis más detallado evaluando la calidad de la norma
mientras que la generación de pruebas abordó el problema de conformidad.
Este proyecto ha demostrado que las técnicas dedicadas al modelado, análisis y pruebas
de la seguridad se pueden aplicar a otras áreas, es un caso de éxito en el que con el uso
de los métodos formales se modelan los estándares que regulan la seguridad de un
aeropuerto.
Chip de firmware para incrustación de teléfonos

móviles:
FeliCa es una tecnología de tarjeta utilizado por IC Mobile, teléfono móvil de origen
Japonés, que es utilizado como monedero electrónico, tickets para tren, identificación,
cuenta con un sistema de seguridad y protocolo de comunicaciones con un firewall que
controla los servicios, la aplicación de métodos formales fue indispensable ya que uno de
los aspectos a destacar es asegurar la máxima calidad del software con el fin de evitar
grandes problemas sociales relacionados con el servicio brindado a los clientes
Dispositivos de firma digital de seguros

SmartCards son dispositivos adecuados para la generación de firmas digitales, la
organización alemana de estandarización desarrollo una especificación de interfaz con
66
aplicación y función de firma, para la preparación del modelo formal se evidenciaron

amenazas o problemas como, extracción de la clave secreta , uso de aplicaciones sin
tener permiso del titular, modificación de los datos firmados, por tal motivo se recurrió a la
especificación formal para definir las políticas de seguridad , esto prioriza la importancia
de las políticas de seguridad.
El modelo formal fue desarrollado usando "Verificación support Environment", la cual es
una herramienta de apoyo a los métodos formales en el ciclo de vida completo del
software
Sistema de metro en parís controlado por software

Metro de parís cuando se abrió una línea de trafico totalmente controlada por software y
con trenes sin conductor, los componentes de seguridad critica de abordo en la pista se
desarrollaron formalmente utilizando el método de maquina abstracta, incluyo modelos
refinados y concretos, posee , el refinamiento de las pruebas se realizó mediante pruebas
formales, Uso del lenguaje B junto con matemática simple que le permite a los ingenieros
utilizarlo rápidamente con periodos cortos de formación, la técnica de especificación multi
- nivel que permite pasar del modelo abstracto al código
El uso de métodos formales aplicándolos de la mejor forma mejora los procedimientos y
productos de las empresas.
Casos de no éxito
La industria del software tiene una larga y bien ganada reputación de no cumplir sus
promesas y, a pesar de más de 60 años de progreso, tiene años -incluso décadas- por
debajo de la madurez necesaria que requiere para satisfacer las necesidades de la
naciente Sociedad del Conocimiento.
Goguen (1997) cita
algunas estimaciones de los gastos que generan los fracasos del desarrollo de software,
los calculó en 81 mil millones de dólares para 1995 y en 100 mil millones para 1996;
posteriormente (1999), llamaba la atención sobre la cancelación del contrato de 8 mil
millones de dólares a The International Business Machines -IBM- por la FAA -The Federal
Aviation Administration-, para el diseño de un sistema de control aéreo para toda la
nación; y del contrato del DOD -United States Department of Defense-, a la misma IBM,
por $2 mil millones
para modernizar su sistema de información; del fallo del software para la entrega en
tiempo real de datos en las Olimpiadas de 1996; y del año y medio de retraso en el
sistema para el manejo automatizado de equipaje en el aeropuerto de Denver para United
Airlines, con un costo de $1,1 millones diarios. En su libro, Neumann (1994) revela que
estos problemas no son en absoluto nuevos, aunque parece que se incrementan; incluso
67
señala que algunos de ellos ya provocaron muertes de personas, por ejemplo la

sobredosis de radiación en un sistema de terapia a mediados de los 80 (Gowen & Yap,
1991). Es claro que aún no es posible, con la tecnología actual, asegurar el éxito de los
proyectos de software, y que para proyectos grandes y complejos el enfoque ad hoc ha
demostrado ser insuficiente.
Otra razón Por la que un método formal no tenga éxito sería un ejemplo claro el caso de el
modelado de las normas para aeropuertos internacionales llevó al descubrimiento de
ambigüedades del lenguaje natural e hipótesis ocultas. El análisis más detallado de los
modelos formales ayudó a evaluar la calidad de la norma mientras que la generación de
pruebas abordó el problema de conformidad. Los principales resultados científicos de
EDEMOI (modelado de aeropuertos internacionales de la aviación comercial) fueron:

En qué casos no tendría éxito
un método formal, para este análisis se toman cuatro puntos relevantes
1.Decir que los métodos formales son todopoderosos, si nosotros humildes mortales
pudiésemos aplicarlos. Este caso es pernicioso porque nos lleva a expectativas irreales y
a la idea de que los métodos formales son de alguna forma todo-o-nada. La verdad es
que no existe tal garantía, pero la utilidad de los métodos formales no depende de esta
perfección absoluta.
2. Solo se centran en demostrar corrección.
En los Estados Unidos, gran parte del trabajo desarrollado en métodos formales se ha
concentrado en la verificación de programas. Esto ha hecho que los métodos formales
parezcan muy difíciles y no muy relevantes para la vida real. Sin embargo, se puede
lograr muchos beneficios aun sin hacer una sola demostración formal.
3. Solo para sistemas críticos. Esta creencia se basa en la percepción de la dificultad que
implica la aplicación de métodos formales. La verdad es que los sistemas críticos
requieren un uso más acucioso de métodos formales, pero cualquier sistema puede
beneficiarse con el uso de algunas técnicas de especificación formal.
4. Se requieren matemáticos entrenados, los métodos formales se basan en notaciones
matemáticas, y muchas personas creen que esto los hace difíciles para la práctica de los
ingenieros de software. Este caso de no éxito, a su vez, se basa en la percepción de que
las matemáticas son intrínsecamente difíciles.
68
Bibliografía
[1] R. S. Pressman, Software Quality Engineering: A Practitioner’s Approach, vol.
9781118592. 2014.
[2] E. Serna and M. Candidato, “Métodos formales e Ingeniería de Software
Formal ethods and Software Engineering Méthodes formelles et génie logiciel,” no. 30,
pp. 158–184, 2010.
[3] “It’s Time to Start Using Formal Methods for Engineering Embedded Systems - QRA
Corp.” [Online]. Available: https://qracorp.com/formal-methods-engineering-embedded-
systems/. [Accessed: 29-Sep-2019].
[4] “Métodos formales para Ingeniería de Software ” [Online].
Available: http://cs.uns.edu.ar/~gis/mf14/downloads/Clases%20Teoria/Clase01(byn).pdf.
[5] “Formal methods and Software Engineering ” [Online].
Available: https://wwwhome.ewi.utwente.nl/~langerak/fmse/fmse.pdf [Accessed: 29-Sep-
2019].
Casos de no éxito métodos formales pág.

173: https://revistavirtual.ucn.edu.co/index.php/RevistaUCN/article/viewFile/62/129
LAS AMBIEGUEDADES DE
EDEMOI: http://www.utm.mx/edi_anteriores/temas43/1ENSAYO_43_1-R.pdf
Computer
Pioneers - Charles Antony Richard Hoare. (n.d.). Retrieved September 28, 2019,
from https://history.computer.org/pioneers/hoare.html
Edsger
Dijkstra | IEEE Computer Society. (n.d.). Retrieved September 28, 2019,
from https://www.computer.org/profiles/edsger-dijkstra
Professor
Robert W. Floyd | Stanford Computer Science. (n.d.). Retrieved
September 28, 2019, from https://cs.stanford.edu/memoriam/professor-robert-w-floyd
69
Técnicas de
cuarta generación
Capítulo 5
70
TABLA DE CONTENIDO
Autores_______________________________________________________ 71
TECNICAS DE 4 GENERACIÓN (T4G) _____________________________ 72
Definición ____________________________________________________________ 72
Categorías ___________________________________________________________ 73
Características ________________________________________________________ 74
Personajes ___________________________________________________________ 75
Antecedentes T4G _____________________________________________________ 76
Etapas T4G __________________________________________________________ 77
Recolección de requerimientos _________________________________________ 77

Estrategia de diseño __________________________________________________ 78
Implementación _____________________________________________________ 78
Producto ___________________________________________________________ 78
Documentación______________________________________________________ 79
Mantenimiento ______________________________________________________ 79
Ventajas y Desventajas T4G _____________________________________________ 80
Ventajas ___________________________________________________________ 81
Desventajas ________________________________________________________ 81
Ejemplos T4G ________________________________________________________ 82
Ejemplos de Éxito ____________________________________________________ 83

Mathematica ________________________________________________________ 83
SQL_______________________________________________________________ 83
Progress ___________________________________________________________ 84
Ejemplos de No Éxito _________________________________________________ 85
PowerBuilder _______________________________________________________ 85
Caso NIKE _________________________________________________________ 86
Caso Hershey Foods _________________________________________________ 86
Caso Fuerza Aérea de Estados Unidos ___________________________________ 87
Caso VODAFONE ___________________________________________________ 87
Cuestionario __________________________________________________________ 88
Preguntas __________________________________________________________ 88
Respuestas_________________________________________________________ 89
BIBLIOGRAFIA _______________________________________________________ 90
71
AUTORES
Ing. Jorge Armando Millán Gómez
Correo: jamillan94@gmail.com
Cód.: 20192099015
Ing. Cristian Camilo Aponte Quiroga

Correo:Camiloa77@gmail.com
Cód.: 20192099001
Ing. Jaime Brandon Robles Fajardo

Correo: jbroblesf@gmail.com
Cód.: 20192099020
Ing. Nataly Ximena Ceferino Orjuela

Correo: natalyx25@gmail.com
Cód.: 20192099006

72
TECNICAS DE 4 GENERACIÓN (T4G)

Definición
Las técnicas de cuarta generación (T4G) comprenden un conjunto de métodos y
herramientas que permiten realizar la especificación del software a un alto nivel. En general,
el enfoque de estas técnicas va dirigido al uso de notaciones gráficas o lenguaje
especializado para describir el problema que debe resolver el software requerido, en
términos que el cliente pueda entender, por lo que resulta esencial el diálogo entre el cliente
y el desarrollador. La representación de los resultados esperados de la aplicación a un
mayor nivel permitirá que los programas puedan ser construidos más rápido, puesto que
las herramientas traducen la especificación en código fuente automáticamente.
Los entornos de desarrollo de las herramientas que soportan el paradigma T4G se

caracterizan por el uso de lenguajes no procedimentales (L4G) para consulta a bases de
datos, generación de informes y manejo de datos. Dichos lenguajes requieren de pocas
instrucciones, ya que la generación de códigos sucede de forma automática, lo cual
repercute en un menor trabajo para los programadores. Sin embargo demandan mayor
trabajo del equipo de cómputo, debido a sus capacidades gráficas de alto nivel y la
definición e interacción de pantallas.[1]
Figura 1. Definición de las Técnicas de Cuarta Generación.[2]

73
Categorías
Los lenguajes de cuarta generación se dividen en dos categorías. La primera categoría
consiste en aquellos que fueron diseñados y usados principalmente por profesionales de
informática, para el desarrollo de aplicaciones para la producción. Estos tienden a ser
menos “amigables con el usuario” y están orientados a la ejecución, a la integridad de los
datos, así como a la seguridad y su actualización a altas velocidades.
La segunda categoría comprende los lenguajes de cuarta generación orientados al uso

directo de usuarios finales, cumpliendo con sus necesidades diarias de información. Se
caracterizan por el énfasis que se hace en la facilidad de uso, los reportes a la medida y la
actualización de datos a baja frecuencia.
Figura 2. Categorías de las Técnicas de Cuarta Generación.[3]

74
Características
 Están más cerca del lenguaje natural
 Combinan características procedimentales y no procedimentales
 Hacen cálculos sin que el programador tenga que especificar los algoritmos
adecuados
 Permiten especificar condiciones con sus correspondientes acciones
 Aparecieron a fines de la década de los setentas
 Se aplican a problemas específicos y emplean sistemas de bases de datos o
archivos no estándar
 Deben utilizar el software estándar del sistema que se emplea en su medio
ambiente, especialmente para servicios de comunicaciones de datos o bien
deben reemplazar completamente los sistemas previos
Figura 3. Características de las Técnicas de Cuarta Generación.[4]

75
Personajes
 James Martin: Consultor de tecnologías de la información y escritor británico. Utiliza el
término de T4G por primera vez en su libro “Applications Development Without
Programmers”.
 Peter Coad: Empresario de software y autor de libros sobre programación, entre otros,
enfocados al software orientado a objetos. Es un desarrollador de aplicaciones sin fines
de lucro, cofundador y presidente de TheBible.org, y es un partidario de la metodología
liviana llamada FDD desarrollada junto con Jeff DeLuca y Eric Lefebvre.
 Jeff DeLuca: Es un estratega global de tecnologías de la información y un importante
autor en el campo de la metodología de desarrollo de software. Trabajó en IBM
durante 11 años, desarrolló software de red para conectar diferentes tipos de sistemas
informáticos. Es considerado el arquitecto principal de FDD.
 Donald Chamberlin: Es un científico informático, reconocido por ser uno de los
principales diseñadores de la especificación original del lenguaje SQL, y su
investigación en bases de datos relacionales, junto con Raymond Boyce.
Figura 4. Personajes de las Técnicas de Cuarta Generación.[5]

76
Antecedentes T4G
Los antecedentes que dieron pauta para la creación del modelo T4G se observan a
continuación:
Figura 5. Antecedentes de las técnicas de cuarta generación.[6]
 1960: Se crea el RPG (Report Program Generator) de IBM en cual fue uno de los
primeros lenguajes que podrían llamarse iniciadores primitivos de la categoría 4GL.
 1982: James Martin utiliza el término de lenguaje de cuarta generación (4GL) para
referirse a los lenguajes de alto nivel no procedimentales.
 1985: Nantucket Corporation crea Clipper sus utilidades para manejo de base de
datos, tales como la de creación de tablas se entregaban con el código fuente escrito
e incluido, el usuario podía adaptarlas a sus necesidades si quería
 1986: IBM lanza SQL (Structured Query Language) el cual es un lenguaje declarativo
no procedimental que, gracias a su fuerte base teórica y su orientación al manejo
de conjuntos una sola sentencia puede equivaler a uno o más programas que se
utilizarían en un lenguaje de bajo nivel orientado a registros.
 1990: Eric Lefebvre y Jeff DeLuca crean el método ágil FDD (Feature Driven
Development) en donde no se hace énfasis en la obtención de los requerimientos
sino en cómo se realizan las fases de diseño y construcción preocupándose por la
calidad, por lo que incluye un monitoreo constante del proyecto.
 1995: IBM crea la metodología RUP (Rational Unified Process) es conjunto de

metodologías adaptables al contexto y necesidades de cada organización.
77
Etapas T4G
El modelo de procesos de técnicas de cuarta generación consta de las siguientes
etapas[7]:
Figura 6. Etapas de las técnicas de cuarta generación.[8]
Recolección de requerimientos
La T4G comienza con el paso de reunión de requisitos. Idealmente, el cliente describe los
requisitos, que son, a continuación, traducidos directamente a un prototipo operativo. Sin
embargo, en la práctica no se puede hacer eso. El cliente puede que no esté seguro de lo
que necesita; puede ser ambiguo en la especificación de hechos que son conocidos, y
puede que no sea capaz o no esté dispuesto a especificar la información en la forma en
que puede utilizar una herramienta T4G. Por esta razón, el diálogo cliente-desarrollador
descrito por los otros paradigmas sigue siendo una parte esencial del enfoque T4G.
78
Estrategia de diseño
En esta etapa se crea la estrategia de diseño en la cual se deben definir los cuatro atributos
de un programa: estructura de datos, arquitectura del software, representaciones de
interfaz y detalle procedimental o algoritmo. El proceso de diseño traduce los
requerimientos en una representación del software que se pueda evaluar por calidad antes
de que comience la generación del código. Al igual que los requisitos, el diseño se
documenta y se hace parte de la configuración del software.
Implementación
La implementación es la etapa mediante en la cual basados en la recolección de los

requisitos se hace uso del lenguaje de cuarta generación (L4G) el cual permite centrarse
en la representación de los resultados deseados, que es lo que se traduce automáticamente
en un código fuente que produce dichos resultados, para lograrlo debe existir una estructura
de datos con información relevante y a la que el L4G pueda acceder rápidamente.
Actualmente, un entorno para el desarrollo del software que soporte el paradigma T4G
incluye algunas o todas de las siguientes herramientas:
 Lenguajes no procedimentales de consulta a bases de datos

 Generación de informes
 Manejo de datos
 Interacción y definición de pantallas
 Generación de códigos
 Capacidades gráficas
 Generación automatizada de HTML
Producto
En esta etapa se transforma la implementación T4G en un producto, para lograrlo se realiza

una prueba completa, se desarrollar una documentación y se ejecutan todas las otras
actividades de transición requeridas en los otros paradigmas de la ingeniería del software.
Además, el software desarrollado con T4G debe ser construido de forma que facilite que el
mantenimiento pueda ser ejecutado de una forma expeditiva.
79
Documentación
En esta etapa se realiza la documentación del resultado final del producto. Los documentos
son una forma tangible de describir las diferentes representaciones de un sistema de
software (requerimientos, UML, código, etcétera) y su proceso de producción. La
documentación ayuda al proceso de mantenimiento ya que proporciona la información de
las dependencias y restricciones y esto facilita la comprensión y realización de cambios al
código. En consecuencia, demostrar que se usó un proceso confiable incluye generar gran
cantidad de evidencia documental sobre el proceso y el software a desarrollar.
Mantenimiento
En esta etapa se realiza el mantenimiento del Software el cual sufrirá cambios a lo largo de
su vida útil. Estos cambios pueden ser debidos a tres causas:
 Durante la utilización, el cliente detecte errores en el software denominados

errores latentes.
 Se produzcan cambios en alguno de los componentes del sistema.
 El cliente requiera modificaciones funcionales no contempladas en el proyecto
80
Ventajas y Desventajas T4G
Figura 7. Ventajas y Desventajas técnicas de cuarta generación. [9]

81
Ventajas
1. Reducción drástica del tiempo de desarrollo, el tiempo requerido para producir software
se reduce mucho para aplicaciones pequeñas y de tamaño medio, y la cantidad de
análisis y diseño para las aplicaciones pequeñas, también se reduce. (Lo que en un
lenguaje de tercera generación (3GL) como COBOL requiere cientos de líneas de
código, tan solo necesita diez o veinte líneas en un 4GL).
2. Mejora en la productividad.
3. Están más cerca del lenguaje natural.[10]
Desventajas
1. Las herramientas actuales de T4G no son más fáciles de utilizar que los lenguajes de
programación.
2. El código fuente producido por tales herramientas es ineficiente. Al estar generado
automáticamente no pueden hacer uso de los trucos habituales para aumentar el
rendimiento, que se basan en el buen conocimiento de cada caso en particular.
3. El mantenimiento de grandes sistemas es cuestionable.
4. Para aplicaciones de alta complejidad, el tiempo que se ahorra mediante la eliminación
de la codificación se pierde debido al hecho que se exige el mismo o más tiempo de
análisis, diseño y prueba.
5. Sólo son aplicables al software de gestión, la mayoría de las herramientas de cuarta
generación están orientadas a la generación a partir de grandes bases de datos, pero
últimamente están surgiendo herramientas que generan esquemas de códigos para
aplicaciones de ingeniería y de tiempo real.
82
Ejemplos T4G
Figura 8. Ejemplos técnicas de cuarta generación. [11]

83
Ejemplos de Éxito
Bancolombia
Bancolombia para la generación de extractos financieros maneja la codificación en

lenguaje de RPG de IBM que es un lenguaje de cuarta generación y que facilita la
generación de reportes que fue el primer enfoque al momento de su creación, hoy en día
abarca otras funcionalidades.
Mathematica
La primera versión de Mathematica se puso a la venta en 1988, Mathematica se divide en

dos partes, el "kernel" o núcleo que desempeña los cálculos. Y el "front end" o interfaz, que
despliega los resultados y permite al usuario interactuar con el núcleo como si fuera un
documento. En la comunicación entre el kernel y la interfaz (o cualquier otro cliente)
Mathematica usa el protocolo MathLink, a menudo sobre una red. Es posible que diferentes
interfaces se conecten al mismo núcleo, y también que una interfaz se conecte a varios
núcleos. A diferencia de otros sistemas de álgebra computacional, por ejemplo Máxima o
Maple, Mathematica intenta usar las reglas de transformación que conoce en cada
momento tanto como sea posible, tratando de alcanzar un punto estable, actualmente se
conoce como Wolfram Mathematica.[12]
SQL
Los orígenes de SQL están ligados a las bases de datos relacionales, específicamente las
que residían en máquinas IBM bajo el sistema de gestión System R, desarrollado por un
grupo de la IBM en San José, California. En 1970, E. F. Codd propone el modelo relacional
y asociado a este un sublenguaje de acceso a los datos basado en el cálculo de predicados.
Basándose en estas ideas, los laboratorios de IBM definieron el lenguaje SEQUEL
(Structured English Query Language) que más tarde fue ampliamente implementado por el
sistema de gestión de bases de datos (SGBD) experimental System R, desarrollado en
1977 también por IBM. Sin embargo, fue Oracle quien lo introdujo por primera vez en 1979
en un producto comercial.
84
El SEQUEL terminó siendo el predecesor de SQL, que es una versión evolucionada del
primero. SQL pasa a ser el lenguaje por excelencia de los diversos sistemas de gestión de
bases de datos relacionales surgidos en los años siguientes y fue por fin estandarizado en
1986 por el ANSI, dando lugar a la primera versión estándar de este lenguaje, "SQL-86" o
"SQL1". Al año siguiente este estándar es también adoptado por ISO. Sin embargo, este
primer estándar no cubría todas las necesidades de los desarrolladores e incluía
funcionalidades de definición de almacenamiento que se consideró suprimirlas. Así que, en
1992, se lanzó un nuevo estándar ampliado y revisado de SQL llamado "SQL-92" o "SQL2".
En la actualidad SQL es el estándar de facto de la inmensa mayoría de los SGBD
comerciales. Y, aunque la diversidad de añadidos particulares que incluyen las distintas
implementaciones comerciales del lenguaje es amplia, el soporte al estándar SQL-92 es
general y muy amplio.[13]
Progress 4GL
El Progress 4GL original fue diseñado (en 1981) como un lenguaje de arquitectura
independiente y un sistema de base de datos integrado que podría ser utilizado por
personas no expertas para desarrollar aplicaciones comerciales por personas que no eran
informáticos pero que tenían conocimientos en su dominio comercial. En ese momento, las
aplicaciones comerciales a menudo se escribían en COBOL (para máquinas como
mainframes corporativos de IBM) y, a veces, en C (para minicomputadoras
departamentales que ejecutan el sistema operativo UNIX). Cuando la PC de IBM se hizo
popular, surgió la necesidad de un software comercial que pudiera usarse en esas y otras
computadoras de bajo costo. El sistema Progress fue creado para ser utilizado tanto en
máquinas PC de IBM que ejecutan DOS como en una variedad de computadoras que
podrían ejecutar UNIX. [14]
85
Ejemplos de No Éxito
PowerBuilder
Powersoft
En 1991 se crea la versión PowerBuilder 1.0 que prometía facilitar la creación de la

aplicaciones de escritorio en el sistema operativo Windows de Microsoft, esta empresa fue
la encargada hasta la tercera versión en el año 1993.[15]
Sybase
En el año 1994 Sybase adquiere a PowerSoft, desde ese momento comenzó una gran
época para PowerBuilder, se integraría con otros productos de la empresa y sumaría una
presencia mundial, sin embargo con el advenimiento de Internet, la aparición de nuevos
lenguajes de programación y la baja innovación de Sybase en este producto provocó una
pérdida de competitividad.[16]
Sybase SAP
En 2010 la empresa SAP adquiere a Sybase, desde el punto de vista tecnológico SAP
requería productos que fortalecieron sus software y no depender de terceros, en esta línea
PowerBuilder nunca fue de su interés quedando relegado durante los últimos 7 años,
perdiendo popularidad y funcionalidades.[17]
APPEON
En julio de 2016 la empresa SAP anuncia que firmó un acuerdo que cede la administración
del desarrollo de PowerBuilder a la empresa Appeon una compañía dedicada a la
prestación de servicios tecnológicos basados en las tecnologías de la extinta Sybase.[18]
86
Los primeros ERP se remontan a principios de los años 90 y se pueden

considerar como una nueva versión de los MRP -II diferenciándose sobre
todo en aspecto tecnológicos como:
 Un tratamiento generalizado de los procesos de gestión.

 Utilización de GUI (Graphics User Interface)
 Utilización de bases de datos relacionales
 Lenguajes de cuarta generación
 Tendencias a la integración de procesos
A continuación se muestran algunos ejemplos de proyectos fracasados de

ERP que utilizaban T4G [19]:
Caso NIKE
En el año 2000, la firma deportiva Nike sufrió un fallo en la actualización de su ERP que
impidió a las tiendas realizar pedidos a la compañía (justo en plena campaña de
lanzamiento de sus zapatillas Air Jordans) provocando un caos tan extraordinario que le
provocó un descenso del 20% en su valor bursátil y pérdidas de 100 millones de dólares en
ventas que no pudieron cubrirse. A ello hemos de sumar los 400 millones de dólares que le
había costado a Nike la instalación del nuevo sistema de pedidos y gestión de almacenes.
Caso Hershey Foods
Otro error similar, otro fallo en la implementación del software ERP, acabó con la campaña
de Halloween de 1999 de la cadena de supermercados Hershey Foods. Distintos problemas
de instalación, integración y configuración de sus aplicaciones SAP ERP, Siebel CRM y
Manugistics acabaron con un colapso que provocó una caída del valor de esta firma de
retail en Bolsa del 8% al no poder comercializar caramelos tradicionales de esta festividad
por valor de 100 millones de dólares.
87
Caso Fuerza Aérea de Estados Unidos
Los desastres con los ERP no se limitan a malas instalaciones o actualizaciones: también
un diseño insuficiente puede dar al traste con miles de millones. En concreto, 1000 millones
de dólares fueron los que perdió la Fuerza Aérea de Estados Unidos en desarrollar un
sistema de gestión de recursos empresariales que finalmente fue descartado por no tener
una “capacidad militar significativa”. Según las autoridades norteamericanas, todo el
proceso de diseño fue un auténtico dolor de cabeza: seis gestores del proyecto, 5 ejecutivos
y más de 10 estructuras organizativas a lo largo de los ocho años de vida de la iniciativa. A
ello hay que unir que los ideólogos de la iniciativa subestimaron claramente la complejidad
de una entidad militar como ésta, haciendo un planteamiento confuso y totalmente ineficaz
para los objetivos del Ejército.
Caso VODAFONE
En el caso de Vodafone, popular compañía de telefonía con alcance internacional, que

consolidó varias de sus herramientas corporativas, incluyendo su CRM migrado a una
plataforma Siebel. La pesadilla comenzó cuando los datos de varios de sus clientes no se
migraron correctamente a la nueva plataforma, con lo que se comenzaron a producir fallos
en los cobros y suspensiones aleatorias de los servicios a varios consumidores. Vodafone
no declaró estos problemas a los reguladores, con lo que cuando se desveló todo tuvo que
acarrear con una multa de 4,6 millones de libras esterlinas.
88
Cuestionario
Preguntas
1. Las técnicas de cuarta generación buscan describir el software en palabras que el usuario
pueda entender.
A. Verdadero
B. Falso
2. En la segunda categoría de los lenguajes de cuarta generación se encuentran aquellos

orientados a:
A. La ejecución y la integridad de los datos
B. El uso de los profesionales de informática
C. La actualización del software a altas velocidades
D. El uso de los usuarios finales
3. ¿Cuál de las siguientes NO es una característica de las técnicas de cuarta generación?

A. Buscan utilizar un lenguaje cercano al natural
B. Permiten especificar condiciones con sus correspondientes acciones
C. Requieren especificación a muy bajo nivel
D. Generan el código de forma automática
4. James Martín utilizo por primera vez el término de Lenguajes de cuarta generación.
A. Verdadero
B. Falso
5. Una de las siguientes NO es una Etapa de las técnicas de cuarta generación

A. Dialogo con el cliente
B. Estrategia de diseño
C. Producto
D. Mantenimiento
6. Uno de los siguientes personajes NO pertenece en el desarrollo de las técnicas de cuarta

generación:
A. Donald Chamberlin
B. James Martin
C. Peter Coad
D. Steve Jobs
89
7. La implementación de lenguaje de bajo niveles es una de las características de las T4G

A. Verdadero
B. Falso
8. La implementación de las T4G aumenta el tiempo de desarrollo de los proyectos.

A. Verdadero
B. Falso
9. En cuales aspectos la implementación de T4G beneficia el desarrollo de proyectos :

A. Facilidad en la utilización
B. Generación de código eficiente
C. Reducción de tiempo y aumento de la productividad
D. Mantenimiento de sistemas de gran tamaño
10. RPG (Report Program Generator) de IBM en cual fue uno de los primeros lenguajes que
podrían llamarse iniciadores primitivos de la categoría 4GL.
A. Verdadero
B. Falso
Respuestas
A B C D
10
90
BIBLIOGRAFIA
[1] I. Pilar Alexandra Moreno, I. Alexandra Aparicio Revisado Editado, and I. Jairo Martínez,
“Ingeniería de Software,” 2012.
[2] J. A. Millán Goméz, “Definición Ténicas de Cuarta Generación.” Universidad Distrital,
[3] N. X. Ceferino Orjuela, “Categorías Técnicas de Cuarta Generación.” Universidad Distrital,
[4] N. X. Ceferino Orjuela, “Caracteristicas Técnicas de Cuarta Generación.” Universidad
Distrital, p. 1, 2019.
[5] J. A. M. Gomez, “Personajes Técnicas de Cuarta Generación.” Universidad Distrital,
[6] J. A. Millán Goméz, “Antecedentes Técnicas de Cuarta Generación.” Universidad Distrital,
[7] E. Gómez Vargas, “Ingeniería de Software.” Universidad Distrital, Bogota,Colombia, p. 94,
2016.
[8] J. A. Millán Goméz, “Etapas Técnicas de Cuarta Generación.” Universidad Distrital,
[9] J. A. Millán Goméz, “Ventajas y Desventajas Técnicas de Cuarta Generación.” Universidad
Distrital, Bogota,Colombia, p. 1, 2019.
[10] J. Pradel Miquel and J. Raya Matos, “Introducción a la ingeniería de software.” UNISTMO,
Mexico, p. 84, 2011.
[11] J. A. Millán Goméz, “Ejemplos Ténicas de Cuarta Generación.” Universidad Distrital,
[12] F. Phillips, “Review: Wolfram Mathematica 7,” MacWorld, 2009. [Online]. Available:
https://www.macworld.com/article/1138219/mathematica_7.html.
[13] F. A.Morteo and B. L.E, UN ENFOQUE PRACTICO DE SQL, Primera. Argentina: Ediciones
Cooperativas, 2004.
[14] J. Sadd, “OpenEdge Development : Progress 4GL Handbook,” EE.UU, 2005.
[15] P. Lannigan, “PowerBuilder History, Powersoft History,” lannigan, 2014. [Online]. Available:
http://www.lannigan.org/powersoft_powerbuilder_history.htm.
[16] G. Rifkin, “Sybase To Acquire Powersoft,” The New York Times, 1994. [Online]. Available:
https://www.nytimes.com/1994/11/15/business/sybase-to-acquire-powersoft.html.
[17] V. Ashlee, “SAP to Buy Sybase, Ally in Software,” The New York Times, 2010. [Online].
Available:
https://www.nytimes.com/2010/05/13/technology/13sap.html?mtrref=www.google.com&gwh
=7AE51C1CFF7DFF82E21B14F95420B74F&gwt=pay&assetType=REGIWALL.
[18] M. Berner, “Appeon Signs Agreement with SAP to Bring Major Innovations to
PowerBuilder,” Cision, 2016. [Online]. Available: https://www.prnewswire.com/news-
releases/appeon-signs-agreement-with-sap-to-bring-major-innovations-to-powerbuilder-
300291905.html.
[19] A. Iglesias Fraga, “Cuando un ERP falla: 5 escenarios de caos motivados por errores de
implementación,” TICbeat, 2017. [Online]. Available:
https://www.ticbeat.com/tecnologias/cuando-un-erp-falla-5-escenarios-de-caos-motivados-
por-errores-de-implementacion/.

Libro-Modelos de Procesos de Desarrollo de Software

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Libro-Modelos de Procesos de Desarrollo de Software

Cargado por

Copyright:

Formatos disponibles

Modelos de Procesos

Prototipo Desechable __________________________________________________ 6

Tipos de Modelo de Prototipo ____________________________________________ 14

Ejemplos de Éxito ____________________________________________________ 15

Ing. Harold David Hurtado Cortes

Ing. Jhonattan Alexander Diaz Duarte

Ing. Mauricio Sandoval Parra

Ing. Jorge Eliecer Sierra Torres

Evaluador: MSc. Alexandra Abuchar Porras

Figura 1. Tipos de Prototipo y su Definición [1]

Figura 2. Prototipo Desechable [1]

Figura 3. Modelo Prototipado Desechable [1]

Figura 4. Prototipo Evolutivo. [1]

Figura 5. Modelo Prototipado Evolutivo [1]

Los modelos de prototipado interactivo tiene la bondad de:

 Los desarrollos orientados a objetos se ajustan a un modelo de proceso iterativo e

 Se puede argumentar lo mismo para los desarrollos basados en componentes.

 Las tareas de cada fase se llevan a cabo de una forma iterativa.

 A la vez que existe un ciclo de desarrollo análisis-diseño, implementación-análisis

 En el desarrollo incremental el sistema se divide en un conjunto de Particiones.

 Cada una se desarrolla de forma completa hasta que se finaliza el sistema.

Esta idea de interactividad máxima propia de la orientación a objetos ha sido equiparada

Figura 6. Dimensión Incremental – Evolutivo [1]

Figura 7. Dimensión Iterativo – Evolutivo [1]

Figura 8. Características del Prototipo [1]

 Kristen Nygaard: (Nacido el 27 de agosto de 1926, Oslo, Nor., Fallecido el 10 de agosto

Mientras trabajaba en el Centro de Computación de Noruega (NCC) en la década de

 Donald Chamberlin: (Nacido el 12 de octubre de 1931, Mandal, Nor., Fallecido el 29 de

Figura 9. Personajes que influyeron en el modelo de Prototipo [2] [3] [4]

Antecedentes del Modelo de Prototipos

Durante la década de los 70 se daba respuesta a proyectos grandes y con requisitos

Etapas General del Modelo de Prototipo

Figura 10. Etapas del modelo de prototipo [5]

En esta etapa lo esencial es determinar el problema y su ámbito, la importancia y los efectos

Cuando se tienen que los resultados de un proyecto son aceptables, se procede a

comenzar la construcción de un prototipo, en este se debe representar los dominios

Modelo diseño rápido

Después de que se haya revisado la representación de los requerimientos, se crea un

Construcción del prototipo

Desarrollo, entrega y retroalimentación

Tipos de Modelo de Prototipo

Figura 11. Tipos de Modelos Prototipados [6]

Ventajas y Desventajas Modelo de Prototipo

Las ventajas que encontramos al implementar el modelo de desarrollo de software

El conocimiento adquirido al Al desarrollar por prototipos, los

Se ajusta mejor al cambio, cuando Cuando se desarrolla por prototipos,

reducido (También se puede omitir

Al realizar la integración entre el A veces se quiere proyectar el

Al presentarse un prototipo, no se Erróneamente, el usuario puede

Se realiza el desarrollo en una A veces se piensa que,

Figura 12. Tipos de Modelos Prototipados [7] [8] [9]

Google no es una empresa que carece de recursos. Cuando

El propósito del prototipo era simplemente probar cuál es la

mundo físico, al estilo de un "informe minoritario". No era

1. El modelo de prototipo es una modelo auxiliar experimental de un sistema o de un

2. Que personajes influyeron o crearon el modelo de prototipo.

3. En qué año se fue propuesto el modelo de prototipo.

4. Cuáles de estas fases no corresponden a las fases del modelo de prototipo.

5. En qué fase se realiza la retroalimentación del modelo de prototipo.

6. Los modelos de prototipo se caracterizan en siete tipos.

7. El modelo de prototipo no reduce la probabilidad de construir productos que no

8. El modelo de prototipo tiene la desventaja de que erróneamente, el usuario puede

9. Cuales son los tipos de modelo de prototipo: