miércoles, agosto 31, 2005

Precondiciones y Poscondiciones en los Casos de Uso

Es muy común confundir el uso de las precondiciones y poscondiciones en los casos de uso. Las precondiciones son confundidas con validaciones que hace el sistema durante el caso de uso, mientras que las poscondiciones se asumen como operaciones que hace el sistema después de la ejecución decaso de uso. Para aclarar un poco las cosas propongo las siguientes definiciones

Precondición

Fuente: Internet
Las precondiciones son los hechos que se han de cumplir para que el flujo de evento se pueda llevar a cabo.

Fuente: Wikipedia
La sección de precondiciones se usa para informar cualquier condición que DEBA ser verdadera cuando el usuario inicia el caso de uso. Sin embargo, no son eventos que inician el caso de uso.

Fuente: Craig Larman “Use Case Model: Writing Requirements in Context”
Las precondiciones declaran lo que DEBE ser siempre verdadero antes de iniciar el escenario en el cado de uso. Las precondiciones no son probadas dentro del caso de uso, son condiciones que se asumen verdaderas. Normalmente, una precondición implica un escenario de otro caso de uso que se ha completado satisfactoriamente, como por ejemplo la “autenticación”, o más general “el cajero se identificar y se autentica”.

Conclusión
Las precondiciones son un conjunto de condiciones que deben ser ciertas antes de iniciar el caso de uso. Es muy común que la precondición sea el resultado exitoso de un caso de uso anterior.

Poscondición

Fuente: Internet
Las poscondiciones son los hecho que se han de cumplir si el flujo de eventos normal se ha ejecutado correctamente.

Fuente: Wikipedia
La sección de poscondiciones resumen el estado de las cosas después de que el escenario se completa

Fuente: Craig Larman “Use Case Model: Writing Requirements in Context”
Las garantias de exito o poscondiciones declaran que DEBE ser verdadero cuando se completa exitosamente el caso de uso, sea a través de su escenario principal o a través de un flujo alternativo. La garantía debe cumplir las necesidades de todos los stakeholders

Conclusión
Las poscondiciones indican el estado final de las cosas después de que el caso de uso termine exitosamente a través de cualquiera de sus flujos. No son acciones del sistema sino resultados de acciones. Se deben tener en cuanta las necesidades de todos los stakeholders para la definición de las poscondiciones.

Referencias

viernes, agosto 26, 2005

Aplicación Masiva Desarrollada en Java

Become.com's Web Crawler: A Massively Scaled Java Technology Application.
Muy interesante este artículo en el que explican cómo fue posible implementar una plataforma de Crawlers capaces de indexar más de 3 billones de páginas en el lapso de una semana.

Aunque en general un proyecto como estos no sería implementado en Java, la experiencia en CEO de la compañía en otro proyecto similar le indicó que era una buena alternativa.

Este tipo de ejemplo son los que sorprenden y hacen replantear el estereotipo de las aplicaciones desarrolladas en Java

Artículo Original
Sitio web del Producto

miércoles, agosto 24, 2005

¿Hacia donde va Google?

No pretendo responder esta pregunta porque solo la gente de Google sabe para donde van, pero si quiero plantear una hipótesis basándome en las herramientas que han liberado.

Gmail es tanto un servicio correo, como un cliente de correo web. El servicio de correo es simplemente excelente, porque aun siendo gratuito ofrece una enorme capacidad y gran calidad en cuanto a estabilidad y disponibilidad. El cliente de correo es una de las aplicaciones Web más eficientes, elegantes incluso diría con inspiración en el iPod (por su limpieza de diseño y efectividad de utilización). Este cliente de correo web es sumamente ligero, tiene todas las características importantes de Outlook y sobretodo posee la capacidad de buscar con el poder de Google, lo que evita muchísimo trabajo de clasificación.

Google Desktop 2 es una herramienta que integra muchos servicios, obviamente en el corazón está su motor de búsqueda que, como una gran sorpresa, indexa el mail de Outlook y se integra con este. Además, permite ver fotos, mantenerse informado con los blogs favoritos, saber cómo va la bolsa de Estado Unidos, saber cuales son los temas más candentes de Internet. Además, provee una API que permite desarrollar plug-ins y de esta manera extender los servicios, algo que le encanta al mundo del Open Source.

