martes, 24 de mayo de 2016

GESTION DE CAMBIOS EN EL SOFTWARE


Se pueden encontrar libros, artículos y ponencias sobre la gestión del cambio. Es uno de los grandes misterios humanos ya que la resistencia al cambio es un síntoma absolutamente natural. Ahora bien, ¿cuales son los motivos que pueden ocasionarla?.

Las razones que llevan a la resistencia al cambio están basadas en alguno de estos factores. Todos hemos llegado a implantar un software a una compañía y nos hemos encontrado con grupos de personas que tratan de echar abajo la implantación del proyecto. Son típicas las presiones que podemos encontrarnos por este tipo de usuarios:
·         Este programa no hacía lo que el anterior.
·         Este programa es más difícil.
·         No puedo trabajar con este software le falta la dirección a la factura no puedo seguir trabajando.
·         Simplemente no funciona.
·         Esto está lleno de problemas.
·         Esto no es lo que nos vendieron

Todos los implantadores de software nos hemos encontrado con este tipo de frases en la implantación de un nuevo software en una empresa. Este tipo de comportamientos son naturales, ya que todo cambio nos pone nerviosos, en ocasiones existe una visión demasiado parcial del cambio. Las personas juzgan negativamente al cambio exclusivamente por lo que sucede en su ámbito de influencia (su grupo de trabajo, su sector, su gerencia) sin considerar los beneficios globales que obtiene la empresa en su conjunto.
En algunos casos, el cambio despierta sentimientos negativos en las personas y éstas sencillamente no quieren cambiar; ya que consideran que no les conviene o que las obliga a moverse fuera de su zona de comodidad. Estas reacciones pueden partir de sentimientos tales como:
·         El desacuerdo. Los individuos pueden estar simplemente en desacuerdo en cuanto a las premisas o los razonamientos sobre los que se sustenta el cambio. En algunos casos basan sus juicios en modelos mentales muy cerrados o tienen dificultades para abandonar hábitos muy arraigados.
·         La incertidumbre. Los efectos del nuevo sistema no son totalmente predecibles y esto genera temor por falta de confianza en sus resultados.
·         La pérdida de identidad. A veces, las personas edifican su identidad sobre lo que hacen. En este marco de referencia, los cambios califican y ofenden. Aparecen las actitudes defensivas.
·         La necesidad de trabajar más. Normalmente se percibe que deben encararse simultáneamente dos frentes distintos: el de continuación de las viejas tareas y el de inicio de las nuevas rutinas.

¿Qué hacer para enfrentar a todos estos problemas? Tener PACIENCIA. Está científicamente probado que la gestión del cambio es un simple problema de tiempo. En la gestión del cambio en grupos se pasa por una fases estándares que todos tenemos que superar.


La fase emocionalmente más complicada es la denominada Decaimiento, en esa fase parece que estás peor que antes de empezar, que no se cumplen las expectativas, que realmente los usuarios no aceptan el cambio, esa en la que te planteas si todo el esfuerzo que se ha realizado merece la pena. En una fase momentánea, a partir de ese momento todo empezará a ir mejor. Aguanta, ten paciencia y comunica mejor que nunca. El tiempo de esta fase dependerá de la comunicación y del tipo de usuarios a los que te enfrentes.

Una de los cambios más complicados de gestionar que he conocido recientemente es el del nuevo interfaz de Facebook, ya lo hemos olvidado pero no hace más de seis meses, los foros, blogs, ardían con el cambio del nuevo interfaz de Facebook. Hacía tiempo que no recordaba un cambio tan complicado, millones de personas se unían en blogs y foros para pedir a Facebook que volviera para atrás, que se habían equivocado, que el nuevo interfaz era 1.000.000 de veces peor que el anterior, etc…
El problema para un usuario intermedio (el que no tiene una opinión formada) es que yo mismo leyendo todos aquellos comentarios me planteaba que si se habían equivocado. Los incendios en blogs y foros me hacían dudar del nuevo interfaz. Se estaba viviendo la etapa del decaimiento. Lo difícil de esta etapa es que parece que vas para atrás. Realmente el nuevo interfaz de Facebook llevaba meses en la web para probarlo en formato Beta, pero todo explotó el día que se dijo Ya es oficial ese día todo se encendió en la RED. Fue una época dura para todo el equipo de Facebook ya que se ponía en duda la continuidad de la Red social, decían que estaban cavando su propia tumba. Meses después nadie se acuerda de todo aquello porque los humanos tenemos una capacidad innata para olvidar este tipo de cosas. Todos los detractores han desaparecido y todos los usuarios se han ido acostumbrando al nuevo interfaz, al final el cambio se estabilizó y Facebook se ha consolidado con la red social líder en el mundo. Hay que tener paciencia y estar muy seguro de lo que haces para sobrevivir a esa presión emocional de la fase de decaimiento.

