Seguridad en el ciclo de desarrollo del software

La mayor parte de las organizaciones desarrolla o contrata el desarrollo de aplicaciones propias para su gestión de negocio. Como todo software,estas aplicaciones pueden contener fallas de seguridad y a diferencia del software comercial, no se dispone de actualizaciones o parches liberados en forma periódica por el fabricante. El tratamiento de las vulnerabilidades en aplicaciones propias corre por parte de la organización que las desarrolla.Lamentablemente es una práctica habitual en muchas organizaciones lapuesta en producción! de sistemas sin la participación del sector de seguridad de la información. Muchas otras veces, el sector de seguridad se entera demasiado tarde,y no tiene su%ciente margen de acción para el análisis de seguridad dela aplicación desarrollada. Por lo general, en el mejor de los casos, se coordina un testeo de seguridad una vez que la aplicación ya está desarrollada. Aquí muchas veces se encuentran errores que requieren el rediseño de parte de la aplicación, lo cual implica un costo adicional en tiempo y esfuerzo.

Seguridad en el análisis de requerimientos

En esta etapa, se deben identificar aquellos requerimientos funcionales que tendrán impacto en los aspectos de seguridad de la aplicación. Algunos de ellos son: requerimientos de compliance con normativas locales o internacionales, tipo de información que se transmitirá o procesará , datos personales, datos financieros, contraseñas, datos de pago electrónico, etc. y requerimientos de registros de auditoria.

Seguridad en el diseño

Una vez que se cuenta con el diseño detallado de la aplicación, una práctica interesante es la de realizar sobre el mismo un análisis de riesgo orientado a software. Existen técnicas documentadas al respecto,tales como Threat Modeling. Estas técnicas permiten definir un marco para identificar debilidades de seguridad en el software, antes de la etapa de codificación. Como valor agregado, del análisis de riesgo orientado a software se pueden obtener casos de prueba para ser utilizados en la etapa de testing.

Seguridad en la codificación

Una vez concluido el diseño, le toca a los desarrolladores el turno decodificar los distintos componentes de la aplicación. Es en este punto en donde suelen incorporarse, por error u omisión, distintos tipos de vulnerabilidades. Estas vulnerabilidades podríamos dividirlas en dos grandes grupos a saber: vulnerabilidades clásicas y vulnerabilidades funcionales. Las primeras son bien conocidas y categorizadas. Vulnerabilidades funcionales son aquellas ligadas específicamente a la funcionalidad de negocio que posee la aplicación, por lo que no están previamente categorizadas.

Testing Q/A de seguridad

Tradicionalmente, la labor del equipo de testing fue la de encontrar y reportar errores funcionales de la aplicación. Para esto, se desarrollan "casos de test" basados en la funcionalidad esperada. Estos denominamos "testing funcional" y básicamente consiste en validar que la aplicación haga lo que se esperaba que hiciera.

Confiabilidad del software

La confiabilidad de software significa que un programa particular debe de seguir funcionando en la presencia de errores. Los errores pueden ser relacionados al diseño, a la implementación, a la programación, o el uso de errores.

Conceptos asociados con la confiabilidad:

Atributos de la confiabilidad:

La confiabilidad se expresa mediante diferentes atributos o propiedades:

Disponibilidad	Medida en la cual el  sistema está listo para ser usado.
Fiabilidad	Medida en la cual el sistema suministra su servicio de forma continua.
seguridad	Medida en la cual un sistema evita consecuencias catastróficas en su entorno.
Confidencialidad	Se trata de una propiedad de la información que pretende garantizar el acceso solo a personas autorizadas
Integridad	se refiere a la corrección y a la complementación de los datos en una base de datos.
Mantenibilidad	Medida en la cual el sistema es apto para reparaciones y modificaciones

Deterioros de la confiabilidad

Existen tres factores de deterioro de la confiabilidad:

1.-Falla o fracaso: es un comportamiento inaceptable del sistema que no cumple con su especificación.

2.-Error: estado interno del sistema que difiere de uno válido y que es susceptible de coincidir a un fallo.

