Desarrollo-de-sistemas-con-metodologa-RUP-Ratlonal-Unified-Process

Vista previa del material en texto

~GENIE ~~ 
UNIVERSIDAD NACIONAL AUTONÓM,A DE MÉXICO ~ 
.. FACULTAD DE INGENIERIA • 
DESARROLLO DE SISTEMAS 
CON METODOLOGÍA RUP 
(RATlONAL UNIFIED PROCESS) 
T E S I S 
QUE PARA OBTENER EL TÍTULO DE 
INGENIERO EN COMPUTACIÓN 
PRESENTAN 
ERIKA VILLALBA DOMÍNGUEZ 
EDER YAIR RAMÓN MARTÍNEZ 
M.C MARÍA JAQUELlNA LÓPEZ BARRIENTOS 
 
UNAM – Dirección General de Bibliotecas 
Tesis Digitales 
Restricciones de uso 
 
DERECHOS RESERVADOS © 
PROHIBIDA SU REPRODUCCIÓN TOTAL O PARCIAL 
 
Todo el material contenido en esta tesis esta protegido por la Ley Federal 
del Derecho de Autor (LFDA) de los Estados Unidos Mexicanos (México). 
El uso de imágenes, fragmentos de videos, y demás material que sea 
objeto de protección de los derechos de autor, será exclusivamente para 
fines educativos e informativos y deberá citar la fuente donde la obtuvo 
mencionando el autor o autores. Cualquier uso distinto como el lucro, 
reproducción, edición o modificación, será perseguido y sancionado por el 
respectivo titular de los Derechos de Autor. 
 
 
 
 
 
Dedicatorias de Erika 
 
A Dios, por su bondad y bendiciones en cada momento de mi vida. 
 
A la luz de mis ojos, mi hijo Itan Tadeo, por su existencia, por sus palabritas, por sus sonrisas y 
ese amor que desprende su mirada y le dan razón a mi vida. 
 
A mis madres: Silvia, por ser el pilar de la casa, por enseñarme a luchar ante la adversidad por 
demostrarme que en la vida se puede tener todo lo que uno desea estudiando y trabajando 
mucho, por su amor. A Anastasia, por haber estado ahí guiando mis pasos hasta poder llegar 
hasta donde ahora estoy, por ser la impulsadora de mí la carrera y de lo que soy. 
 
A mi padre Germán, por desear mi bienestar y demostrarme que si se quiere se puede, que 
siempre hay una forma, que las mejores cosas de la vida no son fáciles, pero tampoco 
imposible, por su consejos y enseñanza de vida. 
 
A mis hermanas: Silvia, que fue mi consejera en cada etapa de mi vida, que me dio la mano y el 
hombro cuando lo necesitaba, que es una gran maestra para mí en todos los aspectos, pues soy 
afortunada y bendecida con su presencia en mi vida. Por su apoyo en la revisión de este 
trabajo. A Pamela, por su fortaleza y coraje que me hicieron entender que en la vida hay que 
respetar los espacios de cada persona, por su apoyo incondicional, porque hoy admiro su 
fortaleza, su coraje ante las circunstancias difícil y que agradezco a dios tenerla en mi vida. 
 
A mi sobrina Ángela: Mi princesa por alimentarme el alma con su sonrisa, por sus abrazos, por 
sus palabritas inocentes, por quererme como lo hace y por su existencia en mi vida. 
 
A mi gran amigo y compañero de tesis, Eder Yair: Porque sin él este proyecto no sería lo que es 
hoy, que le he aprendido mucho por ser una persona dedicada y disciplinada. Por su amistad. 
 
Agradecimiento 
A mi familia por ser mi familia. 
 
A mi asesora de tesis María Jaquelina López Barrientos, por la paciencia, sus consejos, el apoyo, 
la tolerancia que tuvo con nosotros y por su conocimiento. 
 
A mis amigos que durante toda la carrera fueron un gran apoyo, por los aprendizajes de vida 
que tuve a su lado, por su talento y enseñanza, por las historias que vivimos y que se quedan 
grabadas en el corazón, por sus consejos y el cariño que siempre me han demostraron. 
A mis amigas de trabajo, por esta etapa que estamos compartiendo, por los festejos, los 
consejos, el cariño, y el apoyo que siempre me han brindado. Y por todo lo que falta. 
Y a todos los que estuvieron en cada etapa de mi vida y me enseñaron algo. 
 
 
 
Dedicatorias de Eder Yair 
 
 
Esta investigación culmina con el trabajo de años de estudio y preparación, tanto intelectual 
como humana. No ha sido fácil llegar hasta aquí y como en toda investigación los resultados no 
pueden atribuirse a una sola persona, no hay mejor forma de comenzar que dedicando y 
agradeciendo el apoyo y colaboración de todos aquellos que me han acompañado en este 
proceso. 
 
A mis padres y hermanas que han sufrido las consecuencias de los largos días en la Facultad. A 
ellos dedico este trabajo, por su amor, su apoyo y compresión que me brindaron, sin los cuales 
no habría logrado llegar hasta aquí. 
 
A Erika, mi amiga y compañera de Tesis por su ayuda, apoyo, amistad y porque sin ella este 
trabajo no sería lo que es hoy. 
 
 
 
 
 
Agradecimiento 
 
Al programa de becarios de DGSCA, que me ayudaron a formarme como profesionista y 
también a conocer diferentes ideologías tanto académicas como personales. 
 
A nuestra asesora de Tesis María Jaquelina López Barrientos por su orientación al momento de 
realizar este trabajo y por haber confiado en nuestra capacidad para llevar a cabo este 
proyecto. 
 
Y por último, a todos aquellos que desde que era niño me ayudaron en algún momento. 
Y a los que van llegando a mi vida y comparten conmigo una nueva etapa. 
 
A todos ustedes ¡Gracias! 
 
 
i 
 
Índice 
 
 
PRÓLOGO ................................................................................................................................................................... 1 
1. INGENIERÍA DE SOFTWARE ............................................................................................................................ 6 
1.1 HISTORIA DE LA INGENIERÍA DE SOFTWARE ......................................................................................................... 6 
1.2 CONCEPTOS BÁSICOS ......................................................................................................................................... 10 
1.3 CLASIFICACIÓN DE LAS METODOLOGÍAS DE ANÁLISIS DE SISTEMAS................................................................... 13 
1.4 METODOLOGÍAS DE ANÁLISIS DE SISTEMAS ....................................................................................................... 15 
1.4.1 PROCESO Y CARACTERÍSTICAS DE LAS METODOLOGÍAS ............................................................................ 15 
2. METODOLOGÍAS Y PROCESOS DE ANÁLISIS DE SOFTWARE ............................................................. 36 
2.1 PROCESOS DE DESARROLLO DE LA METODOLOGÍA ............................................................................................. 37 
2.1.1 MÉTODO EN CASCADA .............................................................................................................................. 37 
2.1.2 MÉTODO DE PROTOTIPOS EVOLUTIVOS ..................................................................................................... 39 
2.1.3 MÉTODO INCREMENTAL ........................................................................................................................... 43 
2.1.4 MÉTODO EN ESPIRAL ................................................................................................................................ 44 
2.1.5 MODELO EXTREME PROGRAMMING (XP) ................................................................................................. 47 
3. ANÁLISIS ORIENTADO A OBJETOS .............................................................................................................. 52 
3.1 HISTORIA DEL ANÁLISIS ORIENTADO A OBJETOS ................................................................................................ 55 
3.2 PROGRAMACIÓN ORIENTADA A OBJETOS (POO) ................................................................................................ 57 
3.2.1 LENGUAJES ORIENTADOS A OBJETOS ........................................................................................................ 64 
4. LENGUAJE UML ................................................................................................................................................. 68 
4.1 DEFINICIÓN DE UML .........................................................................................................................................69 
4.2 DIAGRAMAS DE UML ........................................................................................................................................ 71 
4.2.1 DIAGRAMA DE CASOS DE USO ................................................................................................................... 73 
4.2.2 DIAGRAMA DE SECUENCIA ....................................................................................................................... 76 
4.2.3 DIAGRAMA DE ESTADOS ........................................................................................................................... 80 
4.2.4 DIAGRAMA DE ACTIVIDADES .................................................................................................................... 83 
4.2.5 DIAGRAMA DE CLASES ............................................................................................................................. 87 
4.2.6 DIAGRAMA DE OBJETOS ........................................................................................................................... 92 
4.2.7 DIAGRAMA DE COLABORACIÓN ............................................................................................................... 92 
4.2.8 DIAGRAMA DE COMPONENTES ................................................................................................................. 94 
4.2.9 DIAGRAMA DE DISTRIBUCIÓN .................................................................................................................. 96 
5. PROCESO UNIFICADO RATIONAL APLICADO ............ ........................................................................... 100 
5.1 HISTORIA ......................................................................................................................................................... 100 
5.2 CARACTERÍSTICAS DE LA METODOLOGÍA ......................................................................................................... 101 
5.2.1 PROCESO DIRIGIDO A CASOS DE USO ....................................................................................................... 101 
5.2.2 PROCESO CENTRADO EN LA ARQUITECTURA ........................................................................................... 102 
 
 
ii 
 
