MANTENIMIENTO DEL SOFTWARE

sábado, 2 de julio de 2011


ACTIVIDADES REALIZADAS

En esta sección el grupo de trabajo conformado por Pablo Barrera, Angela García y Leydi Cortés presentó en una conferencia y un panel sobre Manteniemiento del Software


ESTRATEGIAS UTILIZADAS

 Presentación de los siguientes contenidos académicos:

RALLY DEL CONOCIMIENTO

INTRODUCCIÓN
Aunque es una actividad que se puede aprovechar para reforzar algunos contenidos vistos en clase, la verdadera finalidad de esta actividad es la socialización y el trabajo en equipo.
Es una actividad tan variable que puede adaptarse a cualquier grado y situación determinada de cada grupo.

ORGANIZACIÓN
Esta actividad es forzosamente para realizar en equipo, y lo más recomendable es que, en caso de existir varias personas con Necesidades Especiales o con Problemas de Integración o socialización, se distribuyan en diferentes equipos, al igual que las personas más sobresalientes y los líderes sociales, con el fin de que los equipos queden lo más nivelados posibles.

MATERIAL
El material a emplear depende de las actividades que se vayan a realizar, lo que si se mantiene constante es una hoja para cada equipo, de preferencia de color diferente, donde estarán escritas las instrucciones a seguir por cada equipo.

PROCEDIMIENTO
Tomando como ejemplo un grupo de 30 alumnos, se forman 5 equipos de 6 niños cada uno, y es necesario que se realicen como mínimo 5 actividades diferentes dirigidas por un maestro cada una, aunque lo más recomendable es tener una actividad más para evitar que se junten 2 equipos en una sola área (se necesitarían 5 ó 6 maestros para dirigir las actividades).
Se puede asignar un color a cada equipo, o bien, dar la oportunidad de escoger un nombre, por ejemplo de algún animal para representarse ellos mismos.
Se les explican las instrucciones a los niños antes de que salgan a jugar:
  1. Es una actividad en equipo, así que todos tienen qué participar, nadie puede quedarse fuera; si el equipo no está completo, no pueden realizar las actividades hasta que se junten.
  2. Para pasar a la siguiente actividad, la persona que esté dirigiendo la actividad actual debe firmar la hoja para marcar que ya la terminaron.
  3. Una vez terminadas todas las actividades, deben entregar la hoja a determinado maestro, y conforme al orden en que se entregue, se designa qué equipo ganó, cuál fue segundo lugar, y así.
Una vez que hayan terminado todos de hacer los trabajos y entregar las hojas, los niños deben regresar a su aula para conocer los resultados.

Antes de hacerlo, es conveniente primero rescatar la importancia de haber trabajado en equipo y la participación de cada uno.
Se pueden hacer preguntas también sobre qué actividad fue la más difícil, cuál se les hizo más fácil, cuál les gustó más; y aquí se le puede dar preferencia a la participación de los alumnos de interés para el docente.
Una sugerencia que he manejado al realizar esta actividad es colocar letras en lugar de números, por ejemplo las cinco vocales, y utilizar las vocales como letras iníciales de palabras como A de Aplicado, E de Estudioso o I de Inteligente. Aunque no hay que olvidar que la letra también representa un lugar y que existe un equipo ganador.


MANTENIMIENTO DEL SOFTWARE
El mantenimiento de software de software es una de las actividades más comunes en la ingeniería de software, es el proceso de mejora y optimización del software después de su entrega al usuario final es decir revisión del programa, así como también corrección y prevención de los defectos.
El mantenimiento de software es también una de las fases en el ciclo de vida de desarrollo de sistemas, que se aplica al desarrollo de software. La fase de mantenimiento es la fase que viene después del despliegue (implementación) del software en el campo.
La fase de mantenimiento del producto se puede difundir por los involucrados del software e involucran cambios al software en orden de corregir defectos y dependencias encontradas durante su uso tanto como la adición de nueva funcionalidad para mejorar la usabilidad y aplicabilidad del software.
El mantenimiento del software involucra varias técnicas específicas. Una técnica es el rebanamiento  estático, la cual es usada para identificar todo el código de programa que puede modificar alguna variable. Es generalmente útil en la refabricación del código del programa y fue específicamente útil en asegurar conformidad para los distintos problemas del software.
La fase de mantenimiento de software es una parte explícita del modelo en cascada del proceso de desarrollo de software el cual fue desarrollado durante el movimiento de programación estructurada en computadores. El otro gran modelo, el Desarrollo en espiral desarrollado durante el movimiento de ingeniería de software orientada a objeto no hace una mención explícita de la fase de mantenimiento. Sin embargo, esta actividad es notable, considerando el hecho de que dos tercios del coste del tiempo de vida de un sistema de software involucran mantenimiento.
En un ambiente formal de desarrollo de software, la organización o equipo de desarrollo tendrán algún mecanismo para documentar y rastrear defectos y deficiencias. El Software tan igual como la mayoría de otros productos, es típicamente lanzado con un conjunto conocido de defectos y deficiencias. El software es lanzado con esos defectos conocidos porque la organización de desarrollo en las utilidades y el valor del software en un determinado nivel de calidad compensan el impacto de los defectos y deficiencias conocidas.
Las deficiencias conocidas son normalmente documentadas en una carta de consideraciones operacionales o notas de lanzamiento es así que los usuarios del software serán capaces de trabajar evitando las deficiencias conocidas y conocerán cuándo el uso del software sería inadecuado para tareas específicas.
Con el lanzamiento del software, otros defectos y deficiencias no documentados serán descubiertas por los usuarios del software. Tan pronto como estos defectos sean reportados a la organización de desarrollo, serán ingresados en el sistema de rastreo de defectos.
Las personas involucradas en la fase de mantenimiento de software esperan trabajar en estos defectos conocidos, ubicarlos y preparar un nuevo lanzamiento del software, conocido como un lanzamiento de mantenimiento, el cual resolverá los temas pendientes.

