SDLC

Software Development Lifecycle es el paraguas para nombrar las etapas que recorre el software desde idea hasta retirada. Distintas metodologías (agile, cascada, devops, continuous delivery) definen fronteras de etapa y formas de pasar de una a otra distintas. Las etapas en sí son prácticamente invariantes: discovery, diseño, build, test, deploy, operar, retirar.

Útil como vocabulario, no como proceso. Los equipos que tratan de imponer un SDLC estricto acaban con sobrecarga de documentación que no sobrevive al segundo sprint. Los que lo ignoran del todo redescubren cada fase por las malas («enviamos sin plan de deploy», «no pensamos cómo retirar esto»).

Ejemplo de la etapa que todos se saltan: una startup construye tres servicios internos en dos años, los envía y sigue adelante. Nadie es dueño de «operar» y nadie planificó «retirar». Dieciocho meses después dos de los tres servicios siguen corriendo, nadie recuerda por qué, el único ingeniero que los entendía se ha ido, y desactivar cualquiera de los dos podría romper algo o no. Ese es el coste no facturado de saltarse la mitad de atrás del ciclo. El arreglo es barato si se hace al principio (nombrar un dueño, escribir un plan de deploy y de desmantelamiento) y caro si se descubre después.

La metodología que elijas decide sobre todo cuán rígidas son las fronteras entre etapas. Un SDLC en cascada las corre estrictamente en secuencia con firmas en cada puerta; un SDLC agile entrelaza diseño, build y test de forma continua y revisita etapas anteriores a medida que aprende. Las etapas son el mismo conjunto en cualquier caso, que es la idea útil: discutir «agile contra cascada» es en realidad discutir cuán permeables deberían ser las fronteras, y la respuesta correcta depende de cuánto pueden cambiar todavía tus requisitos.

El trade-off honesto y el error común: los founders oyen «SDLC» y o lo sobre-formalizan en un proceso con puertas y firmas que mata la velocidad, o lo descartan como teatro de empresa y se saltan las etapas poco glamurosas. La postura correcta es tratarlo como una lista de cosas que deben ocurrir en algún sitio, no una secuencia por la que marchar. La forma preferida por Wavect: una fase de discovery pagada al inicio, diseño y build entrelazados en ciclos cortos, TDD y CI/CD automatizados desde el día uno, operar con propiedad clara, retirar con caminos de migración documentados.