.

1. República Bolivariana de Venezuela
Ministerio del Poder Popular Para la Educación Universitaria
Universidad Nacional Experimental Sur del Lago “Jesús María
Semprum”
Programa Nacional de Formación en Informática
Trayecto II – Trimestre I
Ing del Software
Procesos de Desarrollo de Software
Prof: Integrantes:
Ing. Palomares Maryleivis Morán Leynes C.I. 26.347.622
González María C.I. 27.183.773
Bravo Wenvania C.I. 27.538.945
Delgado Daviana C.I. 26.347.907
Montiel Denisse C.I. 26.258.456
Santa Bárbara de Zulia, Abril 2017

2. Introducción
En las dos últimas décadas las notaciones de modelado y posteriormente
las herramientas han sido las "balas de plata" para el deseado éxito en el
desarrollo de software. El proceso de desarrollo asumido en este contexto
llevaba asociada una marcada tendencia hacia el control del proceso
mediante una rigurosa definición de actividades, artefactos y roles. Este
esquema "tradicional" para abordar el desarrollo de software ha demostrado
ser efectivo en proyectos de gran envergadura donde por lo general se exige
un alto grado de ceremonia en el proceso. Sin embargo, este enfoque no
resulta ser el más adecuado para muchos de los proyectos actuales donde el
contexto es muy cambiante, y en donde se exige reducir drásticamente los
tiempos de desarrollo pero manteniendo una alta calidad. En la práctica, para
muchos equipos de desarrollo, ante las dificultades para utilizar metodologías
tradicionales, se llegó a la resignación de prescindir del "buen hacer" de la
ingeniería del software con el objetivo de ajustarse a estas restricciones.
Ante esta situación, las metodologías ágiles aparecen como una posible
respuesta para llenar este vacío metodológico. Por estar especialmente
orientadas para proyectos pequeños, las metodologías ágiles constituyen
una solución a medida, con una elevada simplificación que a pesar de ello no
renuncia a las prácticas esenciales para asegurar la calidad del producto. El
tema es de rabiosa actualidad. La curiosidad que siente la mayor parte de
ingenieros de software, profesores, e incluso alumnos, sobre los métodos
ágiles hace prever una fuerte proyección industrial de las metodologías
ágiles. Por un lado, para muchos equipos de desarrollo el uso de
metodologías tradicionales les resulta muy lejano a su forma de trabajo
actual considerando las dificultades de su introducción e inversión asociada
en formación y herramientas. Por otro, las características de los proyectos
para los cuales las metodologías ágiles han sido especialmente pensadas se
ajustan a un amplio rango de proyectos industriales de desarrollo de
software; aquellos en los cuales los equipos de desarrollo son pequeños, con
plazos reducidos, requisitos volátiles, nuevas tecnologías, etc. Esto último
abriría interesantes canales de cooperación entre la industria y la
universidad.

3. Metodologías Empleadas
Una metodología software es un enfoque, una manera de interpretar la
realidad o la disciplina en cuestión, que en este caso particular
correspondería a la Ingeniería del Software. Es una aproximación organizada
y sistemática para el ciclo de vida del sistema o sus partes. Especifica las
tareas individuales y sus secuencias [Palvia y Nosek, 1993] Conjunto de
procedimientos, técnicas, herramientas y un soporte documental que ayuda a
los desarrolladores a realizar nuevo software [Piattini et al., 2004]
Metodologías orientadas a procesos
La Ingeniería del Software se fundamenta en el modelo básico
entrada/proceso/salida de un sistema, estas metodologías se enfocan
fundamentalmente en la parte de proceso , utilizan un enfoque de
descomposición descendente para evaluar los procesos del espacio del
problema y los flujos de datos con los que están conectados. Este tipo de
metodologías se desarrolló a lo largo de los años 70
Representantes de este grupo son las metodologías de análisis y
diseño estructurado como:
1) Merise [Tardieu et al., 1986]
2) YSM (Yourdon Systems Method) [Yourdon Inc., 1993]
3)SSADM (Structured Systems Analysis and Design Method)
4) [Ashworth y Goodland, 1990]
5) METRICA v.2.1 [MAP, 1995]
6) METRICA v3.0 (Parcialmente)
7) [MAP, 2001]
Metodologías orientadas a Datos
Estas metodologías se centran más la parte de entrada/salida, las
actividades de análisis comienzan evaluando en primer lugar los datos y sus
interrelaciones para determinar la arquitectura de datos subyacente, cuando
esta arquitectura está definida, se definen las salidas a producir y los
procesos y entradas necesarios para obtenerlas.