TIPOS DE MANTENIMIENTO
A continuación se señalan los tipos de mantenimientos existentes, definidos tal y como se especifican para la metodología de MÉTRICA:
Perfectivo: son las acciones llevadas a cabo para mejorar la calidad interna de los sistemas en cualquiera de sus aspectos: reestructuración del código, definición más clara del sistema y optimización del rendimiento y eficiencia.
Evolutivo: son las incorporaciones, modificaciones y eliminaciones necesarias en un producto software para cubrir la expansión o cambio en las necesidades del usuario.
Adaptativo: son las modificaciones que afectan a los entornos en los que el sistema opera, por ejemplo, cambios de configuración del hardware, software de base, gestores de base de datos, comunicaciones, etc.
Correctivo: son aquellos cambios precisos para corregir errores del producto software.
Cabe señalar que, de estos 4 tipos de mantenimiento, solamente el correctivo y el evolutivo entran en el ámbito de MÉTRICA, ya que los otros dos requieren actividades y perfiles distintos a los del proceso de desarrollo.
 
REINGENIERÍA DEL SOFTWARE
modificación de un producto software, o de ciertos componentes, usando para el análisis del sistema existente técnicas de Ingeniería Inversa y, para la etapa de reconstrucción, herramientas de Ingeniería Directa, de tal manera que se oriente este cambio hacia mayores niveles de facilidad en cuanto a mantenimiento, reutilización, comprensión o evaluación.
Cuando una aplicación lleva siendo usada años, es fácil que esta aplicación se vuelva inestable como fruto de las múltiples correcciones, adaptaciones o mejoras que han podido surgir a lo largo del tiempo. Esto deriva en que cada vez que se pretende realizar un cambio se producen efectos colaterales inesperados y hasta de gravedad, por lo que se hace necesario, si se prevé que la aplicación seguirá siendo de utilidad, aplicar reingeniería a la misma.
Entre los beneficios de aplicar reingeniería a un producto existente se puede incluir:
·         Pueden reducir los riegos evolutivos de una organización.
·         Puede ayudar a las organizaciones a recuperar sus inversiones en software.
·         Puede hacer el software más fácilmente modificable
·         Amplía las capacidades de las herramientas CASE
·         Es un catalizador para la automatización del mantenimiento del software
·         Puede actuar como catalizador para la aplicación de técnicas de inteligencia artificial para resolver problemas de reingeniería
La reingeniería del software involucra diferentes actividades como son:

·         análisis de inventarios
·         reestructuración de documentos
·         ingeniería inversa
·         reestructuración de programas y datos
·         ingeniería directa

Con la finalidad de crear versiones de programas ya existentes que sean de mejor calidad y los mismos tengan una mayor facilidad de mantenimiento.




LA IMPORTANCIA DE LA REINGENIERÍA DEL SOFTWARE

·         Puede reducir los riesgos evolutivos de una organización
·         Puede ayudar a las organizaciones a recuperar sus inversiones en software
·         Puede hacer el software más fácilmente modificable
·         Amplía las capacidades de las herramientas CASE
·         Es un catalizador para la automatización del mantenimiento del software
·         Puede actuar como catalizador para la aplicación de técnicas de inteligencia artificial (IA) para resolver problemas de reingeniería

INGENIERIA DIRECTA
«Corresponde al desarrollo de software tradicional»
REESTRUCTURACION
«Es la transformación de una forma de representación a otra en el mismo nivel de abstracción relativo, mientras se mantenga el comportamiento externo del sistema (funcionalidad y semántica)»
«Es la modificación del software para hacerlo más fácil de entender y cambiar»


INGENIERIA INVERSA
«Es el proceso de análisis de un sistema para identificar sus componentes e interrelaciones y crear representaciones del sistema en otra forma o a un nivel más alto de abstracción»

AREAS EN LA INGENIERÍA INVERSA
Redocumentación:
 «Es la creación o revisión de una representación equivalente semánticamente dentro del mismo nivel de abstracción relativo»
Recuperación de diseño:
 «Es un subconjunto de la ingeniería inversa, en el cual, aparte de las observaciones del sistema, se añaden conocimientos sobre su dominio de aplicación, información externa, y procesos deductivos con el objeto de identificar abstracciones significativas a un mayor nivel»
REDISEÑO
«Consiste en consolidar y modificar los modelos obtenidos, añadiendo nuevas funciones  requeridas por los usuarios»
REINGENIERÍA DEL SOFTWARE
«Es el examen y alteración de un sistema para reconstruirlo de una nueva forma y la subsiguiente implementación de esta nueva forma»


OTRAS TECNOLOGIAS
La remodularización. Consiste en cambiar la estructura modular de un sistema de forma que se obtenga una nueva estructura siguiendo los principios del diseño estructurado.
Análisis de la facilidad de mantenimiento. Normalmente la mayor parte del mantenimiento se centra relativamente en unos pocos módulos del sistema Visualización. El proceso más antiguo para la comprensión del software.
Análisis y mediciones. Son importantes tecnologías que estudian ciertas propiedades de los programas.

PROCESO DE REINGENIERIA DEL SOFTWARE
·         Mejorar su facilidad de mantenimiento futuro
·         Facilitar su migración, que el proceso de traducir un programa de un lenguaje a otro, moverlo  de un entorno operativo a otro o actualizar su tecnología
·         Aumentar su esperanza de vida
·         Capturar sus componentes en un repositorio que puede ser gestionado por herramientas CASE
·         Incrementar la productividad de mantenimiento
ANALISIS DE CÓDIGO FUENTE

Análisis estático
Consiste en una evaluación que estudia la estructura del código sin ejercitar o ejecutar dicho código.