Profesionalmente me enfrenté a dos grandes momentos de cambio con la herramienta Velazquez Visual:
De Zeus a Cliente-Servidor: Hace 8 años la plataforma que utilizábamos en la empresa propuso el cambio de Zeus a Cliente-Servidor, ese cambio no sólo era tecnológico sino económico ya que se cobrarían licencias por usuario. Nada más aparecer la versión 1.0 se estableció la norma en la organización de vender absolutamente TODO en cliente-servidor. Tenía la visión de que la cliente-servidor era el futuro y debíamos apostar por ella a 100%. Aunque ya no nos acordemos internamente pocas veces viví una fase decaimiento tan dura en mi vida. La parte comercial, técnica, proyecto, TODOS echaban humo y pedían regresar al modelo Zeus, mejor económicamente y mucho más estable técnicamente (desde su punto de vista claro).

Aquella fase duró internamente casi un año pero tuvo su recompensa, sabemos que aquella apuesta nos convirtió en líderes en tecnología cliente-servidor, nos adelantamos a la competencia técnica y comercialmente. ¿Perder dinero? todo lo contrario aquello suposo un gran paso para nuestra organización y llevó a Visual MS ha acometer proyectos que hasta ese momento eran impensables. Gracias a aguantar un periodo de decaimiento largo y no volver para atrás hoy día estamos donde estamos.

Cuando se produce un cambio no se debe de frenar, sino potenciar. Cualquier freno en un cambio aumenta el tiempo de la fase de decaimiento que siempre se produce pero se puede acortar o alargar depende del tipo de usuario al que te enfrentes. No tengas miedo a esta fase, es parte del proceso, intenta llevarla lo mejor posible y hacerla lo más corta posible. 

Tomado de: https://crearsoftware.com/2009/07/05/la-gestion-del-cambio-en-el-software/


MANTENIMIENTO DEL SOFTWARE



El estándar IEEE 1219 [IEEE, 1993] define el Mantenimiento del Software como “la modificación de un producto software después de haber sido entregado [a los usuarios o clientes] con el fin de corregir defectos, mejorar el rendimiento u otros atributos, o adaptarlo a un cambio en el entorno”.

En el estándar ISO 12207, de Procesos del Ciclo de Vida del Software [ISO/IEC, 1995] se establece que “el Proceso de Mantenimiento contiene las actividades y tareas realizadas por el mantenedor. Este proceso se activa cuando el producto software sufre modificaciones en el código y la documentación asociada, debido a un problema o a la necesidad de mejora o adaptación. El objetivo es modificar el producto software existente preservando su integridad. Este proceso incluye la migración y retirada del producto software. El proceso termina con la retirada del producto software”. El mantenedor es la organización que proporciona el servicio de mantenimiento.

Pressman [1998] dice que “la fase mantenimiento se centra en el cambio que va asociado a la corrección de errores, a las adaptaciones requeridas a medida que evoluciona el entorno del software, y a cambios debidos a las mejoras producidas por los requisitos cambiantes del cliente”.

Mantenimiento Correctivo 

El mantenimiento correctivo tiene por objetivo localizar y eliminar los posibles defectos de los programas. Un defecto en un sistema es una característica del sistema con el potencial de causar un fallo. Un fallo ocurre cuando el comportamiento de un sistema es diferente del establecido en la especificación. Entre otros, los fallos en el software pueden ser de:

  • Procesamiento, por ejemplo, salidas incorrectas de un programa. 
  • Rendimiento, por ejemplo, tiempo de respuesta demasiado alto en una búsqueda de información. 
  • Programación, por ejemplo, inconsistencias en el diseño de un programa. 
  • Documentación, por ejemplo, inconsistencias entre la funcionalidad de un programa y el manual de usuario.