4. Representantes
1) JSP (Jackson Structured Programming) [Jackson, 1975]
2) JSD (Jackson Structured Design) [Jackson, 1983]
3) LCP (Logical Construction Program) [Warnier, 1974]
4) DESD (Desarrollo de Sistemas Estructurados de Datos), también
conocido como metodología Warnier-Orr [Orr, 1977]
Orientadas a Estados y Transiciones
Aproximación que se encuentra aún en una fase temprana de desarrollo,
utiliza técnicas y conceptos de Inteligencia Artificial para especificar y generar
sistemas de información.
Representantes
1) KADS (Knowledge Acquisition and Development Systems) [Wielinga et
al., 1991]
2) IDEAL [Gómez et al., 1998] Orientadas al diseño del conocimiento
Orientadas al desarrollo de sistemas hipermediales
Pretenden sistematizar la creación de aplicaciones Web dentro de un
proceso de creación de software bien definido, muchas de estas
aproximaciones adolecen de tratar de forma separada los aspectos
hipermediales de los meramente funcionales, esto dificulta el afrontar el
problema del desarrollo de aplicaciones Web dentro de un contexto uniforme
Representantes
1) HDM (Hypermedia Design Model) [Garzotto et al., 1993]
2) HFPM (Hypermedia Flexible Process Modeling) [Olsina, 1998]
3) OOHDM (Object-Oriented Hypermedia Design Method) [Rossi, 1996]
4) OOH-Method [Gómez et al., 2000]
5) OOWS (Object-Oriented Web-Solutions) [Pastor et al., 2001a]
6) WSDN (Web Site Design Method) [De Troyer y Leune, 1997]

5. Basadas en métodos formales
Implican una revolución en los procedimientos de desarrollo, ya que a
diferencia de todas las anteriores, se basan en teorías matemáticas que
permiten una verdadera aproximación científica y rigurosa al desarrollo de
sistemas de información y software asociado
Representantes
1) OO-Method [Pastor et al., 2001b]
Metodologías Ágiles
Un proceso es ágil cuando el desarrollo de software tiene las siguientes
características:
Es incremental, es cooperativo, es sencillo y es adaptable.
En 2001, Kent Beck y otros 16 notables desarrolladores, escritores y
consultores (conocidos como la Alianza Ágil) firmaron el Manifiesto para el
desarrollo ágil del software, el cual establecía: Hemos descubierto mejores
formas de desarrollar software al construirlo por nuestra cuenta y ayudar a
otros a hacerlo. Por medio de este trabajo hemos llegado a valorar: A los
individuos y sus interacciones sobre los procesos y las herramientas, al
software en funcionamiento sobre la documentación extensa, a la
colaboración del cliente sobre la negociación del contrato, a la respuesta al
cambio sobre el seguimiento de un plan Introducción a la Ingeniería del
Software
Importancia
El ambiente moderno de los negocios ocasiona que los sistemas basados
en computadores y los productos de software estén en cambios continuos y
deben realizarse en forma acelerada. La ingeniería del software ágil
representa una opción razonable a la ingeniería convencional para ciertas
clases de software y ciertos tipos de proyectos de software. Ha demostrado
su utilidad al entregar sistemas exitosos con rapidez.
La Alianza Ágil Define 10 Principios para quienes alcanzar la agilidad:
1) Nuestra mayor prioridad es satisfacer al cliente mediante la entrega
temprana y continua de software valioso .
2) Bienvenidos lo requisitos cambiantes, incluso en fases tardías del
desarrollo.
3) Entrega con frecuencia software en funcionamiento, desde un par de
semanas hasta un par de meses, con una preferencia por la escala de
tiempo mas corta.