3.-Defecto: condición que provoca un error.

Medios de la confiabilidad

Los medios son los métodos y técnicas que permiten:

1.-Proveer la capacidad de entregar un servicio.

2.-Que alcance la confianza en esa capacidad.

Son usados en el proceso de construcción de software con el propósito de adquirir la confiabilidad:

-Evitar de defectos: para evitar o prevenir la introducción y ocurrencia de defectos.

-Tolerancia a defectos: para suministrar servicios que cumplan con su especificación a pesar de la existencia de defectos.

Contribuyen a la validación del software luego de ser desarrollado con el propósito de asegurar la confiabilidad.

-Eliminación de defectos: Detectar la eliminación de defectos y eliminarlos

-Predicción de defectos/fallos: para estimar la presencia de defectos y la ocurrencia y la consecuencia de los fallos.

Seguridad en Ingeniería de software

Introduccción

La criticidad de los actuales sistemas de información en diferentes dominios de la sociedad determina que, si bien es importante asegurar que el software se desarrolla de acuerdo a las necesidades del usuario (requerimientos funcionales), también lo es garantizar que el mismo sea seguro. Hasta hace poco tiempo la Ingeniería de Software y la Ingeniería de Seguridad venían desarrollándose de forma independiente, limitando la posibilidad de que la seguridad sea considerada como parte del proceso de desarrollo de sistemas de software seguros. Si no se dispone de una definición precisa de lo que significa seguridad y cómo debe comportarse un software, no tiene sentido alguno preguntarse si el mismo es seguro o no. Es necesario revisar la terminología y definir un conjunto de conceptos de manera más rigurosa, considerar y comparar diferentes metodologías de tratamiento de la seguridad pasibles de ser articuladas con las metodologías para el proceso del ciclo de vida del desarrollo de software ya existentes, y considerar los modelos de madurez y aseguramiento de calidad.

La creciente dependencia de tareas críticas respecto del software conlleva a que el valor del mismo ya no resida solamente en la aptitud que posee de mejorar o sostener la productividad y la eficiencia de las organizaciones, sino que además se requiere que posea la capacidad de continuar operando de manera confiable aun cuando deba enfrentar eventos que amenazan su utilización. Esto ha conducido a un conjunto de cambios, derivados de la incorporación de los aspectos de seguridad, en la visión de las propiedades de los sistemas de información que hacen uso intensivo de software, por lo que resulta necesario revisar algunos conceptos de manera más precisa. Surgen de esta revisión dos conceptos fundamentales como son “software assurance”(SA) y “software secure”.

Seguridad de software

La seguridad en el software es un área de investigacion y de estudio en el cual con el paso del tiempo se han desarrollado varias tecnicas tanto para proteccion del software, como para ataque de un software utilizando herramientas especialmente diseñadas para cada tipo de software. Esto a la vez nos ayuda para poner a prueba cuan seguro es nuestro software y desarrollar software mas seguro.

Actualmente en el desarrollo de Software, el desarrollador ya no sólo debe concentrarse únicamente en los usuarios y sus requerimientos, sino también en los posibles atacantes. Esto ha motivado cambios importantes en el proceso de diseño y desarrollo de software para incorporar a la seguridad dentro de los requerimientos críticos del sistema. Prácticamente todo sistema debe incorporar cuestiones de seguridad para defenderse de ataques maliciosos.

Como desarrollador de software uno primero debe de determinar lor riesgos de una aplicación particular. por ejemplo un sitio web puede ser sujeto de una variedad de riesgo, tales como ataques hacia el servidor, el host, ataques sobre la base de datos, lo que pudiera implicar perdidas monetarias.

Criterios para desarrollar un Software Seguro

• Autenticación: el proceso de verificar la identidad de una entidad.
• Control de acceso: el proceso de regular las clases de acceso que una entidad tiene sobre los recursos.
• Auditoria: un registro cronológico de los eventos relevantes a la seguridad de un sistema. Este registro puede luego examinarse para recontruir un escenario en particular.
• Confidencialidad: la propiedad de que cierta información no este disponible a ciertas entidades.
• Integridad: la propiedad de que la información no sea modificada en el trayecto fuente-destino.
• Disponibilidad: la propiedad de que el sistema sea accesible a las entidades autorizadas.