·         Auditoría de código: revisión del código para identificar errores de sintaxis y para comprobar el seguimiento de los estándares de codificación.
·         Métricas de producto: permiten obtener un conjunto de métricas sobre distintos atributos del software
·         Análisis de flujo: identifica el flujo de control y de datos para determinar dónde están los errores





GESTION DE CONFIGURACION DEL SOFTWARE

ACTIVIDADES REALIZADAS

En esta sección el grupo de trabajo conformado por Martha Delgado, Diego Contreras y Diego Sandoval en  una charla sobre Gestión de Cambios o Gestión de Configuración del Software.


ESTRATEGIAS UTILIZADAS

 Presentación de los siguientes contenidos académicos: 
 
La gestión de la configuración del software es uno de los procesos clave para toda organización dedicada a la Ingeniería del Software, ya que posibilita una mejor organización del desarrollo y mantenimiento, producto, facilitando el resto de procesos de producción.
Durante el proceso de construcción de un software, los cambios son inevitables. Los cambios provocan confusión e incertidumbre, sobre todo cuando no se han analizado o pronosticado correctamente. Es importante considerar ciertas modificaciones que pueden ocurrirle al software dentro de todo el proceso de ingeniería. 

“El arte de coordinar el desarrollo de software para minimizar…la confusión, se denomina gestión de la configuración. La gestión es el arte de identificar, organizar y controlar las modificaciones que sufre el software…la meta es maximizar la productividad minimizando errores.”   
                             Babich. 

1. GESTION DE LA CONFIGURACION DEL SOFTWARE (GCS)
Los cambios dentro del desarrollo del software pueden ocurrir en cualquier momento por lo tanto debemos estar preparados, las actividades de CGS sirven para:
  • Identificar el cambio de nuestro software.
  • Controlar ese cambio.
  • Garantizar que el cambio quede bien implantado.
  • Informar el cambio.
La gestión de configuración del software no es un mantenimiento del software, el mantenimiento es la etapa final de la ingeniería hasta que se retire el producto del equipo, la CGS es un conjunto de actividades de seguimiento y control que comienzan cuando se inicia el proyecto de desarrollo del software y termina sólo una vez que el software queda fuera de circulación.
Desgraciadamente, en el proceso de ingeniería del software existe una variable importantísima que entra en juego, el cambio.
La primera Ley de la ingeniería de sistemas establece: “Sin importar en que momento del ciclo de vida del sistema nos encontremos, el sistema cambiará y el deseo de cambiarlo persistirá a lo largo de todo el ciclo de vida”.
Entonces nos hacemos diferentes preguntas: ¿Por qué cambiar el sistema? ¿Que produce los en el sistema cambios? La respuesta a estas interrogantes se puede encontrar en cuatro aspectos fundamentales y a menudo muy tradicionales dentro del desarrollo del software:
  • Nuevos requisitos del negocio o condiciones que dictan los cambios en las condiciones del producto o en las normas comerciales.
  • Nuevas necesidades del los clientes que demandan la modificación de los datos producidos por un sistema basado en computadora.
  • Reorganización y/o reducción del volumen comercial que provoca cambios en las prioridades del proyecto o en la estructura del equipo de ingeniería del software.
  • Restricciones presupuestarias o de planificaciones que provocan una redefinición del sistema o del producto.
La gestión de configuración del software realiza un conjunto de actividades desarrolladas para gestionar y registrar los cambios a lo largo del ciclo de vida del software de computadora.
La GCS es una actividad de garantía de calidad del software que se aplica en todas las fases del proceso de ingeniería del software.
1.1. LINEAS BASE
Una línea base es un concepto de gestión de configuración del software que nos ayuda a controlar los cambios sin impedir seriamente los cambios justificados. La IEEE define una línea base como:
Una especificación o producto que se ha revisado formalmente y sobre los que se ha llegado a un acuerdo, y que de ahí en adelante sirve como base para un desarrollo posterior y que puede cambiarse solamente a través de procedimientos formales de control de cambios.
Una forma de describir la línea base es mediante una analogía. Considere las puertas de la cocina de un gran restaurante. Para evitar colisiones una puerta esta marcada como SALIDA y la otra como ENTRADA las puertas tienen topes que hacen que solo se puedan abrir en la dirección apropiada. Si un camarero recoge un pedido en la cocina lo coloca en una bandeja y luego se da cuenta de que ha cogido un plato equivocado, puede cambiar el plato correcto rápidamente informalmente antes de salir de la cocina.
Sin embargo, si abandona la cocina le da el plato al cliente y luego se le informa de su error, debe seguir el siguiente proceso: 1) Mirar en la orden de pedido si ha cometido algún error. 2) Disculparse insistentemente. 3) Volver a la cocina por la puerta de entrada. 4) Explicar el problema etc.
Una línea base es análoga a un plato mientras pasa por las puertas de la cocina de un restaurante antes de que un elemento de configuración del software se convierta en línea base, el cambio se puede llevar a cabo rápida e informalmente. Sin embargo, una vez que se establece una línea base, pasamos, de forma figurada, por una puerta de un solo sentido. Sé pueden llevar a cabo los cambios, pero se debe aplicar un procedimiento formal para evaluar y verificar cada cambio.
En el contexto de la ingeniería del software definimos una línea base como un punto de referencia en el desarrollo del software y que queda marcado por el envío de uno o más elementos de configuración del software (ECS) y la aprobación de ECS obtenido mediante una revisión técnica formal. Por ejemplo, los elementos de una especificación de diseño se documentan y se revisan. Se encuentran errores y se corrigen cuando todas las partes de las especificaciones se han revisado corregido y aprobado, la especificación de diseño se convierte en línea base. Solo se pueden realizar cambios futuros en la arquitectura del software (contenidos en la especificación del diseño) tras haber sido evaluados y aprobados. Aunque se puedan definir las líneas base con cualquier nivel de detalle las líneas base más comunes son las que se muestran en la figura 1.0. 