Mantenimiento Adaptativo 

Este tipo de mantenimiento consiste en la modificación de un programa debido a cambios en el entorno (hardware o software) en el cual se ejecuta. 

Estos cambios pueden afectar al sistema operativo (cambio a uno más moderno), a la arquitectura física del sistema informático (paso de una arquitectura de red de área local a Internet/Intranet) o al entorno de desarrollo del software (incorporación de nuevos elementos o herramientas como ODBC). 

El tipo de cambio necesario puede ser muy diferente: desde un pequeño retoque en la estructura de un módulo hasta tener que re escribir prácticamente todo el programa para su ejecución en un ambiente distribuido en una red.

Mantenimiento Adaptativo 

Los cambios en el entorno software pueden ser de dos clases: 

  • En el entorno de los datos, por ejemplo, al dejar de trabajar con un sistema de ficheros clásico y sustituirlo por un sistema de gestión de bases de datos relacionales. 

  • En el entorno de los procesos, por ejemplo, migrando a una nueva plataforma de desarrollo con componentes distribuidos, Java, ActiveX, etc. 
El mantenimiento adaptativo es cada vez más usual debido principalmente al cambio, cada vez más rápido, en los diversos aspectos de la informática: nuevas generaciones de hardware cada dos años, nuevos sistemas operativos -ó versiones de los antiguos- que se anuncian regularmente, y mejoras en los periféricos o en otros elementos del sistema. Frente a esto, la vida útil de un sistema software puede superar fácilmente los diez años [Pressman, 1993].

Mantenimiento Perfectivo 

Cambios en la especificación, normalmente debidos a cambios en los requisitos de un producto software, implican un nuevo tipo de mantenimiento llamado perfectivo. 

Desde algo tan simple como cambiar el formato de impresión de un informe, hasta la incorporación de un nuevo módulo aplicativo. Podemos definir el mantenimiento perfectivo como el conjunto de actividades para mejorar o añadir nuevas funcionalidades requeridas por el usuario.

Algunos autores dividen este tipo de mantenimiento en dos: 

  • Mantenimiento de Ampliación: orientado a la incorporación de nuevas funcionalidades. 
  • Mantenimiento de Eficiencia: que busca la mejora de la eficiencia de ejecución. 
Este tipo de mantenimiento aumenta cuando un producto software tiene éxito comercial y es utilizado por muchos usuarios, ya que cuanto más se utiliza un software, más peticiones de los usuarios se reciben demandando nuevas funcionalidades o mejoras en las existentes.

Mantenimiento Preventivo

Este  tipo de mantenimiento consiste en la modificación del software para mejorar sus propiedades (por ejemplo, aumentando su calidad y/o su mantenimiento) sin alterar sus especificaciones funcionales. 

Por ejemplo, se pueden incluir sentencias que comprueben la validez de los datos de entrada, re estructurar los programas para mejorar su legibilidad, o incluir nuevos comentarios que faciliten la posterior comprensión del programa. Este tipo de mantenimiento es el que más partido saca de las técnicas de ingeniería inversa y reingeniería.

En algunos casos se ha planteado el Mantenimiento para la Reutilización, consistente en modificar el software (buscando y modificando componentes para incluirlos en bibliotecas) para que sea mas fácilmente reutilizable. En realidad este tipo de mantenimiento es preventivo, especializado en mejorar la propiedad de reusabilidad del software.

Actividades de Mantenimiento

