


BICENTENARIADEARAGUA
VICERRECTORADO
ACADÉMICO
INGENIERÍAENSISTEMA
ANÁLISISDESISTEMASY
DISEÑOS
E-BOOK
AUTOR: JOSÉ PARADA
C.I.30.144.994
SECCIÓN: 1
FACILITADOR: ALEJANDRA REYES
SAN JOAQUÍN DE TURMERO, JUNIO DE 2023
En el contexto de los sistemas de información, una cascada se refiere a una serie de procesos o etapas que se ejecutan secuencialmente, en los que la salida de una etapa se convierte en la entrada de la siguiente En una cascada de sistemas de información, se trata de un proceso de desarrollo de software que sigue un enfoque secuencial y lineal, en el que cada fase del ciclo de vida del software se completa antes de avanzar a la siguiente
El modelo en cascada se divide generalmente en las siguientes etapas:
1 Requerimientos y análisis: Etapa en la que se identifican y se definen los requerimientos del sistema, se realiza un análisis de los mismos y se establecen los objetivos y metas del proyecto.
2. Diseño: Etapa en la que se realiza el diseño de la arquitectura del sistema, se define la estructura de datos, se establecen las interfaces de usuario y se diseñan los algoritmos y estructuras de control.
3. Implementación: Etapa en la que se codifica el software y se lleva a cabo la integración de los componentes del sistema.
4. Pruebas: Etapa en la que se realizan pruebas del software para asegurarse de que cumple con los requerimientos y funciona correctamente
5 Mantenimiento: Etapa en la que se realiza el mantenimiento y actualización del software para asegurar su correcto funcionamiento.
Este modelo se ha utilizado durante décadas en el desarrollo de software, aunque ha sido criticado por su enfoque inflexible y por no permitir cambios en etapas anteriores una vez se ha avanzado a una etapa posterior Sin embargo, sigue siendo utilizado en algunos proyectos que requieren un enfoque secuencial y bien definido
El modelo en cascada fue propuesto originalmente en 1970 por Winston Royce, un ingeniero de software estadounidense. En un artículo titulado "Managing the Development of Large Software Systems", Royce presentó su modelo de desarrollo de software en cascada como una posible solución para abordar los problemas de gestión y control de proyectos en el desarrollo de software.
Aunque el modelo en cascada ha sido criticado por su rigidez y falta de flexibilidad, ha sido muy influyente en el desarrollo de software y ha sido utilizado en muchas organizaciones y proyectos a lo largo de las últimas décadas. Además, ha servido de base para otros modelos y metodologías de desarrollo de software, como el modelo V o el modelo en espiral
El modelo en cascada tiene algunas características específicas que lo distinguen de otros modelos de desarrollo de software. Algunas de las características más importantes del modelo en cascada son las siguientes:
1. Enfoque secuencial: El modelo en cascada es un enfoque secuencial y lineal para el desarrollo de software, en el que cada fase se completa antes de avanzar a la siguiente. Esto significa que no se puede avanzar a la siguiente fase hasta que se hayan completado todas las actividades de la fase anterior
2 Fases bien definidas: El modelo en cascada se divide en fases bien definidas, cada una de las cuales tiene sus propios objetivos y entregables. El objetivo de cada fase es producir un conjunto de entregables específicos que se utilizan como entrada para la siguiente fase
3. Planificación: El modelo en cascada requiere una planificación rigurosa y detallada antes de comenzar el desarrollo del software. Esto incluye la identificación de los requerimientos, la definición de los objetivos y metas del proyecto, la planificación de la gestión de riesgos y la estimación de los recursos y el tiempo necesarios para cada fase.
4. Documentación: El modelo en cascada requiere una documentación detallada de todas las etapas del ciclo de vida del software, incluyendo los requerimientos del sistema, el diseño de la arquitectura del sistema, el código fuente, las pruebas y los manuales de usuario.
5. Control de cambios: El modelo en cascada tiene un control de cambios estricto, lo que significa que los cambios en una fase del ciclo de vida del software no se permiten después de que se haya completado esa fase y se haya avanzado a la siguiente.
6. Pruebas al final: En el modelo en cascada, las pruebas se realizan al final del ciclo de vida del software, una vez que se ha completado la implementación. Esto permite una evaluación integral del software antes de su entrega. El modelo en cascada se divide generalmente en las siguientes etapas o fases:
Elementos y uso
1. Requerimientos y análisis: En esta etapa se identifican y se definen los requerimientos del sistema, se realiza un análisis de los mismos y se establecen los objetivos y metas del proyecto. Los entregables de esta fase incluyen el documento de requerimientos del sistema y el plan de análisis.
2. Diseño: En esta etapa se realiza el diseño de la arquitectura del sistema, se define la estructura de datos, se establecen las interfaces de usuario y se diseñan los algoritmos y estructuras de control. Los entregables de esta fase incluyen el diseño de la arquitectura del sistema, el diseño detallado de los componentes del sistema y el plan de pruebas.
El desarrollo iterativo es una metodología de desarrollo de software en la que el ciclo de vida del software se divide en pequeñas iteraciones o ciclos que se repiten varias veces hasta que se alcanza el resultado final. Cada iteración consiste en una serie de actividades que incluyen la planificación, el análisis de requerimientos, el diseño, la implementación y las pruebas. Una vez que se completa una iteración, se realiza una revisión y se utiliza el feedback obtenido para mejorar el producto y planificar la siguiente iteración.
El desarrollo iterativo se centra en la entrega temprana de un software funcional y en la mejora continua del producto a lo largo del tiempo. En lugar de planificar todo el proyecto desde el principio, se planifican y ejecutan pequeñas iteraciones que permiten a los equipos de desarrollo trabajar de manera más flexible y adaptarse a los cambios en los requerimientos y el entorno del proyecto.
El desarrollo iterativo se basa en varios principios, como la entrega incremental, la retroalimentación temprana, la adaptabilidad y la mejora continua. Al entregar incrementos de software de manera temprana y frecuente, se pueden identificar problemas y oportunidades de mejora de manera rápida, lo que permite a los equipos de desarrollo adaptarse y mejorar el producto de manera continua.
Esta metodología se utiliza en proyectos de desarrollo de software en los que los requerimientos son inciertos o cambiantes, o en los que se requiere una entrega temprana y frecuente del software. También se utiliza en proyectos en los que se requiere una alta calidad del software y en los que se busca una mejora continua del producto a lo largo del tiempo.
Es el resultado de la evolución de varias metodologías y enfoques de desarrollo de software a lo largo de los años.
Una de las primeras metodologías que se basó en principios iterativos fue el "Desarrollo Evolutivo de Software" (Evolutionary Software Development), que fue propuesto en 1970 por Harlan Mills, un ingeniero de software estadounidense. Esta metodología se centraba en la entrega temprana de software y en la mejora continua del producto a lo largo del tiempo, y sentó las bases para el desarrollo iterativo.
Posteriormente, en la década de 1990, el desarrollo iterativo se popularizó con la metodología "Proceso Unificado de Desarrollo de Software" (Rational Unified Process), que fue desarrollada por Rational Software Corporation y más tarde adquirida por IBM. El Proceso Unificado se basaba en la idea de dividir el ciclo de vida del software en iteraciones y en la entrega temprana y frecuente de software.
Desde entonces, el desarrollo iterativo se ha convertido en una metodología popular y ampliamente utilizada en el desarrollo de software, y ha sido adoptado por muchas organizaciones y proyectos en todo el mundo.
El desarrollo iterativo tiene algunas características específicas que lo distinguen de otros modelos de desarrollo de software. Algunas de las características más importantes del desarrollo iterativo son las siguientes:
1. Iteraciones: El desarrollo iterativo se divide en iteraciones o ciclos cortos de desarrollo, en los que se planifica, diseña, implementa y prueba una parte del software. Cada iteración tiene una duración fija y produce un resultado funcional.
2. Entrega incremental: El desarrollo iterativo se centra en la entrega incremental y frecuente de software funcional, en lugar de esperar hasta el final del proyecto para entregar el producto completo.
3. Feedback temprano: El desarrollo iterativo se basa en la retroalimentación temprana y frecuente de los usuarios y los stakeholders, lo que permite a los equipos de desarrollo adaptarse y mejorar el producto a lo largo del tiempo.
4. Adaptabilidad: El desarrollo iterativo se adapta a los cambios en los requerimientos y el entorno del proyecto, permitiendo a los equipos de desarrollo trabajar de manera más flexible y adaptarse a las necesidades del cliente.
5. Mejora continua: El desarrollo iterativo busca la mejora continua del producto a lo largo del tiempo, mediante la identificación temprana de problemas y oportunidades de mejora.
6. Planificación flexible: El desarrollo iterativo se basa en una planificación flexible, en la que se planifican y ejecutan pequeñas iteraciones en lugar de planificar todo el proyecto desde el principio.
En general, el desarrollo iterativo es un enfoque ágil y flexible para el desarrollo de software, que se centra en la entrega temprana y frecuente de software funcional y en la mejora continua del producto a lo largo del tiempo. El desarrollo iterativo se utiliza generalmente en proyectos de desarrollo de software en los que los requerimientos son inciertos o cambiantes, o en los que se requiere una entrega temprana y frecuente del software.
El desarrollo iterativo se compone de varios elementos que se repiten en cada iteración o ciclo del proceso de desarrollo. Algunos de los elementos más importantes del desarrollo iterativo son los siguientes:
1. Planificación de iteraciones: En esta fase se planifica la próxima iteración, se definen los objetivos y metas específicas para la iteración y se establece el alcance del trabajo a realizar.
2. Análisis de requerimientos: En esta fase se revisan y actualizan los requerimientos del software y se definen los requerimientos específicos para la iteración.
3. Diseño: En esta fase se realiza el diseño detallado del software, se definen las interfaces de usuario, se diseñan los algoritmos y estructuras de control y se establecen las pruebas unitarias.
4. Implementación: En esta fase se codifica el software y se lleva a cabo la integración de los componentes del sistema.
5. Pruebas: En esta fase se realizan pruebas del software para asegurarse de que cumple con los requerimientos y funciona correctamente.
6. Evaluación y retroalimentación: En esta fase se evalúa el resultado de la iteración y se recibe retroalimentación de los usuarios y los stakeholders.
El desarrollo iterativo se utiliza generalmente en proyectos de desarrollo de software en los que los requerimientos son inciertos o cambiantes, o en los que se requiere una entrega temprana y frecuente del software. También se utiliza en proyectos en los que se busca una mejora continua del producto a lo largo del tiempo, o en los que se requiere una alta calidad del software.
El desarrollo iterativo es una metodología muy práctica y flexible, que se adapta fácilmente a los cambios en los requerimientos y el entorno del proyecto. Al entregar incrementos de software de manera temprana y frecuente, se pueden identificar problemas y oportunidades de mejora de manera rápida, lo que permite a los equipos de desarrollo adaptarse y mejorar el producto de manera continua.
RUP (Rational Unified Process) es un proceso de desarrollo de software iterativo e incremental que se centra en la gestión del ciclo de vida del software. Fue desarrollado por Rational Software Corporation (ahora parte de IBM) y es ampliamente utilizado en la industria del software.
El proceso RUP está basado en una serie de fases iterativas que incluyen la especificación de requisitos, el diseño, la implementación, las pruebas y el despliegue. Cada iteración se enfoca en la entrega de un conjunto de funcionalidades del software y se repite hasta que se completa el producto final.
RUP también se enfoca en la gestión de proyectos de software, proporcionando un marco de trabajo para la planificación, seguimiento y control del proyecto. Además, RUP se basa en un enfoque de desarrollo en equipo, fomentando la colaboración y la comunicación entre los miembros del equipo.
En resumen, RUP es un proceso de desarrollo de software iterativo e incremental que se centra en la gestión del ciclo de vida del software, la entrega de funcionalidades y la gestión de proyectos de software.
El proceso de desarrollo de software RUP (Rational Unified Process) fue creado por Rational Software Corporation en 1994. Desde entonces, ha sido ampliamente utilizado por empresas y organizaciones de todo el mundo para desarrollar software de alta calidad de manera efectiva y eficiente.
A lo largo de los años, RUP ha evolucionado y se ha adaptado a las cambiantes necesidades de la industria del software. Hoy en día, RUP sigue siendo una metodología de desarrollo de software popular y efectiva, aunque ha sido reemplazado por otras metodologías más modernas, como Agile y DevOps.
Las principales características del proceso de desarrollo de software RUP (Rational Unified Process) son las siguientes:
1. Es iterativo e incremental: RUP se basa en ciclos iterativos e incrementales en los que se desarrolla y se entrega una parte del software en cada iteración. Cada iteración construye sobre la anterior, lo que permite que el equipo de desarrollo se adapte a los cambios y mejoras en el software a medida que progresa el proyecto.
2. Se centra en la arquitectura: RUP se enfoca en la arquitectura del software desde el inicio del proyecto. Esto significa que se dedica tiempo y esfuerzo a definir la estructura y los componentes del software antes de comenzar el desarrollo. Esto ayuda a garantizar que el software esté bien diseñado y sea fácil de mantener.
3. Se basa en mejores prácticas: RUP se basa en las mejores prácticas de la industria del software, lo que significa que utiliza técnicas y herramientas probadas para el desarrollo de software. Esto ayuda a garantizar que el software se desarrolle de manera eficiente y efectiva.
4. Es adaptable: RUP es una metodología adaptable que se puede personalizar para satisfacer las necesidades específicas de un proyecto. Esto significa que el proceso puede ser modificado para adaptarse a diferentes tamaños de equipo, proyectos y requisitos de software.
5. Se enfoca en la gestión de proyectos: RUP incluye una serie de herramientas y técnicas de gestión de proyectos que ayudan a garantizar que el proyecto se complete a tiempo, dentro del presupuesto y con la calidad esperada. Esto incluye la planificación del proyecto, el seguimiento y control del progreso y la gestión de riesgos.
En resumen, las características clave de RUP son su enfoque iterativo e incremental, su enfoque en la arquitectura del software, su uso de mejores prácticas, su adaptabilidad y su enfoque en la gestión de proyectos.
El proceso de desarrollo de software RUP (Rational Unified Process) consta de cuatro elementos principales que se aplican en diferentes fases del ciclo de vida del software: .
2. Disciplinas: RUP define nueve disciplinas principales que se aplican en diferentes fases del ciclo de vida del software. Estas disciplinas incluyen la gestión del proyecto, la gestión de requisitos, el análisis y diseño, la implementación, las pruebas, la gestión del cambio, la gestión del despliegue, la gestión del medio ambiente y la gestión de la configuración. Cada disciplina tiene sus propias actividades y tareas que se llevan a cabo para lograr los objetivos de la fase en la que se está trabajando.
3. Roles: RUP define una serie de roles que se asignan a los miembros del equipo de desarrollo de software. Estos roles incluyen al arquitecto, al analista de negocios, al diseñador, al programador, al probador, al gerente de proyecto, entre otros. Cada rol tiene sus propias responsabilidades y tareas específicas que deben cumplirse para lograr los objetivos del proyecto.
4. Artefactos: RUP define una serie de artefactos que se crean durante el desarrollo del software. Estos artefactos incluyen documentos, modelos, diagramas, casos de uso, código fuente, planos de prueba, entre otros. Cada artefacto tiene su propio propósito y se utiliza para comunicar información importante sobre el software a diferentes miembros del equipo de desarrollo y a otras partes interesadas.
En resumen, los elementos principales de RUP son las fases, disciplinas, roles y artefactos. Cada uno de estos elementos se aplica en diferentes etapas del ciclo de vida del software para garantizar que el proyecto se desarrolle de manera efectiva y eficiente.
XP (Extreme Programming) es una metodología de desarrollo ágil de software que se centra en la entrega rápida y constante de un software funcional y de alta calidad. Fue creada por Kent Beck a finales de la década de 1990 y se basa en principios como la comunicación frecuente, la retroalimentación continua y la adaptación al cambio.
XP se enfoca en el trabajo en equipo y la colaboración entre los miembros del equipo de desarrollo de software. El equipo trabaja en ciclos cortos de desarrollo, generalmente de una a dos semanas, en los que se planifica, se diseña, se implementa, se prueba y se entrega una funcionalidad del software. XP también hace énfasis en la calidad del código y en la utilización de técnicas como la programación en parejas y la integración continua para garantizar que el software funcione correctamente y sea fácil de mantener.
En resumen, XP es una metodología de desarrollo ágil que se enfoca en la entrega rápida y constante de un software funcional y de alta calidad, a través de principios como la comunicación frecuente, la retroalimentación continua y la adaptación al cambio, con un enfoque en el trabajo en equipo, la calidad del código y la utilización de técnicas de desarrollo colaborativas.
Extreme Programming (XP) fue creada por Kent Beck a finales de la década de 1990. La metodología XP fue presentada por primera vez en la conferencia Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA) en 1999.
Desde entonces, XP ha sido ampliamente adoptada por equipos de desarrollo de software en todo el mundo, especialmente en proyectos que requieren una entrega rápida y constante de software funcional y de alta calidad. Aunque ha sido superada por otras metodologías ágiles más modernas en algunos aspectos, XP sigue siendo una metodología de desarrollo de software popular y efectiva en la actualidad.
Las principales características de Extreme Programming (XP) son:
1. Desarrollo iterativo e incremental: XP se basa en ciclos cortos de desarrollo iterativo e incremental, en los que se planifica, diseña, construye, prueba y entrega una funcionalidad del software en períodos de tiempo cortos, generalmente de una a dos semanas. Esto permite una entrega rápida y constante de software funcional y de alta calidad.
2. Enfoque en la comunicación y colaboración: XP promueve la comunicación frecuente y la colaboración entre los miembros del equipo de desarrollo de software, incluyendo al cliente. Esto ayuda a garantizar que el software se desarrolle de acuerdo con las expectativas y necesidades del cliente.
3. Pruebas unitarias y de integración: XP hace énfasis en la calidad del código a través de la escritura de pruebas unitarias y de integración para garantizar que el software funcione correctamente y sea fácil de mantener.
4. Programación en parejas: XP utiliza la programación en parejas, en la que dos miembros del equipo de desarrollo trabajan juntos en el mismo código. Esto ayuda a mejorar la calidad del código y a compartir conocimientos entre los miembros del equipo.
5. Integración continua: XP utiliza la integración continua para garantizar que el software se integre correctamente y se pruebe continuamente. Esto ayuda a identificar y solucionar problemas con el software de manera oportuna.
6. Diseño simple: XP promueve el diseño simple y la refactorización para reducir la complejidad del software y facilitar su mantenimiento.
En resumen, las principales características de XP son su enfoque en el desarrollo iterativo e incremental, la comunicación y colaboración, las pruebas unitarias y de integración, la programación en parejas, la integración continua y el diseño simple.
Los elementos principales de la metodología Extreme Programming (XP) son los siguientes:
1. Planificación: XP se enfoca en la planificación continua y flexible. En lugar de planificar todo el proyecto de antemano, el equipo de XP realiza una planificación a corto plazo, generalmente de una a dos semanas, y se ajusta según sea necesario.
2. Diseño: XP se centra en el diseño simple y la refactorización. Esto significa que el equipo de XP mantiene el diseño del software lo más simple posible y lo mejora continuamente a medida que se desarrolla el software.
3. Pruebas: XP hace énfasis en las pruebas unitarias y de integración. El equipo de XP escribe pruebas automatizadas para cada función del software y realiza pruebas de integración continuas para garantizar que el software funcione correctamente y sea fácil de mantener.
4. Programación en parejas: XP utiliza la programación en parejas, en la que dos miembros del equipo de desarrollo trabajan juntos en el mismo código. Esto ayuda a mejorar la calidad del código y a compartir conocimientos entre los miembros del equipo.
5. Integración continua: XP utiliza la integración continua para garantizar que el software se integre correctamente y se pruebe continuamente. Esto ayuda a identificar y solucionar problemas con el software de manera oportuna.
6. Entrega continua: XP se enfoca en la entrega rápida y constante de software funcional y de alta calidad. El equipo de XP entrega nuevas funcionalidades del software en ciclos cortos de una a dos semanas.
En sistemas informáticos, un watch es un comando utilizado en sistemas operativos tipo Unix y en la línea de comandos de algunas aplicaciones para ejecutar un comando o un conjunto de comandos a intervalos regulares y mostrar su salida en tiempo real.
El comando watch permite monitorear de manera continua la salida de un comando sin necesidad de ejecutar el comando repetidamente manualmente. El usuario especifica el intervalo de tiempo entre las ejecuciones del comando, y watch muestra la salida de manera continua en la pantalla hasta que se detiene manualmente.
El comando watch en sistemas operativos tipo Unix fue creado en la década de 1970 como parte del sistema operativo Multics. Posteriormente, fue adoptado por sistemas operativos derivados de Unix, incluyendo Linux, macOS y otros sistemas operativos similares
El comando watch sigue siendo una herramienta útil y popular en la línea de comandos de estos sistemas operativos en la actualidad.
El comando watch en sistemas informáticos tiene las siguientes características:
1. Monitoreo en tiempo real: El comando watch permite monitorear la salida de un comando en tiempo real, lo que significa que la salida se muestra automáticamente en la pantalla a medida que se produce.
El comando watch en sistemas informáticos tiene las siguientes características:
1. Monitoreo en tiempo real: El comando watch permite monitorear la salida de un comando en tiempo real, lo que significa que la salida se muestra automáticamente en la pantalla a medida que se produce.
2. Intervalos de tiempo personalizables: El usuario puede especificar el intervalo de tiempo entre las ejecuciones del comando, lo que permite ajustar la frecuencia con la que se muestra la salida.
3. Ejecución de comandos múltiples: El comando watch puede ejecutar un solo comando o un conjunto de comandos, lo que permite monitorear múltiples procesos o actividades al mismo tiempo.
4. Fácil de usar: El comando watch es fácil de usar y no requiere conocimientos avanzados de programación o de la línea de comandos para su uso.
5. Herramienta útil para el diagnóstico de problemas: El comando watch es una herramienta útil para el diagnóstico de problemas en sistemas informáticos, ya que permite monitorear y analizar la salida de los comandos en tiempo real.
1. Comando a monitorear: El usuario especifica el comando o conjunto de comandos que desea monitorear.
2. Intervalo de tiempo: El usuario especifica el intervalo de tiempo entre cada ejecución del comando.
3. Parámetros opcionales: El comando watch admite parámetros opcionales para personalizar su comportamiento, como el número máximo de veces que se ejecuta el comando o la opción de detener el comando después de que se produce una salida determinada.
La aplicación del comando watch en sistemas informáticos es amplia y puede ser utilizada en diversas situaciones, como:
1. Monitoreo de procesos: El comando watch se puede utilizar para monitorear la salida de procesos en tiempo real, como el uso de recursos del sistema, el progreso de una tarea o script, o cualquier otro tipo de actividad que genere una salida en la línea de comandos.
2. Diagnóstico de problemas: El comando watch también se puede utilizar para diagnosticar problemas en sistemas informáticos, como el seguimiento de los cambios en los archivos de registro o la verificación de los resultados de un comando para detectar errores.
3. Automatización de tareas: El comando watch se puede utilizar para automatizar tareas en sistemas informáticos, como la actualización de un directorio de archivos o la creación de un informe a partir de la salida de un comando.
En resumen, el comando watch en sistemas informáticos tiene elementos como el comando a monitorear, el intervalo de tiempo y los parámetros opcionales, y se puede aplicar para monitorear procesos, diagnosticar problemas y automatizar tareas en sistemas informáticos.
1. Shotts Jr., W.E. (2019). The Linux Command Line: A Complete Introduction. No Starch Press. https://www.amazon.com/Linux-Command-Line-CompleteIntroduction/dp/1593279523
2. Peek, J., O'Reilly, T., y Loukides, M. (2002). Unix Power Tools. O'Reilly Media. https://www.amazon.com/Unix-Power-Tools-Jerry-Peek/dp/0596003307
3. Barrett, D.J. (2016). Linux Pocket Guide. O'Reilly Media. https://www.amazon.com/Linux-Pocket-Guide-Daniel-Barrett/dp/1491927577
4. Blum, R. (2015). The Linux Command Line and Shell Scripting Bible. Wiley. https://www.amazon.com/Linux-Command-Shell-ScriptingBible/dp/111898384X
5. Nemeth, E., Snyder, G., Hein, T.R., y Whaley, B. (2017). UNIX and Linux System Administration Handbook. Addison-Wesley Professional. https://www.amazon.com/UNIX-Linux-System-AdministrationHandbook/dp/0134277554
1. Royce, W. (1970). Managing the Development of Large Software Systems. Proceedings of IEEE WESCON, 26, 1-9.
https://ieeexplore.ieee.org/document/6267705
2. Boehm, B. (1988). A Spiral Model of Software Development and Enhancement. ACM SIGSOFT Software Engineering Notes, 11(4), 14-24.
https://doi.org/10.1145/135186.135188
3. Pressman, R.S. (2014). Software Engineering: A Practitioner's Approach. McGraw-Hill Education
https://www amazon com/Software-EngineeringPractitioners-Roger-Pressman/dp/0078022126
4. Sommerville, I. (2011). Software Engineering. Pearson Education Limited.
https://www.amazon.com/Software-Engineering-IanSommerville/dp/0137035152
5. McConnell, S. (1996). Rapid Development: Taming Wild Software Schedules. Microsoft Press.
https://www.amazon.com/Rapid-Development-TamingSoftware-Schedules/dp/1556159005
1. Kruchten, P. (1999). The Rational Unified Process: An Introduction. AddisonWesley Professional.
https://www.amazon.com/Rational-Unified-ProcessIntroduction/dp/0201571692
2. Jacobson, I., Booch, G., y Rumbaugh, J. (1999). The Unified Software Development Process. Addison-Wesley Professional.
https://www.amazon.com/Unified-Software-DevelopmentProcess/dp/0201571692
3. Ambler, S.W. (2002). The Object Primer 3rd Edition: Agile Model Driven Development with UML 2.0. Cambridge University Press.
https://www.amazon.com/Object-Primer-3rd-AgileDevelopment/dp/0521540186
4. Larman, C. (2004). Agile and Iterative Development: A Manager's Guide. Addison-Wesley Professional.
https://www.amazon.com/Agile-IterativeDevelopment-Managers-Addison-Wesley/dp/0131111558
5. Kruchten, P. (2013). The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP. Addison-Wesley Professional.
https://www.amazon.com/Rational-Unified-Process-MadeEasy/dp/0321166090