6. 4) Los dueños de los procesos de negocios y los desarrolladores deben
trabajar juntos a diario a lo largo del proyecto.
5) Construir proyectos alrededor de individuos motivados.
6) Darles el ambiente y el soporte que necesitan, y confiar en ellos para
obtener el trabajo realizado.
7) El método mas eficiente y efectivo de transmitir información hacia y
dentro de un equipo de desarrollo es la conversación cara a cara.
8) El software en funcionamiento es la medida primaria de progreso.
9) Los procesos ágiles promueven el desarrollo sustentable.
10) Los patrocinadores, desarrolladores y usuarios deben ser capaces de
mantener un paso constante de manera indefinida.
Programación extrema
Pone más énfasis en la adaptabilidad que en la previsibilidad, cambio de
requisitos es evidente modelo de proceso iterativo e incremental, pruebas
unitarias continuas, programación en parejas Integración del equipo de
programación con el cliente, corrección de todos los errores refactorización
del código , propiedad del código compartida, simplicidad en el código
SCRUM
Es un proceso marco que incluye un conjunto de prácticas y roles
predefinidos El equipo crea un incremento de software potencialmente
entregable (utilizable) Se acuerda la cantidad de trabajo de compromiso.
Proceso Unificado de desarrollo de Software
El Proceso Unificado es un proceso de desarrollo de software: “conjunto
de actividades necesarias para transformar los requisitos del usuario en un
sistema software”. · RUP es un marco genérico que puede especializarse
para una variedad de tipos de sistemas, diferentes áreas de aplicación, tipos
de organizaciones, niveles de aptitud y diferentes tamaños de proyectos. ·
RUP está basado en componentes. El sw esta formado por componentes
software interconectados a través de interfaces. · RUP está dirigido por
casos de uso, centrado en la arquitectura, y es iterativo e incremental.
Fases
Cada ciclo constas de cuatro fases: inicio, elaboración, construcción, y
transición.
Fase de Inicio
Durante la fase de inicio se desarrolla una descripción del producto final, y
se presenta el análisis del negocio. Esta fase responde las siguientes
preguntas:

7. · ¿Cuáles son las principales funciones del sistema para los usuarios más
importantes?
· ¿Cómo podría ser la mejor arquitectura del sistema?
· ¿Cuál es el plan del proyecto y cuánto costará desarrollar el producto?
En esta fase se identifican y priorizan los riesgos más importantes. El
objetivo de esta fase es ayudar al equipo de proyecto a decidir cuáles son los
verdaderos objetivos del proyecto. Las iteraciones exploran diferentes
soluciones posibles, y diferentes arquitecturas posibles. Puede que todo el
trabajo físico realizado en esta fase sea descartado. Lo único que
normalmente sobrevive a la fase de inicio es el incremento del conocimiento
en el equipo.
Los artefactos que típicamente sobreviven a esta fase son:
- Un enunciado de los mayores requerimientos planteados generalmente
como casos de uso.
- Un boceto inicial de la arquitectura.
- Una descripción de los objetivos del proyecto.
- Una versión muy preliminar del plan del proyecto.
- Un modelo del negocio.
La fase de inicio finaliza con el Hito de Objetivos del Ciclo de Vida. Este
hito es alcanzado cuando el equipo de proyectos y los stakeholders llegan a
un acuerdo sobre:
- Cuál es el conjunto de necesidades del negocio, y que conjunto de
funciones satisfacen estas necesidades.
- Una planificación preliminar de iteraciones.
- Una arquitectura preliminar.
Debe poder responderse las siguientes cuestiones:
- ¿Se ha determinado con claridad el ámbito del sistema?
¿Se ha determinado lo que va a estar dentro del sistema y fuera de el
sistema?
- ¿Se ha llegado a un acuerdo con todas las personas involucradas
(stakeholders) sobre los requisitos funcionales del sistema?
- ¿Se vislumbra una arquitectura que pueda soportar estas características?

8. - ¿Se identifican los riesgos críticos?
¿Se prevé forma de mitigarlos?
- ¿El uso del producto justifica la relación costo-beneficio?
- ¿Es factible para su organización llevar adelante el proyecto?
- ¿Están los inversores de acuerdo con los objetivos?
Fase de Elaboración
Durante la fase de elaboración se especifican en detalle la mayoría de los
casos de uso del producto y se diseña la arquitectura.
Las iteraciones en la fase de elaboración:
- Establecen una firme comprensión del problema a solucionar.
- Establece la fundación arquitectural para el software.
- Establece un plan detallado para las siguientes iteraciones.
- Elimina los mayores riesgos.
El resultado de esta fase es la línea base de la arquitectura. En esta fase
se construyen típicamente los siguientes artefactos:
- El cuerpo básico del sw en la forma de un prototipo arquitectural.
- Casos de prueba
- La mayoría de los casos de uso (80%) que describen la funcionalidad del
sistema.
- Un plan detallado para las siguientes iteraciones.
La fase de elaboración finaliza con el hito de la Arquitectura del Ciclo de
Vida. Este hito se alcanza cuando el equipo de desarrollo y los stakeholders
llegan a un acuerdo sobre:
- Los casos de uso que describen la funcionalidad del sistema.
- La línea base de la arquitectura
- Los mayores riesgos han sido mitigados
- El plan del proyecto
Al alcanzar este hito debe poder responderse a preguntas como:

9. - ¿Se ha creado una línea base de la arquitectura?
¿Es adaptable y robusta? ¿Puede evolucionar?
- ¿Se han identificado y mitigado los riesgos más graves?
- ¿Se ha desarrollado un plan del proyecto hasta el nivel necesario para
respaldar una agenda, costes, y calidad realistas?
- ¿Proporciona el proyecto, una adecuada recuperación de la inversión?
- ¿Se ha obtenido la aprobación de los inversores?
Fase de Construcción
Durante la fase de construcción se crea el producto. La línea base de la
arquitectura crece hasta convertirse en el sistema completo. Al final de esta
fase, el producto contiene todos los casos de uso implementados, sin
embargo puede que no este libre de defectos. Los artefactos producidos
durante esta fase son:
- El sistema software
- Los casos de prueba
- Los manuales de usuario
La fase de construcción finaliza con el hito de Capacidad Operativa Inicial.
Este hito se alcanza cuando el equipo de desarrollo y los stakeholders llegan
a un acuerdo sobre:
- El producto es estable para ser usado
- El producto provee alguna funcionalidad de valor
- Todas las partes están listas para comenzar la transición
Fase de Transición
Cubre el período durante el cual el producto se convierte en la versión
beta. Las iteraciones en esta fase continúan agregando características al sw.
Sin embargo las características se agregan a un sistema que el usuario se
encuentra utilizando activamente. Los artefactos construidos en esta fase
son los mismos que en la fase de construcción. El equipo se encuentra
ocupado fundamentalmente en corregir y extender la funcionalidad del
sistema desarrollado en la fase anterior.

10. La fase de transición finaliza con el hito de Lanzamiento del Producto.
Este hito se alcanza cuando el equipo de desarrollo y los stakeholders llegan
a un acuerdo sobre:
- Se han alcanzado los objetivos fijados en la fase de Inicio.
- El usuario está satisfecho.
Disciplinas
Cada disciplina es un conjunto de actividades relacionadas (flujos de
trabajo) vinculadas a un área específica dentro del proyecto total. Las más
importantes son: Requerimientos, Análisis, Diseño, Codificación, y Prueba. El
agrupamiento de actividades en disciplinas es principalmente una ayuda para
comprender el proyecto desde la visión tradicional en cascada.
Está asociada con un conjunto de modelos que se desarrollan. Estos
modelos están compuestos por artefactos. Los artefactos más importantes
son los modelos que cada disciplina realiza: modelo de casos de uso,
modelo de diseño, modelo de implementación, y modelo de prueba.
Proceso Unificado de Software
El Proceso Unificado consiste en una serie de disciplinas o flujos de
trabajo que van desde los requisitos hasta las pruebas. Los flujos de trabajo
desarrollan modelos desde el modelo de casos de uso hasta el modelo de
pruebas.
Elementos para Interpretar el Modelado del Software (Lenguaje
Unificado de Modelado)
Los elementos de UML son los bloques básicos de construcción de un
sistema orientado a objetos. Son abstracciones que constituyen los
ciudadanos de primera clase en un modelo. Se utilizan para construir
modelos bien formados.
• Posee tres tipos de elementos:
1) Estructurales
Clase
Una clase es una descripción de un conjunto de objetos que comparten
los mismos atributos, operaciones, relaciones y semántica. Es un concepto
de diseño, en ejecución, el sistema está formado por instancias de clases
(Objetos)

11. Las clases se pueden utilizar para: capturar el vocabulario del sistema que
se está desarrollando (fase de análisis) representar la solución
Objeto
Un objeto representa una instancia de una clase en un determinado
contexto. Es un concepto de ejecución . El sistema estará formado por un
conjunto de objetos interaccionando entre sí
Interfaz
Colección de operaciones que especifican un servicio que puede ser
ofrecido por una clase o componente. Describen el comportamiento visible
externamente de dichos elementos. Pueden representar el comportamiento
completo de la clase/componente o solo una parte. Una interfaz define un
conjunto de especificaciones de operaciones (signaturas), pero no las
implementaciones de dichas operaciones.
Caso de Uso
Describe un comportamiento de un sistema, clase o componente, desde
el punto de vista del usuario. Describe un conjunto de secuencias de
acciones que ejecuta un sistema y que produce un resultado observable que
es de interés para un usuario particular. Se emplea para estructurar los
aspectos de comportamiento. Un caso de uso es realizado por una
colaboración.
Colaboración
Define una interacción entre una sociedad de roles y otros elementos que
colaboran para proporcionar un comportamiento mayor que la suma de sus
comportamientos aislados. Tienen dimensión estructural y de
comportamiento
Clase Activa
Tipo especial de clase cuyos objetos tienen uno o más procesos o hilos
de ejecución Pueden dar origen a actividades de control. Son iguales que
las clases salvo que sus objetos pueden ser concurrentes con otros objetos
de clases activa
Componente
Parte modular de la arquitectura física de un sistema que oculta su
implementación tras un conjunto de interfaces externas. Define su
comportamiento en base a interfaces requeridas y ofertadas Reemplazables

