Bueno siguiendo con desarrollo del software vamos a ver los métodos o modelos de desarrollo de software
que existen.
Ahora bien una aclaración antes de esto esto es un tema muy extenso que incluye muchos modelos de desarrollo.
Yo me voy a enfocar en los principales.
Sin embargo hay libros enteros dedicados a estos e incluso libros enteros dedicados a un solo modelo
de desarrollo de software.
Así que voy a hacer mi esfuerzo para poder resumirlo y darles una vista holística para temas de examen.
Luego empezamos con el modelo cascada.
Creo que este fue el primer modelo que se desarrolló para desarrollar software y por ende era muy rígido
poco flexible con fases bien definidas era un desarrollo linear digámoslo así o un progreso lineal donde
cometíamos el error en una etapa pues no podíamos echarnos para atrás en esa etapa y continuar o arreglar
errores sino que teníamos que volver al inicio y desarrollar desde cero básicamente.
Obviamente los cambios eran muy costosos no sólo en tiempo sino en temas monetarios por ejemplo la misma
naturaleza del modelo Orda.
Luego tenemos que pasamos a modelos un poco más flexibles como por ejemplo el modelo espiral que era
un modelo Basquetour todo para controlar el riesgo para no para no asumir grandes riesgos.
Básicamente lo que hacía era poner metas pequeñas al inicio es decir desarrollamos primero la pantalla
de inicio o la pantalla de login y conforme iba progresando el tiempo o o el desarrollo pues iban generándose
metas un poco más agresivas.
Por ejemplo ahora pongamos inscripcion para la conexión de la pantalla login y luego ponemos doble factor
de autenticación etcétera etcétera.
Entonces aquí el espiral pues no nos podía dar una mano con eso luego entramos a prototipos que aquí
podríamos mencionar también en rápida aplicación de la Open Osram verdad que se basaban en prototipos
como su nombre lo dice por ejemplo yo podría decir bueno voy a primero desarrollar la interfaz gráfica
de la pantalla qué colores voy a utilizar como van a estar distribuidos los menús etcétera etcétera.
Y lo hablo con el cliente el me da su aprobación.
Este modelo incluía mucha interacción con el cliente verdad y luego ya me pasaba a otros términos más
técnicos tal vez desarrollando como todo todo digámoslo así toda la base de diseño gráfico el Bakken
la base de datos etcétera etcétera.
Y luego me me pasaba igual al desarrollo como tal de la aplicación y luego entramos a los modelos ágiles
que digamos que los modelos ágiles es como una especie de sombrilla.
El nombre como tal que incluye muchos modelos de verdad por ejemplo el modelo XP o Extreme Provócame
que es otra vez un modelo ágil que USAP programadores los ponía en parejas digámoslo así o pequeños
grupos de programadores que trabajaban en las especificaciones del software por ejemplo.
Bueno tú como programador vas a vas a trabajar en la pantalla de inicio de lo que vas a agregar inscripcion
tú vas a trabajar en la pantalla de transacciones tú vas a trabajar en la pantalla de facturación tú
vas a trabajar etcétera etcétera.
Ya luego se integraba el software como tal pero habían muchos problemas no vamos a entrar al tema de
DevOps que arregló muchos de estos problemas pero bueno es string programen podría ser uno de los modelos
que cae dentro de la sombrilla de ágiles y luego viene el famoso querido y controversial scrum verdad
les digo Este es un modelo muy bueno que otra vez voy a hacer mi mejor esfuerzo por resumirlo pero es
un modelo que lleva mucha mucha expertise de hecho hay certificaciones como tal para hacer un master.
Pero bueno es scrum porque es Scrum es un término que se le dio o a un derivado del deporte de rugby
por qué había una analogía que dijeron sus creadores que esta Kutxi Inocar perdónanos naca que decían
bueno tengamos una vista holística en vez de que todo el equipo vaya hacia adelante al mismo tiempo.
Por qué no las personas se pasan la bola o la pelota de atrás para adelante de un lado para el otro
es decir por qué no somos flexibles y necesitamos movernos para este lado porque no nos movemos para
este lado si evitamos avanzar pero para avanzar necesitamos retroceder dos metros pues hagámoslo.
Entonces esta es una analogía que se le dio o el nombre que se le viene derivado del rugby verdad y
luego bueno básicamente scrum contiene equipos pequeños de desarrollo o desarrolladores perdón que se
les conocen como Scrum Timms.
Luego está el scrum master que es digamos un miembro ciño o ya recorrido en el tema de desarrollo y
en temas de scrum que es un master de desarrollo y actúa como el coach si lo queremos ver ya otra vez
con la analogía del rugby activad como el coach del equipo y le da las herramientas al equipo o a reuniones
y básicamente soporta al equipo les da el apoyo que se necesita.
Y por último tenemos el rock aúnen o dueño del producto que es el que esponsor o el patrocinador frente
al negocio como tal.
Es decir bueno vamos a desarrollar una página web y ésta nos va a dar muchas mucho revenido muchas ventas
nuevas por x y sea y bueno como el enlace con el negocio.
Estos son los tres términos más comunes en scrum y otra vez es un modelo muy flexible que no me voy
a meter a los detalles de cómo funciona porque como les digo es una certificación entera pero sí que
sí que creo creo que hoy en día es este el modelo más utilizado para el desarrollo de software como
tal incluso para muchos proyectos que ni siquiera tienen que ver con desarrollo de software.
Por la misma funcionalidad y flexibilidad que tiene me parece algo increíble pero bueno.
Luego tenemos el ciclo de vida de desarrollo de software como tal o el software development Life Saiko
y bueno hay muchas etapas otra vez.
Esto no es recetas de cocina.
Hay etapas que pueden agregarse o cambiarse sin embargo vamos a respaldar nuestras etapas en buenas
prácticas como por ejemplo lo es la lista 800 guian 14 que es donde no está metida.
Luego aquí tenemos una serie de pasos específicos que nos sugiere para el ciclo de vida desarrollo de
software.
Por ejemplo preparar el plan de toma de requerimientos y esto incluye especialmente cuando hablamos
de la lista y siempre incluye temas de seguridad.
Entonces preparar el plan para toma de requerimientos.
Luego tenemos la inicial la inicialización como tal del proyecto que aquí tenemos que el sistema necesita
ser expresado en términos de negocio en términos de beneficios.
Necesitamos tener como un Istari donde se digan los beneficios de un proyecto o de otro proyecto o realmente
empezar el proyecto de desarrollo de software.
Luego tenemos derramen Acquisition Oracles en verdad porque podríamos decir bueno el ciclo de vida desarrollo
de software no sólo va a ser desarrollar hijos podría también ser desarrollar desarrollado por un tercero
o la compra de un software verdad.
Al final si ya tenemos bien mapeados que son los requerimientos tanto de negocio funcionales de seguridad
que son los que tenemos pues si lo vamos a tercerizar o vamos a comprar un producto como se le conoce
enlatado o no que ya está realizado pues ya teniendo los requerimientos de un mapeados podemos decir
Bueno necesito un producto que cumpla con estos requerimientos para que cumpla con mis necesidades.
Entonces desarrollar o adquirir pues podría ser parte del mismo ciclo de vida desarrollo o incluso un
mix.
Desarrollar una parte y adquirir otra.
Luego tenemos la implementación donde tenemos que hacer controles de seguridad testeo de seguridad tenemos
que ver si si se lleva bien con otras aplicaciones en el sistema si no se lleva bien las pruebas de
regresión que hayamos mencionado anteriormente etcétera etcétera.
Básicamente la implementación en producción.
Luego la operación y mantenimiento que expertise necesitamos tener que necesitamos tener mantenimiento
del proveedor o no necesitamos hacer cambios cada cuánto se va actualizar cada cuánto lo vamos a actualizar
nosotros qué va a pasar si una actualización quiebra la funcionalidad etcétera etcétera y luego tenemos
el desposó o el desecho del software como tal.
Somos dueños del código fuente o no es un código propietario lo vamos a dejar ahí por temas de cumplimiento
lo vamos a eliminar como lo vamos a eliminar etcétera etcétera.
Luego pasamos a otro tema que se llama Integrated Artyom y Petain.
Este es un tema que no se menciona mucho pero sí se usa digamos que no le hemos dado el nombre pero
sí que utilizamos muchas veces.
Qué significa el integrated production.
Es un equipo multidisciplinario por eso.
No es un grupo multidisciplinario de personas que son colectivamente responsables digámoslo así para
entregar un producto o un proceso en este caso relacionado a software IP Elipe.
Hoy pichí de está compuesto por personas que planean ejecutan implementan todo lo que se refiere al
ciclo día desarrollo de software.
Esto significa que podemos incluir personas los stakeholders por ejemplo personas de recursos humanos
personas de contabilidad cualquier cualquier parte interesada en que se desarrolle el producto como
tal o el software como tal.
No no necesariamente está atado a programadores para la parte técnica como tal.
También tenemos a personas de muchas interdisciplinario y digámoslo así verdad.
Luego tenemos el famoso DevOps que ya esto ya entramos un poquito ya en el tema de seguridad o un tema
y otra vez interdisciplinario como tal por qué interdisciplinario.
Porque DevOps lo que incluye son cuatro quiero decir departamentos pero digamos que tres son cuatro
tres quiero decir departamentos pero al final pueden ser personas con expertise específico.
Por ejemplo primero el desarrollo como tal no pueden dejar afuera el desarrollo development.
Luego tenemos el cuadri Asurans o aseguramiento de la calidad como tal.
Y luego tenemos o en este caso EITI Operations.
Entonces tenemos tres departamentos o tres personas con expertise específica que unidas forman DevOps
como tal verdad.
Entonces aquí es bueno vamos a desarrollar si vamos a desarrollar programas a tener en cuenta a las
operaciones del día a día esto significa que vamos a hacer escaneos de vulnerabilidades y también tenemos
un GDR que pueda bloqueé alguna funcionalidad de la aplicación así que hay que poner una regla específica.
Y bueno vamos a ver que realmente el software no tenga tenga todas las variables sanity izadas etcétera
etcétera.
Digamos que es como un ciclo más completo para el desarrollo de software.
Ahora bien cuando nosotros tenemos tercerizados o somos vamos a comprar alguna aplicación o algo o algún
software enlatado pues casi nunca vamos a tener acceso al código fuente.
Por ejemplo si nosotros quisiéramos comprar un Zapp por ejemplo o algún R.M CRM bueno y cantidad de
software enlatado pocas veces vamos a tener acceso al código fuente.
Y qué pasa si nosotros estamos poniendo un Kord bisnes ahí en esa aplicación por ejemplo voy a comprar
algún algún software para venta en línea o alguna página web y casi toda mi aplicación va a funcionar
ahí.
Qué pasa si ellos después de diez años cierran la empresa ya no le dan mantenimiento ya no sacan fixes
ya no ya no le dan mantenimiento a la aplicación y mi negocio se va a ver muy afectado.
Para esto hay software cloud se resguardan del tema vemos en criptografía que se makis grow.
Bueno pues lo mismo aplica aquí para Softworks verdad es un tercero o alguien externo tanto para nosotros
como para la compañía que nos provee el servicio de desarrollo que nos vendió la aplicación y ellos
almacenan el software como tal en el código fuente.
En dado caso podríamos poner en el contrato o en LCL en dado caso esta empresa que nos está que nos
está vendiendo el producto se vaya del negocio o cierre sus operaciones pues esta empresa Tercera y
que nos hizo el software screw nos puede dar acceso al código fuente para nosotros ya sea lo sigamos
manteniendo manteniendo por nuestra cuenta o se lo debemos a otro tercero para que ellos sigan con el
mantenimiento y el desarrollo gorda.
Obviamente es un proceso doloroso porque vamos entender el código de alguien más es alguien difícil
los programadores se van a se van a identificar con esto entonces.
Pero bueno está la opción.
Y bueno eso es todo por hoy amigos espero les ha gustado y todo muy pronto.