DISCUSSION

2.3.1 El modelo en espiral

A continuación se describe un Modelo de Ciclo de Vida que fuera desarrollado para sistemas confiables (trusted) [Marmor-Squires 89], y que resulta adecuado para el desarrollo de sistemas con capacidad de supervivencia; está basado en los modelos en cascada y en espiral, y una extensión del modelo en espiral para incorporar conceptos de sistemas confiables.

Las características fundamentales del modelo en espiral son la administración del riesgo, la robustez y la flexibilidad. La descripción del modelo en espiral se desprende particularmente de Boehm [Boehm 89]. Seguidamente se describe el modelo en espiral básico y a una especializa- ción del mismo.

El desarrollo de software es, en el mejor de los casos, un proceso dificultoso. De hecho, muchos sistemas de software, especialmente en el área comercial, simplemente evolucionan sin un pro- ceso de desarrollo bien definido; otros son desarrollados utilizando una ambigua progresión de etapas, posiblemente con algún grado de retroalimentación entre etapas adyacentes –por ejem- plo, en el modelo en cascada [Royce 87], el cual más bien realiza una explicación del proceso de desarrollo de facto a posteriori más que ofrecer una guía para su ejecución [Parnas 86]. A lo largo de los años, se han propuesto numerosas variaciones o alternativas al modelo en cas- cada; cada una de estas alternativas han superado ciertos defectos de dicho modelo, pero intro- ducen sus propios problemas. En tanto este modelo atiende al importante propósito de introducir una disciplina en el proceso de desarrollo de software, esencialmente impone progresiones li- neales, las que fueran necesarias en el mundo orientado al procesamiento por lotes (batch) de limitadas alternativas y escaso potencia computacional, asumiendo un sistema de ensamblado lineal tipo fabril, en el cual comprendemos cada parte.

En la actualidad, la disponibilidad de estaciones de trabajo, redes y almacenamiento masivo barato, junto con una variedad de herramientas, hace posible una amplia variedad de activida- des de programación exploratorias como parte del proceso de desarrollo. Esto significa que resulta posible desarrollar prototipos o modelos como partes de sistemas, obtener la reacción de una potencial comunidad de usuarios, y retro-alimentar con esta información el proceso de desa- rrollo. Asimismo, la creciente disponibilidad de ambientes de desarrollo y ejecución han acele- rado esta tendencia.

software que supere las deficiencias del modelo en cascada, y adecue actividades tales como prototipado, reutilización, y codificación automática como una parte del proceso. Una conse- cuencia de la flexibilidad del modelo de ciclo de vida es que el desarrollador se enfrenta con opciones de muchas etapas de proceso, y con las opciones deviene el riesgo. En consecuencia, gran parte del énfasis en el modelo en espiral está puesto en la administración del riesgo. Esto, a su vez, puede resultar en un progreso desparejo en varios aspectos del desarrollo del sistema, con áreas de alto riesgo que están siendo exploradas en profundidad en tanto que se difieren áreas de bajo riesgo.

El modelo en espiral ve al proceso de desarrollo en un sistema de coordenadas polares. La coordenada r representa el costo del proyecto acumulativo y la coordenada w representa la fecha de avance. El plano se encuentra dividido en cuatro cuadrantes que representan los diferentes tipos de actividades, tal como se indican:

I Determinación de objetivos, alternativa y restricciones

II Evaluación de alternativas; identificación y resolución de riesgos III Actividades de desarrollo

IV Revisión y planificación de ciclos futuros.

Además, la frontera entre los cuadrantes I y IV representa el compromiso de adelantar con un elemento, solución o método particular, y avanzar hacia la siguiente etapa (o espiral) dentro de un espacio definido de actividades (por ejemplo, diseño). Actividades específicas pueden super- poner múltiples espirales. Además, se pueden requerir espirales concurrentes para atender áreas de riesgo diverso. La línea de compromiso puede implicar una decisión de terminar el proyecto o de cambiar la dirección en base a los resultados obtenidos.

La Figura 5 muestra un ciclo de la espiral. Debemos observar que w no avanza de manera uni- forme con el tiempo. Algunos ciclos de la espiral pueden requerir de meses para completarse, mientras que otros sólo requieren de días; de manera similar, si bien el incremento de w indica avance dentro de un ciclo de la espiral, no necesariamente denota un progreso hacia la terminación del proyecto.