Basili et al. [1996] identifican las siguientes once actividades, que se realizan con cada modificación del software: 
  •  Análisis de impacto y de costes/beneficios: se dedica esta actividad a analizar diferentes alternativas de implementación y/o a comprobar su impacto en la planificación, coste y facilidad de operación. 
  • Comprensión del cambio: puede consistir en localizar el error y determinar su causa, o en comprender los requisitos de una mejora solicitada. 
  •  Diseño del cambio: se refiere al diseño propuesto para el cambio, pudiéndose incluir un rediseño del sistema. 
  • Codificación y pruebas unitarias: se codifica y prueba el funcionamiento de cada componente modificado. 
  • Inspección, certificación y consultoría: esta actividad se dedica a inspeccionar el cambio, comprobar otros diseños, reuniones de inspección, etc.
  • Pruebas de integración: se refiere a comprobar la integración de los componentes modificados con el resto del sistema. 
  •  Pruebas de aceptación: en esta actividad, el usuario comprueba, junto al personal encargado del mantenimiento, la adecuación del cambio a sus necesidades. 
  •  Pruebas de regresión: en esta actividad se somete el software modificado a casos de pruebas previamente almacenados y por los que ya pasó.
  • Documentación del sistema: se revisa y reescribe, en caso necesario, la documentación del sistema para que se ajuste al producto software ya modificado. 
  • Otra documentación (del usuario, por ejemplo): se revisa y reescribe, en caso necesario, los diferentes manuales de usuario y otra documentación, excepto la documentación del sistema. 
  • Otras actividades, como las dedicadas a la gestión del proyecto de mantenimiento.

Tomado de https://swcb37.files.wordpress.com/2013/08/mantenimiento-de-software.pdf



GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARE



Generalidades

A lo largo del ciclo de vida del proceso de software, los productos de software evolucionan. Desde la concepción del producto y la captura de requisitos inicial hasta la puesta en producción del mismo, y posteriormente desde el inicio del mantenimiento hasta su retiro, se van realizando una serie de cambios, tanto en el código como en la documentación asociada. La Gestión de Configuración del Software es una disciplina encargada del control de la evolución de los productos de software.
Como todo proceso, la Gestión de Configuración también puede ser sistematizada y automatizada, lo que se denomina un Sistema de Gestión de Configuración (SGC). Actualmente existen en el mercado diversas herramientas que permiten apoyar una o más actividades de la Gestión de Configuración. 


Definiciones

Gestión de Configuración es el proceso de identificar y definir los elementos en el sistema, controlando el cambio de estos elementos a lo largo de su ciclo de vida, registrando y reportando el estado de los elementos y las solicitudes de cambio, y verificando que los elementos estén completos y que sean los correctos.

El propósito de la Gestión de Configuración del Software es establecer y mantener la integridad de los productos de software a través del ciclo de vida del proceso de software. 

La Gestión de Configuración del Software implica la identificación de la Configuración del software en puntos dados en el tiempo, el control sistemático de los cambios en la Configuración y el mantenimiento de la integridad y trazabilidad de la Configuración a través del ciclo de vida del software. Los productos incluidos son:


 Software distribuido al cliente.

 Documentos de requerimientos del software.

 Código.

 Elementos requeridos para crearlos (ejemplo: el compilador)


Aspectos Funcionales 

1. Identificación: Se necesita definir un esquema de identificación para reflejar la estructura del producto, esto involucra identificar la estructura y clases de componentes, dando a cada uno un nombre, una identificación de versión y una identificación de Configuración.

2. Control: Se deben controlar los cambios que se le hacen a través del ciclo de vida, asegurando que el software sea consistente a través de la creación de una línea base del producto.

3. Estado: Se debe registrar y reportar el estado de los componentes y solicitudes de cambio.

4. Auditoria y revisión: Se debe validar que el producto este completo y se asi mantener la consistencia entre los componentes, asegurando que estén en un estado apropiado a través de todo el ciclo de vida del producto y que el mismo sea una colección bien definida de componentes.



Algunos conceptos presentes en la DisciplinaConfiguración

Las características funcionales y físicas de una versión especifica de hardware y elementos de software que combinados de acuerdo a procedimientos de construcción específicos cumplen un propósito particular. 

Elementos de configuración de software

Definimos como un elemento de Configuración a una unidad física y/o lógica parte de un conjunto mayor de elementos, producida o adquirida, que por sus características es distinguible de las demás y cuya evolución interesa administrar.

Son elementos de Configuración en un proyecto de software: 
01. El plan de proyecto.
02. El plan de Gestión de Configuración.
03. El documento de definición de requerimientos.
04. Estándares de análisis, diseño, codificación, pruebas, y auditoria.
05. Documentos de análisis del sistema.
06. Documentos de diseño del sistema.
07. Prototipos.
08. Documentos de diseño de alto nivel.
09. Documentos de diseño de bajo nivel.
10. Especificaciones de prueba del sistema.
11. El plan de pruebas del sistema.
12. El Código fuente del programa.
13. Código objeto y ejecutable.
14. Especificaciones de pruebas de unidad.
15. Planes de pruebas de unidad.
16. Documentos de diseño de base de datos.
17. Datos de prueba.
18. Datos del proyecto.
19 .Manuales de usuario. 
Versión 