12. El sistema se define en base a componentes conectados entre sí. Los
componentes pueden ser de granularidad variable
Artefacto
Parte física y reemplazable de un sistema que contiene información física
(bits). Es utilizada o generada en el proceso de desarrollo Hay diferentes
artefactos de despliegue: código fuente, ejecutables, scripts, etc.
Nodo
Elemento físico que existe en tiempo de ejecución y representa un
recurso computacional. En un nodo pueden residir un conjunto de artefactos.
Sirven para describir las plataformas en las que se ejecutan las aplicaciones
2. De Comportamiento
Interacción
Comportamiento que comprende un conjunto de mensajes
intercambiados entre un conjunto de objetos, dentro de un contexto
particular, para un propósito específico. Sirven para modelar el
comportamiento de una sociedad de objetos, o una operación individual.
Además de a los objetos implicados, involucran: Mensajes, Acciones y
Enlaces (conexiones entre objetos).
Máquina de Estados
Comportamiento que especifica las secuencias de estados por las que
pasa un objeto o una interacción durante su vida, en respuesta a eventos,
junto con sus reacciones a dichos eventos. Sirven para especificar el
comportamiento de una clase individual o una colaboración de clases.
Involucran a: Estados, Transiciones (flujo de un estado a otro), Eventos (que
disparan una transición) y Actividades (respuesta a una transición)
Actividad
Comportamiento que especifica la secuencia de pasos que ejecuta un
proceso computacional. Una acción es un paso de una actividad.
3) De Agrupamiento
Paquete
Es recomendable que el contenido sea una colección de elementos UML
relacionados de forma lógica. Se pueden utilizar en cualquier tipo de
diagrama UML. Un paquete puede contener otros paquetes, sin límite de
anidamiento, pero cada elemento pertenece a (está definido en) sólo un

13. paquete. La visibilidad de los elementos incluidos en un paquete puede
controlarse para que algunos sean visibles fuera del paquete mientras que
otros permanezcan ocultos.
Diagramas de Flujo
Es la representación gráfica de flujo de secuencia rutinarias. Se basan en
la utilización de diversos símbolos para representar operaciones específicas.
Se les llama diagramas de flujo porque los símbolos utilizados se conectan
por medio de flechas para indicar la secuencia de la operación.
Tipos:
1) Formato vertical: En él el flujo o la secuencia de las operaciones, va de
arriba hacia abajo. Es una lista ordenada de las operaciones de un proceso
con toda la información que se considere necesaria, según su propósito.
2) Formato horizontal: En él, el flujo o la secuencia de las operaciones, va
de izquierda a derecha.
3) Formato panorámico: El proceso entero está representado en una sola
carta y puede apreciarse de una sola mirada mucho más rápido que leyendo
el texto, lo que facilita su comprensión, aun para personas no familiarizadas.
Registra no solo en línea vertical, sino también horizontal, distintas acciones
simultáneas y la participación de más de un puesto o departamento que el
formato vertical no registra.
4) Formato Arquitectónico: Describe el itinerario de ruta de una forma o
persona sobre el plano arquitectónico del área de trabajo. El primero de los
flujogramas es eminentemente descriptivo, mientras que los utilizados son
fundamentalmente representativos.
Ejemplo:

14. Símbolos y Notaciones
Inicio o fin Actividad Decisión
Conector
Ciclo de Vida
El proceso de desarrollo de software no es único. No existe un proceso de
software universal que sea efectivo para todos los contextos de proyectos de
desarrollo. Debido a esta diversidad, es difícil automatizar todo un proceso
de desarrollo de software.
A pesar de la variedad de propuestas de proceso de software, existe un
conjunto de actividades fundamentales que se encuentran presentes en
todos ellos [4]:
1. Especificación de software: Se debe definir la funcionalidad y
restricciones operacionales que debe cumplir el software.
2. Diseño e Implementación: Se diseña y construye el software de
acuerdo a la especificación.
3. Validación: El software debe validarse, para asegurar que cumpla con
lo que quiere el cliente.
4. Evolución: El software debe evolucionar, para adaptarse a las
necesidades del cliente.
Además de estas actividades fundamentales, Pressman [1] menciona un
conjunto de “actividades protectoras”, que se aplican a lo largo de todo el
proceso del software. Ellas se señalan a continuación:
 Seguimiento y control de proyecto de software.
 Revisiones técnicas formales.
 Garantía de calidad del software.
 Gestión de configuración del software.
 Preparación y producción de documentos.
 Gestión de reutilización.
 Mediciones.
 Gestión de riesgos.
Pressman [1] caracteriza un proceso de desarrollo de software. Los

15. elementos involucrados se describen a continuación:
 Un marco común del proceso, definiendo un pequeño número de
actividades del marco de trabajo que son aplicables a todos los proyectos
de software, con independencia del tamaño o complejidad.
 Un conjunto de tareas, cada uno es una colección de tareas de
ingeniería del software, hitos de proyectos, entregas y productos de
trabajo del software, y puntos de garantía de calidad, que permiten que las
actividades del marco de trabajo se adapten a las características del
proyecto de software y los requisitos del equipo del proyecto.
 Las actividades de protección, tales como garantía de calidad del
software, gestión de configuración del software y medición, abarcan el
modelo del proceso. Las actividades de protección son independientes de
cualquier actividad del marco de trabajo y aparecen durante todo el
proceso.

16. Conclusión
No existe una metodología universal para hacer frente con éxito a cualquier
proyecto de desarrollo de software. Toda metodología debe ser adaptada al
contexto del proyecto (recursos técnicos y humanos, tiempo de desarrollo, tipo de
sistema, etc. Históricamente, las metodologías tradicionales han intentado abordar
la mayor cantidad de situaciones de contexto del proyecto, exigiendo un esfuerzo
considerable para ser adaptadas, sobre todo en proyectos pequeños y con
requisitos muy cambiantes. Las metodologías ágiles ofrecen una solución casi a
medida para una gran cantidad de proyectos que tienen estas características. Una
de las cualidades más destacables en una metodología ágil es su sencillez, tanto en
su aprendizaje como en su aplicación, reduciéndose así los costos de implantación
en un equipo de desarrollo.
Esto ha llevado hacia un interés creciente en las metodologías ágiles. Sin
embargo, hay que tener presente una serie de inconvenientes y restricciones para
su aplicación, tales como: están dirigidas a equipos pequeños o medianos (Beck
sugiere que el tamaño de los equipos se limite de 3 a 20 como máximo, otros dicen
no más de 10 participantes), el entorno físico debe ser un ambiente que permita la
comunicación y colaboración entre todos los miembros del equipo durante todo el
tiempo, cualquier resistencia del cliente o del equipo de desarrollo hacia las
prácticas y principios puede llevar al proceso al fracaso (el clima de trabajo, la
colaboración y la relación contractual son claves), el uso de tecnologías que no
tengan un ciclo rápido de realimentación o que no soporten fácilmente el cambio

17. Bibliografía
Análisis y Diseño de Sistemas. Libro Virtual.
http://ac.itdurango.mx/araceli_dguez/LIBROS%20ELECTRONICOS/Kendall%
20&%20Kendall%20-
Edicion%203%20Analisis%20y%20dise%F1o%20de%20sistemas.pdf
Diagramas de Flujo. Libro Virtual
https://electronicsdj.files.wordpress.com/2009/09/diagramas-de-flujo.pdf
Metodologías Ágiles en el Desarrollo de Software. 2013. Libro Virtual
http://issi.dsic.upv.es/archives/f-1069167248521/actas.pdf
Metodologías de Desarrollo de Software. Libro Virtual.
https://uvirtual.unet.edu.ve/file.php/419/Metodologias_de_desarrollo_de_Soft
ware_IS.pdf
Proceso Software y Ciclo de Vida. Libro Virtual.
https://www.fdi.ucm.es/profesor/gmendez/docs/is0809/02-
ProcesoCicloDeVida.pdf
Patricia López y Francisco Ruiz. Lenguaje Unificado de Modelado – UML.
Libro Virtual. http://ocw.unican.es/ensenanzas-tecnicas/ingenieria-del-
software-i/materiales-de-clase-1/is1-t02-trans.pdf