Asignatura Datos del alumno Fecha

Diseño y Desarrollo
Apellidos: Sánchez Noceda
de Programas
17 diciembre 2019
Informáticos
Nombre: Julio Efraín
Seguros

Ciclos de Vida de Desarrollo de Software Seguro (S-SDLC)

TABLA DE CONTENIDO
1 ACOTAMIENTO........................................................................................................................... 2
2 INTRODUCCIÓN.......................................................................................................................... 2
3 MODELOS Y METODOLOGÍAS..................................................................................................... 3
3.1 AGILE/ÁGIL MODELO.........................................................................................................................3
3.2 LEAN/FINO/ESBELTO MODELO.............................................................................................................3
3.3 WATERFALL/CASCADA MODELO...........................................................................................................4
3.4 ITERATIVE/ITERATIVO MODELO.............................................................................................................4
3.5 SPIRAL/ESPIRAL MODELO....................................................................................................................5
4 METODOLOGÍAS SDLC................................................................................................................ 5
4.1 MICROSOFT SDL............................................................................................................................5
4.2 BSIMM..........................................................................................................................................6
4.3 CLASP............................................................................................................................................6
4.4 SAAM............................................................................................................................................6
5 TABLAS COMPARATIVAS............................................................................................................. 7
6 PROPUESTA DE USO S-SDLC........................................................................................................ 9
7 CONCLUSIONES........................................................................................................................ 10
8 Referencias.........................................................................................................................................11

TEMA 1 – Actividades
 Asignatura Datos del alumno Fecha
Diseño y Desarrollo
Apellidos: Sánchez Noceda
de Programas
17 diciembre 2019
Informáticos
Nombre: Julio Efraín
Seguros

1 Acotamiento
El desarrollo del presente documento es para dar cumplimiento a la actividad de la
materia Diseño y Desarrollo de Programas Informáticos Seguros impartida por
Rhett H. Nieto Gutiérrez en la Universidad Internacional de La Rioja, S. A. (UNIR)
con la finalidad de conocer los diferentes modelos de Ciclo de Vida del Desarrollo de
Software Seguro (S-SDLC).

2 Introducción.
El ciclo de vida del desarrollo de software (SDLC) identifica errores en la creación de
software antes de que se descubran (a un costo mucho mayor) en etapas sucesivas. Pero
es mucho más que eso, por supuesto: SDLC también puede diseñar un plan para hacer
todo bien la primera vez.

Hay que considerar que mientras los nombres de las distintas fases pueden cambiar
dependiendo el Modelo SDLC usado, cada fase/etapa conceptual del arquietipo será
usada para desarrollar cualquier aplicación. El proceso SDLC implica varias etapas, que
incluye desde planificación/definir, análisis, diseño, construcción/desarrollar, pruebas,
implementación y mantenimiento.

Me gustaría incluir una definición de S-SDLC establecida por OWASP, The Open Web
Application Security Project.

S-SDLC – Secure Software Development Life Cycle:Conjunto de principios de

diseño y buenas prácticas a implantar en el SDLC, para detectar, prevenir y
corregir los defectos de seguridad en el desarrollo y adquisición de
aplicaciones, de forma que se obtenga software de confianza y robusto frente a
taques maliciosos, que realice solo las funciones para las que fue diseñado, que
esté libre de vulnerabilidades, ya sean intencionalmente diseñadas o
accidentalmente insertadas durante su ciclo de vida y se asegure su integridad,
disponibilidad y confidencialidad”.

Las metodologías de S-SDLC más populares utilizadas en la actualidad son Touch

Points de Cigital, Microsoft SDL, OWASP CLASP y la BITS Software Assurance
Framework. A alto nivel, estas metodologías S-SDLC son muy similares y consisten en
la integración de las actividades de seguridad, tales como los requisitos de seguridad,
revisión de arquitectura segura, la arquitectura de modelado de análisis de riesgos,
amenazas, análisis estático, revisión de código fuente, las actividades de pruebas de
seguridad, penetración dentro de las actividades existentes..

