Un error común al interpretar SSD

(repost) Originalmente Publicado el 6 marzo, 2014

El área de procesos SSD (Service System Development) tiene un paralelismo importante con las áreas de ingeniería del modelo CMMI for Development. Esto es porque quienes  definieron el modelo de servicios entendieron que definir un servicio desde cero, puede verse, en cierto sentido, de forma análoga al desarrollo de un software.
El servicio tiene que pasar por una fase de captura y análisis de requisitos, donde se identifica el alcance y las necesidades que vendrá a cubrir este nuevo servicio, luego por una fase de diseño, construcción, verificación…esto es, probar que el servicio cumple con sus requisitos y finalmente, validar que es el servicio cumple las expectativas del cliente, o recibe el valor que esperaba del mismo.
Si aplicamos el modelo a una organización que brinda servicios no IT, SSD no presenta inconvenientes en su interpretación. ¿O sí?
Pero si vamos a las organizaciones que proveen servicios relacionados con software, comienzan las confusiones y conflictos.
Por eso, siempre hay que volver al comienzo: la definición del servicio, y de sus requisitos.
Si brindamos servicios de AM, o mantenimiento de una aplicación X, podríamos simplificar un escenario diciendo que, independientemente del cliente, los requisitos del servicio son los mismos: se necesitan recursos de infraestructura, personas con ciertos skills y los parámetros de capacidad, disponibilidad y continuidad ofrecidos/acordados. Esos son los requisitos de mi servicio AM para la aplicación X.
Si lo vemos con el enfoque de desarrollo de software, los requisitos serían todos los pedidos de corregir, ampliar o cambiar una porción de código de la aplicación X… en cambio, para el servicio, estas son peticiones de servicio.
¿Se entiende por qué lo que es un requisito desde el modelo de desarrollo (CMMI-DEV), no es requisito para servicios (CMMI-SVC)?

Leave a Comment

Your email address will not be published. Required fields are marked *