5.2.3 PROCESO ITERATIVO E INCREMENTAL .................................................................................................... 104 
5.3 MEJORAS PRACTICAS PARA EL DESARROLLO DE SOFTWARE ............................................................................ 106 
5.3.1 GESTIÓN DE REQUISITOS ........................................................................................................................ 108 
5.3.2 DESARROLLO DE SOFTWARE ITERATIVO ................................................................................................. 109 
5.3.3 LA ARQUITECTURA BASADA EN COMPONENTES ...................................................................................... 110 
5.3.4 MODELO V ISUAL (USANDO UML) ......................................................................................................... 110 
5.3.5 VERIFICACIÓN CONTINUA DE LA CALIDAD.............................................................................................. 111 
5.3.6 GESTIÓN DE LOS CAMBIOS ...................................................................................................................... 112 
5.4 ESTRUCTURA DEL PROCESO ............................................................................................................................. 113 
5.4.1 ESTRUCTURA DINÁMICA ........................................................................................................................ 113 
5.4.1.1 Fase Inicio ................................................................................................................................................................... 115 
5.4.1.1.1 Documento de visión del sistema ..................................................................................................................... 116 
5.4.1.1.3 Documento de Requerimientos ........................................................................................................................ 116 
5.4.1.1.4 Modelo de negocio ............................................................................................................................................ 116 
5.4.1.1.5 Glosario .............................................................................................................................................................. 116 
5.4.1.2 Fase elaboración ......................................................................................................................................................... 117 
5.4.1.2.1 Casos de uso ....................................................................................................................................................... 118 
5.4.1.2.2 Documento de Arquitectura .............................................................................................................................. 118 
5.4.1.2.3 Prototipo ............................................................................................................................................................. 118 
5.4.1.2.4 Plan de desarrollo .............................................................................................................................................. 118 
5.4.1.3 Fase construcción ....................................................................................................................................................... 119 
5.4.1.3.1 Sistema versión beta .......................................................................................................................................... 120 
5.4.1.4 Fase transición ............................................................................................................................................................ 120 
5.4.1.4.1 Documento de despliegue ................................................................................................................................. 121 
5.4.1.4.2 Plan de pruebas .................................................................................................................................................. 121 
5.4.1.4.3 Prototipo Operacional, versión alpha ............................................................................................................... 121 
5.4.2 ESTRUCTURA ESTÁTICA ......................................................................................................................... 121 
5.4.2.1 Roles............................................................................................................................................................................ 122 
5.4.2.2 Actividades ................................................................................................................................................................. 124 
5.4.2.3 Artefactos .................................................................................................................................................................... 124 
5.4.2.4 Flujos de trabajo ......................................................................................................................................................... 124 
5.4.2.4.1 Modelado del negocio ....................................................................................................................................... 124 
5.4.2.4.2 Requisitos ........................................................................................................................................................... 125 
5.4.2.4.3 Análisis y Diseño ............................................................................................................................................... 126 
5.4.2.4.4 Implementación................................................................................................................................................. 127 
5.4.2.4.5 Pruebas ............................................................................................................................................................... 128 
5.4.2.4.6 Despliegue .......................................................................................................................................................... 129 
5.4.2.4.7 Gestión del proyecto .......................................................................................................................................... 130 
5.4.2.4.8 Configuración y control de cambios ................................................................................................................ 130 
5.4.2.4.9 Ambiente ............................................................................................................................................................ 130 
CONCLUSIONES ................................................................................................................................................... 132 
GLOSARIO .............................................................................................................................................................. 134 
BIBLIOGRAFÍA ..................................................................................................................................................... 140 
MESOGRAFÍA ........................................................................................................................................................ 141 
APÉNDICES ............................................................................................................................................................ 142 
APÉNDICE A.1 ....................................................................................................................................................... 142 
APÉNDICE A.2 ....................................................................................................................................................... 142 
APÉNDICE A.3 ....................................................................................................................................................... 142 
APÉNDICE A.4 ....................................................................................................................................................... 142 
 
 
iii 
 
APÉNDICE A.5 ....................................................................................................................................................... 142 
APÉNDICE B.1 ........................................................................................................................................................ 142 
APÉNDICE B.2 ........................................................................................................................................................ 142 
APÉNDICE B.3 ........................................................................................................................................................ 142 
APÉNDICE B.4 ........................................................................................................................................................ 142 
APÉNDICE B.5 ........................................................................................................................................................ 142 
APÉNDICE B.6 ........................................................................................................................................................ 142 
APÉNDICE B.7 ........................................................................................................................................................ 142 
APÉNDICE B.8 ........................................................................................................................................................ 142 
APÉNDICE B.9 ........................................................................................................................................................ 143 
APÉNDICE B.10 ...................................................................................................................................................... 143 
APÉNDICE B.11 ...................................................................................................................................................... 143 
APÉNDICE B.12 ...................................................................................................................................................... 143 
APÉNDICE C.1 ........................................................................................................................................................ 143 
APÉNDICE C.2 ........................................................................................................................................................ 143 
APÉNDICE C.3 ........................................................................................................................................................ 143 
 
 
 
 
1 
 
Prólogo 
 
La ingeniería de software afecta a la economía y a las sociedades de muchas formas 
ya que contribuye al incremento de la productividad. Socialmente cambia la cultura del 
mundo debido al extendido uso de la computadora. El correo electrónico (e-mail), la 
WWW (World Wide Web) y la mensajería instantánea permiten a la gente interactuar en 
nuevas formas. 
 
El software baja el costo, mejora la calidad de los servicios de salud, los departamentos 
de bomberos, las dependencias gubernamentales y otros servicios sociales. Los 
proyectos exitosos donde se han usado métodos de ingeniería de software incluyen a 
Linux son, por ejemplo, el software del trasbordador espacial, los cajeros automáticos, 
entre otros. 
 
En este sentido la ingeniería aplicada al software se basa en herramientas 
preestablecidas de manera eficiente y óptima. No es sólo resolver problemas, sino, 
tener en cuenta varias soluciones y elegir la más apropiada. El objetivo desde hace 
tiempo, ha sido encontrar procesos o metodologías predecibles y repetibles que 
mejoren la productividad y la calidad. 
 
La ingeniería de software requiere llevar a cabo muchas tareas como son: análisis de 
requisitos (extraer los requisitos del software a desarrollar), descripción (detallar el 
software a realizar), diseño (funcionamiento de forma general), programación (pasar el 
diseño a código), prueba (comprobar que el software realice correctamente las tareas 
indicadas), documentación (manual de usuario) y el mantenimiento (del software para 
su mejora). 
 
Los factores más importantes que han llevado a la necesidad de tener software de 
calidad son: el aumento del poder de la computación en las empresas, el incremento en 
el número de usuarios de los sistemas, los usuarios que solicitan sistemas hechos a la 
medida y las nuevas tecnologías que surgen. 
 
 
2 
 
La complejidad del software producido y demandado, se incrementa constantemente. 
Las aplicaciones de software son complicadas porque modelan el mundo real. En estos 
días, las aplicaciones típicas son muy grandes y complejas para que un individuo las 
entienda, por ello, lleva gran tiempo implementar software. 
 
En la actualidad la mayoría del software que se construye es riesgoso y difícil de 
controlar, muchos de éstos son construidos sin una metodología de por medio y por lo 
tanto el resultado son clientes insatisfechos. Esto resulta cuando no se toma en cuenta 
el emplear una metodología adecuada, sobre todo cuando se trata de proyectos 
pequeños que duran pocos meses. Lo que se hace con este tipo de proyectos es 
separar rápidamente en procesos, cada proceso en funcionesy por cada función 
determinar un tiempo aproximado de desarrollo. 
 
Cuando los proyectos que se van a desarrollar son de mayor amplitud, se debe tomar 
en cuenta una metodología de desarrollo buscando cuál sería la más apropiada. Lo 
cierto es que muchas veces no se encuentra la más adecuada y se termina por hacer o 
diseñar una metodología propia, algo que por supuesto no está mal, siempre y cuando 
cumpla con el objetivo. 
 
Los problemas de desarrollo de software se deben en gran medida a la mala 
implementación de la metodología. Así, la clave para el éxito de un proyecto de 
desarrollo de software es la adecuada implementación de la metodología con la que se 
va a desarrollar, para obtener la satisfacción del usuario final. 
 