1.2. ELEMENTO DE CONFIGURACIÓN DE SOFTWARE
 
Un elemento de la configuración del software es la información creada como parte del proceso de ingeniería un ECS (elemento de configuración de software) es un documento, un conjunto completo de casos de prueba o un componente de un programa dado. Los siguientes ECS son el objetivo de las técnicas de gestión de configuración y forman un conjunto de líneas base:
1) Especificación del sistema
2) Plan de proyecto
3) a. Especificación de requisitos
b. Prototipo ejecutable o “en papel”
4) Manual de usuario preliminar
5) Especificación de diseños
a. Descripción del diseño de datos
b. Descripción del diseño arquitectónico
c. Descripciones del diseño de los módulos
d. Descripciones del diseño de interfaces
e. Descripciones de los objetos (si se utilizan técnicas de P.O.O)
6) Listados del código fuente
7) a. Plan y procedimiento de pruebas
b. Casos de prueba y resultados registrados
8) Manuales de operación de y de instalación
9) Programas ejecutables
a. Módulos, código ejecutable
b. Módulos enlazados
10) Descripción de la base de datos
a. Esquema y estructura de archivos
b. contenido inicial
11) Manual del usuario final
12) Documentos de mantenimiento
a. Informes de problemas del software
b. Peticiones de mantenimiento
c. Ordenes de cambios e ingeniería
13) Estándares y procedimientos de ingeniería del software
Es importante considerar poner las herramientas de desarrollo de software bajo control de configuración. Es decir congelar la versiones de editores, compiladores y otras herramientas CASE utilizadas durantes el desarrollo, un cambio en las versiones utilizadas puede que produzca resultados diferentes que la versión original.
Los ECS se organizan como objetos de configuración que deben ser catalogados por la base de datos del proyecto con un nombre único. Un ECS tiene un nombre y atributos, y está conectado a otros objetos mediante relaciones.
2. EL PROCESO DE GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARE
La GCS es un elemento importante de garantía de calidad es responsable de controlar los cambios. Sin embargo también se debe identificar los ECS individuales. El proceso se puede definir en cinco tareas de CGS:
  • Identificación
  • Control de versiones
  • Control de cambios
  • Auditorias de configuración
  • Generación de informes 
3. IDENTIFICACIÓN DE OBJETOS EN GCS
 
Se pueden identificar dos tipos de objetos los objetos básicos y los objetos compuestos.
Un objeto básico es una unidad de texto creada durante el análisis, diseño, codificación o prueba. Un objeto compuesto es una colección de objetos básicos u objetos compuestos. Cada objeto tiene un conjunto de características que los identifican como únicos. El nombre del objeto es una cadena de caracteres que identifica al objeto sin ambigüedad. La descripción del objeto es una lista de elementos de datos que identifican:
  • El tipo de ECS (documento, programa, datos) que está representado por el objeto.
  • Un identificador del proyecto; y la información de la versión y/o el cambio.
El esquema de identificación de los objetos de software debe tener en cuenta que los objetos evolucionan a lo largo del proceso de ingeniería, por lo que se puede crear un grafo de evolución.
En el grafo de evolución se describe la historia del objeto y sus cambios, las grandes modificaciones hacen que un objeto cambie, por lo que cambia el número de versión principal.

4. CONTROL DE VERSIONES
El control de versiones combina procedimientos y herramientas para gestionar las versiones de los objetos de configuración creadas durante el proceso de ingeniería del software.
“La gestión de configuración permite a un usuario especificar configuraciones alternativas del sistema de software mediante la selección de las versiones adecuadas. Esto se puede gestionar asociando atributos a cada versión del software y permitiendo luego especificar y construir una configuración describiendo el conjunto de atributos deseado.”
Los atributos pueden ser tan sencillos como un número específico de versión asociado a cada objeto o tan complejos como una cadena de variables lógicas que especifiquen tipos de cambios funcionales aplicados al sistema.
Para construir la variante adecuada de una determinada versión de un programa, a cada componente se le asigna una tupla de atributos. A cada variante se le asigna uno o más atributos. Otra forma de establecer los conceptos de la relación entre componentes, variantes y versiones es representarlas como un fondo de objetos
La principal diferencia entre los distintos está en la sofisticación de los atributos que se usan para construir versiones y variantes específicas de un sistema y en la mecánica del proceso de construcción.
5. CONTROL DE CAMBIOS
En un gran proyecto de desarrollo de software, el cambio incontrolado lleva rápidamente al caos. El control de cambios combina los procedimientos humanos y las herramientas automáticas para proporcionar un mecanismo para el control de cambio.
Los resultados de la evaluación se presentan como un informe de cambios a la autoridad de control de cambios (ACC). Para cada cambio aprobado se genera una orden de cambio de ingeniería (OCI) La OCI describe el cambio a realizar, las restricciones que se deben respetar y los criterios de revisión y de auditoria. El objeto a cambiar es “dado de baja” de la base de datos del proyecto; se realiza el cambio y se aplican las adecuadas actividades de SQA. Luego, el objeto es “dado de alta” en la base de datos y se usan los mecanismos de de control de versiones apropiadas (sección 4) para crear la siguiente versión del software.
Los procedimientos de “alta” y “baja” implementan dos elementos importantes del control de cambios: control de acceso y control de sincronización. El control de acceso gobierna los derechos de los ingenieros de software a acceder y modificar objetos de configuración concretos. El control de sincronización asegura que los cambios en paralelo, realizados por personas diferentes, no se sobrescriben mutuamente.
Antes de que un ECS se convierta en una línea base, sólo es necesario aplicar un control de cambios informal. El que haya desarrollado el ECS en cuestión podrá hacer cualquier cambio justificado por el proyecto y por los requisitos técnicos. Una vez que el objeto ha pasado la revisión técnica formal y ha sido aprobada, se crea la línea base.
Una vez que el ECS se convierte en una línea base, aparece el control de cambios a nivel de proyecto. Para hacer un cambio, el encargado del desarrollo debe recibir la aprobación del gestor del proyecto (si el cambio es local), o de la ACC si el cambio impacta en otros ECS. En algunos casos, se dispensa de generar formalmente las peticiones de cambio, los informes de cambio y las OCI. Sin embargo, hay que hacer una evaluación de cada cambio así como un seguimiento y revisión de los mismos.
Cuando se distribuye el producto de software a los clientes, se instituye el control de cambios formal. La autoridad de control de cambios (ACC) desempeña un papel activo en el segundo y tercer nivel de control. El papel de la ACC es el de tener una visión general, o sea, evaluar el impacto del cambio fuera del ECS en cuestión. ¿Cómo impactará el cambio en el hardware? ¿Cómo impactará en el rendimiento?¿Cómo alterará el cambio la percepción del cliente sobre el producto?
6. AUDITORIA DE LA CONFIGURACION
¿Cómo podemos asegurar que el cambio se ha implementado correctamente? La respuesta es doble: 1) revisiones técnicas formales y 2) auditorias de configuración del software.
Las revisiones técnicas formales se centran en la corrección técnica del elemento de configuración que ha sido modificado. Los revisores evalúan el ECS para determinar la consistencia con otros ECS, las omisiones o los posibles efectos secundarios.
Una auditoria de configuración del software complementa la revisión técnica formal al comprobar características que generalmente no tiene en cuenta la revisión. La auditoria se plantea y responde con las siguientes preguntas:
  • ¿Se ha hecho el cambio especificado en la OCI? ¿Se han incorporado modificaciones adicionales?
  • ¿Se ha llevado a cabo una revisión técnica formal para evaluar la corrección técnica?
  • ¿Se han seguido adecuadamente los estándares de ingeniería de software?
  • ¿Se han “recalcado” los cambios en el ECS?¿Se han especificado la fecha del cambio y el autor?¿Reflejan los cambios los atributos del objeto de configuración?
  • ¿Se han seguido procedimientos del GCS para señalar el cambio, registrarlo y divulgarlo?
  • ¿Se han actualizado adecuadamente todos los ECS relacionados?
