No hay una respuesta correcta aquí.
Me gusta recurrir al modelo de calidad de Philip Crosby para medir cosas como esta. Si no estás familiarizado:
- La definición de calidad es conformidad con los requisitos (requisitos que significan tanto el producto como los requisitos del cliente)
- El sistema de calidad es la prevención.
- El estándar de rendimiento es cero defectos (en relación con los requisitos)
- La medida de la calidad es el precio de la no conformidad
Veamos esto en dos partes: la primera, especifica los requisitos de seguridad por adelantado; segunda parte, descubre que los requisitos de seguridad no están en la especificación original después de la implementación.
- ¿Cuál es el mejor software para usar la tableta digitalizadora Wacom Intuos Draw?
- ¿Cuál es la mejor aplicación bancaria?
- ¿Qué softwares se utilizan en la industria de la ilustración?
- ¿Cuál es el beneficio de usar un software de giro / reescritura de artículos?
- Si deshabilito la instalación de paquetes de software de terceros en Linux, ¿cómo puedo instalarlos más adelante?
Primera parte: ha definido completamente el comportamiento de seguridad del conjunto de programas, las API, las interfaces de red, la implementación del servidor, el modelo de seguridad de datos tanto en reposo como en tránsito, las partes de identificación y autenticación, todo está bien entendido y completamente modelado , y cree que no hay casos límite que no se hayan considerado.
Cascada: usted escribe código, en fases típicamente, tiene revisiones de código, prueba de unidad, prueba integrada, ya que tiene código listo para implementar la prueba de regresión para que el nuevo código no rompa el código anterior y los ciclos de lanzamiento por etapas. En cada etapa de desarrollo, tiene a alguien que verifica y valida todos los requisitos funcionales, de rendimiento y seguridad que se cumplen, y no se envía ningún código hasta que lo haga.
Precio de incumplimiento: bajo, nada se escapa sin ser examinado. En palabras del comercial ’86 Gallo Wind “no se envía ningún código antes de tiempo”.
Precio de implementación: alto, porque solo puede estimar líneas de tiempo, y tendrá intervalos de tiempo a medida que las cosas se retrasen debido a que no pasa la prueba.
Precio de cumplimiento obligatorio: bajo, porque no hay código no conforme en el sistema.
DevOps: usted escribe código en un modelo de integración continua, y para cada unidad de código el escritor de código es el probador y el implementador de código. Los objetivos finales están definidos, el producto de trabajo provisional mucho menos; a medida que el código llega a la prueba de la unidad (tal vez antes, dependiendo de qué tan bien esté la tienda) se implementa en producción. El nuevo código se implementa contra el código antiguo, y los requisitos funcionales del código se incrementan desde la línea de base hasta el máximo con el tiempo sin lanzamientos programados.
Todo el comportamiento del programa está en flujo ya que toda la base de código está en flujo. Tiene algunas líneas de base (generalmente el modelo de seguridad de datos, el modelo de red, los modelos de autenticación e identificación y una API inicial) que son relativamente inmutables, pero la API crece con el tiempo a medida que se agrega más función de back-end o la interfaz necesita cosas que no son Se puede hacer fácilmente a través de la API actual.
Precio de no conformidad: alto. En cualquier momento dado, el código puede o no cumplir con los requisitos porque la publicación es continua.
Precio de despliegue: bajo. El código ocurre a medida que sucede, y aunque la disponibilidad de funciones puede seguir la trayectoria deseada, no existe una situación en la que al menos los componentes principales del sistema no estén disponibles.
Precio de cumplimiento obligatorio: moderado. El código se está adaptando para una integración continua, se puede inyectar código nuevo y el código antiguo se puede deshacer de manera muy simple.
Parte dos: como en la Parte uno: ha definido completamente el comportamiento de seguridad del conjunto de programas, las API, las interfaces de red, la implementación del servidor, el modelo de seguridad de datos tanto en reposo como en tránsito, las porciones de identificación y autenticación, todo bien entendido y totalmente modelado, y cree que no hay casos límite que no se hayan considerado. Y luego, a mitad del ciclo, o más tarde en el ciclo posterior a la implementación, algo cambia y debe revisar el modelo, las especificaciones, los requisitos, la medida del éxito y crear un nuevo código para que coincida.
Cascada: ahora debe volver a analizar la base de código existente, descubrir cómo modificarla para cumplir con los nuevos requisitos. Habrá una cantidad significativa de tiempo haciendo esto antes de que incluso puedas tocar escribir código. Dependiendo del tamaño de la base del código, esto puede medirse en años, y no es extraño que un gerente de proyecto asignado a tal tarea ejerza presión para una versión “2.0” que cumpla con los nuevos requisitos que de hecho es un nueva construcción desde cero, no basada en código anterior.
Una vez que se acuerda el proceso, se define un ciclo de lanzamiento, se establece la funcionalidad de lanzamiento por etapas, continúa como en la Parte Uno.
Precio de incumplimiento: según Crosby, este sería un nuevo proyecto en el que dejaría de lado el hecho de que anteriormente tiene un sistema en funcionamiento, por lo que el costo aún sería bajo a cero. En realidad, tendría que tomarse el tiempo dedicado a descubrir cómo modificar el sistema para cumplir con los nuevos requisitos más el tiempo de modificación, por lo que será minucioso. Que Dios te ayude si acabas de “perder algo” en lugar de un cambio importante en el regulador que forzó los nuevos requisitos.
Precio de despliegue: masivo. Debe cortar un sistema de producción completo a un nuevo sistema de producción. Puede usar algunas técnicas de DevOps, en particular el uso de equilibradores de carga para dividir la carga, una vez que tenga un almacén de datos de backend unificado que pueda usar tanto los sistemas antiguos como los nuevos, pero aún así es doloroso.
Precio de cumplimiento obligatorio: igual que en la primera parte.
DevOps:
Tiene un nuevo conjunto de requisitos que agrega a su conjunto anterior de requisitos y, como antes, las cosas se implementan a medida que se implementan y se implementan a medida que se hacen. Las pruebas de regresión se vuelven más importantes ya que no desea romper el comportamiento esperado anterior contra el nuevo código que impone nuevos requisitos, y el análisis de cómo los nuevos requisitos cambian la interacción del usuario generará mucho código.
Nuevamente, en ausencia de cambios en el almacén de datos del backend que afectan tanto la implementación hacia adelante como hacia atrás, el código simplemente se implementa.
Precio de no conformidad: alto. en cualquier momento dado, solo una parte de la base del código cumplirá con los requisitos, y el código que cumple con los requisitos de hoy puede revertirse mañana.
Precio de despliegue: bajo. el código se implementa con el tiempo, cambia a nuevas instancias administradas por división de carga.
Precio de cumplimiento obligatorio: moderado, mucho más bajo que la cascada. Una vez más, el despliegue del código ocurre de manera incremental y se puede inyectar un nuevo código y revertir el viejo frío simplemente.
Por lo tanto, si cree que los requisitos funcionales y de seguridad pueden entenderse y definirse y probarse por completo, y el tiempo para la primera implementación no es un problema, la cascada plana mata todo lo demás.
Es por eso que aún así es como construimos sistemas seguros, sistemas integrados, firmware de dispositivos y todo lo demás que puede encapsularse y reducirse.
Si, por otro lado, cree que solo comprende parcialmente los requisitos completos y sus implicaciones y espera que antes de que el proyecto se entregue por completo que habrá cambios, sería un idiota si no usara otra cosa que no sea cascada.
Tenga en cuenta que existe una alternativa, pionera en Cisco para sus lanzamientos de código de enrutador IOS, llamada “tren de código”, que proporciona todo el rigor de la cascada con algo de la flexibilidad de DevOps, al dividir el código general en partes más pequeñas con un lanzamiento calendario y un conjunto de reglas para modificar lo que hay en cada fragmento de lanzamiento progresivo.
Si tiene inquietudes acerca de mantener un control estricto sobre la calidad del código pero mantener algo cercano a la velocidad de liberación de la integración continua, estudie eso en orden.
Nota adicional: debe ser capaz de comprender y articular los requisitos funcionales y de seguridad en todos los casos de uso anticipados para que todo esto sea más que una conjetura, y ahí es donde falla el 90% + del código moderno.