Una versión es una instancia de un elemento de Configuración. El término se usa para señalar a un elemento de Configuración del software que tiene un conjunto definido de características funcionales. 

Revisión 

Se define revisión como una versión que se construye sobre otra versión anterior. El término revisión generalmente se asocia a la noción de corrección de errores, esto es, hacer cambios a un programa que corrigen solo errores en el diseño lógico pero no afectan las capacidades funcionales documentadas, dado que ningún requerimiento ha cambiado.

Variante 


Se define variante como una versión que es una alternativa a otra versión. Las variantes pueden permitir a un elemento de Configuración satisfacer requerimientos en conflicto. Una variante es una nueva versión de un elemento que será añadida a la Configuración sin reemplazar a la versión anterior.

Por ejemplo, si se desarrolla una aplicación para varios sistemas operativos, algunas librerías pueden requerir modificaciones para poder ser compiladas o ejecutadas en los diferentes sistemas; la versiones para Unix y para Windows NT de una librería serían variantes del mismo elemento.

La creación de variantes implica la creación de ramas en un grafo de evolución. 


Línea base 

Una línea base es una especificación o producto revisado y aprobado formalmente, que sirve como base para el desarrollo posterior, y puede ser modificado solo a través de procedimientos formales de control de cambios.

El término también se usa para referirse a una versión particular de un elemento de software que ha sido aprobado. En cualquier caso, la línea base solo se puede modificar a través de procedimientos formales de control de cambios. Una línea base, junto con todos los cambios aprobados a la línea base, representa la Configuración aprobada actual. 


Procesos Asociados 

El estándar ISO/IEC 12207 ([ISO 12207]) para Procesos del Ciclo de Vida del Software, establece el Proceso de Gestión de Configuración como uno de los Procesos de Soporte del Ciclo de Vida. Un Proceso de Soporte ”apoya” a otro proceso como una parte integral, con un propósito distinto, y contribuye al éxito y a la calidad del proyecto de software.

Este proceso consiste de las siguientes actividades: 


1. Implementación del Proceso: Se desarrolla un Plan de Gestión de Configuración que describe las actividades de Gestión de Configuración, los procedimientos y el cronograma para su realización, y los responsables de dichas actividades. Dicho plan debe ser documentado e implementado.

2. Identificación de la Configuración: Se establece un esquema de identificación de los elementos de software y sus versiones a ser controlados por el proyecto.

3. Control de la Configuración: Se identifican y registran las solicitudes de cambio, se analiza y evalúa los cambios, se aprueba o rechaza la solicitud, se implementa, verifica y distribuye el elemento de software modificado.

4. Contabilidad de Estado de la Configuración: Se preparan registros de Gestión y reportes de estado que muestren el estado e historia de los elementos de software controlados, incluyendo líneas base.

5. Evaluación de la Configuración: Se determina y asegura que los elementos de software sean funcionalmente (versus sus requerimientos) y físicamente completos (es decir, si su diseño y Código reflejan una descripción técnica actualizada).

6. Gestión de actualización y distribución: Se controla formalmente la actualización y distribución de los productos de software.


En la figura  se presenta un modelo de este proceso elaborado utilizando el perfil de UML para modelamiento de procesos de software, propuesto por el Object Management Group (OMG)

El estándar IEEE Std. 1074-1995 ([IEEE 1074]) para el Desarrollo de Procesos del Ciclo de Vida del Software, establece el Proceso de Gestión de Configuración del Software como uno de los Procesos Integrales. Estos son los Procesos necesarios para completar exitosamente las actividades del proyecto, y son utilizados para asegurar la finalización y calidad de las funciones del proyecto. Este proceso consiste de las siguientes actividades: 

1. Planificar la Gestión de Configuración. 



2. Desarrollar la Identificación de la Configuración. 



3. Realizar el Control de la Configuración. 

4. Realizar la Contabilidad de Estado. 


Escenarios de Configuración en el Proceso de Software