7. GENERACION DE INFORMES
La generación de informes de estado de la configuración es una tarea de GCS que responde a las siguientes preguntas:
  • 1) ¿Qué pasó?
  • 2) ¿Quién lo hizo?
  • 3) ¿Cuándo pasó?
  • 4) ¿Que más se vio afectado?
La generación de informes de estado de la configuración desempeña un papel vital en el éxito del proyecto de desarrollo de software. Cuando aparece involucrada mucha gente es muy fácil que no exista una buena comunicación. Pueden darse errores entre las personas desarrolladoras del software. El IEC ayuda a eliminar esos problemas, mejorando la comunicación entre todas las personas involucradas
 

Video Pruebas de Software - Presentado por: Javier Andrés Cáceres .

PRUEBAS DEL SOFTWARE

ACTIVIDADES REALIZADAS

En esta sección el grupo de trabajo conformado por Viky Julieta Arias, Maira Orozco, Anderson Quintero, Jonathan Rozo,  Jorge Paez y Karina Sepúlveda presentó una conferencia y un panel sobre pruebas del Software


ESTRATEGIAS UTILIZADAS

 Presentación de los siguientes contenidos académicos: 

DINAMICA A UTILIZAR: CONFERENCIA

El Diccionario de la Lengua Española de la Real Academia nos ayuda a entender que un discurso es la facultad de usar la mente (el razonamiento) para reflexionar o analizar los antecedentes, principios, indicios o señales de cualquier asunto con el fin de entenderlo. Cuando reflexionas, estás discursando, es decir, aplicando tu inteligencia, para entender un asunto y hasta para ser capaz de explicarlo inteligentemente a otras personas. Es una tarea que realizas en el interior de tu mente, una línea de razonamiento.


Conferencia es...


Cuando expones los resultados de tus reflexiones ante una o más personas, es un "discurso" porque se limitan a escucharte y usar su inteligencia para discernir lo que dices. Pero cuando implica dialogar con tus oyentes se convierte en una "conferencia", porque "conferencia" significa básicamente conversar y ese es el sentido principal que le damos en Oratorianet.com, para diferenciarla claramente del discurso.

Si anuncias tu presentación como un "discurso", pero al final del mismo permites tiempo para una sesión de preguntas y respuestas, el "discurso" se convierte en una "conferencia", porque implica diálogo.

Pero ten cuidado, si anuncias tu presentación como una "conferencia", los instruidos supondrán que toda la reunión estará matizada por una conversación fluida entre el orador y el auditorio y pudieran sentirse libres para interrumpirte a cada rato con preguntas o comentarios.

Por eso, si anuncias tu presentación como un "discurso" pero al final del mismo permitirás una sesión de preguntas y respuestas, tú o el presidente de la reunión deben indicar claramente el protocolo que seguirás a fin de que no se produzca desorden en la sala.  Estas son algunas diferentes opciones de conferencia:

    1) Se permitirá que el auditorio interrumpa en cualquier momento, ya sea para hacer preguntas y ofrecer comentarios cuando lo deseen, porque al final no habrá sesión de preguntas y respuestas.

    2) Sírvanse anotar sus preguntas en una libreta, porque el orador invitará al auditorio a hacer preguntas y ofrecer comentarios al final de cada punro principal.

    3) Sírvanse acercarnos sus preguntas y comentarios en una hoja de papel, porque el oradot seleccionará las más relevantes y se concentrará en estas por 5 (10 ó 15 minutos) al final de su discurso.

            a) Esto es para que recuerden sus preguntas y, llegado el momento, las expresen a viva voz desde sus asientos.

            b) O para que el encargado recabe las preguntas y les sean alcanzadas por el presidente al orador por escrito.