Después de identificar las necesidades al desarrollar sistemas, se propone la 
metodología a utilizar, una de las mejores formas de desarrollar software es utilizar un 
modelo de desarrollo en espiral, este modelo está basado en repeticiones o bucles en 
las cuales cada repetición es llamada actividad, estas actividades no son fijas, son 
elegidas en función del análisis de riesgos, el cual debe comenzar por el bucle más 
interno. La metodología que cumple con este modelo es llamada RUP (Rational Unified 
Process) la cual es un proceso de desarrollo de software que junto con el Lenguaje 
 
 
3 
 
Unificado de Modelado UML, constituye la metodología estándar más utilizada para el 
análisis, implementación y documentación de sistemas orientados a objetos. 
 
RUP es una forma disciplinada de asignar tareas y responsabilidades (¿Quién hace? 
¿Qué?, ¿Cuándo? y ¿Cómo?), que pretende implementar las mejores prácticas en 
ingeniería de software teniendo un desarrollo iterativo con una administración de 
requisitos, una arquitectura basada en componentes, un control de cambios, un 
modelado visual del software y la verificación de la calidad del software. 
 
Se caracteriza por ser iterativo e incremental, está centrado en la arquitectura y guiado 
por los casos de uso. Incluye artefactos (que son los productos tangibles del proceso 
como por ejemplo, el modelo de casos de uso, el código fuente, etc.) y roles (papel que 
desempeña una persona en un determinado momento y puede desempeñar distintos 
roles a lo largo del proceso). 
Esta metodología divide el proceso de desarrollo en ciclos, teniendo un producto final 
de cada ciclo, éstos se dividen en fases: 
 
• Fase de inicio: aquí se identifican los principales casos de uso y los riesgos. 
• Fase de elaboración: es donde se completan los casos de uso y se eliminan los 
riesgos. 
• Fase de construcción: donde se elabora un producto totalmente operativo y 
eficiente, además de elaborar los manuales de usuario y la fase de transición donde 
se implementa el producto terminado. 
Una particularidad de esta metodología es que, en cada ciclo de iteración, se hace 
exigente el uso de artefactos. Los artefactos son los resultados parciales o finales que 
es producido y usado durante el proyecto, son las entradas y salidas de las actividades; 
éstos pueden ser un documento, un modelo o un elemento de modelo. Ésta es una de 
las características que hacen de RUP una de las metodologías más importantes para 
alcanzar un grado de certificación en el desarrollo del software. 
 
 
4 
 
En el siguiente trabajo se presentan las características de diversas metodologías, 
descripción de los procesos que éstas involucran, así como resultados, ventajas y 
desventajas de cada una de ellas. En el capítulo 1 se presenta el marco teórico de la 
ingeniería de software, las clasificaciones de las distintas metodologías de desarrollo y 
análisis, así como ventajas y desventajas de ellas; en el capítulo 2 se describe el 
proceso de cada una de estas metodologías; en el capítulo 3 se explica el paradigma 
orientado a objetos, las definiciones y conceptos que se involucran en éste; al llegar al 
capítulo 4 adquirimos los conocimientos necesarios para empezar con el modelado de 
sistemas, en éste se presentan los distintos diagramas que conforman el modelado 
mediante UML. Teniendo los conocimientos de las distintas metodologías y del 
modelado podemos iniciar con el diseño de sistemas de información más completos; en 
el capítulo 5 presentamos el proceso de diseño mediante RUP, así como todos los 
“artefactos” que este proceso contiene. Al llegar el término de este trabajo presentamos 
los resultados obtenidos mediante la aplicación de RUP y las conclusiones que se 
obtuvieron en la realización del presente proyecto. 
 
Capítulo 1 
Ingeniería de Software 
 
 5 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Capítulo 1 
Ingeniería de Software 
 
 6 
1. Ingeniería de software 
 
La ingeniería de software es una disciplina de ingeniería que ofrece métodos, 
técnicas para desarrollar y entregar software de calidad. Mantiene las aplicaciones 
de software utilizando tecnologías y manejo de proyectos. 
 
La ingeniería de software se relaciona con diversas áreas de la informática. Es 
aplicable en negocios, investigación científica, medicina, producción, banca, 
meteorología, derecho, internet, entre otras. 
 
Se puede definir como “Un conjunto de conocimientos y técnicas aplicadas al 
diseño, construcción y documentación de los programas”, para desarrollar, operar y 
mantener los objetivos de la ingeniería de software, los cuales son: 
• Mejorar la calidad de los productos de software. 
• Aumentar la productividad y trabajo de los ingenieros del software. 
• Facilitar el control del proceso de desarrollo de software. 
• Suministrar a los desarrolladores las bases para construir software de alta 
calidad en una forma eficiente. 
• Definir una disciplina que garantice la producción y el mantenimiento de los 
productos de software, dentro del costo estimado. 
El proceso de desarrollo de software se refiere a la traducción de las necesidades 
del usuario en requerimientos de software, éstos son transformados en el diseño del 
sistema, posteriormente el diseño es implementado en código y finalmente el código 
es probado y documentado para su uso operativo. De manera general define 
¿Quién hace? ¿Qué?, ¿Cuándo se hace? y ¿Cómo alcanzar el objetivo deseado? 
1.1 Historia de la ingeniería de software 
 
Inicialmente la programación era un arte que no disponía de métodos sistemáticos 
en los cuales basarse para la realización de productos de software. El software se 
realizaba sin ninguna planificación, posteriormente, desde mediados de los 60 hasta 
finales de los 70 se caracterizó por el establecimiento del software como un 
Capítulo 1 
Ingeniería de Software 
 
 7 
producto que se desarrollaba para la distribución de sectores específicos de la 
sociedad. 
 
La búsqueda de la calidad y el permitir reducir los costos de las soluciones ha sido 
uno de los objetivos más perseguidos desde los inicios de la informática. A 
mediados de los 60, la creación de un producto de software se convertía en una 
tarea angustiosa, por lo cual fue necesario introducir una serie de herramientas y 
procedimientos que facilitaran por un lado, la labor de creación de nuevo software y 
por otro, la comprensión y el manejo del mismo. Éstos fueron los inicios de la 
ingeniería del software. Con el paso del tiempo, la evolución de estos métodos han 
llevado a reconocer la ingeniería del software como una verdadera disciplina, 
derivada de una investigación seria y de un estudio minucioso. 
 
Durante los primeros años de la era de la computadora el desarrollo del software se 
realizaba sin ninguna planificación lo que trajo consigo, que muchas de las 
empresas que desarrollaban software comenzaran a descontrolarse en cuestión de 
planificación de un proyecto y los costos comenzaron a incrementar. Los 
programadores trataban de tener una buena organización y con un esfuerzo heroico, 
a menudo los proyectos salían con gran éxito. 
 
La mayoríadel software que se desarrollaba era considerado software propietario, 
es decir era desarrollado para el uso exclusivo de un reducido grupo de personas u 
organización. Debido a este entorno personalizado del software, el diseño era un 
proceso implícito, realizado en la mente de alguien y la documentación normalmente 
no existía. 
 
Los sistemas de computadora se extienden desde la mitad de la década de los 
sesenta hasta finales de los ochenta. La multiprogramación y los sistemas 
multiusuario introdujeron nuevos conceptos de interacción hombre-máquina. Las 
técnicas interactivas abrieron un nuevo mundo de aplicaciones y nuevos niveles de 
sofisticación del hardware y del software. Los sistemas de tiempo real podían 
recoger, analizar y transformar datos de múltiples fuentes, controlando así los 
procesos y produciendo salidas más rápidas Los avances en los dispositivos de 
Capítulo 1 
Ingeniería de Software 
 
 8 
almacenamiento en línea condujeron a la primera generación de sistemas de gestión 
de bases de datos. 
 
Las empresas desarrolladoras de sistemas tenían que corregir su software existente 
cuando se detectaban errores, cambiaban los requisitos de los usuarios o se tenía 
que adaptar a nuevos dispositivos de hardware que se hubieran adquirido. A este 
conjunto de actividades se le nombro mantenimiento del software que forma parte 
importante del desarrollo de software. 
 
Con los sistemas distribuidos en múltiples computadoras, cada una ejecutando 
funciones concurrentes y comunicándose con alguna otra, incrementó notablemente 
la complejidad de los sistemas informáticos. Las redes de área local y de área 
global, las comunicaciones digitales de gran capacidad de transmisión y la creciente 
demanda de acceso "instantáneo" a los datos, supusieron una fuerte presión sobre 
los desarrolladores del software. La principal característica fue la llegada y amplio 
uso de los microprocesadores. 
 
Entran las potentes máquinas personales controladas por sistemas operativos 
sofisticados, en redes globales y locales, acompañadas por aplicaciones de software 
avanzadas. 
 
La industria del software ya es la cuna de la economía del mundo. Las técnicas para 
el desarrollo del software están cambiando en la forma en que la comunidad 
construye programas informáticos. Las tecnologías orientadas a objetos están 
desplazando rápidamente los enfoques de desarrollo de software más 
convencionales en muchas áreas de aplicaciones. 
Sin embargo, un conjunto de problemas relacionados con el software ha persistido a 
través de la evolución de los sistemas basados en computadora, y estos problemas 
continúan aumentando, como los que se listan a continuación: 
 