GoogleTalk. Este es un capítulo aparte, pues se había especulado enormemente sobre la necesidad que Google proveyera un servicio de mensajería instantánea. Entrando en materia, el software es muy sencillo, siguiendo la filosofía de los demás productos, sin embargo, aun le faltan muchas características, tales como emoticons (gráficos que permiten expresar el estado de ánimo), video conferencia y teleconferencia.

Con estas herramientas, claramente Google va en curso de colisión contra Microsoft: Herramientas de productividad, herramientas de colaboración, herramientas de información. Google se va perfilando como una contrincante de Microsoft Office, que es el caballito de batalla de la empresa de Redmond.

Habrá que esperar al próximo año para ver qué otras herramientas de productividad nos ofrecerá esta dinámica compañía y cómo responderá Microsoft a esta afrenta directa.

¿Será posible una alianza Google Apple?
¿Será posible una distribución Google Linux?
¿Será posible una alianza Google StarOffice?
¿Será Google el siguiente Microsoft y Microsoft el siguiente IBM?

lunes, agosto 22, 2005

Participación en el XXV Salón de Informática de ACIS

Este año me invitaron a participar en el XXV Salón de informática de ACIS, llamado "Arquitectura Empresariales de Software: Espejismos y Realidades". La invitación se debe a la experiencia que ha tenido mi compañía y a mi participación directa en todo el proceso. El salón se llevará a cabo en la cuidad de Bogotá, el 29 de Septiembre de 2005.

La conferencia que dictaré se llama "Implementación de una visión de Arquitectura: Experiencias y Resultados".

Además de mostrar nuestros resultado, espero poder tomar el pulso del progreso de la industria del software y, sobre todo, de los clientes de esta industria en este evento.

Actualizaré el blog con los resúmenes de las conferencias en la medida en que participe y me parezcan interesants.

Se puede encontrar más información aquí

De la teoría a la práctica

El jueves pasado (2005/08/18) participé en la tertulia de Ingeniería de Software de la universidad EAFIT. El tema general de la tertulia tenía que ver con las herramientas utilizadas para la gestión, desarrollo y calidad de proyectos de software.

Los puntos más importantes, según mi criterio, fueron:

· Las diferencias entre las visiones del proveedor y del cliente de software
· La voluntad de compartir los conocimientos para lograr mejorar la competitividad de nuestra industria de software

En cuanto a las diferencias entre las visiones del cliente y del proveedor se puede resaltar que el cliente necesita software flexible, resultados rápidos y gran calidad. Aun que estas metas parecen contradictorias, esa es la realidad del negocio y el reto que se debe asumir. El proveedor, por su lado, está mentalizado que lo único constante en software es el cambio y para poder entregar soluciones flexibles necesita el conocimiento técnicos y las herramientas adecuadas.

Respecto a compartir el conocimiento, Raquel Anaya, la directora del grupo de investigación, mencionó algo muy importante: El uso de herramientas Open Source en nuestro medio ha ido desarrollando la cultura de compartir el conocimiento por el bien común. Ahora las empresas de desarrollo se encuentran enfocadas en la integración de herramientas Open Source para cubrir el ciclo completo de desarrollo. Honrando la licencia Open Source, deben liberar el resultado de su trabajo al público, por lo que el esfuerzo conjunto de la industria del software está orientado a mejorar este aspecto. Esperemos que llegue a buen término para el bien, tanto de clientes, como de proveedores.

Cuando este tipo de reuniones involucran a los actores reales del negocio, la discusión se hace más interesante y se enriquecen todos los participantes, especialmente lo estudiantes. La academia, sin lugar a dudas es fundamental, pero periódicamente debe acoger a la industria para verificar como los modelos académicos se adaptan a las realidades del medio.

viernes, agosto 19, 2005

Ser jefe, ser Lider II

El tema del liderazgo es similar en todos entornos, sin embargo cada entorno tiene diferencias que hacen que ciertas características sean más importantes que otras.

Una forma de liderazgo muy efectiva en los ambientes de tecnología consiste en el conocimiento y la experiencia. Dentro de los equipos de desarrollo generalmente hay un líder técnico, este no tiene un cargo formalmente establecido, sino que a través de su experiencia y conocimiento logra establecer un liderazgo entre sus compañeros. Del otro lado de la balanza se encuentra el jefe del equipo, generalmente el coordinador o jefe de proyecto. El perfil del jefe del proyecto es más administrativo que técnico.