Recuerda: La "conferencia" es una conversación entre el orador y su auditorio, o entre los panelistas de un panel, o entre un entrevistador y su entrevistado. En cambio, un "discurso" es un monólogo en el que presentas o explicas tus ideas y conclusiones sin mediar diálogo alguno con nadie.
Las pruebas de software, en inglés testing son los procesos que permiten verificar y revelar la calidad de un producto software. Son utilizadas para identificar posibles fallos de implementación, calidad, o usabilidad de un programa de ordenador o videojuego. Básicamente es una fase en el desarrollo de software consistente en probar las aplicaciones construidas.
Las pruebas de software se integran dentro de las diferentes fases del ciclo del software dentro de la Ingeniería de software. Así se ejecuta un programa y mediante técnicas experimentales se trata de descubrir que errores tiene.
Para determinar el nivel de calidad se deben efectuar unas medidas o pruebas que permitan comprobar el grado de cumplimiento respecto de las especificaciones iniciales del sistema.
El testing puede probar la presencia de errores pero no la ausencia de ellos
Hay muchos planteamientos a la hora de abordar el proceso de pruebas de software, pero para verificar productos complejos de forma efectiva requiere de un proceso de investigación más que seguir un procedimiento al pie de la letra. Una definición de "testing" es: proceso de evaluación de un producto desde un punto de vista crítico, donde el "tester" (persona que realiza las pruebas) somete el producto a una serie de acciones inquisitivas, y el producto responde con su comportamiento como reacción. Por supuesto, nunca se debe testear el software en un entorno de producción. Es necesario testear los nuevos programas en un entorno de pruebas separado físicamente del de producción. Para crear un entorno de pruebas en una máquina independiente de la máquina de producción es necesario crear las mismas condiciones que en la máquina de producción. Existen a tal efecto varias herramientas vendidas por los mismos fabricantes de hardware (IBM, Sun, HP etc.). Esas utilidades reproducen automáticamente las bases de datos para simular un entorno de producción.
En general, los informáticos distinguen entre errores de programación (o "bugs") y defectos de forma. En un defecto de forma, el programa no realiza lo que el usuario espera. Por el contrario, un error de programación puede describirse como un fallo en la semántica de un programa de ordenador. Éste podría presentarse, o no, como un defecto de forma si se llegan a dar ciertas condiciones de cálculo.
Una práctica común es que el proceso de pruebas de un programa sea realizado por un grupo independiente de "testers" al finalizar su desarrollo y antes de sacarlo al mercado. Una práctica que viene siendo muy popular es distribuir de forma gratuita una versión no final del producto para que sean los propios consumidores los que la prueben. En ambos casos, a la versión del producto en pruebas y que es anterior a la versión final (o "master") se denomina beta, y a dicha fase de pruebas, beta testing.
Puede además existir una versión anterior en el proceso de desarrollo llamada alpha, en la que el programa, aunque incompleto, dispone de funcionalidad básica y puede ser testeado.
Finalmente y antes de salir al mercado, es cada vez más habitual que se realice una fase de RTM testing (Release To Market), dónde se comprueba cada funcionalidad del programa completo en entornos de producción.
Otra práctica es que el proceso de pruebas se realice desde el mismo momento en que empieza el desarrollo y continúe hasta que finaliza.

La importancia de la detección oportuna

En la cadena de valor del desarrollo de un software específico, el proceso de prueba es clave a la hora de detectar errores o fallas. Conceptos como estabilidad, escalabilidad, eficiencia y seguridad se relacionan a la calidad de un producto bien desarrollado. Las aplicaciones de software han crecido en complejidad y tamaño, y por consiguiente también en costos. Hoy en día es crucial verificar y evaluar la calidad de lo construido de modo de minimizar el costo de su reparación. Mientras antes se detecte una falla, más barata es su corrección.
El proceso de prueba es un proceso técnico especializado de investigación que requiere de profesionales altamente capacitados en lenguajes de desarrollo, métodos y técnicas de pruebas y herramientas especializadas. El conocimiento que debe manejar un ingeniero de prueba es muchas veces superior al del desarrollador de software.

Tipos de pruebas

DINAMICA A UTILIZAR: EL PANEL