1. La habilidad de construir nuevos programas no pueden ir al mismo ritmo 
de la demanda de éstos. 
Capítulo 1 
Ingeniería de Software 
 
 9 
2. La dificultad de construir programas lo suficientemente rápido como para 
cumplir las necesidades del mercado y de los negocios. 
3. El uso excesivo de computadoras y dependencia de las operaciones 
fiables del software. Cuando el software falla, pueden ocurrir daños 
económicos enormes. 
4. El no poder construir software informático que tengan fiabilidad y la calidad 
necesaria para el usuario. 
5. El soporte y mejora de los programas es amenazada por diseños pobres y 
recursos inadecuados. 
 
En respuesta a estos problemas, la práctica de la ingeniería del software se está 
adoptando en toda la industria. 
En nuestra actualidad ingeniería de software ha cambiado la cultura del mundo 
debido al extendido uso de la computadora. El correo electrónico (e-mail), la WWW, 
permiten a la gente comunicarse en nuevas formas. El software baja el costo y 
mejora la calidad de los servicios. 
La ingeniería de software se puede considerar como la ingeniería aplicada al 
software, esto es con base a herramientas preestablecidas, la aplicación de las 
mismas de la forma más eficiente y óptima; objetivos que siempre busca la 
ingeniería. No es sólo la resolución de problemas, sino más bien teniendo en cuenta 
las diferentes soluciones, elegir la más apropiada. 
En los años noventa los estándares de la ingeniería de software y la madurez de 
proceso han caracterizado la industria del software como una disciplina madura. En 
un nivel más técnico, la ingeniería de software comienza con una serie de tareas 
que hacen modelos y que resultan en una especificación completa de requisitos y 
una representación comprensiva de diseño del software que será construido. 
El software se ha convertido en el elemento clave de la evolución de los sistemas y 
productos informáticos. Ha pasado de ser una resolución de problemas 
especializadas y una herramienta de análisis de información, a ser una industria por 
sí misma. Cada uno de estos elementos compone una configuración que se crea 
como parte del proceso de la ingeniería del software. El objetivo de la ingeniería del 
Capítulo 1 
Ingeniería de Software 
 
 10 
software es proporcionar un marco de trabajo para construir software con mayor 
calidad. 
Las economías de los países desarrollados dependen en gran parte del software, 
más y más sistemas son actualmente controlados por software. La ingeniería de 
software concierne a teorías, métodos y herramientas para el desarrollo profesional 
de software. 
 
1.2 Conceptos básicos 
La ingeniería de software es una disciplina de la Ingeniería que concierne a todos 
los aspectos de la producción de software, los Ingenieros de Software adoptan un 
enfoque sistemático para llevar a cabo su trabajo y utilizan las herramientas y 
técnicas necesarias para resolver el problema planteado, de acuerdo a las 
restricciones de desarrollo y recursos disponibles. 
Hay que dejar claro cuál es la diferencia entre ingeniería de software y computación, 
la primera concierne sólo al desarrollo de sistemas o productos de software y la 
segunda concierne a la teoría, así como a los fundamentos de cualquier sistema de 
cómputo, sea de hardware o de software. 
La ingeniería de sistemas concierne a todos los aspectos del desarrollo de sistemas 
basados en cómputo, que incluyen hardware, software y el proceso de ingeniería, 
mientras que la ingeniería de software es solo parte de este proceso. 
¿Qué es el Software? Es un producto que consiste de programas de cómputo y su 
documentación asociada. Los productos de software genéricos son producidos por 
una organización para ser vendidos al mercado, mientras que los productos hechos 
a la medida son sistemas desarrollados bajo pedido a un desarrollador específico. 
Un buen producto de software debe tener las siguientes características: 
Confiable : El software no debe causar daños físicos o económicos en el caso de 
fallos. Es un término necesario que sea separado en varios elementos, los cuales 
permiten darle al software el fiabilidad, éstos son: 
Capítulo 1 
Ingeniería de Software 
 
 11 
• Consistencia y precisión. 
• Solidez. 
• Simplicidad. 
• Calidad en los procesos de desarrollo. 
Eficiente : Debe realizar las funciones establecidas con resultados confiables, 
ejecutar todas las operaciones que se requieren en un tiempo aceptado y que sea 
fácilmente usado por el grupo de usuarios a quien está dirigido. 
El software debe contar con una interfaz de usuario adecuada y su documentación. 
La importancia de estas características depende del tipo de producto y en el 
ambiente en el que será utilizado. Algunos de estos atributos pueden predominar 
dependiendo del tipo de sistema que se requiera. Los costos tienden a crecer 
exponencialmente si son requeridos altos niveles de alguna de estas características. 
Facilidad para dar mantenimiento : Debe ser posible que el software evolucione y 
que siga cumpliendo con sus especificaciones. Involucra los elementos que 
simplifican la labor de prevención, corrección o ampliación del código del programa. 
Retomar un código escritomeses antes es un trabajo dispendioso y agobiante, en 
especial cuando las aplicaciones no cuentan con la característica a la cual aquí se 
hace referencia. Las siguientes características se pueden considerar como atributos 
de este aspecto: 
• Exactitud y claridad en la documentación 
• Modularidad acoplamiento 
• Facilidad de lectura 
• Simplicidad 
El software contiene instrucciones de computadora, descripción de las estructuras 
de datos, algoritmos, componentes de software, procedimientos y funciones escritas 
en algún lenguaje de programación. El software puede dividirse de la siguiente 
forma: 
 
Capítulo 1 
Ingeniería de Software 
 
 12 
• Por su estructura: 
o Funcionales. 
o Orientados a objetos. 
o Orientados a listas. 
o Orientados a componentes. 
• Por su función: 
o Programas o Sistemas de Usuario 
o Interfaces Hombre-Máquina. 
o Herramientas de Software. 
o Librerías. 
o Sistemas de Uso Genérico: Compiladores, Procesadores de Texto, 
etc. 
o Bases de Datos. 
o Sistemas Basados en Web. 
• Por su plataforma de cómputo: 
o Sistemas Embebidos. 
o Sistemas de Cómputo Distribuido. 
o Sistemas de Cómputo Paralelo. 
o Sistemas de Tiempo Real. 
o Sistemas Basados en Chips. 
El proceso de software es un conjunto de actividades requeridas para desarrollar un 
sistema de software como son: 
Especificación - Establecer los requerimientos y restricciones del sistema, qué 
debe hacer el software y cuáles son sus especificaciones de desarrollo. 
Diseño - Producir un modelo en papel del sistema. 
Manufactura - Se comienza con construcción del sistema. 
Prueba - Verificar que el sistema cumpla con las especificaciones requeridas. 
Capítulo 1 
Ingeniería de Software 
 
 13 
Instalación - Entregar el sistema al usuario y asegurar su funcionamiento. 
Mantenimiento - Reparar los errores en el sistema cuando sean descubiertos. 
Se debe tomar en cuenta que el proceso de software debe ser confiable (los errores 
son localizados antes de la entrega), robusto (no interrumpe las operaciones ante 
problemas inesperados), de fácil mantenimiento y rápido (rapidez en la construcción 
del sistema). 
Todos los tipos de software requieren que los analistas, diseñadores y 
desarrolladores apliquen una metodología de desarrollo para que se logren 
productos a las necesidades del usuario. 
El éxito de un proyecto involucra elementos como la planeación, la administración y 
la utilización de metodologías de desarrollo de software. A través de la planeación 
se determinan los recursos necesarios para el desarrollo del proyecto, la factibilidad 
del mismo y el tiempo estimado de desarrollo; unido a ello con la administración se 
controla, evalúa y corrige la dirección de acuerdo a las contingencias y demás 
elementos que se vayan presentando durante el desarrollo; finalmente, a través del 
uso de una metodología de desarrollo de software constituyen uno de los 
mecanismos que actualmente se utilizan para lograr que los participantes trabajen 
en conjunto y garanticen un buen producto de software. 
1.3 Clasificación de las metodologías de análisis d e sistemas 
La metodología para el desarrollo de software es un método sistemático de realizar, 
gestionar y administrar un proyecto para llevarlo a cabo con altas posibilidades de 
éxito. 
La finalidad del uso de la metodología de análisis de sistemas es disminuir el 
tiempo, corregir y controlar cada etapa de desarrollo de un programa. Lo que nos 
permitirá de forma sistemática obtener un producto correcto y libre de errores. 
 
Actualmente podemos clasificar las metodologías de análisis, con base en el 
paradigma de programación (Figura 1.1), estas son: 
 
 
Capítulo 1 
Ingeniería de Software 
 
 14 
Metodologías estructuradas 
 
