Mantenimiento evolutivo
La denominación de mantenimiento evolutivo se ha reservado tradicionalmente para los mantenimientos de los desarrollos de software. Sin embargo, por analogía, nuestra experiencia nos muestra que un Sistema de Misión Crítica (que además incluye software), se comporta en su conjunto de la misma manera que un Desarrollo de Software y por eso aplicamos esta misma terminología y metodología para abordar las mejoras.
De hecho, y aquí reside la esencia y la diferenciación de nuestro origen IT, nosotros modelizamos el CPD utilizando una personalización de UML (Unified Modeling Language), en la que mediante la utilización de diagramas (de estructura estática, de casos de uso y de estados), estudiamos el comportamiento del CPD estática y dinámicamente y su posible evolución.
Los resultados de estos análisis son de interés, no sólo para definir los test y pruebas a realizar en su Sistema, sino que nos permite ser una referencia para la industria. En este sentido, sabemos que somos una referencia para nuestros proveedores a los que aportamos y proponemos posibilidades de mejora en sus equipos y desarrollos.
Tipos de mantenimiento
Aunque pueda parecer un tema formal, nos gustaría comentar que, de todas las clasificaciones con las que hemos trabajado durante años, la que propone el MAP (Métrica v3) nos parece la más precisa, aunque con alguna matización.
Según el MAP y atendiendo a los fines, los tipos de mantenimiento pueden clasificarse de la siguiente manera:
Correctivo: son aquellos cambios precisos para corregir errores del producto software.
Evolutivo: son las incorporaciones, modificaciones y eliminaciones necesarias en un producto software para cubrir la expansión o cambio en las necesidades del usuario. Nota: realmente podría llamarse a este Mantenimiento Perfectivo.
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.
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. Nota: Es el que tradicionalmente se conoce como Mantenimiento Preventivo.
Marco conceptual metodológico del servicio Aquads IT Evolution:
En nuestro caso, lo que llamamos el servicio Aquads IT Evolution se basa en:
I.- Una metodología para el análisis y gestión de riesgos (Magerit, complementado con Métrica y UML) que nos daría como resultado:
- Unas necesidades de seguridad
- Los controles necesarios a implementar
II.- Con la conclusión de los controles a implementar, la ISO17799 nos aportaría los catálogos de controles (el conjunto de “buenas prácticas”).
III.- Por último, y solo en el caso de necesitar una certificación, la UNE71502 nos aportaría el conocimiento de cómo debe ser un sistema de seguridad que quiere ser certificable por una entidad de certificación.
Pero, contando con todo ese background metodológico y ahí reside nuestra propuesta de valor como empresa de ingeniería, nuestra aportación consiste en saber cuándo debemos aplicarla a rajatabla y cuando no.
En definitiva, hemos interiorizado estas metodologías que hoy nos permiten SIMPLIFICAR y ADAPTAR a la envergadura de su proyecto las mejoras necesarias: es decir, aplicamos metodología pero no somos esclavos de ella.
Todo ello nos permite proponerle las incorporaciones, modificaciones y eliminaciones necesarias para cubrir la expansión o cambio en sus necesidades (definición “de libro” de Mantenimiento Evolutivo).
Permítanos que le pongamos dos ejemplos heterogéneos, pero de absoluta actualidad, que aclaren nuestra propuesta:
Ejemplo 1: Sistemas de alta densidad (Blades)
Muchos de ustedes se habrán planteado la incorporación de esta tecnología en sus CPDs, pues bien, ello exige un replanteamiento en este caso a nivel medioambiental muy importante que debe abordarse con rigor.
Ejemplo 2: Proyectos de CRM , BI (BSC)
En todo proyecto de CRM o de Balance Scored Card, por citar dos proyectos de relevancia estratégica, subyace un proceso de cambio, en muchos casos dramático.
Todo proceso de cambio debe gestionarse (por desgracia, no vale solo el sentido común) y como sabemos, uno de los factores claves del éxito es planificar, conseguir y reconocer victorias a corto plazo.
En la metodología de gestión del cambio, se identifican siempre tres tipos de personas:
- los apóstoles (los que nos ayudarán)
- los indecisos,
- los que se resisten al cambio e intentarán dinamitarlo que en algunos libros los llaman “terroristas”, (hombre, tampoco exageremos).
Sin embargo, estas personas que se resisten pueden “dinamitar” una victoria a corto plazo fácilmente si su infraestructura no está preparada y hacer fracasar todo el proyecto que no conseguirá la credibilidad que buscamos.
Por no hablar de que algunos de los riesgos a los que principalmente está expuesta la tecnología de información en soluciones CRM, como pueden ser el uso inadecuado de los datos de las tarjetas de crédito de los clientes, la fuga de información sobre próximas campañas, ataques de Internet, accesos no autorizados (intrusos), no disponibilidad del servicio, sabotaje, información alterada o eliminada, entre otros, transacciones en líneas perdidas, bases de datos de clientes que se distribuyen fuera de la compañía, daño físico a la infraestructura de tecnología de información, uso inadecuado de los datos del cliente (LOPD), divulgación de información confidencial,… (Bueno, tampoco hay que asustarse, pero sí conocerlo)
En consecuencia, es fundamental determinar este riesgo que antes del proyecto no existía y hoy puede ser muy peligroso y su infraestructura debe evolucionar antes del lanzamiento del mismo.
Creemos que son dos ejemplos suficientemente explicativos de en qué podemos ayudarles.