En esta técnica un equipo de expertos discute un tema en forma de diálogo o conversación ante el grupo.
Como en el caso de la Mesa redonda y el Simposio, en el Panel se reúnen varias personas para exponer sus ideas sobre un determinado tema ante un auditorio. La diferencia, consiste en que en el Panel dichos expertos no "exponen", no "hacer uso de la palabra", no actúan como "oradores", sino que dialogan, conversan, debaten entre sí el tema propuesto, desde sus particulares puntos de vista y especialización, pues cada uno es experto en una parte del tema general.
En el Panel, la conversación es básicamente informal, pero con todo, debe seguir un desarrollo coherente, razonado, objetivo, sin derivar en disquisiciones ajenas o alejadas del tema, ni en apreciaciones demasiado personales. Los integrantes del Panel ( de 4 a 6 personas) tratan de desarrollar a través de la conversación todos los aspectos posibles del tema, para que el auditorio obtenga así una visión relativamente completa acerca del mismo.
Un coordinador o moderador cumple la función de presentar a los miembros del Panel ante el auditorio, ordenar la conversación, intercalar algunas preguntas aclaratorias, controlar el tiempo, etc.
Una vez finalizado el Panel (cuya duración puede ser de alrededor de una hora, según el caso) la conversación o debate del tema puede pasar al auditorio, sin que sea requisito la presencia de los miembros del panel. El coordinador puede seguir conduciendo esta segunda parte de la actividad grupal, que se habrá convertido en un "Foro".
La informalidad, la espontaneidad y el dinamismo son características de esta técnica de grupo, rasgos por cierto bien aceptados generalmente por todos los auditorios.
¿Cómo se realiza?
Preparación:
De acuerdo con el tema elegido para el Panel, el organizador selecciona a los componentes o miembros del mismo, tratando de que sean personas:
·         Capacitadas y de ser posibles reconocidas en la cuestión,
·         Que puedan aportar ideas más o menos originales y diversas,
·         Que enfoquen los distintos aspectos del tema
·         Qué posean facilidad de palabra (pero no verborrea)
·         Qué posean juicio critico y capacidad para el análisis tanto como para la síntesis.
·         Aún sería deseable, un cierto sentido del humor para amenizar una conversación que podría tornarse en algunos momentos un poco cansada.
Es conveniente una reunión previa del coordinador con todos los miembros que intervendrán en el panel, para cambiar ideas y establecer un plan aproximado del desarrollo de la sesión, compenetrarse con el tema, ordenar los subtemas y aspectos particulares, fijar tiempo de duración, etc.
Así pues, aunque el Panel debe aparecer luego como una conversación espontanea e improvisada, requiere para su éxito ciertos preparativos como los expuestos.
Desarrollo:
1.    El coordinador o moderador inicia la sesión, presenta a los miembros del panel, y formula la primera pregunta acerca del tema que se va a tratar.
2.    Cualquiera de los miembros del panel inicia la conversación, aunque puede estar previsto quien lo harta, y se entabla el diálogo que se desarrollará según el plan flexible también previsto.
3.    El coordinador interviene para efectuar nuevas preguntas sobre el tema, orientar el dialogo hacia aspectos no tocados, centrar la conversación en el tema cuando se desvía demasiado de él, superar una eventual situación de tensión que pudiera producirse, etc. Habrá de estimular el diálogo si éste decae, pero sin intervenir con sus propias opiniones.
4.    Unos cinco minutos antes de la terminación del diálogo, el coordinador invita a los miembros a que hagan un resumen muy breve de sus ideas.

·         Puede designarse un secretario para tomar notas de las ideas más importantes, las cuales pueden ser distribuidas luego entre los interesados. También cabe la utilización de una grabadora de audio o mucho mejor de vídeo.
·         Se aconseja tener especial cuidado en la elección de los miembros del Panel, pues una conversación de este tipo debe mantener despierto el interés de un auditorio que permanece en pasividad expectante. Aparte del conocimiento y autoridad sobre el tema, se requiere en los interlocutores ciertas dotes de amenidad, facilidad de palabra, claridad de exposición, serenidad, ingenio y alguna salida de buen humor.

5.    Finalmente el propio coordinador, basándose en notas que habrá tomado, destacará las conclusiones más importantes.
6.    Si así se desea y el tiempo lo permite, el coordinador puede invitar al auditorio a cambiar ideas sobre lo expuesto, de manera informal, al estilo de un Foro. En esta etapa no es indispensable la presencia de los miembros del panel, pero si éstos lo desean, pueden contestar preguntas del auditorio, en cuyo caso el coordinador actuará como "canalizador" de dichas preguntas, derivándolas al miembro que corresponda.
Sugerencias Practicas:
Los miembros del panel y el coordinador deben estar ubicados de manera que puedan verse entre sí para dialogar, y a la vez ser vistos por el auditorio. La ubicación semicircular suele ser la más conveniente, ya sea detrás de una mesa o sin ella pero con asientos cómodos.

PANEL: PRUEBAS DEL SOFTWARE
CORDINADOR:
JONATHAN
EXPERTOS:
JORGE
YURAIMA
VIANNY
DESARROLLO
JONATHAN INICIA LA PRESENTACION DE LOS EXPERTOS EN EL TEMA DE PRUEBAS DE SOFTWARE PARA DAR POR INICIADA LA SESION. AL TERMINAR LA PRESENTACION LANZA LA PRIMERA PREGUNTA

1. ¿Qué SON LAS PRUEBAS DEL SOFTWARE?
LA PREGUNTA LA RESPONDE EL INGENIERO JORGE 

Las pruebas de software, en inglés testing son los procesos que permiten verificar y revelar la calidad de un producto software. Son utilizadas para identificar posibles fallos de implementación, calidad, o usabilidad de un programa de ordenador o videojuego. Básicamente es una fase en el desarrollo de software consistente en probar las aplicaciones construidas.
Las pruebas de software se integran dentro de las diferentes fases del ciclo del software dentro de la Ingeniería de software. Así se ejecuta un programa y mediante técnicas experimentales se trata de descubrir que errores tiene.
Para determinar el nivel de calidad se deben efectuar unas medidas o pruebas que permitan comprobar el grado de cumplimiento respecto de las especificaciones iniciales del sistema.

OTRO CONCEPTO SOBRE PRUEBAS PODRIA SER EL SIGUIENTE Y LO COMENTA LA INGENIERA YURAIMA

2. ¿Que tipos de prueba de programa deben ser considerados ?
RESPONDE LA PREGUNTA LA INGENIERA VIANNY

 Caja negra. No esta basada en el conocimiento del código o diseño interno, determina la funcionalidad del sistema.