La orientación de esta metodología se dirige hacia los procesos que intervienen en 
el sistema a desarrollar, es decir, cada función que realice el sistema se fragmenta 
en pequeños módulos individuales para resolver de una manera más sencilla el 
problema y posteriormente unirlos en una solución. 
 
Metodologías orientadas a objetos 
 
Estas metodologías no comprenden los procesos como funciones sino que arma 
módulos basados en componentes, es decir, cada componente es independiente del 
otro, lo que nos permite obtener un código reutilizable. 
Metodologías Ágiles 
Estas metodologías ofrecen una alternativa a los procesos de desarrollo de software 
tradicionales, caracterizados por ser rígidos y dirigidos por la documentación que se 
genera en cada una de las actividades desarrolladas. 
Capítulo 1 
Ingeniería de Software 
 
 15 
 
Figura 1.1 Clasificación de las metodologías de análisis de sistemas 
1.4 Metodologías de análisis de sistemas 
Las metodologías nos indican las actividades a realizar para lograr el producto de 
software deseado, mostrando además qué personas deben participar en el 
desarrollo de las actividades y qué papel deben de tener. Además detallan la 
información que se debe producir como resultado de una actividad y los 
procedimientos necesarios para comenzar. 
1.4.1 Proceso y características de las metodologías 
 
Ciclo de Vida 
Un modelo de ciclo de vida de software es una vista de las actividades que ocurren 
durante el desarrollo de sistemas, intenta determinar el orden de las etapas 
involucradas y los criterios de transición asociadas entre estas etapas. 
◆ Modelo Orientados a la Especificación 
 
 
◆ Modelos de Desarrollo Evolutivo 
 
 
 
◆ Modelos Iterativos 
 
 
◆ Modelo Concurrente 
 
◆ Modelo de Desarrollo Rápido 
•Modelo en cascada 
•Modelo en V 
Metodologías 
Orientadas a 
objetos 
 
•Modelo incremental 
•Modelo en espiral 
Metodologías 
Ágiles 
Metodologías 
 Estructuradas 
•Modelo de prototipos evolutivos 
•Modelo de prototipos de pruebas 
Metodologías 
◆ RUP (Proceso Unificado de Rational) 
◆ Modelo XP (Programación Extrema) 
 
◆ Modelo de Desarrollo de Software Adaptable 
 
◆ DSDM (Método de Desarrollo de Sistema Dinámico) 
 
◆ Método de Desarrollo Manejado por Rasgos 
 
◆ Modelo Scrum 
Capítulo 1 
Ingeniería de Software 
 
 16 
El ciclo de vida del software se encarga de: 
• Describir las fases principales de desarrollo de software. 
• Definir las fases primarias esperadas de ser ejecutadas durante esas fases. 
• Administra el progreso del desarrollo. 
Elementos del Ciclo de Vida 
Se compone de fases sucesivas compuestas por tareas planificables. Según el 
modelo de ciclo de vida, la sucesión de fases puede ampliarse con ciclos de 
realimentación, de manera que conceptualmente se considere una misma fase y se 
pueda ejecutar más de una vez a lo largo de un proyecto, recibiendo en cada 
iteración aportaciones de resultados que se van produciendo (realimentación). 
Los elementos que integran un ciclo de vida son: 
Las fases . Una fase es un conjunto de actividades relacionadas con un objetivo en 
el desarrollo del proyecto. Se construye agrupando tareas que pueden compartir un 
tramo determinado del tiempo de vida de un proyecto. La agrupación de tareas 
impone requisitos temporales correspondientes a la asignación de recursos. Cada 
fase viene definida por un conjunto de elementos observables externamente como 
son las actividades con las que se relaciona, los datos de entrada (resultados de la 
fase anterior, documentos o productos requeridos para la fase, experiencias de 
proyectos anteriores), los datos de salida (resultados a utilizar por la fase posterior, 
experiencia acumulada, pruebas o resultados efectuados) y la estructura interna de 
la fase. 
Los entregables . Son los productos intermedios que se generan en cada fase. 
Pueden ser materiales (componentes, equipos) ó inmateriales (documentos, 
software). Los entregables permiten evaluar la marcha del proyecto mediante 
comprobaciones de posibles modificaciones a los requisitos funcionales y de las 
condiciones de realización previamente establecidos. Cadauna de estas 
evaluaciones puede servir, además, para la toma de decisiones a lo largo del 
desarrollo del proyecto. 
 
Capítulo 1 
Ingeniería de Software 
 
 17 
Metodologías estructuradas 
 
a) Modelos orientados a la especificación 
 
Se adoptan procesos de desarrollo de software estructurado definiendo actividades 
a realizar delimitadas por especificaciones, diseño y desarrollo con tiempos 
intermedios de separación entre ellas, en las cuales se suponían acabadas las 
actividades de las etapas anteriores. 
 
Modelo en cascada . Este es el modelo básico que sirve como bloque de 
construcción para los demás de ciclo de vida tradicionales, consta en realizar el 
desarrollo de software a través de una secuencia simple de fases (Figura 1.2). Cada 
fase tiene un conjunto de metas bien definidas, y las actividades dentro de la fase 
contribuyen a la satisfacción de metas de esa fase o quizás a una subsecuencia de 
metas de la fase. 
 
 
Figura 1.2. Modelo en cascada 
 
Ventajas 
� La ventaja de este modelo radica en su sencillez ya que sigue los pasos 
intuitivos necesarios a la hora de desarrollar el software. 
 
 
 
Capítulo 1 
Ingeniería de Software 
 
 18 
Desventajas 
� Los proyectos reales raramente siguen el flujo secuencial que propone el 
modelo, siempre hay iteraciones y se crean problemas en la aplicación del 
paradigma. 
� Normalmente, es difícil para el cliente establecer explícitamente al principio 
todos los requisitos del sistema, los cuales son necesarios para este modelo, 
además tiene dificultades en acomodar posibles incertidumbres que pueden 
existir al comienzo de muchos productos. 
� El cliente debe tener paciencia, ya que solo se tendrá una versión operativa 
del sistema hasta llegar a las etapas finales del proyecto. 
� El riesgo es mayor que el de otros modelos, pues en lugar de hacer pruebas 
de aceptación al final de cada etapa, las pruebas comienzan a efectuarse 
luego de haber terminado la implementación, lo que puede traer como 
consecuencia un retroceso de todo el proceso. 
� El modelo no contempla la posibilidad de retornar a etapas, cosa que en la 
realidad puede ocurrir. 
 
Modelo en V. Entre las muchas variantes surgidas del modelo en cascada está el 
modelo en V (Figura 1.3), que resuelve en parte el problema de la simplicidad del 
modelo de cascada que sólo muestra una salida por proceso y el hecho de que esta 
salida no puede ser reinsertada como parte de la entrada de etapas anteriores. 
 
 
Figura 1.3: Modelo en V 
 
Capítulo 1 
Ingeniería de Software 
 
 19 
Ventajas 
���� El modelo involucra validaciones de cada una de las etapas del modelo de 
cascada. 
 
Desventajas 
���� Se toma toda la complejidad del problema de una vez y no en iteraciones o 
ciclos de desarrollo, lo que disminuye el riesgo. 
 
b) Modelos de desarrollo evolutivo 
 
Los documentos producidos al final de cada etapa pueden convertirse en obstáculos 
ya que las sucesivas etapas no podrán empezar hasta que éstos no se acaben. En 
los modelos evolutivos se produce un sistema rudimentario inicial que evoluciona 
según las necesidades del cliente hasta cumplir con los requisitos últimos de éste. Al 
no requerir pre-especificaciones detalladas tampoco exige una costosa producción 
de documentación por etapas. 
 
Las etapas de los modelos evolutivos son: 
 
1) Formulación de un esquema de los requisitos del sistema como guía para los 
programadores (aunque no necesariamente incompleta ni consistente). 
2) Desarrollo de un sistema, tan rápido como sea posible, basado en las 
especificaciones anteriores. 
3) Evaluación y modificación del sistema según vayan así especificándolo los 
propios usuarios. 
 
Modelo de prototipos evolutivos. El modelo de desarrollo evolutivo construye una 
serie de grandes versiones sucesivas de un producto. Sin embargo, mientras que la 
aproximación incremental presupone que el conjunto completo de requerimientos es 
conocido al comenzar, el modelo evolutivo asume que los requerimientos no son 
completamente conocidos al inicio del proyecto. 
 
Capítulo 1 
Ingeniería de Software 
 
 20 
En el modelo evolutivo, los requerimientos son cuidadosamente examinados, y sólo 
los que son bien comprendidos son seleccionados para el primer incremento. Los 
desarrolladores construyen una implementación parcial del sistema que recibe sólo 
estos requerimientos. El sistema es entonces desarrollado, los usuarios lo usan, y 
proveen retroalimentación a los desarrolladores. Basada en esta retroalimentación, 
la especificación de requerimientos es actualizada, y una segunda versión del 
producto es desarrollada y desplegada. El proceso se repite indefinidamente (Figura 
1.4). 
 