Objetivos para un Software Seguro

1. independencia de la seguridad: la seguridad debe de construirse y utilizarse de manera independiente de la aplicacion.
2. independencia de la aplicación: la aplicación no debe depender del sistema de seguridad usado, debe ser desarrollada y matenida en forma separada.
3. Uniformidad: la seguridad debe aplicarse de manera correcta y consistente a través de toda la aplicación y del proceso que desarrolla la misma.
4. Modularidad: mantener la seguridad separada. Entre otras ventajas esto nos brindará mayor flexibilidad y menor costo de mantenimiento.
5. Ambiente seguro: se debe partir de un entorno confiable. es decir las herramientas de desarrollo y lenguajes de programación no deben contener agujeros de seguridad.
6. Seguridad desde el comienzo: la seguridad debe ser considerada como un requerimiento desde el inicio del siseño.

Arquitecturas de dominio específico

Para el desarrollo de software existen  diversas arquitecturas de dominio específico. Que serían: Diseño de software de arquitectura multiprocesador, diseño de software distribuido,  diseño de software distribuido en tiempo real y diseño de software cliente/servidor.

Existen dos modelos de dominio específico:

• Modelos genéricos que son abstracciones de varios sistemas reales
• Modelos de referencia que son modelos abstractos y describen a una clase mayor de sistemas.

Diseño Software Arquitectura Multiprocesador