Algunas metodologías de ciclo de vida de desarrollo de software: Agile, Lean,

Waterfall, Iterative y Spiral, cada uno de estos enfoques varía en algunos aspectos de
los demás, pero todos tienen un propósito común: ayudar a los equipos a entregar
software de alta calidad de la manera más rápida y rentable posible.

TEMA 1 – Actividades
 Asignatura Datos del alumno Fecha
Diseño y Desarrollo
Apellidos: Sánchez Noceda
de Programas
17 diciembre 2019
Informáticos
Nombre: Julio Efraín
Seguros

3 Modelos y Metodologías.
Metodología de desarrollo seguro Empresa Modelo
Microsoft Security Development Lifecycle. Microsoft Tradicional
Oracle Software Security Assurance Oracle Tradicional
Comprenhensive Lightweight Application Security OWASP Tradicional
Process
Team Software Process Secure Software Engineer Tradicional
Institute
Software Assurance Maturity Model OWASP Tradicional
Building Security In Maturity Model Cigital Ágil
Agile Development Using Microsoft Security Microsoft Ágil
Development Lifecycle.

A continuación, una breve descripción de las seis metodologías SDLC más comunes:

3.1 Agile/Ágil Modelo

El modelo Agile ha existido durante aproximadamente una década. Pero últimamente,

se ha convertido en una importante fuerza impulsora detrás del desarrollo de software
en muchas organizaciones. Algunas empresas valoran tanto la metodología Agile que
ahora la están aplicando a otros tipos de proyectos, incluidas las iniciativas no
tecnológicas.

En el modelo ágil, "falla rápida" es algo bueno. El enfoque produce ciclos de

lanzamiento en curso, cada uno con pequeños cambios incrementales de la versión
anterior. En cada iteración, el producto se prueba. El modelo Agile ayuda a los equipos a
identificar y abordar pequeños problemas en los proyectos antes de que evolucionen a
problemas más significativos, y comprometer a las partes interesadas del negocio y
obtener sus comentarios durante todo el proceso de desarrollo.

Como parte de su adopción de esta metodología, muchos equipos también están

aplicando un marco ágil conocido como Scrum para ayudar a estructurar proyectos de
desarrollo más complejos. Los equipos Scrum trabajan en "sprints", que generalmente
duran de dos a cuatro semanas, para completar las tareas asignadas. Las reuniones
diarias de Scrum ayudan a todo el equipo a monitorear el progreso a lo largo del
proyecto. Y el ScrumMaster tiene la tarea de mantener al equipo enfocado en su
objetivo. (Para obtener más información sobre Scrum, consulte el sitio web de Scrum
Alliance).

3.2 Lean/Fino/Esbelto Modelo

El modelo Lean para el desarrollo de software está inspirado en prácticas y principios de

manufactura esbelta. Los siete principios Lean (en este orden) son: eliminar el
desperdicio, amplificar el aprendizaje, decidir lo más tarde posible, entregar lo más
rápido posible, capacitar al equipo, construir integridad y ver el todo.

TEMA 1 – Actividades
 Asignatura Datos del alumno Fecha
Diseño y Desarrollo
Apellidos: Sánchez Noceda
de Programas
17 diciembre 2019
Informáticos
Nombre: Julio Efraín
Seguros

El proceso Lean consiste en trabajar solo en lo que se debe trabajar en ese momento, por
lo que no hay espacio para la multitarea. Los equipos del proyecto también se centran en
encontrar oportunidades para reducir el desperdicio en todo momento a lo largo del
proceso SDLC, desde abandonar reuniones innecesarias hasta reducir la documentación.
El modelo Agile es en realidad un método Lean para el SDLC, pero con algunas
diferencias notables. Una es cómo cada uno prioriza la satisfacción del cliente: Agile lo
convierte en la principal prioridad desde el principio, creando un proceso flexible donde
los equipos de proyecto pueden responder rápidamente a los comentarios de las partes
interesadas en todo el SDLC. Lean, mientras tanto, enfatiza la eliminación de
desperdicios como una forma de crear más valor general para los clientes, lo que, a su
vez, ayuda a mejorar la satisfacción.