Figura 1.4: Modelo de desarrollo de prototipos evolutivos de software 
 
Ventajas 
� Todo lo que se tiene que hacer es construir un subconjunto de requerimientos 
conocidos (incremental), y comprender al principio que muchos nuevos 
requerimientos es probable que aparezcan cuando el sistema sea desplegado 
o desarrollado. 
 
Desventajas 
� El desarrollo de software en forma de prototipos evolutivos requiere un 
especial cuidado en la manipulación de documentos, programas, datos de 
pruebas, etc. desarrollados para distintas versiones del software. 
� Cada paso debe ser registrado, la documentación debe ser recuperada con 
facilidad y los cambios deben ser efectuados de una manera controlada. 
 
Capítulo 1 
Ingeniería de Software 
 
 21 
Modelo de prototipos de pruebas. En el modelo de prototipos de pruebas se crea 
una implementación parcial de un sistema, para el propósito explícito de aprender 
sobre los requerimientos del sistema (Figura 1.5). Un prototipo es construido de una 
manera rápida; esto es dado a los usuarios, clientes o representantes de ellos, 
posibilitando que ellos experimenten con el prototipo. Estos individuos luego proveen 
la retroalimentación sobre el prototipo proporcionado, quienes capturan en la 
documentación actual de la especificación de requerimientos la información 
entregada por los usuarios para el desarrollo del sistema real. Cuando los 
requerimientos son comprendidos se desecha del prototipo y se empieza a 
desarrollar el sistema real. 
 
Figura 1.5: Modelo de desarrollo de prototipos de pruebas desechables 
Ventajas 
� El prototipo puede ser usado como parte de la fase de requerimientos 
(determinar requerimientos) o puede servir para algún o todo el desarrollo 
incremental en modelos incrementales o evolutivos. 
� El prototipo es construido con los requerimientos generales y más 
pobremente entendidos. 
 
Desventajas 
� El desarrollo de software requiere un especial cuidado en la manipulación de 
documentos, programas, datos de pruebas, etc. 
 
 
 
Capítulo 1 
Ingeniería de Software 
 
 22 
c) Modelos iterativos 
La idea principal detrás de mejoramiento iterativo es desarrollar un sistema de 
programas de manera incremental, permitiéndole al desarrollador sacar ventaja de lo 
que se ha aprendido a lo largo del desarrollo anterior, incrementando versiones 
entregables del sistema. El aprendizaje viene de dos vertientes: el desarrollo del 
sistema, y su uso. Los pasos claves en el proceso eran comenzar con una 
implementación simple de los requerimientos del sistema, e iterativamente mejorar 
la secuencia evolutiva de versiones hasta que el sistema completo esté 
implementado. En cada iteración, se realizan cambios en el diseño y se agregan 
nuevas funcionalidades y capacidades al sistema. 
Modelo incremental. Sugerido por Mills, en 1980, divide el proceso en conjuntos de 
procesos menores, que se identifican y resuelven por separado. En el modelo 
incremental (Figura 1.6) el cliente identifica y esquematiza los servicios esperados 
por el sistema priorizándolos. Esta priorización es tenida en cuenta a la hora del 
desarrollo, posteriormente de la esquematización, y división surgen fragmentosa ser 
resueltos por distintas partes del sistema, una vez que uno de los incrementos se ha 
completado y puesto en funcionamiento, el cliente puede usarlo teniéndose así en 
cuenta sus sugerencias tanto para mejorar esa parte como para reestructurar y 
mejorar las demás. 
 
Figura 1.6: Modelo de desarrollo incremental 
Capítulo 1 
Ingeniería de Software 
 
 23 
 
Ventajas 
� El sistema es dividido en procesos menores. 
� El desarrollo del sistema es creado tomando encuesta la prioridad de los 
requerimientos, es decir, el sistema primero cumple con los requerimientos 
más importantes para el usuario, permitiéndole satisfacer dichas necesidades 
aunque el sistema no esté terminado. 
 
Desventajas 
� La identificación de los incrementos son relativamente pequeños y deben 
cubrir alguna funcionalidad, siendo difícil, en muchos casos asociar requisitos 
del cliente con funcionalidades del sistema. Los requisitos, normalmente no 
son independientes y la consecución de uno implica el desarrollo de varias 
funcionalidades. 
� Exige la implantación de una infraestructura común a varias partes del 
sistema. Esto dificulta aún más la independencia de las partes del sistema. 
� Problemas de la gestión de los contratos, ya que partes del sistema no se 
saben cuándo van a empezar, es difícil llevar un sistema de contrataciones y 
organizar el trabajo del personal involucrado, que usualmente debe fijarse con 
horarios y fechas desde el principio. 
 
Modelo en espiral. En el modelo en espiral cada parte se resuelve 
independientemente teniendo en cuenta los costos y riesgos. Propuesto inicialmente 
por Boehm en 1988. Ve el desarrollo del proyecto como una espiral, desde una 
concepción inicial, en el centro, hasta el desarrollo final del sistema (Figura 1.7), está 
basado en una constante evolución de los riesgos involucrados ya que antes de 
entrar a la fase siguiente se debe tener una completa evaluación de riesgos, estos 
riesgos son considerados falta de información de manera que para resolverlos es 
necesario recolectar información y analizarla. 
 
Entre sus principales características se encuentran la de permitir revisiones 
regulares del progreso logrado frete a objetivos bien definidos, permitiendo eliminar 
los problemas usuales en el modelo de prototipos evolutivos. 
Capítulo 1 
Ingeniería de Software 
 
 24 
 
Figura 1.7 Modelo en espiral de Boehm original de 1988 
Ventajas 
� En sistemas pequeños donde no se presenten un gran riesgo en la obtención 
de los requisitos se convierte en un sencillo modelo en cascada 
� Como el software evoluciona, a medida que progresa el proceso, el 
desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en 
cada uno de los niveles evolutivos. 
� Permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos 
en cualquier etapa de evolución del producto. 
� Demanda una consideración directa de los riesgos técnicos en todas las 
etapas del proyecto. 
� Reduce los riesgos. 
 
Capítulo 1 
Ingeniería de Software 
 
 25 
Desventajas 
� La dificultad del análisis de riesgos, por lo que se requiere de personas 
especializadas y con experiencia en el análisis de riesgos. 
� Los problemas de contratación, ya que este modelo trata de evitar decisiones 
prematuras, que son, por otro lado esenciales a la hora de prever fechas de 
contratación. 
 
d) Modelo concurrente 
Llamado algunas veces ingeniería concurrente, es un modelo de tipo de red donde 
todas las personas actúan simultáneamente o al mismo tiempo. 
El término ingeniería concurrente se ha usando desde 1986, cuando el Instituto para 
el Análisis de la Defensa de Estados Unidos lo describió en su reporte R-388. 
Mejora el enfoque secuencial de la producción tradicional mediante tres elementos 
principales: 
 
� Una arquitectura computacional distribuida que permite la sincronización, la 
programación óptima de tareas y el manejo adecuado de flujos de 
información. 
� Una representación unificada de toda la información de diseño y manufactura, 
de forma que pueda visualizarse e interpretarse desde diversas perspectivas. 
� Un conjunto de herramientas computacionales que permiten desarrollar 
prototipos a bajo costo, de forma óptima e inteligente. 
 
Sus principales características son: ser un modelo que esta dirigido por las 
necesidades del usuario, las decisiones de la gestión de los procesos de desarrollo y 
los resultados de las revisiones de los prototipos. 
Ventajas 
� El enfoque concurrente permite la realización simultánea de todas las tareas 
de desarrollo hasta la fabricación del prototipo. 
Capítulo 1 
Ingeniería de Software 
 
 26 
� Funciona utilizando equipos de trabajo multidisciplinarios teniendo un gran 
énfasis en el manejo de rutas de información más que de jerarquías 
organizacionales. 
� El modelo de desarrollo concurrente es aplicable a todo tipo de desarrollo de 
software y proporciona una imagen exacta del estado actual de un proyecto. 
 
Desventajas 
 
� Define una red de actividades, donde todas las actividades de la red existen 
simultáneamente con otras. 
 
e) Modelo de desarrollo rápido 
 
El Desarrollo Rápido de Aplicaciones (DRA-Rapid Application Development) es un 
modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo 
de desarrollo extremadamente corto. DRA es una adaptación a alta velocidad en el 
que se logra el desarrollo rápido utilizando un enfoque de construcción basado en 
componentes. Si se comprenden bien los requisitos y se limita el ámbito del 
proyecto, el proceso DRA permite al equipo de desarrollo crear un sistema 
completamente funcional dentro de periodos cortos de tiempo. 
 