Caja blanca. Esta basada en la lógica interna de la aplicacion y el código. Hace una cobertura de declaraciones del código, ramas, caminos y condiciones.
Unidad de testeo o prueba. Es la escala mas pequeña de la prueba, esta basada en la funcionalidad de los módulos del programa, como funciones, procedimientos, módulos de clase, etc. En ciertos sistemas también se verifican o se prueban los drivers y el diseño de la arquitectura.
Integración incremental. Cuando nuevas funciones son ingresadas al sistema se hace la prueba basándose en la funcionalidad, la dependencia con otros módulos y la integración con el programa completo.
Prueba de integración. Se basa en las pruebas de conexiones y comunicaciones entre diferentes módulos. Es esencial en sistemas de cliente_servidor o red.
Prueba funcional. La caja negra hace la prueba funcional de los requerimientos de la aplicacion y generalmente es realizada por el programador, en cambio, la prueba funcional es realizada por los testers.
Prueba de sistema. Es una prueba de caja negra incluyendo todos los componentes del sistema desde el hardware a la documentación.
Prueba de fin a fin. Es similar a la prueba de sistema pero esta involucra la interacción con otros hardwares, bases de datos y redes.
Prueba de sanidad. Determina si la nueva versión de un software esta bien realizada y si necesita un nuevo esfuerzo en la prueba de software. Por ejemplo la nueva versión de un programa cumple con casi todos los requisitos pero destruye la base de datos al leerla, por lo tanto se dice que este software no esta en una condición sana.
Prueba de regresión. Es una nueva revisión en las pruebas del programa luego de que este haya sufrido algún cambio o por apuros de tiempo o la modificación fue en el ambiente en que se desenvuelve. Actualmente aparecieron herramientas automatizadas que hacen que este tipo de pruebas no lleve demasiado tiempo.

INTERVIENE LA INGENIERA YURAIMA SOBRE EL TEMA O SOBRE LA PREGUNTA QUE SE LANZO Y DA SU OPINION O COMPLEMENTA LO QUE TIENE QUE VER SOBRE CUALES TIPOS DE PRUEBAS HAY

Prueba de aceptación. Es la prueba final basada en las especificaciones del usuario o basada en el uso del programa por el usuario final luego de un periodo de tiempo.
Prueba de carga. Esta basada en las aplicaciones bajo cargas pesadas , generalmente usadas en sitios web y en servidores con gran cantidad de datos donde se determina en cuales puntos existen degradaciones del sistema.
Prueba de estrés. Es una prueba de carga y perfomance basada en la funcionalidad del sistema bajo cargas pesadas , un gran numero de repeticiones, manejo de grandes datos y demasiadas preguntas a bases de datos grandes.
Prueba de perfomance. Es una de las pruebas finales y sirve para definir los requerimientos y la calidad del software, en base a las pruebas de carga y estrés. Incluye entrevistas con el usuario y programador.
Prueba de instalación y desinstalación. Determina la eficiencia de los procesos que instalan y desinstalan las aplicaciones del programa.
Prueba de recuperacion. Es la prueba que evalúa que tan bien se recupera el sistema luego de bloqueos , fallas del hardware u otros problemas catastróficos.
Prueba de seguridad. Evalúa que tan bien el sistema se protege contra accesos , internos o externos, no autorizados, esta prueba requiere sofisticadas tecnicas y herramientas.
Prueba de compatibilidad. Evalúa el desempeño del software en diferentes hardwares , sistemas operativos , redes, etc.
Prueba de exploración. Es una prueba informal del software que no esta basada en ningún plan o caja de prueba y a menudo los testers aprenden del programa al explorar todas las aplicaciones posibles.
Prueba de anuncio. Es similar a la prueba de exploración pero los testers deben tener suficiente noción sobre el funcionamiento del programa antes de comenzar esta prueba. Incluye reunión con analistas y programadores.
Prueba de usuario. Determina si el usuario se desenvuelve satisfactoriamente con el programa.
Prueba de comparación. En esta prueba se comparan los pro y los contra del programa con los programas creados con la competencia.
Prueba alfa. Es la prueba cuando la aplicacion esta cerca de la entrega al usuario. Se hacen pequeños cambios generalmente en el diseño de interfaces. Esta prueba es hecha por usuarios.
Prueba beta. Es la búsqueda de bugs en el programa completo. Generalmente es hecha por usuarios.
Prueba de mutación. Esta prueba esta basada en la introducción deliberada de diferentes códigos externos al programa (bugs) para reexaminar si estos bugs pueden ser detectados. Requiere gran disponibilidad de recursos de computación.
3. ¿CUALES SON LOS TEMAS QUE SE DEBEN IMPLEMENTAR  EN UNA ESTRATEGIA DE ÉXITO PARA UNA PRUEBA DE SOFTWARE?
·         Especificar los requisitos del producto de manera cuantificable mucho antes de que empiecen las pruebas
·         Establecer explícitamente los objetivos de la prueba
·         comprender cuales son los usuarios del software y desarrollar un perfil
·         desarrollar un plan de pruba que destaque
·         construir un software robusto diseñado para probarse a si mismo
·         usar revisiones tecnicas fromales y efectivas como filtro previo a la prueba.
·         realizar revisiones tecnicas formales para evaluar la estrategia de prueba
·         desarrollar un enfoque de mejora continua para el proceso de prueba.
RESPONDE EL INGENIERO ESPECIALISTA EN PRUEBAS, AL TERMINAR CON EL INGENIERO EL CORDINADOR SE DIRIGE A LOS EXPERTOS Y AL AUDITORIO GENERAL CON EL SIGUIENTE ARGUMENTO Y LANZA UNA PREGUNTA

RESPONDE LA INGENIERA VIANNY KARINA
La estrategia de prueba que elige la mayor parte de los equipos de software se ubican entre estos dos extremos. Toma un enfoque incrmental de las pruebas ; inicia con la prueba de unidades individuales del programa, pasa a pruebas diseñadas para facilitar la integración de las unidades, y culmina con prubas que realizan sobre el sistema construido

 
4.¿ QUE ES LA DEPURACIÓN, ES CONSIDERADA UNA PRUEBA?
La depuración ocurre como consecuencia de una prueba realizada con éxito. Es decir,  cuando un caso de prueba descubre un error, la  depuración es la acción que lo elimina. Auqnue la depuración puede y debe  ser un proceso ordenado, isgue siendo un arte
En si la depuracion no es una prueba , pero siempre ocurre como consecuencia de una.

EL CORDINADOR DEL PANEL SOBRE PRUBAS DEL SOFTWARE CULMINA LA SESION, DESPIDE A LOS INVITADOS.