3.3 Waterfall/Cascada Modelo

Algunos expertos sostienen que el modelo Waterfall nunca fue un modelo de proceso
para proyectos reales según StackExchange. En cualquier caso, el modelo Waterfall es
ampliamente considerado como la más antigua de las metodologías SDLC
estructuradas. También es un enfoque muy sencillo: terminar una fase y luego pasar a la
siguiente. No hay vuelta atrás. Cada etapa se basa en información de la etapa anterior y
tiene su propio plan de proyecto.

La desventaja de Waterfall es su rigidez. Claro, es fácil de entender y simple de

administrar. Pero los retrasos tempranos pueden retrasar toda la línea de tiempo del
proyecto. Con poco espacio para revisiones una vez que se completa una etapa, los
problemas no se pueden solucionar hasta que llegue a la etapa de mantenimiento. Este
modelo no funciona bien si se necesita flexibilidad o si el proyecto es a largo plazo y
está en curso.

Aún más rígido es el modelo de verificación y validación relacionado, o modelo en

forma de V. Esta metodología de desarrollo lineal surgió del enfoque Waterfall. Se
caracteriza por una fase de prueba correspondiente para cada etapa de desarrollo. Al
igual que Waterfall, cada etapa comienza solo después de que la anterior haya
terminado. Este modelo SDLC puede ser útil, siempre que su proyecto no tenga
requisitos desconocidos.

3.4 Iterative/Iterativo Modelo

El modelo iterativo es la repetición encarnada. En lugar de comenzar con requisitos

completamente conocidos, los equipos de proyecto implementan un conjunto de
requisitos de software, luego prueban, evalúan y señalan requisitos adicionales. Se
produce una nueva versión del software con cada fase o iteración. Enjuague y repita
hasta que el sistema completo esté listo.

TEMA 1 – Actividades
 Asignatura Datos del alumno Fecha
Diseño y Desarrollo
Apellidos: Sánchez Noceda
de Programas
17 diciembre 2019
Informáticos
Nombre: Julio Efraín
Seguros

Las ventajas del modelo iterativo sobre otras metodologías SDLC comunes es que
produce una versión funcional del proyecto al inicio del proceso y hace que sea menos
costoso implementar cambios. Una desventaja: los procesos repetitivos pueden
consumir recursos rápidamente.

Un ejemplo de un modelo iterativo es el Rational Unified Process (RUP), desarrollado

por la división Rational Software de IBM. Como se explica en este documento de IBM,
RUP es un "producto de proceso" diseñado para mejorar la productividad del equipo
que también "captura muchas de las mejores prácticas en el desarrollo de software
moderno en una forma adecuada para una amplia gama de proyectos y organizaciones".

RUP divide el proceso de desarrollo en cuatro fases: inicio, cuando se establece la idea
de un proyecto; elaboración, cuando el proyecto se define más a fondo y se evalúan los
recursos; construcción, cuando el proyecto se desarrolla y se completa; y transición,
cuando se lanza el producto. Cada fase del proyecto implica modelado, análisis y diseño
de negocios, implementación, pruebas e implementación.

3.5 Spiral/Espiral Modelo

Una de las metodologías SDLC más flexibles, el modelo Spiral se inspira en el modelo
iterativo y su repetición; el proyecto pasa por cuatro fases (planificación, análisis de
riesgos, ingeniería y evaluación) una y otra vez en una "espiral" hasta que se completa,
lo que permite múltiples rondas de refinamiento.