La limitación de tiempo impuesto en un proyecto DRA demanda un ámbito en 
escalas. Si una aplicación de gestión puede modularse de forma que permita 
completarse cada una de las funciones principales en menos de tres meses, es un 
sistema candidato para ser desarrollado usando DRA. Cada una de las funciones 
pueden ser enfrentadas por un equipo DRA diferente y ser integradas en un solo 
conjunto. 
 
Ventajas 
� Su principal ventaja es el desarrollar sistemas funcionales en poco tiempo. 
 
 
 
Capítulo 1 
Ingeniería de Software 
 
 27 
Desventajas 
� Para proyectos grandes, el DRA requiere de recursos humanos suficientes 
como para crear el número correcto de equipos DRA. 
� DRA requiere clientes y desarrolladores comprometidos en las rápidas 
actividades necesarias para completar un sistema en un marco de tiempo 
abreviado. Si no hay compromiso, por ninguna de las partes constituyentes, 
los proyectos DRA fracasarán. 
 
Metodologías ágiles 
En febrero de 2001 nace el término ágil aplicado al desarrollo de software, cuyo 
objetivo es esbozar los valores y principios que deberán permitir a los equipos 
desarrollar software rápidamente y respondiendo a los cambios que puedan surgir a 
lo largo del proyecto. 
Estas metodologías se basan en 12 principios básicos para el desarrollo de 
software: 
� La prioridad es satisfacer al cliente mediante oportunas y continuas entregas 
de software que le aporte un valor. 
� Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente 
tenga una ventaja competitiva. 
� Entregar frecuentemente, software que funcione desde un par de semanas a 
un par de meses, con el menor intervalo de tiempo posible entre entregas. 
� La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del 
proyecto. 
� Construir el proyecto en torno a individuos motivados. Darles el entorno y el 
apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo. 
� El diálogo cara a cara es el método más eficiente y efectivo para comunicar 
información dentro de un equipo de desarrollo. 
� El software que funciona es la medida principal de progreso. 
Capítulo 1 
Ingeniería de Software 
 
 28 
� Los procesoságiles promueven un desarrollo sostenible. Los promotores, 
desarrolladores y usuarios deberían ser capaces de mantener una paz 
constante. 
� La atención continua a la calidad técnica y al buen diseño mejora la agilidad. 
� La simplicidad es esencial. 
� Las mejores arquitecturas, requisitos y diseños surgen de los equipos 
organizados por sí mismos. 
� En intervalos regulares, el equipo reflexiona respecto a cómo llegar a ser más 
efectivo, y según esto ajusta su comportamiento. 
 
Ventajas 
� Capacidad de respuesta a cambios de requisitos a lo largo del desarrollo, ya 
que se incorpora una planificación al proceso de desarrollo. 
� Entrega continua y en tiempos cortos del software funcional. 
� Trabajo continuo entre el cliente y el equipo de desarrollo. 
� Minimizan los costos de los cambios de requerimientos y alcances. 
� Permite al cliente no tomar decisiones prematuras, mediante técnicas 
establecidas por la metodología especifica, permitiendo no realizar 
inversiones innecesarias en tecnología. 
 
Desventajas 
� Falta de documentación del diseño, lo cual hace difícil el mantenimiento y uso 
del sistema. 
� Presenta una fuerte dependencia de las personas, ya que se evita en lo mas 
posible la documentación y el diseño convencional, los proyectos ágiles 
dependen en gran medida de las personal del equipo de desarrollo 
 
a) Metodología XP (Programación Extrema) 
Las raíces de la XP yacen en la comunidad de Smalltalk, y en particular la 
colaboración cercana de Kent Beck y Ward Cunningham a finales de los 80´s. 
Ambos refinaron sus prácticas en numerosos proyectos a principios de los 90´s, 
extendiendo sus ideas de un desarrollo de software adaptable y orientado a la gente. 
Capítulo 1 
Ingeniería de Software 
 
 29 
La XP empieza con cuatro valores: Comunicación, Retroalimentación, Simplicidad y 
Coraje. Construye sobre ellos una docena de prácticas que los proyectos XP deben 
seguir. Muchas de estas prácticas son técnicas antiguas, tratadas y probadas, 
incluyendo la mayoría de los procesos planeados. 
En esta plataforma XP construye un proceso de diseño evolutivo que se basa en 
refactorar un sistema simple en cada iteración. Todo el diseño se centra en la 
iteración actual y no se hace nada anticipadamente para necesidades futuras. El 
resultado es un proceso de diseño disciplinado, lo que es más, combina la disciplina 
con la adaptabilidad de una manera que indiscutiblemente la hace la más 
desarrollada entre todas las metodologías adaptables. 
b) Modelo de desarrollo de software adaptable 
 
Creado por Highsmith, la cual ve a la planificación como una paradoja en un 
ambiente adaptable, ya que los resultados son naturalmente imprevisibles. En la 
planificación tradicional, las desviaciones del plan son errores que deben corregirse. 
En el ambiente adaptable, sin embargo, las desviaciones nos guían hacia la solución 
correcta. 
En este ambiente imprevisible se necesita que las personas colaboren de la mejor 
manera para tratar con la incertidumbre. La atención de la gerencia es menor en lo 
que tiene que hacer la gente, y mayor sobre la comunicación alentadora para que 
las personas puedan proponer las respuestas creativas ellos mismos. 
En ambientes predictivos, el aprendizaje se desalienta a menudo. Las cosas se 
ponen de antemano y entonces se sigue ese diseño. Highsmith se enfoca 
directamente en fomentar las partes difíciles del desarrollo adaptable, en particular 
cómo fomentar la colaboración y el aprendizaje dentro del proyecto. 
c) DSDM (Método de Desarrollo de Sistema Dinámico) 
El DSDM empezó en Gran Bretaña en 1994 como un consorcio de compañías del 
Reino Unido, el método empieza con un estudio de viabilidad y negocio. El estudio 
de viabilidad considera si DSDM es apropiado para el proyecto. El estudio de 
Capítulo 1 
Ingeniería de Software 
 
 30 
negocio es una serie corta de talleres para entender el área de negocio dónde tiene 
lugar el desarrollo. También propone arquitecturas de esbozos del sistema y un plan 
del proyecto. 
El resto del proceso forma tres ciclos entretejidos: 
� El ciclo del modelo funcional produce documentación de análisis y 
prototipos. 
� El ciclo de diseño del modelo diseña el sistema para uso operacional. 
� El ciclo de implantación se ocupa del despliegue al uso operacional. 
DSDM tiene principios subyacentes que incluyen una interacción activa del usuario, 
entregas frecuentes, equipos autorizados, pruebas a lo largo del ciclo. Como otros 
métodos ágiles usan ciclos de plazos cortos de entre dos y seis semanas. Hay un 
énfasis en la alta calidad y adaptabilidad hacia requisitos cambiantes. 
d) Método de desarrollo manejado por rasgos 
El Desarrollo Manejado por Rasgos (FDD siglas en inglés) fue desarrollado por Jeff 
De Luca y el viejo gurú de la OO Peter Coad. Se enfoca en iteraciones cortas que 
entregan funcionalidad tangible. En el caso del FDD las iteraciones duran dos 
semanas. 
El FDD tiene cinco procesos. Los primeros tres se desarrollan al principio del 
proyecto. 
� Desarrollar un Modelo Global 
� Construir una Lista de los Rasgos 
� Planear por Rasgo 
� Diseñar por Rasgo 
� Construir por Rasgo 
Los últimos dos se hacen en cada iteración. Cada proceso se divide en tareas y se 
da un criterio de comprobación. Los desarrolladores entran en dos tipos: dueños de 
clases y programadores jefe. 
Capítulo 1 
Ingeniería de Software 
 
 31 
Los programadores jefe son los desarrolladores más experimentados. A ellos se les 
asignan rasgos a construir. Sin embargo ellos no los construyen solos. Sólo 
identifican qué clases se involucran en la implantación de un rasgo y juntan a los 
dueños de dichas clases para que formen un equipo para desarrollar ese rasgo. El 
programador jefe actúa como el coordinador, diseñador líder y mentor mientras los 
dueños de clases hacen gran parte de la codificación del rasgo. 
e) Metodología Scrum 
Scrum divide un proyecto en iteraciones (llamada carreras cortas) de 30 días. Antes 
de que comience una carrera se define su funcionalidad requerida y entonces se 
deja al equipo para que la entregue. El punto es estabilizar los requisitos durante la 
carrera. 
Sin embargo la gerencia no se desentiende durante la carrera corta. Todos los días 
el equipo sostiene una junta corta (quince minutos), llamada scrum, dónde el equipo 
discute lo que hará al día siguiente. En particular muestran a los bloques de la 
gerencia: los impedimentos para progresar que se atraviesan y que la gerencia debe 
resolver. También informan lo que se ha hecho para que la gerencia tenga una 
actualización diaria de dónde va el proyecto. 
Scrum se enfoca principalmente en la planeación iterativa y el seguimiento del 
proceso. Es muy cercana a las otras metodologías ágiles en muchos aspectos y 
debe funcionar bien con las prácticas de código de la XP. 
Metodología Orientada a objetos 
 