Un sistema multiproceso o multitarea es aquel que permite ejecutar varios procesos de forma concurrente, la razón es porque actualmente la mayoría de las CPU’s sólo pueden ejecutar un proceso cada vez. La única forma de que se ejecuten de forma simultánea varios procesos es tener varias CPU’s (ya sea en una máquina o en varias, en un sistema distribuido.

La ventaja de un sistema multiproceso reside en la operación llamada cambio de contexto. Esta operación consiste en quitar a un proceso de la CPU, ejecutar otro proceso y volver a colocar el primero sin que se entere de nada.

El multiproceso no es algo difícil de entender: más procesadores significa más potencia computacional. Un conjunto de tareas puede ser completado más rápidamente si hay varias unidades de proceso ejecutándolas en paralelo. Esa es la teoría, pero otra historia es la práctica, como hacer funcionar el multiproceso, lo que requiere unos profundos conocimientos tanto del hardware como del software.

Es necesario conocer ampliamente como están interconectados dichos procesadores, y la forma en que el código que se ejecuta en los mismos ha sido escrito para escribir aplicaciones y software que aproveche al máximo sus prestaciones.

Diseño Software Arquitectura Cliente-Servidor

La arquitectura cliente-servidor es una forma de dividir las responsabilidades de un Sistema de Información separando la interfaz de usuario (Nivel de presentación) de la gestión de la información (Nivel de gestión de datos).

Esta arquitectura consiste básicamente en que un programa, el Cliente informático realiza peticiones a otro programa, el servidor, que les da respuesta.

Aunque esta idea se puede aplicar a programas que se ejecutan sobre una sola computadora es más ventajosa en un sistema multiusuario distribuido a través de una red de computadoras.

La arquitectura cliente-servidor sustituye a la arquitectura monolítica en la que no hay distribución, tanto a nivel físico como a nivel lógico.

Ventajas de la arquitectura cliente-servidor

• Centralización del control: los accesos, recursos y la integridad de los datos son controlados por el servidor de forma que un programa cliente defectuoso o no autorizado no pueda dañar el sistema.
• Escalabilidad: se puede aumentar la capacidad de clientes y servidores por separado.

Se reduce el tráfico de red considerablemente. Idealmente, el cliente se comunica con el servidor utilizando un protocolo de alto nivel de abstracción como por ejemplo SQL.

Diseño Software Distribuido

Estos recursos técnicos suelen catalogarse en:

• Infraestructura.
• Plataforma.
• Comunicaciones.
• Datos.

Pero no olvidemos que detrás del sistema operativo hay personas que lo usan y los gestionan. El factor humano será fundamental como nos cuidaremos de recordar a lo largo del todo el diseño.

Diseñar un sistema distribuido es crear aplicaciones de software que, utilizando servicios y ayudándose de la conectividad, participen y se integren en este entorno de forma transparente a las plataformas de proceso y de almacenamiento de datos, dotándolas de los recursos necesarios para gestionarse de forma integrada con el resto del sistema distribuido.

Los servicios permitirán usar todos los recursos técnicos y el sistema distribuido resulto ante no será nada más, ni nada menos, que un conjunto de servicios que interoperan entre ellos colaborando para cumplir los objetivos que se han establecido para el sistema.

Los sistemas distribuidos que se diseñen y construyan deben estar alineados con los objetivos de negocio de la empresa, aumentar la eficacia y eficiencia operacional de la compañía y permitir el mayor rendimiento con el menor coste en las estructuras informáticas que dan soporte.

No olvide nunca estos tres puntos. El objetivo es siempre alinear tecnología y negocio.

El sistema resultante debe ser adaptable, ofrecer el rendimiento necesario con el coste más barato que seamos capaces de conseguir.Con este objetivo final, empezamos nuestro viaje para el cual le voy a pedir un esfuerzo. Las tecnologías llegan, se consolidan o desaparecen, y al final mueren. Y siempre con facilidad y rapidez.

Pero las estrategias, las tácticas y las técnicas de diseño tienen un ciclo de vida mucho más lento y robusto. Y están por encima de las tecnologías en que se implementan. Intente poner en su mochila solo las primeras. Este es un viaje por el mundo del diseño de sistemas distribuidos, no sus técnicas de implementación aunque haremos las necesarias salidas a ese mundo cuando sea necesario.

Arquitecturas en un sistema distribuido. La arquitectura de Empresa. La palabra arquitectura es de aquellos términos utilizados ampliamente dentro del mundo informático. Cuando atacamos sistemas distribuidos, la palabra aparece continuamente.

Esta constatación de la realidad no resulta extraña si acudimos a la definición que ANSI/IEEE hace del término: “Arquitectura es la organización fundamental de un sistema, donde se integran sus componentes, se establecen las relaciones e interdependencias entre esos componentes y su entorno y se establecen los principios para su diseño, gestión y evolución”.

Patrones de diseño

Los patrones de diseño son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces.

Un patrón de diseño resulta ser una solución a un problema de diseño. Para que una solución sea considerada un patrón debe poseer ciertas características. Una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reutilizable, lo que significa que es aplicable a diferentes problemas de diseño en distintas circunstancias.

¿Qué es un patrón de diseño?

Los patrones de diseño son soluciones para problemas típicos y recurrentes que nos podemos encontrar a la hora de desarrollar una aplicación.

Aunque nuestra aplicación sea única, tendrá partes comunes con otras aplicaciones: acceso a datos, creación de objetos, operaciones entre sistemas etc. En lugar de reinventar la rueda, podemos solucionar problemas utilizando algún patrón, ya que son soluciones probadas y documentadas por multitud de programadores.

“Los patrones de diseño son el esqueleto de las soluciones a problemas comunes en el desarrollo de software.”

En otras palabras, brindan una solución ya probada y documentada a problemas de desarrollo de software que están sujetos a contextos similares. Debemos tener presente los siguientes elementos de un patrón: su nombre, el problema (cuando aplicar un patrón), la solución (descripción abstracta del problema) y las consecuencias (costos y beneficios).

Existen varios patrones de diseño popularmente conocidos, los cuales se clasifican como se muestra a continuación:

• Patrones Creacionales: Inicialización y configuración de objetos.
• Patrones Estructurales: Separan la interfaz de la implementación. Se ocupan de cómo las clases y objetos se agrupan, para formar estructuras más grandes.
• Patrones de Comportamiento: Más que describir objetos o clases, describen la comunicación entre ellos.

Además existe otro tipo de patrones:

• Patrones de Interacción: Son patrones que nos permiten el diseño de interfaces web.

Categorías de patrones de diseño

Según la escala o nivel de abstracción:

• Patrones de arquitectura: Aquellos que expresan un esquema organizativo estructural fundamental para sistemas de software.
• Patrones de diseño: Aquellos que expresan esquemas para definir estructuras de diseño (o sus relaciones) con las que construir sistemas de software.
• Dialectos: Patrones de bajo nivel específicos para un lenguaje de programación o entorno concreto.

Además, también es importante reseñar el concepto de “antipatrón de diseño”, que con forma semejante a la de un patrón, intenta prevenir contra errores comunes de diseño en el software. La idea de los antipatrones es dar a conocer los problemas que acarrean ciertos diseños muy frecuentes, para intentar evitar que diferentes sistemas acaben una y otra vez en el mismo callejón sin salida por haber cometido los mismos errores.

Además de los patrones ya vistos actualmente existen otros patrones como el siguiente:

• Interacción: Son patrones que nos permiten el diseño de interfaces web.

Estructuras o plantillas de patrones

Para describir un patrón se usan plantillas más o menos estandarizadas, de forma que se expresen uniformemente y puedan constituir efectivamente un medio de comunicación uniforme entre diseñadores. Varios autores eminentes en esta área han propuesto plantillas ligeramente distintas, si bien la mayoría definen los mismos conceptos básicos.

La plantilla más común es la utilizada precisamente por el GoF y consta de los siguientes apartados:

• Nombre del patrón: nombre estándar del patrón por el cual será reconocido en la comunidad (normalmente se expresan en inglés).
• Clasificación del patrón: creacional, estructural o de comportamiento.
• Intención: ¿Qué problema pretende resolver el patrón? También conocido como: Otros nombres de uso común para el patrón.
• Motivación: Escenario de ejemplo para la aplicación del patrón.
• Aplicabilidad: Usos comunes y criterios de aplicabilidad del patrón.
• Estructura: Diagramas de clases oportunos para describir las clases que intervienen en el patrón.
• Participantes: Enumeración y descripción de las entidades abstractas (y sus roles) que participan en el patrón.
• Colaboraciones: Explicación de las interrelaciones que se dan entre los participantes.
• Consecuencias: Consecuencias positivas y negativas en el diseño derivadas de la aplicación del patrón.
• Implementación: Técnicas o comentarios oportunos de cara a la implementación del patrón.
• Código de ejemplo: Código fuente ejemplo de implementación del patrón.
• Usos conocidos: Ejemplos de sistemas reales que usan el patrón.
• Patrones relacionados: Referencias cruzadas con otros patrones.

¿Por qué usar patrones de diseño?

Si queremos desarrollar aplicaciones robustas y fáciles de mantener, debemos cumplir ciertas reglas, estas reglas de diseño son recomendables (muy recomendables), no son obligatorias. Siempre podemos decidir no aplicarlas, no es obligatorio utilizar los patrones, solo es aconsejable en el caso de tener el mismo problema o similar que soluciona el patrón, siempre teniendo en cuenta que en un caso particular puede no ser aplicable. "Abusar o forzar el uso de los patrones puede ser un error".

Los patrones de diseño nos ayudan a cumplir muchos de estos principios o reglas de diseño. Programación SOLID, control de cohesión y acoplamiento o reutilización de código son algunos de los beneficios que podemos conseguir al utilizar patrones.

Objetivos de los patrones de diseño:

• Proporcionar catálogos de elementos reusables en el diseño de sistemas software.
• Evitar la reiteración en la búsqueda de soluciones a problemas ya conocidos y solucionados anteriormente.
• Formalizar un vocabulario común entre diseñadores.
• Estandarizar el modo en que se realiza el diseño.
• Facilitar el aprendizaje de las nuevas generaciones de diseñadores condensando conocimiento ya existente.

Ventajas

Proporcionan una estructura conocida por todos los programadores, de manera que la forma de trabajar no resulte distinta entre los mismos. Así la incorporación de un nuevo programador, no requerirá conocimiento de lo realizado anteriormente por otro. Permiten tener una estructura de código común a todos los proyectos que implemente una funcionalidad genérica. La utilización de patrones de diseño, permite ahorrar grandes cantidades de tiempo en la construcción de software.

El software construido es más fácil de comprender, mantener y extender. Existen versiones ya implementadas de esta funcionalidad común (frameworks) como Struts o Velocity y que nos permiten centrarnos en desarrollar sólo la funcionalidad específica requerida por cada aplicación. Además, da mejor imagen de profesionalidad y calidad.

Desventajas:

Los proyectos reales raramente siguen el flujo secuencial que propone el modelo, siempre hay iteraciones y se crean problemas en la aplicación del paradigma.

Normalmente, es difícil para el cliente establecer explícitamente al principio  todos los requisitos. El ciclo de vida clásico lo requiere y tiene dificultades en acomodar posibles incertidumbres que pueden existir al comienzo de muchos productos.

El cliente debe tener paciencia. Hasta llegar a las etapas finales del proyecto, no estará disponible una versión operativa del programa. Un error importante no detectado hasta que el programa esté funcionando puede ser desastroso.

Arquitecturas de Software

Descomposición modular

Introducción

La arquitectura del software, en su forma más sencilla, es la estructura de organización de los componentes de un programa (módulos), la forma en la que éstos interactúan y la estructura de datos que utilizan. Sin embargo, en un sentido más amplio, los componentes se generalizan para que representen los elementos de un sistema grande y sus interacciones.

Una meta del diseño del software es obtener una aproximación arquitectónica de un sistema.

Ésta sirve como estructura a partir de la cual se realizan las actividades de diseño más detalladas. Un conjunto de patrones arquitectónicos permite que el ingeniero de software resuelva problemas de diseño comunes.

Modularidad

La modularidad es la manifestación más común de la división de problemas. El software se divide en componentes con nombres distintos y abordables por separado, en ocasiones llamados módulos, que se integran para satisfacer los requerimientos del problema.

El software monolítico (un programa grande compuesto de un solo módulo) no es fácil de entender para un ingeniero de software. El número de trayectorias de control, alcance de referencia, número de variables y complejidad general haría que comprenderlo fuera casi imposible. En función de las circunstancias, el diseño debe descomponerse en muchos módulos con la esperanza de que sea más fácil entenderlos y, en consecuencia, reducir el costo requerido para elaborar el software.

Debe hacerse un diseño (y el programa resultante) con módulos, de manera que el desarrollo pueda planearse con más facilidad, que sea posible definir y desarrollar los incrementos del software, que los cambios se realicen con más facilidad, que las pruebas y la depuración se efectúen con mayor eficiencia y que el mantenimiento a largo plazo se lleve a cabo sin efectos colaterales de importancia.

Descomposición Modular

Es el proceso que consiste en descomponer el problema a resolver en módulos o tareas más simples. Cada tarea representa una actividad completa y se codifica de manera independiente. Facilita el diseño descendente del problema, centrándonos cada vez en la resolución de subproblemas de magnitud inferior.

A la resolución de cada uno de estos subproblemas de complejidad inferior se denomina refinamiento por pasos. Los módulos pueden ser planificados, codificados, comprobados y depurados independientemente, y a continuación se combinan uno a uno con otros módulos.

     Pasos o Etapas:

1. 1.  Identificar los módulos.
   2.  Describir cada módulo.
   3.  Describir las relaciones entre los módulos.

 

Estrategias para la descomposición modular:

Después de elegir la organización del sistema en su totalidad, debemos decir como descomponer los    subsistemas en módulos.

No   existe   una   distinción   rígida   entre   la   organización   del   sistema   y   la descomposición  modular. Sin embargo, los componentes de los módulos son normalmente   más   pequeños, lo   que   permite   usar   estilos   alternativos   de descomposición.

Los módulos se descomponen normalmente de varios componentes del sistema simples. Hay dos estrategias para descomponer un subsistema en módulos:

• Descomposición orientada a objetos: Donde se descompone un sistema en un conjunto de objetos que se comunican.
• Descomposición orientada a flujos de funciones: Donde se descompone el sistema en módulos funcionales que aceptan datos y los transforman en datos de salida.

Características:

>> Ocultamiento de la información

El principio del ocultamiento de información sugiere que los módulos se “caractericen por decisiones de diseño que se oculten (cada una) de las demás”. En otras palabras, deben especificarse y diseñarse módulos, de forma que la información (algoritmos y datos) contenida en un módulo sea inaccesible para los que no necesiten de ella.

El ocultamiento implica que la modularidad efectiva se logra definiendo un conjunto de módulos independientes que intercambien sólo aquella información necesaria para lograr la función del software. La abstracción ayuda a definir las entidades de procedimiento (o informativas) que constituyen el software. El ocultamiento define y hace cumplir las restricciones de acceso tanto a los detalles de procedimiento como a cualquier estructura de datos local que utilice el módulo.

El uso del ocultamiento de información como criterio de diseño para los sistemas modulares proporciona los máximos beneficios cuando se requiere hacer modificaciones durante las pruebas, y más adelante, al dar mantenimiento al software. Debido a que la mayoría de los datos y detalles del procedimiento quedan ocultos para otras partes del software, es menos probable que los errores inadvertidos introducidos durante la modificación se propaguen a distintos sitios dentro del software.

>> Independencia funcional

La independencia funcional se logra desarrollando módulos con funciones “miopes” que tengan “aversión” a la interacción excesiva con otros módulos. Dicho de otro modo, debe diseñarse software de manera que cada módulo resuelva un subconjunto específico de requerimientos y tenga una interfaz sencilla cuando se vea desde otras partes de la estructura del programa.

Es lógico preguntar por qué es importante la independencia.

El software con modularidad eficaz, es decir, con módulos independientes, es más fácil de desarrollar porque su función se subdivide y las interfaces se simplifican (cuando el desarrollo es efectuado por un equipo hay que considerar las ramificaciones).

Los módulos independientes son más fáciles de mantener (y probar) debido a que los efectos secundarios causados por el diseño o por la modificación del código son limitados, se reduce la propagación del error y es posible obtener módulos reutilizables. En resumen, la independencia funcional es una clave para el buen diseño y éste es la clave de la calidad del software.

La independencia se evalúa con el uso de dos criterios cualitativos: la cohesión y el acoplamiento.

~ Cohesión: Es una extensión natural del concepto de ocultamiento de información. Un módulo cohesivo ejecuta una sola tarea, por lo que requiere interactuar poco con otros componentes en otras partes del programa. En pocas palabras, un módulo cohesivo debe (idealmente) hacer sólo una cosa.

Aunque siempre debe tratarse de lograr mucha cohesión (por ejemplo, una sola tarea), con frecuencia es necesario y aconsejable hacer que un componente de software realice funciones múltiples. Sin embargo, para lograr un buen diseño hay que evitar los componentes “esquizofrénicos” (módulos que llevan a cabo funciones no relacionadas).

~ Acoplamiento: Es una indicación de la interconexión entre módulos en una estructura de software, y depende de la complejidad de la interfaz entre módulos, del grado en el que se entra o se hace referencia a un módulo y de qué datos pasan a través de la interfaz. En el diseño de software, debe buscarse el mínimo acoplamiento posible.

El grado de   acoplamiento mide la interrelación entre dos módulos, según el tipo de conexión y la complejidad de las interfaces:

        Fuerte

• • Por contenido, cuando desde un módulo se puede cambiar datos locales de otro.
  • Común, se emplea una zona común de datos a la que tienen acceso varios módulos.

      Moderado

De control, la zona común es un dispositivo externo al que están ligados los módulos, esto implica que un cambio en el formato de datos los afecta a todos.

      Débil

• • De datos, viene dado por los datos que intercambian los módulos. Es el mejor.
  • Sin acoplamiento directo, es el acoplamiento que no existe.

~ Comprensibilidad: Para facilitar los cambios, el mantenimiento y la reutilización de módulos es necesario que cada uno sea comprensible de forma aislada. 

Para ello es bueno que posea independencia funcional, pero además es deseable:

• Identificación, el nombre debe ser adecuado y descriptivo.
• Documentación, debe aclarar todos los detalles de diseño e implementación que no queden de manifiesto en el propio código.

~ Adaptabilidad: La adaptación de un sistema resulta más difícil cuando no hay independencia funcional, es decir, con alto acoplamiento y baja cohesión, y cuando el diseño es poco comprensible.

Otros factores para facilitar la adaptabilidad:

ð  Previsión: Es necesario prever que aspectos del sistema pueden ser susceptibles de cambios en el futuro, y poner estos elementos en módulos independientes, de manera que su modificación afecte al menor número de módulos posibles.

ð  Accesibilidad: Debe resultar sencillo el acceso a los documentos de especificación, diseño, e implementación para obtener un conocimiento suficiente del sistema antes de proceder a su adaptación.

ð  Consistencia: Después de cualquier adaptación se debe mantener la consistencia del sistema, incluidos los documentos afectados.

Proceso Unificado

La metodología de Proceso Unificado (UP) es un método iterativo de diseño de software que describe cómo desarrollar software de forma eficaz, utilizando técnicas probadas en la industria.

El Proceso Unificado de Desarrollo de Software o simplemente Proceso Unificado es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura, enfocado en el riesgo, y por ser iterativo e incremental. El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos específicos.

El nombre Proceso Unificado se usa para describir el proceso genérico que incluye aquellos elementos que son comunes a la mayoría de los refinamientos existentes.

Es una metodología orientada a conducir el proceso de desarrollo de software en sus aspectos técnicos; los flujos y productos de trabajo de UP no incluyen la administración del proyecto. UP es una versión libre y abierta del modelo propuesto por Jacobson, Booch y Rumbaugh.

UP divide el trabajo de desarrollo de software en cuatro fases: inicio, elaboración, construcción y transición, las cuales se describen a continuación.

Fase de Inicio en UP

En esta fase corresponde definir el negocio. Es la etapa donde se define la factibilidad del proyecto a realizar, se representa el modelo de negocio, visión y metas del proyecto, se identifican actores, conceptos de dominio y deseos de usuario. Adicionalmente se complementa con la definición de la arquitectura preliminar, y estimaciones (imprecisas, preliminares) de plazos y costos. También se define la viabilidad del proyecto.

Fase de Elaboración en UP

En la fase de elaboración se obtiene la visión refinada del proyecto a realizar, la implementación iterativa del núcleo central de la aplicación, la resolución de los riesgos más altos, la identificación de nuevos requisitos y nuevos alcances, y estimaciones más ajustadas. A esta altura existe la posibilidad de detener el proyecto por complejidad técnica.

Fase de Construcción en UP

La fase de construcción es la implementación iterativa del resto de los requisitos de menor riesgo y elementos más sencillos. Es la evolución hasta convertirse en un producto listo, incluyendo todos los requisitos (100%), para entregarse al Cliente. Al final de esta fase el sistema contiene todos los casos de uso que el cliente y la dirección del proyecto han acordado. La mayoría de los casos de uso que no se desarrollaron en la fase anterior se desarrollan en iteraciones, en grupos de requisitos o casos de uso durante esta fase.

Fase de Transición en UP

Es el periodo donde el producto es completamente entregado al cliente para ser testeado y desplegado (instalado).

Algunas características a enunciar según UP son:

• ·         Los proyectos se organización en una serie de mini-proyectos cortos de duración (2 a 6 semanas), llamados iteraciones, que incluyen un conjunto reducido de requerimientos a implementar.
• ·     El resultado de cada iteración es un sistema que puede ser probado, integrado y ejecutado. La salida es un subconjunto con calidad de producción final.
• ·     Rápida retroalimentación y asimilación de los cambios, posibilitada por el tamaño limitado de lo realizado en cada iteración.
• ·         Se abordan, resuelven y prueban primeramente las decisiones de diseño críticas o de alto riesgo.