Gestión de configuración del código fuente



La evolución del Código fuente es quizás el ejemplo mas claro en la Gestión de Configuración. A lo largo del desarrollo (y posteriormente en el mantenimiento) las modificaciones al software se realizan sobre el Código fuente. Y es según el Código fuente que se valida la documentación asociada. 


Los sistemas administradores de versiones se suelen integrar a los entornos de desarrollo y realizan administración de versiones del Código fuente. Cada modificación de uno de los archivos del programa va generando una revisión del mismo, y periódicamente se crean líneas base de todo el proyecto. 

De este modo, un equipo de desarrollo puede trabajar en paralelo, compartiendo versiones de archivos de Código fuente y actualizándolos periódicamente según se van creando o modificando los archivos que conforman el proyecto. 

Gestión de configuración en el desarrollo de software 


Como ya habíamos comentado, un elemento de Configuración puede ser prácticamente cualquier producto o subproducto del desarrollo de software. Las especificaciones de requisitos, los documentos de análisis y de diseño, el Código fuente y ejecutable, y los procedimientos y datos de prueba pueden ser sometidos a control de Configuración. 

Con un control riguroso, es posible entonces mantener registro del estado de todos estos elementos, lo que facilita la introducción de cambios si se tiene registro de las dependencias entre ellos, además de facilitar la elaboración de entregables; por ejemplo, si se tiene registro de las dependencias entre los elementos de Configuración, es posible que si se produce un cambio en las especificaciones, los documentos de análisis y diseño y el Código fuente asociados puedan ser actualizados sin que tome demasiado tiempo realizar su búsqueda.

Gestión de configuración en el mantenimiento de software

En el mantenimiento de software, cobra importancia la función del Comité de Control de Cambios (CCC), que se encarga de recibir, estudiar y aprobar las solicitudes de cambio en el software que son presentadas, sea por los usuarios o por los propios encargados del mantenimiento. En este caso, las funciones de control y de auditoria se vuelven casi indispensables, pues es necesario mantener registro de todas las solicitudes de cambio presentadas y del estado actual de cada una de ellas. Un sistema de Gestión de Configuración que apoye la Gestión de solicitudes de cambio, debería permitir el registro por parte de los usuarios de las solicitudes de cambio, su revisión por parte del CCC, y si son aprobadas la creación de ordenes de cambio. 

Un cambio implica generalmente la actualización tanto del Código fuente, como de los documentos de especificación de requisitos, análisis y diseño, casos de prueba y manuales. Por lo tanto, en el escenario anterior, resulta de utilidad mantener un registro de las dependencias entre los elementos de Configuración. El cambio se vera reflejado en la creación de nuevas versiones de los elementos respectivos. 

Gestión en la distribución del software a las PC- Usuarios

Cuando se pone en producción un software, se distribuyen copias del mismo entre los diversos usuarios del sistema. En este escenario, un sistema de Gestión de Configuración debería permitir registrar las Configuraciones (conjunto de versiones de elementos de Configuración) que cuenta cada PC - usuario. Puede ocurrir, que si un mismo sistema se vende a distintos clientes, en algún momento surjan requerimientos contradictorios o necesidades que lleven a la creación de variantes de los elementos de Configuración. El sistema de Gestión de Configuración apoyaría entonces al momento de estudiar una solicitud de un usuario a conocer cual es la Configuración con la que esta trabajando. 

Modelo Genérico 

A continuación se propone un modelo genérico para la Gestión de Configuración del software, representado en la figura 2. Este modelo procura abarcar los escenarios presentados anteriormente y da soporte a los siguientes requerimientos: 

1. Permite la creación de tipos de elementos de Configuración. De este modo, es posible que el usuario cree sus propios tipos de elementos dependiendo que es lo que desea controlar. 

2. Permite la creación de tipos de relaciones entre los elementos de Configuración. Es posible que el usuario cree los tipos de relaciones que desee, y que especifique dependencias para la creación de nuevas versiones entre el origen y el destino de la relación. Estas dependencias pueden ser: 


 Ninguna, 


 Condicional-Origen (sí el origen cambia, el destino podría cambiar), 



 Condicional-Destino (sí el destino cambia, el origen podría cambiar), 

 Obligatoria-Origen (sí el origen cambia, el destino debe cambiar), 

 Obligatoria-Destino (si el destino cambia, el origen debe cambiar).