Cada ciclo del modelo atiende a todas las actividades entre los eventos de revisión y compromi- so. En el inicio del proceso, los ciclos pueden ser cortos en tanto se exploran alternativas en el espacio de decisión del proyecto. A medida que se van resolviendo los riesgos, los ciclos se pueden alargar, de tal manera que el cuadrante de desarrollo incluye varias etapas de la cas- cada. La espiral se puede finalizar con la entrega del producto –en cuyo caso las actividades de modificación o mantenimiento son nuevas espirales- o continuar hasta que el producto es abandonado.

Figura 5. Ciclo en espiral de un proyecto.

2.3.2 Un modelo en espiral para el desarrollo de sistemas con capacidad de supervivencia

El proceso en espiral “puro” generalizado recién discutido proporciona un framework para mo- delos más especializados. La especialización y el mejoramiento consisten en la adaptación de las actividades llevadas a cabo conforme al modelo a los requerimientos especiales de los sis- temas que están siendo producidos.

Esto se lleva a cabo mediante la especificación de (1) las actividades que se hacen cargo de los conductores que caracterizan al sistema y (2) las restricciones que caracterizan el ambiente en el cual el sistema está siendo producido. Esta combinación da lugar a una versión especializa- da del modelo en espiral que integra la capacidad de supervivencia dentro del proceso de ad- ministración, como se describe en la Figura 6.

Los sistemas con capacidad de supervivencia deben satisfacer una variedad de intereses con- flictivos:

• Los usuarios finales necesitan que los sistemas lleven a cabo su misión operativa princi- pal, posiblemente a expensas de violar políticas de seguridad bajo ciertas circunstancias. • Resulta común el caso en que los sistemas deban también satisfacer alguna autoridad

de certificación o acreditación; las etapas requeridas para estas aprobaciones pueden entrar en conflicto con los intereses de los usuarios.

• Los desarrolladores desean terminar el trabajo, preferentemente antes de lo planifica- do y por debajo de lo presupuestado.

• Dentro de la organización encargada del desarrollo, pueden existir tensiones entre los diferentes especialistas involucrados.

• La resolución de estos conflictos puede traducirse en restricciones en el ambiente y en proceso de desarrollo. Cuadrante I Determinar objetivos Definir alternativas Determinar restric- ciones Cuadrante II Análisis básico Mitigación de riesgo Cuadrante IV Planificación del próxi-

mo ciclo Planificación de los ciclos subsiguientes

Cuadrante III

Desarrollo del producto Revisión y Com-

• Siempre están presentes las consideraciones de costo. El proceso de desarrollo en es- piral ha demostrado ser el más efectivo en costo que los métodos tradicionales, pero exhibe una diferente distribución del costo a lo largo del tiempo. Bajo el modelo en es- piral, los desembolsos generalmente son mayores en las actividades de especificación y diseño iniciales, lo que conlleva a una reducción de costos en las actividades de imple- mentación e integración posteriores.

Figura 6. Especialización del modelo en espiral para el conductor supervivencia.

La Tabla 4 identifica un conjunto de actividades típicas en el desarrollo de un sistema y los correspondientes elementos de supervivencia en cada uno de ellos. El punto clave es que la supervivencia está integrada dentro de actividades más amplias; por ejemplo, junto con la defi- nición de requerimientos del sistema, deben estar definidos los atributos de supervivencia: fun- ción, desempeño, confiabilidad, escalabilidad, y otras propiedades.

Esta tabla identifica un conjunto de actividades típicas en el desarrollo de un sistema y los co- rrespondientes elementos de supervivencia en cada uno de ellos. El punto clave es que la super- vivencia está integrada dentro de actividades más amplias; por ejemplo, junto con la definición de requerimientos del sistema, deben estar definidos los atributos de supervivencia: función, desempeño, confiabilidad, escalabilidad, y otras propiedades.

Las actividades de la Tabla 4 constituyen el objetivo para la administración del proyecto bajo el modelo en espiral especializado de la Figura 5.

A manera ilustrativa, supongamos la siguiente aplicación del proceso de administración en espi- ral a la fase de definición de arquitectura. Asumimos que las fases anteriores han sido comple- tadas exitosamente y que los documentos apropiados de requerimientos y de especificaciones

Modelo de Proceso en Espiral con Supervivencia

adicionada a cada Activi- dad Modelo de Proceso en Espiral Requerimiento/ Conductor Prin- cipal Restricciones Principales Fundamento Funcionalidad Desempeño Confiabilidad Escalabilidad … Supervivencia Agregado Misión Organización Ambiente Costo Planificación Conocimiento Tecnología …