El modelo espiral generalmente se usa para proyectos grandes. Permite a los equipos de
desarrollo crear un producto altamente personalizado e incorporar comentarios de los
usuarios al principio del proyecto. Otro beneficio de este modelo SDLC es la gestión de
riesgos. Cada iteración comienza mirando hacia adelante a los riesgos potenciales y
descubriendo la mejor manera de evitarlos o mitigarlos.

4 Metodologías SDLC
4.1 MICROSOFT SDL.
El ciclo de vida de desarrollo de seguridad (SDL) es una metodología para el control de
seguridad orientado al desarrollo de software. Es una iniciativa por parte de Microsoft y
una directiva obligatoria desde el año 2004. Microsoft SDL se basa en tres conceptos
básicos que son la formación, mejora continua de procesos y responsabilidades. La
formación está basada en los roles técnicos dentro del grupo de desarrollo. La mejora
continua en los procesos se basa en que las organizaciones pueden responder
adecuadamente a los cambios que sufre la tecnología y las amenazas, ya que los riesgos
de seguridad son dinámicos por estos mismos cambios. Esta metodología está estructura
en cinco áreas, que es su ciclo de vida de desarrollo de software:
 Formación, directivas y capacidades organizativas. Seguridad Básica. Donde
todos los elementos del equipo de desarrollo de software deben tener una
formación debidamente con la finalidad de mantener los conceptos básicos y
últimas tendencias de seguridad y privacidad. Los desarrolladores, evaluadores y

TEMA 1 – Actividades
 Asignatura Datos del alumno Fecha
Diseño y Desarrollo
Apellidos: Sánchez Noceda
de Programas
17 diciembre 2019
Informáticos
Nombre: Julio Efraín
Seguros

administradores de programas que están implicados en el desarrollo de

programas de software.
 Requisitos y Diseño. Estable los requisitos de seguridad, crea umbrales de
calidad y límites de errores, para establecer niveles mínimos aceptables en para
la evaluación en materia de riesgos de seguridad y privacidad. Por parte del
diseño establece requisitos de diseño, el análisis de superficie de ataques y los
modelos de riesgo, en el cual determina las características seguras y
características de seguridad, estable
 Implementación. El uso de herramientas aprobadas para comprobar la
seguridad asociadas, que pueden ser advertencias y opciones de compilación, la
prohibición de funciones no seguras y el análisis estático del código fuente
 Comprobación. Donde se realiza el análisis dinámico de los programas de
software en tiempo de ejecución, las pruebas de explotación de vulnerabilidades
mediante datos aleatorios para provocar errores en los programas y la revisión de
los modelos de riesgos y de la superficie de ataques, para asegurar cambios de
diseño o de implementación
 Lanzamiento y Respuesta. Aquí se establece el plan de respuesta a incidentes,
donde los programas sin vulnerabilidades conocidas deberán quedar expuestos a
amenazas, la revisión de seguridad final donde se realice por un asesor de
seguridad donde se realicen penetraciones y parcheos, el lanzamiento archivado
donde se certifica que cumplió con los requisitos de privacidad y seguridad para
poder lanzar el software

4.2 BSIMM.
Building In Maturity Model (BSIMM) es un modelo desarrollado en 2009 derivador de
OpenSAMM (McGraw, Chess & Migues, 2009). Es un enfoque práctico basado en
evidencia empírica y observación de datos de nueve iniciativas de seguridad de software
de servicios financieros, proveedores de software independientes y firmas de tecnología
(Adobe, EMC, QUALCOMM, Google, Wells Fargo, Microsoft, DTCC y otras dos
compañías no reveladas). A diferencia de otras metodologías SSDL, no cuenta con
compilación de buenas prácticas a nivel teórico. Es una colección de prácticas utilizadas
en el mundo real.

4.3 CLASP
Es un conjunto de buenas prácticas para el desarrollo seguro de software desarrollado
por varias compañías de seguridad que forman parte del consorcio OWASP (Open Web
Application Security Project), que permite integrar en cualquier fase del SDLC
independiente de la metodología implementada.