Para que el equipo se desempeñe adecuadamente el jefe de proyecto debe asumir un rol motivacional pues el liderazgo real del equipo se encuentra en la faceta técnica. Cuando un jefe de proyecto se involucra en la parte técnica, generalmente la acción es contraproducente causando un rechazo. En contraste, cuando el jefe del proyecto descubre los factores que motivan al equipo y a cada uno de sus integrantes, el equipo se desempeña adecuadamente.

Es responsabilidad del jefe del proyecto conformar un equipo de trabajo con un líder técnico, sino, el mismo tendrá que asumir esta responsabilidad que generalmente no le sienta bien.

En este caso se evidencia como el liderazgo no necesariamente va investido de una autoridad formal y sin embargo es efectivo


  • Parte I

  • Parte III

  • miércoles, agosto 17, 2005

    Luna de Miel en Panamá

    El 30 de Julio de 2005 sucedió el evento más importante en mi vida, finalmente me casé con la mujer que adoro y con la que espero compartir mi tiempo por el resto de la vida.

    Aquí, algunas fotos del hotel, de cuidad de Panamá y de una de las maravillas del mundo, el Canal de Panamá


    Mi esposa y yo saliendo del centro de visitantes del Canal de Panamá


    Mi esposa en centro de visitantes desde donde se pueden observar los barcos pasar a través de las esclusas de Miraflores


    Ese soy yo aguantando el sol para poder ver esta maravilla del mundo funcionado.


    El barco ingrasa al primer juego de esclusas de Miraflores


    Una panorámica de la Ciudad e Panamá desde las tres islas o Amador, como también es conocido


    Catedral del casco antigüo de Ciudad de Panamá


    La moderna cuidad de Panamá y su zona bancaria


    La playa del hotel, costa del oceano pacífico en Panamá. Desde aquí se debería trabajar siempre.


    Una de la lindas piscinas del hotel


    Mi esposa y yo después de unos buenos cocktails, mar y piscina.


    Se nota la emoción por los postres


    Vamos en el carrito de golf que recorre el hotel rumbo al lobby principal para tomar el transporte hacia el aeropueto internacional de Tocumen

    Avances en la Guía de Arquitecto

    Sigue el trabajo en la Guía del Arquitecto. No escribo todos los días pero si lo hago con frecuencia. Como va el trabajo todo indica que no será un libro sino un ensayo o un artículo.

    Los capítulos o títulos que he desarrollado son

    · Los valores del arquitecto
    · Las habilidades del arquitecto
    · La imagen del arquitecto
    · Actividades recurrentes del arquitecto

    Quisiera incluir un título más relacionado con el liderazgo y el estilo de liderazgo que puede asumir un arquitecto de software. Sería útil enriquecerlo con mis experiencias y las experiencias de otras personas dedicadas a esta interesante labor.

    Nueva Cara para Dia a Dia

    Ya era hora de un cambio de look para el blog. El anterior ya me tenía un poco cansado, era algo monótono. Por ahora, estoy conforme con esta nueva plantilla.

    La verdad no le he gastado mucho tiempo la cómo se ve el blog. En lo que si he invertido algo de tiempo es en probar AdSense de Google. Este es un servicio de avisos "inteligentes", pues muestra publicidad relacionada con la información contenida en el sistio. La verdad no he visto mucha relación de lo que he escrito con los anuncios que se generan, pero me gusta como se ve.

    Además estoy utilizando un servicio de Hit Counter, para ver cuantas visitas tengo. Por ahora no es que este sea el blog más popular (de hecho, casi no lo es), pero es interesante ver cómo gente de todo el mundo visita este sitio, y sobre todo, cómo llegan aquí. Excelente esta herramienta gratuita.

    Otra cosa que tengo pendiente es actualizar la foto de mi profile, porque la de FortuneCity no funciona muy bien, lo haré pronto.

    martes, agosto 16, 2005

    Plataforma Fácilmente Administrable

    Introducción
    ¿Se ha preguntado alguna vez qué significa “Plataforma Administrable”? Bueno yo también he hecho y basándome en la funciones de la administración definidas académicamente, he planteado que significa “Plataformas Fácilmente Administrables”.

    Plataforma Administrable
    La plataforma tecnológica debe ser fácilmente administrable lo que implica lo siguiente:
    · Fácil Planeación
    · Fácil Organización
    · Fácil Integración
    · Fácil Dirección
    · Fácil Control

    Fácil Planeación
    La plataforma debe proveer las estadísticas suficientes para facilitar la planeación de la capacidad requerida para soportar la operación del negocio.

    Fácil Organización
    La organización implica la definición de una estructura orientada a lograr los objetivos. En otras palabras, la infraestructura debe facilitar su organización física y lógica, de manera que se logren los objetivos del negocio.

    Fácil Integración
    Los elementos de la plataforma deben ser fácilmente integrables, de manera que cooperen para soportar la operación.

    Fácil Dirección
    Dirigir implica hacer correcciones durante la marcha. Estas correcciones pueden ser de capacidad, de organización, de integración o de funcionamiento en general. La plataforma debe poder ser dirigida fácilmente para lograr los objetivos de negocio.

    Fácil Control
    La plataforma debe proveer puntos de control, de manera que se puede monitorear su comportamiento y se puedan tomar decisiones aplicables en el corto plazo (dirección) o en el medio y largo plazo (planeación).

    Prácticas y Herramientas para la gestión aseguramiento de Calidad

    Introducción
    El resultado del proceso de desarrollo de software consiste en soluciones informáticas para problemas de negocio. La gestión y el aseguramiento de calidad de estas soluciones son clave para lograr los objetivos corporativos por los cuales el software fue concebido.

    A través del proceso de desarrollo de software se deben llevar a cabo actividades que permitan verificar la calidad del producto que se está construyendo. Según la IEEE, existen atributos internos y externos de calidad. Los atributos internos son indicadores de los atributos externos, y estos últimos a su vez, predicen la calidad de uso del producto.

    En esta charla se presentarán algunas de las practicas y herramientas relacionadas con la gestión y el aseguramiento de calidad del producto de software.

    Atributos Internos

    Evaluación de calidad en la especificación de requisitos de software
    La evaluación de los requisitos está en un estado incipiente, pues se está desarrollando una metodología de elicitación de requisitos y una metodología de verificación de requisitos.

    El objetivo de este proceso es lograr calificar el documento de especificación de requisitos de una manera objetiva. De acuerdo con las necesidades del negocio se aplicarán tres plantillas de evaluación y de acuerdo a la calificación obtenida por el documento, se continuará el desarrollo del sistema o se solicitará la revisión de las inconformidades.

    La metodología está siendo desarrollada y se incluirá dentro del mapa de procesos de las gerencias de tecnología.

    Evaluación de la arquitectura de software
    Mediante la evaluación de la arquitectura de software se puede verificar en un estado temprano la estructura de un sistema y las principales prácticas que serán utilizadas para su desarrollo. Estas características son indicadores importantes que permiten vislumbrar la calidad técnica del producto, es decir, mediante los atributos internos de calidad se pueden predecir los atributos externos de calidad. La experiencia ha indicado que cuando un proveedor entrega un documento de arquitectura bien estructurado, claro, conciso, resaltando las prácticas y patrones que utilizará, el proveedor ha entendido el problema. Este entendimiento lo ha logrado desde el punto de vista funcional y no funcional y este documento es la evidencia de ello.

    Cuando se recibe un documento de arquitectura poco estructurado, incompleto o poco claro, la experiencia indica que el proveedor no tiene el suficiente conocimiento técnica y que probablemente requerirá mayor nivel de seguimiento durante el proceso de diseño y construcción para lograr un producto adecuado.

    Existe otro extremo que consiste en que el proveedor cuenta con experiencia técnica pero que no ha entendido adecuadamente el problema. En este caso, el proveedor genera la documentación directamente desde sus herramientas de diseño o herramientas CASE sin agregar valor alguno. En estas situaciones la documentación, más que una herramienta de análisis, se ha convertido en una formalidad lo que la hace muy poco útil y práctica.

    Las herramientas utilizadas para este proceso de evaluación son:

    · Un documento estándar de arquitectura de software basado en el modelo de 4+1 vistas. Este modelo es muy reconocido y fue recomendado por consultores de Oracle, Brasil.
    · Una plantilla en Excel, en la cual se especifican cada uno de los items de evaluación que el analista de arquitectura tendrá en cuenta. Además, la plantilla indica el puntaje mínimo con el cual se aprueba la arquitectura del sistema.
    · La evaluación final se entrega al proveedor con toda la explicación de cada una de las observaciones. Esta evaluación es una evidencia objetiva del proceso de calidad que podrá ser revisada en momentos posteriores.

    Atributos Externos

    Evaluación de calidad mediante pruebas técnicas del producto

    Las pruebas técnicas de productos son necesarias debido a:

    · La complejidad del ambiente de ejecución
    · La convivencia otros productos
    · Requisitos de gran eficiencia en el uso de recursos informáticos
    · Requisitos de bajos tiempos de respuesta requeridos

    Las pruebas técnicas que se realizan son tres:

    Homologación
    La homologación es el proceso mediante el cual se verifican los manuales y los medios de instalación. Los manuales requeridos para todo producto son:

    · Manual de instalación del producto: Contiene las instrucciones detalladas para la instalación del producto
    · Manual de pruebas: Es el manual que utilizan los operadores para verificar que un producto de software se encuentra operativo.
    · Ficha técnica: Describe las características y requisitos técnicos necesarios para la operación del software.

    Además, el proceso de homologación recibe el producto en medio digital, los instala y lo pruebas en el ambiente de pruebas.

    Si el producto de software cumple con los requisitos, se instala y funciona adecuadamente, se obtiene la homologación del producto.
    Pruebas de Telecomunicaciones
    Esta prueba se realiza en un laboratorio que permite simular la latencia y el ancho de banda de todas las oficinas, desde canales de 56 Kbps hasta canales Giga.

    Durante las pruebas de telecomunicaciones se verifica el consumo de ancho de banda. El consumo de ancho de banda es diferente para aplicaciones Web y para aplicaciones C/S. En aplicaciones web se impone una restricción por página, mientras que por la naturaleza de las aplicaciones C/S se impone una restricción por consulta.

    Las inconformidades son registradas en el BugTracker. Si el producto no logra obtener los puntajes establecidos como política de la organización, no se le concede la certificación de telecomunicaciones y se pasa al ciclo de desarrollo nuevamente. Si el producto logra los puntajes establecidos, el producto obtiene la certificación de telecomunicaciones.

    La experiencia indica que los productos que se desempeñan adecuadamente en telecomunicaciones tendrán un comportamiento adecuado en tiempo de respuesta y son menos propensos a sufrir problemas rendimiento.

    Las herramientas utilizadas en este proceso son:

    · Laboratorio de pruebas
    · Simulador de canales
    · Sniffer
    · BugTracker

    Pruebas de Bases de Datos
    El objetivo de las pruebas de bases de datos es identificar posibles cuellos de botella debidos a queries ineficientes o estructuras de datos poco optimizadas.

    Algunos puntos que se tienen en cuenta:

    · Full scan de tablas, es decir, uso ineficiente de índices
    · Bloqueos o deadlock
    · Alto consumo de memoria
    · Alto consumo de procesador

    Las herramientas utilizadas en este proceso son:

    · Consola de administración de base de datos
    · Laboratorio de pruebas
    · BugTracker
    · Hoja de cálculo con el informe del DBA

    Las inconformidades son registradas en el BugTracker y el producto debe ser corregido y preparado para el siguiente ciclo de pruebas. Si el producto cumple con todas las pruebas, entonces se le otorga el certificado de bases de datos y puede continuar el proceso.

    Esta es una de las pruebas más críticas para un software, pues indica el comportamiento que el sistema tendrá y su estabilidad. Aunque el ambiente de pruebas pretende simular el ambiente de producción, este último es mucho más complejo y sensible, de manera que si existe una pequeña falla de base de datos es imperativo su corrección, de lo contrario el problema se convertirá en un problema superlativo que afectará de una manera importante al software.

    Pruebas de Seguridad
    Las pruebas de seguridad son un conjunto de pruebas encaminadas a lograr un nivel de seguridad adecuado, establecido por el área de seguridad informática.

    Estas pruebas consisten en una batería de pruebas previamente diseñadas que abarcan desde el aseguramiento del medio de transporte pasando por técnicas de cross-site scripting y SQL Injection.

    La batería de pruebas de seguridad no es divulgada. Los especialistas en seguridad las ejecutan y reportan el tema en el cual la aplicación debe mejorar, pero evitan divulgar la manera de explotar la vulnerabilidad.

    Las herramientas utilizadas para las pruebas son:

    · Laboratorio de pruebas
    · Sniffers
    · Reverse-Proxy
    · Otras herramientas de seguridad

    Pruebas de Estrés
    Por experiencia, las pruebas de estrés son el ítem más importante de las pruebas técnicas, pues son estas las que exigen al máximo todo el conjunto de componentes del software y permiten hallar fallas estructurales que ponen en riesgo la viabilidad del software. En gran medida, una buena definición de la arquitectura del software evitará problemas en las pruebas de estrés, pero no lo garantiza.

    La experiencia indica que para que el software se comporte bien bajo cargas extremas, su arquitectura debe ser sencilla y robusta, evitando complicaciones innecesarias y artificios inoficiosos.

    Siempre, durante el diseño del software, se debe tener en cuenta el perfil de la aplicación, es decir, el nivel de transaccionalidad, el tamaño del público objetivo, la proporción de usuarios concurrentes y otros temas muy importantes que afectan la escalabilidad.

    Aunque las pruebas de estrés nunca han logrado replicar la carga de los ambientes de producción, si logran detectar problemas estructurales que deben ser corregidos.

    Las herramientas utilizadas son:

    · Laboratorio de pruebas
    · Herramienta de estrés de aplicaciones
    · Sniffer
    · Consolas de monitoreo

    Durante una prueba de estrés se monitorean todos los frentes de manera conjunta; bases de datos, servidores de aplicaciones, otros repositorios de datos, redes, etc...

    Si la aplicación logra mantener sus niveles de errores en cero al nivel de concurrencia objetivo la aplicación obtiene el certificado de pruebas de estrés. De lo contrario se registra la no conformidad en el BugTracker y se prepara un segundo ciclo de pruebas de estrés

    Evaluación de calidad mediante ejecución de pruebas funcionales
    Las pruebas funcionales son llevadas a cabo en de dos maneras: a través de testers y a través de usuarios del sistema.

    Los casos de prueba son levantados durante el proceso de desarrollo de la aplicación y sobre todo, durante el proceso de homologación por el analista de calidad asignado para el producto.

    Al finalizar el proceso de desarrollo, el analista de desarrollo debe certificar que el sistema pasa los casos de prueba levantados por el analista de pruebas. Después del proceso de homologación, en el cual se instala la aplicación en el ambiente de laboratorio, los testers o los usuarios finales ejecutan los casos de prueba y registran bug en el BugTracker. Se realizan las correcciones y se inicia un segundo ciclo de pruebas, después del cual se deben haber corregido estos problemas y el producto debe estar listo para su paso a producción.

    La experiencia indica que cuando se han contratado el servicio de testing el proceso de pruebas funcionales ha sido muy efectivo, sin embargo, existen problemas importantes de costo. El esquema de testing se asemeja a un taxímetro, ya que cada hora que el tester pasa en las instalaciones de la compañía es facturada y si surgen inconvenientes de plataforma o de desarrollo, ese es tiempo facturado que no ha sido productivo en términos de pruebas.

    En caso de un producto desarrollado a la medida, el software ya debió haber sido probado por el proveedor. Existe una corriente de pensamiento que asegura que el servicio de testing debe ser pagado por el proveedor sin cargo directo al cliente, pues este último espera un producto de calidad. Sin embargo persiste el esquema en el cual, aunque el producto es desarrollador a la medida, los testers corren por cuenta de la compañía.

    Herramientas:

    · Metodología de pruebas funcionales
    · BugTracker
    · Laboratorio de pruebas

    Gestión de la Calidad
    El ciclo PHVA (Planear, Hacer, Validar, Actuar) indica que después planear y hacer las cosas se requiere validar que el proceso sea efectivo y se debe actuar sobre el proceso para mejorarlo. En general, la herramienta fundamental para la gestión de calidad es el BugTracker, pues contiene la evidencia objetiva que permite obtener estadísticas sobre los niveles de calidad de los productos que diariamente se pruebas en la compañía.

    Además de la gestión de la calidad durante el proceso de desarrollo, existe la gestión de la calidad posimplantación, es decir, cuando inicia el ciclo de mantenimiento. Este ciclo es vital, pues logra mantener el producto de software vigente. La gestión de la calidad del producto en ciclo de mantenimiento se logra a través de Tickets, que son incidentes reportados por los usuarios finales y que deben ser resueltos por los analistas con unos niveles de servicio previamente pactados.

    Tanto los reportes del BugTracker como los Tickets son indicadores que entran en el proceso de evaluación de la gerencia, de los ejecutivos y de los analistas. Desde este punto de vista se gestiona el proceso de desarrollo y por lo tanto de la calidad de los productos de software.