Blogs de MontevideoLibre

Es el desarrollo y aplicacion de estandares y procedimientos para gestionar un sistema software evolutivo.  Porque se necesita gestionar?

• es facil perder la pista de los cambios que se han incorporado dentro de cada version
• pueden existir varias versioens en desarrollo y en uso al mismo tiempo
• se podria hacer un esfuerzo inutil modificando la version erronea de un sistema, entregar una version incorrecta a los clientes o perder la pista de donde ha sido guardado el codigo fuente

Los procedimientos de gestion de configuraciones definen:

• como registrar y procesar los cambios propuestos al sistema
• como relacionar estos con los componentes del sistema
• los metodos utilizados para identificar las diversas versiones del sistema

Las herramientas de gestion de configuraciones se utilizan para:

• almacenar las versiones de los componentes del sistema
• construir sistemas a partir de estos componentes

• llevar el registro de entregas de las versiones del sistema a los clientes

Planificacion

1. Definicion de lo que se debe gestionar  (fuentes, ejecutables, documentos, datos, etc) y el esquema formal para identificar estas identidades (nombre, version, tipo, proyecto, informacion del cambio o la version).
2. Un enunciado de quien toma la responsabilidad de los procedimientos y quien envia las enttidades controladas al equipo de gestion de configuraciones.
3. Las politicas de gestion de configuraciones utilizadas para gestionar el control de los cambios y las versoines
4. Descripcion de las herramientas a utilizar y el proceso a aplicar cuando se utilizan.
5. Definicion de la baase de datos que se utilizara para registrar la informacion de la configuracion.

Fuente: Ingenieria del Software de Ian Sommerville

Interesante proyecto, Mesh Potato es basicamente para hacer llamadas telefonicas sobre una red Mesh : http://www.villagetelco.org/

Donde estan?

cuanto mas complejo es un componente o sistema, mas caro es de mantener

Leyes de Lehman sobre evolucion de los sistemas.

• Cambio Continuado: un programa usado en un entorno real necesariamente debe cambiar o se volvera progresivamente menos util en ese entorno.
• Complejidad creciente: a medida que un programa en evolucion cambia, su estructura tiende a ser cada vez mas compleja.
• Evolucion prolognada del programa:  sugiere que los grandes sistemas tienen su propia dinamica que se establece en una etapa temprana en el proceso de desarrollo. Esta determina las tendencias generales del proceso de mantenimiento del sistema y limita el numero de posibles cambios en el sistema.
• Estabilidad organizacional: la mayoria de los proyectos de programacion grandes trabajan en lo que se denomina un estado saturado. Un cambio en los recursos o en eel personal tiene efectos imperceptibles en la evolucion a largo plazo del sistema.
• Conservacion de la familiaridad: durante el tiempo de vida de un sistema, el cambio incremental en cada entrega es aproximadamente constante.

• Crecimiento continuado: la funcionalidad ofrecida por los sistemas tiene que crecer continuamente paraa mantener la satisfaccion de los usuarios.
• Decremento de la calidad: la calidad de los sistemas comenzara a disminuir a menos que dichos sistemas se adapten a los cambios en su entorno de funcionamiento.
• Realimentacion del sistema: los procesos de evolucion incorporan sistemas de realimentacion multiagente y multibucle y estos deben ser tratados como sistemas de realimentacion para lograr una mejora significativa del producto.

Mantenimiento del software

Es el proceso general de cambiar un sistema despues de que este ha sido entregado.

1. Mantenimiento corrrectivo  o para reparar defectos del software.
2. Mantenimiento adaptativo o para adaptar el software a diferentes entornos operativos.
3. Mantenimiento perfectivo o para aniadir o modificar las funcionalidades del sistema.

Los costos claves que distinguen el desarrollo del mantenimiento y conducen a costos de mantenimiento mas elevados, son:

1. Estabilidad del equipo: usualmente el equipo de desarrollo se disuelve luego de entregar el programa y un nuevo equipo toma el mantenimiento.
2. Responsabilidad contractual: usualmente los desarrolladores  no toman decisiones para contemplar el mantenimiento.
3. Habilidades del personal: se relega el mantenimiento a principiantes y gente no familiarizada con el dominio de la aplicacion.
4. Edad y estructura del programa: Aveces no se desarrollan las aplicaciones con tecnicas de ingenieria de software, no bien estructurados y a medida que pasa el tiempo la estructura tiende a degradarse con los cambios.

Predeccion del mantenimiento

Se deberia intentar predecir que cambios del sistema son probables y que partes del sistema son probablemente los mas dificiles de mantener. Tambien se deberia predecir los costos de mantenimiento durante un periodo de tiempo determinado. Estas predicciones dependen de:

• la aceptacion o no de un cambio en el sistema depende de la mantenibilidad de los componentes del sistema afectados por el cambio.
• la implementacion de los cambios del sistema tiende a degradarlo y por lo tanto reduce su mantenibilidad.
• los costos del mantenimiento dependen del numero de cambio y los costos de la implementacion dependen de la mantenibilidad de los componentes del sistema.

La prediccion del numero de peticiones de cambios del sistema requiere entender la relacion entre el sistema y su entorno. Y para evaluar las relaciones entre un sistema y su entorno hay que tener en cuenta:

• el numero y la complejidad de las interfaces del sistema
• el numero de requerimientos del sistema intrinsecamente volatiles
• los procesos de  negocios en los que se utiliza el sistema

Fuente: Ingenieria del Software de Ian Sommerville

En un paréntesis entre los objetivos de certificación que me propuse para este año le tocó el turno a Juniper. Aprobé el examen JN0-521 que me habilita a la certificación JNCIA-FWV. El sabor que me queda luego de estos últimos exámenes es agridulce y quizá en algún momento escriba algo sobre la efectividad de los [...]

Hay un release (inestable) de Google que nos permite correr de forma nativa Google Chrome en linux debian o ubuntu y que viene empaquetado en formato deb listo para usar

Es el proceso de analiss y pruebas para asegurar que el programa que se esta desarrollando satisface su especificacion y entrega de la funcionalidad esperada por las personas que pagan por el software.

Validacion: Estamos construyendo el producto correcto?
Verificacion: Estamos construyendo el producto correctamente?

Dentro del proceso de V&V existen dos aproximaciones complementarias para el analisis y comprobacion de  los sistemas:

1. Inspecciones de Software : analizan y comprueban las representaciones del sistema tales como el documento de requerimientos, los diagramas de disenioo y el codigo fuente del programa. Tecnica statica de V&V.
2. Pruebas del Software: implica ejecutaar una implementacion del software con datos de prueba. Tecnica dinamica de V&V.

“las pruebas solo pueden demostrar la presencia de errores, no su ausencia”
Dijikstra

Objetivos

• Demostrar a l@s desarrollador@s y al cliente que el software satisface sus requerimientos.
• Descubrir defectos en el software en que el comportamiento de este es incorrecto, no deseable o no cumple su especificacion.

La mayoria de los tratamientos de pruebas comienzan con las pruebas de componentes y a continuacion se realizan las pruebas del sistema.

Pruebas del Sistema

Implican integrar dos o mas componentes que implementan funciones del sistema y a continuacion se prueba este sistema integrado. Existen dos fases:

1. Pruebas de integracion - se tiene acceso al codigo fuente y se intentan buscar defectos del sistema. cuando se encuentra uno se intenta solucionarlo.
2. Pruebas de entregas - se prueba el sistema como si fuera una caja  negra y como si fuera lo que se va a entregar al cliente.

Pruebas de integracion

• Integracion descendente: cuando se crea un esqueleto y se le va agregando los componentes.
• Integracion ascendente: se integran los componentes que proporcionan servicios comunes.

Pruebas de entregas o pruebas funcionales

Es el proceso de probar una entrega del sistema que sera distribuida a los clientes. Hay guias (Whittaker, 2002) que pueden incrementar la probabilidad que las pruebas de defectos tengan exito. Por ejemplo, elegir entradas que fuerzen a que el sistema genere todos los mensajes de error.

Pruebas de rendimiento o estress

Una vez que el sistema se ha integrado, se puede probar rendimiento y fiabilidad. Implica planificar una serie de pruebas en las que la carga se va incrementando regularmente hasta que el rendimiento del sistema se hace inaceptable.

Pruebas de Componentes o Pruebas de Unidad

Es el proceso de probar los componentes individuales en el sistema. El objetivo es encontrar defectos en los componentes. Usualmente l@s encargad@s de las pruebas de componentes son l@s desarrollador@s de las mismas.
Tipos de componentes a probar

1. Funciones individualles o metodos dentro de un objeto
2. Clases de objetos que tienen varios atributos y metodos
3. Componentes compuestos formados por diferentes objetos o funciones

Pruebas de Interfaces

Muchos componentes en un sistema no son simples funciones u ojbetos, sino que componentes compuestos formados por varios objetos que interactuan. Las pruebas sobre estos componentes se hacen a traves de sus interfaces definidas, probando que esta se comporta como fue especificado.

Diseno de Casos de Pruebas

El objetivo del proceso de disenio de casos de prueba (entradas y salidas esperadas) es crear un conjunto de casos de prueba que sean efectivos descuriendo defectos en los programas y muestren que el sistema satisface sus requerimientos.
Para diseniar un caso de prueba, se selecciona una caracteristica del sistema o componente que se esta probando. Se selecciona un conjunto de entradas qeu ejecutan dicha caracteriztica, documenta las salidas esperadas o rangos de salida.

Pruebas basadas en requerimientos

Los casos de prueba se disenian para probar los requerimientos del sistema. Las pruebas basadas en requerimientos son pruebas de validacion en lugar de pruebas de defectos.

Pruebas de particiones

Los datos de entrada y resultados de salida se pueden agrupar en varias clases diferetnes qeu tienen caracteristicas comunes, estas clases se denominan particiones de equivalencia o dominio. Se espera que el programa se comporte igual para todos los miembros de una clase. Se disenian los casos de pruebas para que se usen entradas de todas las particiones y se generen salidas de todas las particiones.

Pruebas estructurales o de caja blanca

Se crean casos de prueba para que se ejecute cada linea de codigo una vez.

Pruebas de Caminos

Son una estrategia de pruebas estructurales cuyo objetivo es probar cada camino de ejecucion independiente en un componente o programa.

Fuente: “Ingenieria de Software” de Ian Sommerville