4.4 SAAM
Marco abierto para ayudar a las organizaciones a diseñar e implementar una estrategia
para la creación de software seguro, es un modelo flexible que se adapta a la cada
organización, independientemente del fabricante, el cual fue creado por Pravir Chanda
OWASP CLASP Project Leader.

TEMA 1 – Actividades
 Asignatura Datos del alumno Fecha
Diseño y Desarrollo
Apellidos: Sánchez Noceda
de Programas
17 diciembre 2019
Informáticos
Nombre: Julio Efraín
Seguros

5 Tablas comparativas.

Comparativa de Modelos S-SDLC.

CARACTERÍSTICA WATERFALL BSIMM
Actividades de Ingeniería Análisis de requisitos. Gobierno
de Requisitos. Diseño del sistema. Construcción.
Diseño del programa. Verificación.
Codificación. Implementación.
Pruebas.
Implementación o
verificación.
Mantenimiento.
Actividades de diseño. Diseño del sistema. Estrategia y métricas.
Diseño del programa. Política y cumplimiento.
Educación y orientación.
Actividades de Codificación. Requisitos de seguridad.
implementación. Se implementa el código Evaluación de amenaza.
fuente, haciendo uso de Arquitectura de seguridad.
prototipos, así como de
pruebas y ensayos para
corregir errores.
Actividades de pruebas Se buscan sistemáticamente Revisión de diseño.
de verificación y y se corrigen todos los Revisión de código.
validación. errores antes de ser Pruebas de seguridad.
entregado al usuario final. Administración de
Es la fase en donde el vulnerabilidades.
usuario final o el cliente Fortalecimiento del
ejecuta el sistema, y se ambiente.
asegura que cubra sus Habilitación operativa.
necesidades.
Recursos. Planificación, Ejecución y Estrategia, Revisión.
Cumplimiento de las Cumplimiento.
actividades

TEMA 1 – Actividades
 Asignatura Datos del alumno Fecha
Diseño y Desarrollo
Apellidos: Sánchez Noceda
de Programas
17 diciembre 2019
Informáticos
Nombre: Julio Efraín
Seguros

Comparativa de Modelos S-SDLC.

CARACTERÍSTICA OWASP MICROSOFT SDL
Actividades de Requerimientos. Formación, directivas y
Ingeniería de Análisis y Diseño. capacidades organizativas.
Requisitos. Desarrollo. Requisitos de Diseño y
Implementación y Desarrollo/ Seguridad.
Codificación. Implementación.
Pruebas. Comprobación.
Mantenimiento Lanzamiento y Respuesta
Actividades de diseño. Requerimientos: Seguridad Física.
R1. Control de autenticación. Establecer requisitos de
R2. Controles de roles y privilegios. seguridad.
R3. Requerimientos orientados riesgo. Crear umbrales de calidad y
R.4 Aprobación de privilegios límites de errores.
Análisis y diseño: Evaluación de los riesgos.
R5. Acceso a componentes y Establecer requisitos de diseño.
administración del sistema. Analizar superficies de ataques.
R6. Pistas de auditoria. Modelos de riesgos.
R7. Gestión de sesiones.
R8. Datos históricos.
R9. Manejo apropiado de errores
R10. Separación de funciones
(segregación).
Actividades de Implementación y codificación: Utilizar herramientas aprobadas.
implementación. R12. Aseguramiento del ambiente de Prohibir funciones no seguras.
desarrollo. Análisis estático.
R13. Elaboración de documentación
técnica.
R14. Codificación segura
R15. Seguridad en las comunicaciones.
R16. Seguridad en promoción a ambientes
de producción.
Actividades de Pruebas: Análisis dinámico.
pruebas de R17. Control de calidad en controles de Fuzz testing.
verificación y seguridad. Revisión de superficie de
validación. R18. Inspección de código por fases. ataques
R19. Comprobación de gestión de Plan de respuesta a incidentes.
configuraciones. Revisión de seguridad final.
R20. Caja negra (top ten de OWASP, guía Lanzamiento archivado.
de pruebas) Ejecutar plan de respuesta a
Mantenimiento: incidentes.
R21. Aseguramiento de riesgos.
R22. Pruebas de seguridad (caja blanca y
caja negra) después de los cambios.
Recursos. Desarrolladores, jefes de proyecto, Plan de respuesta a emergencias
equipos de seguridad. Planificación, en el que se identifica el
Ejecución y Cumplimiento de las personal de ingeniería
actividades