están en nuestras manos. La tarea inicial de la espiral de definición de arquitectura inicial es definir un conjunto de componentes candidatos y sus interconexiones que implementarán los servicios especificados de una manera que satisfagan tanto los requerimientos funcionales como no-funcionales. El arquitecto seleccionará las plataformas candidatas, les asignará funciones, y determinará las conexiones apropiadas entre estas plataformas y las del mundo exterior. Se han de utilizar una variedad de herramientas y técnicas para analizar la arquitectura propuesta a los fines de determinar si satisface los requerimientos y especificaciones. Una posibilidad para este

Actividades del

ciclo de vida Elementos claves de supervivencia Ejemplos Definición de la

misión

Análisis crítico de la misión y las consecuencias de la falla

Estimación del impacto en el costo de los ataques de denegación de servicio Concepto de

operaciones Definición de las capacidades del sistema en ambientes adversos Enumeración de las funciones de la misión crítica que deben resistir a los ataques

Planificación

del proyecto Integración de la supervivencia dentro de las actividades del ciclo de vida

Identificación de técnicas de codifica- ción defensiva para la implementación Definición de

requerimientos Definición de los requerimientos de supervivencia a partir de la perspecti- va de la misión

Definición de los requerimientos de acceso para los activos del sistema críticos durante los ataques Especificación

del sistema Especificación del servicio esencial y los escenarios de intrusión Definición de los pasos que componen las transacciones del sistema críticas Arquitectura

del sistema Integración de estrategias de supervi-vencia dentro de la definición de ar- quitectura

Creación de una red de facilidades para la replicación de los activos de datos críticos

Diseño del sis-

tema Desarrollo y verificación de las estra-tegias de supervivencia Verificación de la exactitud de los algoritmos de encriptación de datos Implementación

del sistema Aplicación de codificación e imple-mentación de técnicas de superviven- cia

Definición de métodos para evitar vulnerabilidades de buffer overflow

Testeo del sis- tema

Tratamiento de los intrusos como si fueran usuarios durante el testo y la certificación

Agregado de la utilización de intru- sión a los modelos de utilización para el testeo estadístico

Evolución del

sistema Mejoramiento de la supervivencia para prevenir la degradación a lo largo del tiempo

Redefinición de la arquitectura en respuesta a los cambios en el ambiente de amenazas

Tabla 4. Actividades de ciclo de vida y los correspondientes elementos de supervivencia.

análisis es que la arquitectura propuesta satisfaga los requerimientos funcionales pero no pueda alcanzar el throughput requerido. Si bien la replicación del procesador ya ha sido empleada para la mejora del desempeño, los procesadores requieren de un acoplamiento fuerte para mantener la sincronización, y su ubicación presenta una vulnerabilidad como potencial punto de falla único. Resulta necesaria otra espiral sobre la arquitectura debido a que restan riesgos irresueltos.

Un examen de la especificación del servicio que representaba el cuello de botella demuestra, aquéllo que a primera vista aparece como un servicio monolítico en realidad se descompone de tal manera que reduce la carga de procesamiento y permite la separación del servicio en dos partes, física y temporalmente. Luego de confirmar que la especificación revisada de este servi- cio satisface los requerimientos y es consistente con las otras especificaciones no modificadas, se revisa la arquitectura. La especificación revisada permite una reducción en la carga del pro- cesador y que la función crítica sea realizada en varias localizaciones distantes con requerimien- tos fuertemente relajados en lo que hace a la sincronización de datos. Como resultado de ello, resulta posible configurar el sistema con la suficiente redundancia de tal manera que se puedan tolerar al menos dos eventos de pérdida de sitio sin que se produzca la pérdida del servicio. Un mayor número de pérdidas de sitio reducirá los niveles de servicio, pero resulta posible priorizar las solicitudes de tal manera que será mantenido un nivel esencial mínimo. El análisis detallado de esta solución muestra una baja probabilidad de que surja una condición que pudiese provocar un inter-bloqueo del sistema. El agregado de mecanismos de sincronización explícita (otra itera- ción) y la capacidad de comunicaciones adicionales reduce el riesgo residual a un nivel acepta- ble, y la fase de arquitectura se completa luego de dos espirales del proceso de administración.

2.3.3 Actividades del ciclo de vida y la capacidad de supervivencia

Los elementos claves de supervivencia de la Tabla 4 son las principales tareas que deben ser ad- ministradas dentro del modelo en espiral para alcanzar la supervivencia del sistema. El Método SNA ha demostrado ser de utilidad en las actividades de definición de requerimientos, especifica- ción del sistema, y arquitectura del sistema. Las mismas serán descriptas en este reporte.