3. Cada tipo de elemento y cada tipo de relación puede tener los campos de información adicional que el usuario considere necesarios. 



4. Un elemento de Configuración corresponde a un tipo y sus versiones pueden estar relacionadas con versiones de otros elementos según se creen relaciones para él. 

5. Un elemento de Configuración tiene un conjunto de versiones asociadas, cada una de las cuales esta asociada al usuario (dueño) que la creo. 

6. Un conjunto de versiones de elementos de Configuración conforma una Configuración. Es posible de este modo registrar muchas Configuraciones para el mismo software, que pueden diferir en cuanto a versiones, o ser variantes (Configuraciones alternativas). 

De este modelo es posible obtener información acerca de: 


1. Los tipos de elementos sometidos a Gestión de Configuración.

2. Las relaciones entre dichos elementos.

3. Las dependencias para la creación de versiones al momento de analizar la introducción de un cambio. Es posible conocer como un cambio en un elemento afectara a los demás.

4. Los usuarios que generaron cada versión de un elemento. 



Tomado de: http://www.histaintl.com/soluciones/configuracion/configuracion.php




sábado, 9 de abril de 2016

METRICAS DEL SOFTWARE




METRICAS PARA LA CALIDAD DE ESPECIFICACION

Usaremos estas métricas para evaluar si el diseño del sistema corresponde con los requisitos establecidos

METRICAS BASADAS EN FUNCIONES
Esta técnica es una de las adecuadas a nuestro proyecto, ya que gracias a ella podemos medir la funcionalidad de nuestro sistema de ventas por catálogo, estimar el costo o esfuerzo requerido para desarrollarlo, prevenir el número de errores y prever el número de componentes.

METRICAS DE DISEÑO ARQUIECTONICO
Esta técnica se utilizará para conocer la complejidad estructural, de datos y del sistema, basándonos en el patrón arquitectónico utilizado (MVC).

METRICAS DE PROYECTO

METRICAS DE PROYECTO WEBAPP
Este tipo métricas se ajusta mejor a nuestro proyecto ya que el entregable final en este, será una aplicación web, nos permite conocer de manera cuantitativa la funcionalidad que otorgamos a nuestros clientes además de permitirnos conocer la facilidad de uso del sistema por parte del usuario y si la estética de la aplicación es apropiada al dominio de esta. Teniendo como medidas:
·         Número de páginas web estáticas
·         Número de páginas web dinámicas
·         Número de vínculos de páginas internas
·         Número de objetos de datos persistentes
·         Número de sistemas externos puestos en interfaz
·         Número de objetos de contenido estatico
·         Número de objetos de contenido dinamico
·         Número de funciones ejecutables

HERRAMIENTAS DE SOFTWARE LIBRE PARA METRICAS DE DESARROLLO

SONAR. Una herramienta de software libre y gratuita que permite gestionar la calidad del código fuente. Al instalarla podremos recopilar, analizar, y visualizar métricas del código fuente. Sonar es básicamente la fusión de las siguientes herramientas Checkstyle y PMD, más otras que no menciono en este post, como Findbugs, Clover y Cobertura. También realiza un histórico de todas las métricas del proyecto. Permite visualizar informes con resúmenes de las métricas. Página oficial: http://www.sonarsource.org. Trabaja, principalmente, para Java. Aunque da soporte, gracias a la amplia librería de plugins (algunos de pago), a los siguientes lenguajes: ABAP, C, Cobol, C#, Delphi/Pascal, Flex/ActionScript, Groovy, JavaScript, Natural, PHP, PL/SQL, Visual Basic 6, Web y XML.  La licencia es: LGPL.

Simian. Herramienta para detectar código duplicado (que es el mayor enemigo de la mantenibilidad, es decir, que si hay código repetido te va a costar más euros mantener el software, te recomiendo aquí este post) en desarrollos realizados con los lenguajes: Java, C#, C, C++, COBOL, Ruby, JSP, ASP, HTML, XML y Visual Basic. Página oficial: http://www.redhillconsulting.com.au/products/simian/. La licencia es libre si su uso está destinado a proyectos OpenSource.