TEMA 1 – Actividades
 Asignatura Datos del alumno Fecha
Diseño y Desarrollo
Apellidos: Sánchez Noceda
de Programas
17 diciembre 2019
Informáticos
Nombre: Julio Efraín
Seguros

6 Propuesta de uso S-SDLC.

No me dedico al desarrollo de software, pero en caso de tener que escoger una
metodología me inclino por el uso de herramientas automatizadas para lograr eficiencia,
es decir, DevOps. Me pronuncio por Kubernets cien por ciento Open Source con apoyo
de Rancher, Jenkins, GitHub, Chef, Puppet, SaltStack, New Relic, Nagios, Ganglia,
Munin, Splunk, Rundeck, por nombrar algunos.

La metodología DevOps es la recién llegada a la escena SDLC, surgió de dos

tendencias: la aplicación de prácticas ágiles y lean al trabajo de operaciones, y el
cambio general en los negocios para ver el valor de la colaboración entre el personal de
desarrollo y operaciones en todas las etapas del proceso SDLC.

En un modelo DevOps, los equipos de Desarrolladores y Operaciones trabajan juntos

estrechamente, y a veces como un solo equipo, para acelerar la innovación y el
despliegue de productos y funcionalidades de software de mayor calidad y más
confiables. Las actualizaciones de los productos son pequeñas pero frecuentes. La
disciplina, la retroalimentación continua y la mejora de procesos, y la automatización de
los procesos de desarrollo manual son todas características del modelo DevOps.

Amazon Web Services describe DevOps de esta manera: “DevOps es la combinación de

filosofías, prácticas y herramientas culturales que aumenta la capacidad de una
organización para entregar aplicaciones y servicios a alta velocidad: evolucionando y
mejorando productos a un ritmo más rápido que las organizaciones que utilizan el
desarrollo de software tradicional y procesos de gestión de infraestructura”. Entonces, al
igual que muchos modelos SDLC, DevOps no es solo un enfoque para planificar y
ejecutar el trabajo, sino también una filosofía que exige cambios significativos de
mentalidad y cultura en una organización.

Elegir el modelo SDLC adecuado para su proyecto de desarrollo de software requerirá

una cuidadosa reflexión. Pero tenga en cuenta que una metodología para planificar y
guiar su proyecto es solo un ingrediente para el éxito. Aún más importante es reunir un
equipo sólido de talentos calificados y comprometidos a hacer avanzar el proyecto a
través de cada desafío o revés inesperado.

DevOps es una filosofía para introducir el cambio cultural con el objetivo de ofrecer
funcionalidades más rápido con una mayor tasa de calidad. Es una forma de cerrar la
brecha entre los desarrolladores y el equipo de operaciones para implementaciones
frecuentes. Podría llamarse desarrollo "Casi en tiempo real" o ciclo de implementación
"Elastic" porque puede implementarse automáticamente tan pronto como los
desarrolladores confirmen un cambio. La intervención humana se minimiza siempre que
sea posible. La automatización a lo largo del ciclo de vida del desarrollo, la
retroalimentación continua y la mejora del proceso son la clave para adoptar DevOps.

TEMA 1 – Actividades
 Asignatura Datos del alumno Fecha
Diseño y Desarrollo
Apellidos: Sánchez Noceda
de Programas
17 diciembre 2019
Informáticos
Nombre: Julio Efraín
Seguros