En general el desarrollo orientado a objetos se realiza de forma iterativa e 
incremental. Es iterativo por que las tareas de cada fase se llevan a cabo de forma 
iterativa, a la vez que existe un ciclo de desarrollo de análisis, diseño e 
implementación que permite hacer evolucionar al sistema. 
 
La parte incremental se lleva a cabo al dividir el sistema en un conjunto de 
particiones, cada una de las cuales se desarrolla de manera completa, hasta, que se 
finaliza el sistema. 
 
Capítulo 1 
Ingeniería de Software 
 
 32 
Al implementar estas dos formas de desarrollo permite que las actividades de 
validación, verificación y aseguramiento de la calidad se puedan realizar. Para cada 
iteración de cada fase de cada incremento en el desarrollo del sistema, es decir, de 
una forma continua. 
El modelo orientado a objetos se caracteriza por: 
 
� La eliminación de fronteras entre fases, ya que debido a la naturaleza iterativa 
del desarrollo orientado a objetos, estas fronteras se difuminan cadavez más. 
� Una nueva forma de concebir los lenguajes de programación y su uso, ya que 
se incorporan bibliotecas de clases y otros componentes reutilizables. 
� Un alto grado de iteración y solapamiento, lo que lleva a una forma de trabajo 
muy dinámica. 
 
Ventajas 
� Permite realizar un modelo de sistemas casi independientemente de los 
requisitos del proyecto. 
� El modelo se establece de una forma similar al razonamiento humano, y por 
lo tanto son más fáciles de entender. 
� Nos permite crear sistemas complejos, ya que se apoya en el desarrollo, de 
un lenguaje de programación orientado a objetos. 
� Nos permite dar mantenimiento más fácil al sistema. 
� Los modelos orientados a objetos representan el mundo real de una forma lo 
más fiel posible. 
 
Desventajas 
 
� Representa mayor dificultad el realizarlo, ya que los modelos orientados a 
objetos exigen una mayor abstracción de los requisitos del sistema. 
� Requieren gran compresión en cuestión de los requerimientos del sistema. 
 
 
 
 
Capítulo 1 
Ingeniería de Software 
 
 33 
RUP (Proceso Unificado de Rational) 
 
RUP es una metodología sólida, con documentación, que apoya el ciclo de vida 
evolutivo incremental, además de basarse en el desarrollo de componentes y al de 
orientado a objetos. Según Kruchten, RUP es un proceso de ingeniería de software 
que provee un enfoque disciplinado para la asignación de tareas y 
responsabilidades dentro de una organización desarrolladora de software. 
 
Los autores de RUP destacan que el proceso de software tiene tres características 
esenciales: 
 
� Dirigido por los Casos de Uso, los cuales no sólo especifican el diseño, si no 
también guían el diseño, implementación y pruebas. 
� Centrado en la arquitectura, es decir se centra en la organización o estructura 
de las partes más relevantes del sistema, lo que permite tener una visión 
común entre todos los involucrados (desarrolladores y usuarios) y una 
perspectiva clara del sistema completo, necesaria para controlar el desarrollo. 
� Iterativo e incremental, en donde el trabajo se divide en partes más pequeñas 
o mini proyectos. Permitiendo que el equilibrio entre Casos de Uso y 
arquitectura se vaya logrando durante cada mini proyecto, así durante todo el 
proceso de desarrollo. 
 
La ventaja principal de la metodología RUP es que cada una de las fases del 
desarrollo puede ser repetida, ordenadamente, cuando se desee para 
implementar nuevos cambios. Tiene una forma disciplinada de asignar tareas, 
administrar los requisitos y verifica la calidad continuamente. 
 
Ventajas 
� Tiene con conjunto de elementos de planificación (plan de desarrollo, plan 
de iteración, plan de calidad, etc.) que permiten controlar el desarrollo de 
software. 
Capítulo 1 
Ingeniería de Software 
 
 34 
� Determina un esquema de escalabilidad y gestión de riesgos con el cual 
detecta problema y fallos de una forma temprana, con la finalidad de 
prevenirlos y corregirlos. 
� Define que artefactos son necesarios para realizar alguna actividad, así 
como, que artefactos deben ser creados en cada actividad. 
 
Desventajas 
RUP representa un proceso basado en la documentación de todo el sistema, por lo 
cual su uso no es muy aconsejable para sistemas a desarrollar en un corto plazo. 
 
Capítulo 2 
Metodologías y procesos de análisis de software 
 35 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Capítulo 2 
Metodologías y procesos de análisis de software 
 36 
2. Metodologías y procesos de análisis de software 
 
La evolución de la disciplina de ingeniería de software ha traído consigo diferentes 
propuestas para mejorar los resultados en la búsqueda de la metodología adecuada 
para producir software de calidad en cualquier contexto de desarrollo. Las 
metodologías se caracterizan por exponer procesos basados en planeación 
exhaustiva. Esta planeación se realiza esperando que el resultado de cada proceso 
sea determinante y predecible. La experiencia ha mostrado que, como consecuencia 
de las características del software, los resultados de los procesos no son siempre 
predecibles y sobre todo, es difícil prever desde el comienzo del proyecto cada 
resultado. 
 
El modelo de cascada fue uno de los primeros modelos de ciclo de vida que 
formalizó un conjunto de procesos de desarrollo de software. Este modelo describe 
un orden secuencial en la ejecución de los procesos asociados. El modelo espiral se 
postuló como una alternativa al modelo de cascada, la ventaja de este modelo 
radica en el perfeccionamiento de las soluciones encontradas con cada ciclo de 
desarrollo, en términos de dar respuesta a los requerimientos inicialmente 
analizados. El modelo de cascada y el modelo espiral suponen, de manera general, 
que los requerimientos del cliente no cambian radicalmente en el transcurso del 
desarrollo del sistema. 
 
Así mismo, la realización de prototipos es una herramienta en la que se apoyan 
diferentes metodologías. Un prototipo debe tener el objetivo de mostrar al cliente o a 
la gerencia del proyecto el resultado que se obtendrá de la implementación de cada 
uno de los requerimientos del cliente una vez terminado el desarrollo. Con los 
prototipos se tiene la posibilidad de obtener retroalimentación de manera oportuna. 
 
La solución a algunos de los problemas presentados por las metodologías 
tradicionales se logra con una gran evolución del modelo espiral. El proceso 
unificado propone la elaboración de varios ciclos de desarrollo, donde cada uno 
finaliza con la entrega al cliente de un producto terminado. Éste se enmarca entre 
los conocidos modelos iterativo-incremental. 
Capítulo 2 
Metodologías y procesos de análisis de software 
 37 
Una alternativa para el desarrollo de sistemas, es el modelo XP el cual se 
caracteriza por ser dirigido por la generación de código y prototipos. Estos modelos 
para el desarrollo de sistemas son los más representativos, los cuales son: en 
cascada, espiral, prototipo, incremental, XP y RUP (capitulo V). 
 
2.1 Procesos de desarrollo de la metodología 
 
En un proyecto de desarrollo de software la metodología (Figura 2.1), define “quién 
debe hacer qué, cuándo y cómo debe hacerlo”, no existe una metodología de 
software universal. Las características de cada proyecto (equipo de desarrollo, 
recursos, etc.) exigen que el proceso sea configurable. 
 
 
 
Figura 2.1 Proceso de desarrollo de software 
 
2.1.1 Método en cascada 
 
Es el enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida 
del software, de forma tal que el inicio de cada etapa debe esperar a la finalización 
de la inmediatamente anterior (Figura 2.2). 
De esta forma, cualquier error de diseño detectado en la etapa de prueba conduce 
necesariamente al rediseño y nueva programación del código afectado, aumentando 
los costos del desarrollo. 
Requisitos Sistema 
Proceso de Desarrollo 
de Software 
Capítulo 2 
Metodologías y procesos de análisis de software 
 38 
 
Figura 2.2. Modelo de en cascada 
 
 
• Fase de ingeniería y análisis del sistema. Debido a que el software es siempre 
parte de un sistema mayor el trabajo comienza estableciendo los requisitos de todos 
los elementos del sistema y luego asignando algún subconjunto de estos requisitos 
al software. 
 
• Fase de análisis de los requisitos. Se analizan las necesidades de los 
usuarios finales del software a desarrollar para determinar qué objetivos debe 
cubrir. De esta fase surge una memoria llamada SRD (Documento de 
Especificación de Requisitos), que contiene la especificación completa de lo 
que debe hacer el sistema sin entrar en detalles internos. Es importante 
señalar que en esta etapa se deben verificar todo lo que se requiere en el 
sistema y será aquello lo que seguirá en las siguientes etapas, ya que no se 
pueden solicitar nuevos requisitos a mitad del proceso de elaboración del 
software 
 
• Fase de