Los siguientes son algunos de los principios de DevOps:

 Crear sistemas de producción similares para el entorno de desarrollo y prueba
 Las implementaciones deben ser iterativas y frecuentes. Garantizar un proceso
confiable y repetible
 Monitorear y validar continuamente las características de calidad operativa.
 Amplificar el circuito de retroalimentación

Las herramientas de automatización están ayudando a las empresas a adoptar DevOps.

Estas herramientas incluyen Jenkins, GitHub, Chef, Puppet, SaltStack, New Relic,
Nagios, Ganglia, Munin, Splunk, Rundeck, por nombrar algunos.

Por lo general, tenemos versiones planificadas que se implementan a través de un

conjunto de herramientas; algunas pueden ser automáticas, pero es necesario ingresar
comandos para invocarlo. DevOps ofrece una herramienta en sí misma que no
significaría nada más que su utilización y la integración de todas las herramientas
automatizadas desde el registro hasta la implementación.

Las implementaciones frecuentes o continuas, necesitan disciplina en todos los niveles y

compromiso para que esto suceda. También es posible que tenga reuniones en la sala de
guerra entre desarrolladores y el equipo de operaciones antes de la implementación.
¿Qué sucede si los equipos de desarrollo y operaciones están dispersos geográficamente
(es decir, a miles de kilómetros de distancia y existe un desafío de diferencia horaria
para realizar reuniones telefónicas)? La agenda del equipo de operaciones es mantener
el sistema en un tiempo mínimo y en este proceso algunos errores críticos no se
resuelven a tiempo o se ignoran. Una vez que DevOps esté en su lugar, puede eliminar
todos estos factores y hacer que el viaje de implementación sea tan suave como la seda.

7 Conclusiones
No me dedico al desarrollo de software, pero en caso de tener que escoger una
metodología me inclino por el uso de herramientas automatizadas para lograr eficiencia,
es decir, DevOps ya que brinda efectividad para garantizar que esté haciendo las cosas
bien. Antes de subirse al tren de DevOps hay mucho pensamiento, planificación y
trabajo. Hay desafíos desde el primer momento: desde elegir la herramienta adecuada
hasta cambiar la administración, pero la recompensa a largo plazo puede permitirle
escalar a alturas.
Me pronuncio por Kubernets cien por ciento Open Source con apoyo de Rancher,
Jenkins, GitHub, Chef, Puppet, SaltStack, New Relic, Nagios, Ganglia, Munin, Splunk,
Rundeck, por nombrar algunos

TEMA 1 – Actividades
 Asignatura Datos del alumno Fecha
Diseño y Desarrollo
Apellidos: Sánchez Noceda
de Programas
17 diciembre 2019
Informáticos
Nombre: Julio Efraín
Seguros

8 Referencias
SDLC Models Explained. Victor Osetskyi. Aug 29, 2017.
https://medium.com/existek/sdlc-models-explained-agile-waterfall-v-shaped-iterative-
spiral-e3f012f390c5

Top 7 SDLC Methodologies, Vijay Singh, Last Updated 17 Dec, 2019.

https://hackr.io/blog/sdlc-methodologies

7 Basic Software Development Models, by Alexander Yukhimishen, Writer.

https://onix-systems.com/blog/7-basic-software-development-models-which-one-to-
choose

SDLC Models Explained: Agile, Waterfall, Iterative, Spiral, 03 January 2019.

https://gradesfixer.com/free-essay-examples/sdlc-models-explained-agile-waterfall-
iterative-spiral/

Waterfall vs. Agile, Written by Mary Lotz on July 5, 2018.

https://www.seguetech.com/waterfall-vs-agile-methodology/

The Open Web Application Security Project / OWASP

https://www.owasp.org/images/9/9d/OWASP-LATAMTour-Patagonia-2016-
rvfigueroa.pdf

TEMA 1 – Actividades