4.7. Tendencias actuales aplicadas a la calidad en los Sistemas de información

 4.7. Tendencias actuales aplicadas a la calidad en los Sistemas de información 

Termino muy usado en el mundo de la moda, entendemos como tendencia cualquier idea religiosa, económica, política, artística, etc., que se orienta en determinada dirección. En tecnologías de la información y comunicaciones, TIC, es un concepto muy utilizado por los responsables de sistemas, ávidos por implantar tecnologías que aporten ventajas competitivas a sus organizaciones. En definitiva invertir en la tecnología adecuada en el momento justo; todo un reto.

Es un juego difícil, con mucho riesgo de patinazos significativos; muy pocos predijeron hace 10 años que existiría algo llamado Facebook y que tendría 500 millones de usuarios. Quizás hace 3 años fuera más fácil identificar dicha tendencia y ver que esa cifra, 500 millones, era posible; es decir hace 3 años muchas empresas con productos destinados al usuario final, pudieron identificar que tenían que estar en Facebook sí o sí.

Es una realidad que muchas empresas llegan a determinadas soluciones tecnológicas tarde y mal (llegan porque hay que estar), por miedo a quedar arrinconados, sin comprender para nada estas nuevas tendencias. Esta actitud les impiden capitalizar a tiempo la ventajas, cuando llegan es tarde y solo les supone costes; hay que estar al precio que sea. Pagan vivir siempre mirando al pasado, al "así se ha hecho siempre" sin darse cuenta como la Red acelera los cambios, y como sus directivos al vivir de espaldas a la Red no llegan a comprender a tiempo las nuevas tendencias.

1. Menos riesgo. 
2. Utilización de las redes sociales dentro de las compañías. 
3. Llega el Internet de los objetos. 
4. Cualquier dato es válido. 
5. Cualquier cosa es un servicio. 

4.6. CMMI

4.6. CMMI

Capability Maturity Model Integration (CMMI) es un modelo de aseguramiento de la calidad que busca la mejora continua de las organizaciones mediante el análisis y re-diseño de los procesos que subyacen en la organización. Fue creado por el SEI (Software Engineering Institute) de la Universidad de Carnegie Mellon y patrocinado por el Ministerio de Defensa de los Estados Unidos. Con el propósito de lograr la mejora de los procesos, CMMI provee: 

1. Una forma de integrar los elementos funcionales de una organización
2. Un conjunto de mejores prácticas basadas en casos de éxito probado de organizaciones experimentadas en la mejora de procesos.
3. Ayuda para identificar objetivos y prioridades para mejorar los procesos de la organización, dependiendo de las fortalezas y debilidades de la organización que son obtenidas mediante un método de evaluación.
4. Un apoyo para que las empresas complejas en actividades productivas puedan coordinar sus actividades en la mejora de los procesos.
5. Un punto de referencia para evaluar los procesos actuales de la organización.

CMMI v1.2 corresponde a la tercera versión entregable del modelo CMMI, posterior a las versiones 1.02 y 1.1. Las versiones previas sirvieron como retroalimentación para que los propios usuarios, evaluadores y evaluados hicieran acotaciones sobre posibles mejoras, las cuales fueron estudiadas, refinadas y algunas incluidas en la versión 1.2.  CMMI v1.2 para desarrollo, que corresponde a una de tres constelaciones de prácticas, es una guía que ayuda a manejar, medir y monitorear procesos utilizados en el desarrollo de  productos y servicios de una organización, y contiene prácticas ligadas a la administración de proyectos, administración de procesos, ingeniería y soporte. Las otras dos constelaciones son CMMI para Adquisición que provee una guía para liderar la adquisición informada  y decisiva, y CMMI para Servicios que proporciona una guía para la entrega de servicios a clientes internos y externos de la organización. Ambas constelaciones se encuentran aún en desarrollo. 

Junto con CMMI se desarrolló y publicó el método de evaluación "Assessment Requirements for CMMI (ARC)" en el año 2000, el cual define los requerimientos considerados esenciales para realizar una evaluación de CMMI en una organización y "Standard CMMI Appraisal Method for Process Improvement", (SCAMPI), manual seguido por los evaluadores para medir el nivel de madurez de una organización. Estos dos documentos también se han actualizado como consecuencia de la retroalimentación de la comunidad involucrada en CMMI, generando la última  versión 1.2 de SCAMPI y ARC ambas publicadas el año 2006. 

Representaciones 

La representación usada en CMMI entrega una guía para efectuar las actividades de mejora de los procesos y es utilizada en el método de evaluación. Según el modelo se tienen dos formas para mejorar. Una forma es mejorar un proceso específico o un conjunto de ellos usando la Representación Continua (Continuous Representation) y la otra es la mejora de la organización completa según los procesos definidos y ocupados usando la Representación Escalonada o por Etapas (Staged Representation). En la Tabla 1 se muestran los niveles para estos dos tipos de representaciones. 

Representación Continua 

La representación continua se focaliza en la mejora de un proceso o un conjunto de ellos relacionado(s) estrechamente a un área de proceso en que una organización desea mejorar, por lo tanto una organización puede ser certificada para un área de proceso en cierto nivel de capacidad. Existen seis niveles de capacidad por donde transitan los procesos asociados a un área de proceso y cada nivel es construido sobre el nivel anterior, es decir para que un proceso alcance un nivel de capacidad necesariamente debe haber alcanzado el nivel anterior.  

Los niveles de capacidad son: 

• Nivel 0 - Incompleto: Un proceso es denominado "proceso incompleto" cuando una o más objetivos específicos del área de proceso no son satisfechos. 
• Nivel 1: Realizado: Un  proceso es denominado "proceso realizado" cuando satisface todos los objetivos específicos del área de proceso.  Soporta y permite el trabajo necesario para producir artefactos.
• Nivel 2: Manejado: Un proceso es denominado como "proceso manejado" cuando tiene la infraestructura base para apoyar el proceso. El proceso es planeado y ejecutado en concordancia con la política, emplea gente calificada los cuales tienen recursos adecuados para producir salidas controladas; involucra partes  interesadas; es monitoreado, controlado y revisado; y es evaluado según la descripción del proceso. 
• Nivel 3: Definido: Un proceso denominado "proceso definido" es adaptado desde el conjunto de procesos estándares de la organización de acuerdo a las guías de adaptación de la organización, y aporta artefactos, medidas, y otra información de mejora a los activos organizacionales. 
• Nivel 4: Manejado cuantitativamente: Un proceso denominado "proceso manejado cuantitativamente" es controlado usando técnicas estadísticas y otras técnicas cuantitativas. Objetivos cuantitativos para la calidad y realización del proceso son establecidos y usados como criterios para manejar el proceso.  
• Nivel 5: Optimización: Un proceso denominado "proceso optimización  es mejorado basado en el entendimiento de causas comunes de variación del proceso.  Un proceso en optimización se focaliza en la mejora continua del proceso realizado a través de mejoras incrementales y usando innovación tecnológica. 

Representación Escalonada 

En la representación escalonada o por etapas se ofrece un método estructurado y sistemático de mejoramiento de procesos, que implica mejorar por etapas o niveles. Al alcanzar un nivel, la organización se asegura de contar con una infraestructura robusta en términos de procesos para optar a alcanzar el nivel siguiente. Por lo tanto es una organización la que puede ser certificada bajo un nivel, en este caso llamado nivel de madurez. Según esta representación un nivel de madurez está compuesto por áreas de procesos en donde los objetivos asociados a ese nivel deben ser cumplidos para que la organización pueda certificarse en aquel nivel de madurez. Hay cinco niveles de madurez, los que son descritos a continuación: 

Nivel  1: Iniciado 

En el nivel de madurez 1, la mayoría de los procesos son "ad-hoc" y caóticos. La organización usualmente no provee un ambiente estable para soportar los procesos. Éxitos en estas organizaciones se debe a la competencia y esfuerzos heroicos de la gente dentro de la organización y no al uso de procesos probados. A pesar de este caos, organizaciones pertenecientes al nivel de madurez 1 con frecuencia producen productos y servicios que funcionan; sin embargo, ellos frecuentemente exceden sus presupuestos y no cumplen sus planes. Estas organizaciones son caracterizadas por la tendencia a no cumplir sus compromisos, al abandono de procesos durante tiempos de crisis, y a la incapacidad para repetir sus éxitos. El Nivel 1 está caracterizado además por la realización de trabajo redundante, por personas que no comparten sus métodos de trabajo a lo largo de la organización y cuando una persona clave en un área de negocio específica dentro de la organización se marcha, su conocimiento se va con ella y se pierde para la organización. Es claro que el Nivel 1 es uno donde ninguna organización quiere estar y donde por lo general la mayoría que no tiene sus procesos definidos se encuentra. 

Nivel 2: Manejado 

En el nivel de madurez 2 se ordena el caos. En el nivel 2 las organizaciones se enfocan en tareas cotidianas referentes a la administración. Cada proyectode la organización cuenta con una serie de procesos para llevarlo a cabo, los cuales son planeados y ejecutados de acuerdo con políticas establecidas; los proyectos utilizan gente capacitada quienes disponen de recursos para producir salidas controladas; se involucran a las partes interesadas; son monitoreados, controlados y revisados; y son evaluados según la descripción del proceso. La disciplina del proceso reflejada por el nivel de madurez 2 ayuda a asegurar que existen prácticas y los proyectos son realizados y manejados de acuerdo a los planes documentados. En el nivel de madurez 2 el estado de los artefactos y la entrega de los servicios siguen planes definidos. Acuerdos son establecidos entre partes interesadas y son revisados cuando sea necesario [Chr06]. Los artefactos y servicios son apropiadamente controlados.  Estos además satisfacen sus descripciones especificadas, estándares, y procedimientos. 

Nivel 3: Definido 

En el nivel de madurez 3, procesos son caracterizados y entendidos de buena forma, y son descritos en estándares, procedimientos, herramientas, y métodos. El conjunto de procesos estándares de la organización, los cuales son la base para el nivel de madurez 3, es establecido y mejorado continuamente. Estos procesos estándares son usados para establecer consistencia a través de la organización. Los proyectos establecen sus procesos adaptando el conjunto de procesos estándares de la organización de acuerdo a guías de adaptación. 

Una diferencia importante entre el nivel 2 y 3 es el alcance de los estándares: la descripción de procesos y los procedimientos. En el nivel de madurez 2, los estándares pueden ser un poco diferentes en cada instancia específica del proceso (por ejemplo sobre un proyecto particular). En el nivel de madurez 3, los estándares, descripción de procesos y procedimientos para un proyecto, son adaptados desde un conjunto de procesos estándares de la organización a un particular proyecto o unidad organizacional y así son más consistentes. Otra distinción crítica es que el nivel de madurez 3, los procesos son típicamente descritos más rigurosamente que en el nivel 2. Un proceso definido claramente plantea el propósito, entradas, criterios de entrada, actividades, roles, medidas, pasos de verificación, salidas y criterios de salida.  En el nivel de madurez 3, procesos son manejados más proactivamente entendiendo las interrelaciones de las actividades y medidas detalladas del proceso, sus artefactos y sus servicios. 

Nivel 4: Manejado cuantitativamente 

En el nivel de madurez 4, la organización y proyectos establecen objetivos cuantitativos para medir la calidad y realización de los procesos y los usa como criterios en el manejo de ellos. Los objetivos cuantitativos son definidos en base a las necesidades de clientes, usuarios finales, organización, y actores de los procesos. La calidad y realización de procesos son entendidos en términos estadísticos y son manejados durante todo el ciclo de vida del proceso. Para subprocesos seleccionados, se recolectan y analizan estadísticamente medidas sobre la  realización de procesos.  Estas métricas son incorporadas en el repositorio de métricas de la organización para apoyar la toma de decisiones. Causas especiales de variación de procesos son identificadas y, cuando sea necesario, las fuentes de estas causas son corregidas para prevenir futuras ocurrencias. 

Una diferencia importante entre los niveles 3 y 4 es la capacidad de predicción de la realización del proceso. En el nivel de madurez 4, la realización de procesos es controlada usando técnicas estadísticas y cuantitativas, y el proceso es cuantitativamente predecible, en cambio en el nivel de madurez 3 la realización del proceso es sólo predecible cualitativamente. 

Nivel 5: Optimizado 

En el nivel de madurez 5, una organización mejora continuamente sus procesos basándose en el conocimiento de las causas comunes de variación inherente en los procesos. El nivel de madurez 5 se focaliza sobre la mejora continua de los procesos a través de mejoras continuas, incrementales y tecnológicas. Los objetivos de mejora cuantitativa de procesos para la organización son establecidos, continuamente revisados para reflejar cambios en los objetivos del negocio y usados como criterio en la mejora de procesos.  Los efectos del empleo de las mejoras de procesos son medidos y evaluados contra los objetivos de mejora cuantitativa del proceso. 

Una diferencia importante entre el nivel de madurez 4 y 5 es el enfoque de la variación de los procesos.  En el nivel de madurez 4, la organización está orientada a encontrar causas especiales de variación y proveer una predicción estadística de los resultados.  Sin embargo, los resultados pueden ser insuficientes para alcanzar los objetivos establecidos. En el nivel de madurez 5 la organización está enfocada en las causas comunes de variación de procesos y modificar los procesos afectados para mejorar la realización de ellos  y alcanzar los objetivos cuantitativos de mejora de procesos. 

Dado a que la organización con que se trabajará quiere certificarse en forma organizacional en Nivel de madurez 3, en adelante sólo se detallará el modelo según la Representación Escalonada. 

4.5. PSP/TSP

4.5. PSP/TSP

Team Software Process (TSP) Integración de Equipos de Desarrollo de Alto Rendimiento.

Equipo

Para lograr comprender mejor lo que esta nueva metodología establece, debemos de comprender el concepto de trabajo en equipo o lo que es un equipo.

Una buena definición de equipo seria al menos dos personas que, están trabajando juntos por una meta, objetivo, misión común, donde a cada persona se le ha asignado roles o funciones específicas a desarrollar, y en donde el cumplimiento de la misión requiere algún tipo de dependencia entro los miembros del grupo.

Como se establece en la definición, un equipo se nutre de características como las siguientes:

• Cohesión: es mantener una unión muy fuerte por parte de los integrantes del equipo, logrando así sentirse mas como un todo, que como partes individuales de un todo.

• Metas claras: establecer metas claras y concisas, alcanzables que puedan ayudar al equipo a trabajar para desarrollar algo en concreto sin perderse en detalles que no están dentro del marco de trabajo.

• Retroalimentación: el equipo de trabajo debe de estar continuamente en alimentación del progreso del proyecto o tareas, medir el avance del mismo y pluralizar los resultados, más que individualizarlos.

• Ambiente de trabajo común: es sin duda alguna esencial establecer un muy buen ambiente de trabajo, principalmente basado en la comunicación y en el establecimiento y la definición de cada uno de los roles, así como de las tareas de los miembros del grupo, esto con el fin de evitar mal entendidos y reproches entre los integrantes.

Dentro de esta perspectiva, le team process software, se fomenta en equipos de trabajo para realizar tareas de manera integral y estableciendo pautas para realizar dichas tareas.

Team Process Software (TSP)

El team process software inicio como una herramienta capaz de ayudarle a los equipos de gerentes de proyectos, así como a los ingenieros a organizar y producir proyectos de software a gran escala; se dio a conocer en 1996 y fue desarrollado por el ingeniero y físico Watts S. Humprey, el cual publico el primer reporte técnico en el 2000. Humprey buscaba dotar a sus estudiantes de ingeniería de software, una visión total del ciclo de vida del software.

Esta novedosa herramienta es considerada como una metodología para administrar el trabajo de mejora y desarrollo de los procesos de software, además de garantizar un entorno de trabajo agradable y natural para los equipos. El TSP brinda un conjunto de pasos bien estructurados que indican qué hacer en cada fase del desarrollo del proyecto y muestra cómo conectar cada fase para construir un producto completo, además brinda una ayuda acerca de como conformar equipos para el desarrollo de software de calidad (Humphrey, 2000a; 2000b).

El desarrollo de esta metodología se originó debido a las limitaciones que presentaba PSP (Personal Software Process) a nivel industrial (McAndrews, 2001) ya que el PSP abarca solo las fases de desarrollo de software desde el diseño a las pruebas unitarias y permite tener control del personal mediante la mejora de las habilidades personales, en busca de la reducción de los efectos presentados en los productos y no proporciona la manera de como los ingenieros podrían aplicar estas habilidades en la practica dentro de las organizaciones.

Conociendo estas limitaciones, el ingeniero y físico Watts S. Humprey creó esta metodología con el fin de sufragar los aspectos que quedaban inconclusos por parte de otras metodologías en la evaluación y mejora de procesos. El TSP acopla los principios de los equipos de producto integrados con los métodos de PSP y el modelo CMM, con el fin de producir equipos efectivos de trabajo.

Como se menciono anteriormente, el TSP trabaja en base a la conformación de equipos de trabajo, pero esta forma de laborar no debe de ser tomada a la ligera. Se necesita una planificación de los equipos de trabajo para establecer los roles y las responsabilidades, ya que muchos de los proyectos fallan debido a que los grupos de trabajo se concentran en resolver problemas de manejo de equipos y no en las tareas fundamentales del proyecto. Para ello el TSP se sustenta en el PSP para crear profesionales con cualidades actas para la realización de proyectos muy grandes, dentro de este marco se incluyen los aspectos de generar planes detallados, reunir y usar datos de procesos, medir y gestionar la calidad del producto y definir y usar procesos operacionales.

Objetivos de Team Process Software:

• Maximizar la calidad del software en detrimento de los costos
• Formar equipos que sean capaces de planear y registrar su trabajo, establecer metas bien definidas y sean aptos para realimentar su propio trabajo mediante la medición del mismo.
• Brindar un punto de vista a los gerentes y lideres de proyecto acerca de como monitorear y como motivar a sus equipos de trabajo para sacar el máximo potencial del mismo.
• Establecer una guía para el mejoramiento en organizaciones maduras; asi como acelerar la mejora continua de procesos.

Fases de ciclo de vida de TSP (Team Process Software)

Como toda metodología que busca la continua mejora de procesos, el TSP posee fases en donde se describe una serie de pautas para ayudar a realizar un buen desarrollo de software por parte del equipo de trabajo.

Las fases son:

• Lanzamiento: en esta etapa se establecen las metas a seguir por parte del equipo, se evalúan los objetivos y se dictan los roles y responsabilidades por parte de cada uno de los miembros del equipo. Además se toman en cuenta los requerimientos por parte del cliente y se arma la estrategia a seguir para la culminación del proyecto.
• Estrategia: en esta etapa se crea un modelo conceptual de lo que se requiere para brindar la solución más óptima, estableciendo el desarrollo a seguir, así como las estimaciones de esfuerzo y de riesgos.
• Planeación: una vez desarrollada la estrategia y teniendo en cuenta los procedimientos a seguir y el modelo de la solución del producto, se procede a brindar los roles y las tareas a cada miembro del grupo. En esta etapa se establece el cronograma para la gestión del tiempo y de las tareas que deben de realizarse.
• Requerimientos: para la gestión de los requerimientos se establecen entrevistas con el cliente a fin de delimitar lo que realmente es necesario producir. Los requerimientos son inspeccionados, con el fin de desarrollar un plan de pruebas para el producto terminado.
• Diseño: dentro de las tareas de la etapa de diseño, se establece la elaboración de un diseño de alto nivel, especificando todo los detalles acera de todos los procesos del producto. En esta fase se desarrolla un plan de pruebas de integración.
• Implementación: esta es la fase en la cual el diseño se pasa a nivel de código, se analiza y se hace una revisión exhaustiva en busca de errores. Se compilan y se ejecutan los módulos y unidades, al tiempo que se analiza la calidad de estos.
• Pruebas: en esta etapa el producto ya casi esta terminado, solo falta la integración de los módulos y la documentación para el usuario final, como lo son los manuales de uso. En esta etapa e presentan las diferentes pruebas al sistema con el fin de asegurar su calidad y evaluar el desempeño del equipo de trabajo. 
• Postmorten: se evalúan los análisis de los resultados de las diferentes pruebas y del desempeño del equipo. Se escribe con detalles el reporte del ciclo de vida del proyecto.

Problemas comunes en los equipos

En las organizaciones y para la elaboración de proyectos a menudo se necesita de la formación de equipos para llegar a concluir las tareas. Sin embargo como la mayoría de las personas son diferentes físicamente, también sus personalidades varían de una persona a otra; esto hace que algunas veces se presenten confrontaciones en los puntos de vista de los equipos de trabajo. Entre los problemas más comunes de los equipos de trabajo tenemos:

• Falta de cooperación y compromiso

• Falta de liderazgo

• Falta de confianza

• Revisiones entre colegas inefectivas

• Diferencia en la distribución de cargas de trabajo

• Cabe la pena resaltar que la mayoría de estos problemas son causados por la falta de comunicación y por un mal manejo de situaciones, en las cuales se necesitan estrategias de negociación, cualidades que debería de tener un líder.

Dentro de las estrategias de resolución de conflictos tenemos:

• Evitar/Salirse (Withdrawal): esta técnica se caracteriza porque las personas tienden a evadir el conflicto, aceptar decisiones por defectos y no querer herir los sentimientos de nadie. Aunque esta técnica no es la más óptima, puede ser usada cuando la victoria parece imposible, cuando el conflicto o la disputa es trivial o bien cuando existe una persona en una mejor posición para resolver el conflicto.
• Suavizar/Acomodar: este método concierne en adecuarse a las necesidades de los demás, sin importar las necesidades propias. En esta técnica el acomodador es la persona que sabe cuándo ceder a otros; casi siempre se muestra persuasivo a renunciar a una posición aun cuando no se justifica. Este tipo de persona denominado acomodador nunca es firme, pero siempre se muestra cooperativo. Este enfoque es apropiado cuando existe algo muchos más valioso que las razones del conflicto, por ejemplo la paz; o bien cuando se está en condiciones de ceder hacia el bien común. 

Sin embargo este enfoque es poco probable que brinde los mejores resultados.

• Comprometerse: se presenta cuando existen algunas personas que prefieren lidiar para tratar de encontrar alguna solución al conflicto que trate de satisfacer a todas las partes. Este enfoque se aplica cuando el precio de perder el proyecto es mayor que el precio de los intereses de las partes, esto es cuando las fuerzas de las partes se encuentran muy equilibradas o cuando el tiempo para la resolución del conflicto es apremiante.
• Confrontar/Resolver el problema: se basa en tratar el problema de forma directa, examinando las posibles alternativas. La confrontación es necesaria cuando las personas o las partes no pueden alcanzar una solución, o cuando el problema ha abarcado mucho tiempo sin una aparente solución.

La confrontación debe de realizarse en un lugar aparte y esta debe constituir una conversación objetiva entre las partes o personas involucradas y el mediador

PSP – Personal Software Process

Para hablar de PSP es necesario mencionar que existe un proceso de mejora a nivel de organización el cual está compuesto por tres vértices, y PSP es uno de ellos.

• CMM se enfoca a nivel organizacional
• TSP se enfoca en grupos de trabajo
• PSP se enfoca a nivel personal

El PSP (Personal Software Process o Proceso Personal de Software) es un conjunto de prácticas para la gestión del tiempo y mejora de la productividad personal de los programadores o ingenieros de software, en tareas de desarrollo y mantenimiento de sistemas. Está alineado y diseñado para emplearse en organizaciones que ya usen modelos de procesos como el CMMI (Capability Maturity Model Integration) o ISO 15504. El PSP fue propuesto por Watts Humphrey en el año 1995 y originalmente estaba dirigido solamente a estudiantes.

El origen del PSP se dio debido a ciertos problemas que se empezaron a presentar en forma recurrente respecto al proceso de desarrollo de software. Por ejemplo:

• Imposibilidad de cumplir con las fechas de entrega
• Defectos detectados en el último minuto
• Incapacidad de demostrar el avance del desarrollo, no hay una medición clara ni exacta
• Esfuerzos duplicados y por ende desperdicio de recursos
• Clientes insatisfechos con el servicio brindado

El pensamiento de Humphrey es que la calidad del software está dada por la calidad de los procesos usados para desarrollar y mantener el software. Dentro de las principales ventajas están:

• Ayuda a estimar, planear y desarrollar sistemas de software
• Orientado a manejar de forma continua las habilidades
• Exige disciplina
• Brinda documentación clara sobre:

1. Registros
2. Procedimientos
3. Formularios y plantillas
4. Estándares

• Disminuye la cantidad de errores
• Permite desarrollar planes precisos
• Da a conocer los pasos a seguir para mejorar la calidad
• Provee de datos para medir la mejora
• Asigna tiempo inclusive en etapas de diseño
• Reduce defectos en el código
• Reduce costos
• Se da un seguimiento a los procesos

Bien es cierto que el PSP es considerado como una guía de trabajo personal para ingenieros de software en organizaciones que utilizan el CMMI, sin embargo también existen algunas desventajas:

• Requiere capturar muchos datos
• Requiere mucho tiempo
• Hay resistencia por parte de los desarrolladores hacia el cambio
• Puede extender los tiempos de desarrollo

El PSP trabaja en una estructura de siete niveles, de lo más básico hasta el control.

PSP 0

 Identificar actividades: definición, secuencia

 Bases mejoras: planeación, evaluación, resultados

 Documentar proceso:

• Actividades (Scripts)
• Tiempos (Logs Time)
• Defectos (Defect Logs)
• Resumir planes, resultados (Proyect plan summary)

PSP 0.1

Registrar tamaño del producto y hacer un histórico:

• Líneas de código
• Function points
• Estandarización de la codificación

Registrar problemas y mejoras de propuestas

PSP 1

Mejora la planeación:

• Con la estimación tamaño del producto (histórico)
• Decidir en base a reportes de pruebas

PSP 1.1

Mejora la planeación:

• Con la estimación de recursos
• Introducción de calendarizar, plasmar el plan con números, un presupuesto. 

PSP 2

Mejora la ejecución: 

• Detección temprana de defectos, en base a la predicción de estos.
• Revisiones de diseño
• Revisiones de código
• Uso de checklists (Listas de verificación) 

PSP 2.1

Mejora el diseño:

• Al hacer uso de formas detalladas de diseño (formas C76, C77)  

PSP 3

Mejora el ciclo, mejora del proceso en términos de hacerlo repetible (ciclico):

• Para aplicación a programas de mayor tamaño
• Registro del seguimiento de asuntos importantes
• Análisis del resumen de la planeación, tiempos, tamaños y defectos por cada ciclo

Esta estructura, a su vez, podemos ubicarla en tres grandes etapas o fases:

• Planificación, donde se desarrolla un plan detallado con el objetivo de obtener compromiso por parte de quien realiza el proyecto de desarrollo.
• Desarrollo
• Post-mortem, donde se obtiene y analizan datos para planificaciones y mejoras futuras.

Pasos para Implementar PSP

Los ingenieros deben ser entrenados por un instructor calificado de PSP
La capacitación es sobre grupos o equipos
Requiere un fuerte soporte de administración, en este sentido es necesario que los administradores entiendan el PSP, saber cómo apoyarlos y como monitorear sus avances, sin un adecuado monitoreo los ingenieros caerán otra vez en los malos hábitos
Después de ser bien entrenados y bien administrados, lo que sigue es optimizar la interacción entre equipos y aquí entraría el Team Software Process, el TSP extiende y refina los métodos de CMM y PSP sobre desarrollo y mantenimiento de equipos, y llega a lo que se le llama un equipo auto-dirigido.

4.4. SPICE

SPICE

El proyecto SPICE es el proyecto 07.29 del subcomité SC7. Es un documento compuesto de 9 partes que al momento de publicar el libro estaba en su primera revisión formal como Proposed Draft Technical Report (PDRT). El siguiente estado del proceso de estandarización es llegar al Draft Technical Report (DTR) y finalmente publicar Technical Report type 2 (TR-2). El tipo 2 significa que todavía existen dudas en la comunidad sobre la aceptación del documento. Después de dos años se realiza la última votación para que se vuelva el estándar internacional. 

El Software Process Assessment (SPA) y el proyecto SPICE tienen sus orígenes en el creciente uso y dependencia de la Tecnología de Información que en consecuencia dió el incremento de frustración e incumplimiento de expectativas por parte de los desarrolladores y los usuarios de software. 

Al principio de los 80´s, los militares de E.U. y del Reino Unido se propusieron mejorar el mecanismo de selección de proveedores de software con el objetivo de detener el creciente costo de software, reducir riesgos en su desarrollo y mejorar la calidad de los productos de software. 

En E.U., el departamento de defensa creó el Software Engineering Institute (SEI), con el objetivo de desarrollar el mecanismo de selección de proveedores. El modelo CMM y el trabajo e impacto de este instituto son bien conocidos. 

Por su parte, en el Reino Unido, el comité conjunto del Gobierno, la Defense Industry Trade Association (DITA) y el Computing Policy Consultative Commitee (CPCC) reconocieron la necesidad de abordar con mayor rigor el problema de selección de proveedores para los sistemas que dependen en gran medida de software (Software Intensive Systems). A la agencia Defense Evaluation Research Agency (DERA) se le encomendó la investigación de los métodos de evaluación de proveedores en la industria mundial. 

4.3. MOPROSOFT

MoProSoft 

MoProSoft se define como un modelo de procesos para el desarrollo y mantenimiento de software dirigido a la pequeña y mediana industria y a las áreas internas de desarrollo de software.  Su objetivo principal es incorporar las mejores prácticas en gestión e ingeniería de software. Su incorporación en la industria eventualmente permitirá elevar la capacidad de ofrecer productos y servicios de software con calidad.

Moprosoft fue desarrollado por expertos mexicanos que  recopilaron las experiencias exitosas de la industria de software a nivel mundial, y las adaptaron a las necesidades y características de las pequeñas y medianas industrias mexicanas (PYMEs) desarrolladoras de software.

MoProSoft está dividido en 9 procesos, llamados también prácticas, organizados por categorías de acuerdo a sus respectivas áreas de aplicación. Las categorías de procesos coinciden con los tres niveles básicos de la estructura de una organización: alta dirección, gestión y  operación.

Cada proceso esta cuidadosamente detallado a través de un instrumento llamado Patrón de Procesos. Esta descripción está dividida en 3 partes: descripción general, descripción de prácticas y guías de ajuste. La descripción general incluye los siguientes componentes: nombre del proceso, categoría, propósito, descripción, objetivos, indicadores, metas cuantitativas, responsabilidad y autoridad. La descripción de la práctica incluye: roles involucrados y capacitación, actividades, diagrama de flujo de trabajo (en UML), verificaciones y validaciones, incorporación a la base de conocimiento, recursos de infraestructura, mediciones, capacitación, situaciones excepcionales, lecciones aprendidas.

Moprosoft determina el nivel de madurez de la capacidad de cada proceso a través de una evaluación, que permite colocar a la empresa en uno de los siguientes 5 niveles.

Nivel 1: Proceso Realizado
Nivel 2: Proceso Administrado
Nivel 3: Proceso Establecido
Nivel 4: Proceso Predecible
Nivel 5: Optimización del proceso

También existe el nivel 0, que indica que el proceso está incompleto (caos). El nivel de una empresa corresponde al nivel máximo al que están  todos sus 9 procesos. Par pasar de un nivel al siguiente, la empresa debe cumplir todos los requisitos de los niveles anteriores más los del nuevo nivel. Los requisitos de cada nivel se encuentran detallados en el modelo.

ESTRUCTURA DE MOPROSOFT

4.2. La norma ISO/IEC 9126

4.2. La norma ISO/IEC 9126. 

Esta norma Internacional fue publicada en 1992, la cual es usada para la evaluación de la calidad de software, llamado “Information technology-Software product evaluation-Quality characteristics and guidelines for their use”; o también conocido como ISO 9126 (o ISO/IEC 9126). Este estándar describe 6 características generales: Funcionalidad, Confiabilidad, Usabilidad, Eficiencia, Mantenibilidad, y Portabilidad.

La norma ISO/IEC 9126 permite especificar y evaluar la calidad del software desde diferentes criterios asociados con adquisición, requerimientos, desarrollo, uso, evaluación, soporte, mantenimiento, aseguramiento de la calidad y auditoria de software. Los modelos de calidad para el software se describen así:

• Calidad interna y externa: Especifica 6 características para calidad interna y externa, las cuales, están subdivididas. Estas divisiones se manifiestan externamente cuando el software es usado como parte de un sistema Informático, y son el resultado de atributos internos de software.

• Calidad en uso: Calidad en uso es el efecto combinado para el usuario final de las 6 características de la calidad interna y externa del software. Especifica 4 características para la calidad en uso.

Al unir la calidad interna y externa con la calidad en uso se define un modelo de evaluación más completo, se puede pensar que la usabilidad del modelo de calidad externa e interna pueda ser igual al modelo de calidad en uso, pero no, la usabilidad es la forma como los profesionales interpretan o asimilan la funcionabilidad del software y la calidad en uso se puede asumir como la forma que lo asimila o maneja el usuario final. 

Evaluación Interna, externa y Calidad de Uso ISO/IEC 9126

Las definiciones se dan para cada característica y subcaracterística de calidad del software que influye en la calidad. Para cada característica y subcaracterística, la capacidad del software es determinada por un conjunto de atributos internos que pueden ser medidos. Las características y subcaracterísticas se pueden medir externamente por la capacidad del sistema que contiene el software.

FUNCIONALIDAD

Funcionalidad es la capacidad del software de cumplir y proveer las funciones para satisfacer las necesidades explícitas e implícitas cuando es utilizado en condiciones específicas. 

Se divide en 5 criterios:

1. Adecuación: La capacidad del software para proveer un adecuado conjunto de funciones que cumplan las tareas y objetivos especificados por el usuario.
2. Exactitud: La capacidad del software para hacer procesos y entregar los resultados solicitados con precisión o de forma esperada.
3. Interoperabilidad: La capacidad del software de interactuar con uno o más sistemas específicos.
4. Seguridad: La capacidad del software para proteger la información y los datos de manera que los usuarios o los sistemas no autorizados no puedan acceder a ellos para realizar operaciones, y la capacidad de aceptar el acceso a los datos de los usuarios o sistemas autorizados
5. Conformidad de la funcionalidad: La capacidad del software de cumplir los estándares referentes a la funcionalidad.

CONFIABILIDAD

La confiabilidad es la capacidad del software para asegurar un nivel de funcionamiento adecuado cuando es utilizando en condiciones específicas. En este caso al confiabilidad se amplia sostener un nivel especificado de funcionamiento y no una función requerida.

La confiabilidad se divide en 4 criterios:

1. Madurez: La capacidad que tiene el software para evitar fallas cuando encuentra errores. Ejemplo, la forma como el software advierte al usuario cuando realiza operaciones en la unidad de diskett vacia, o cuando no encuentra espacio suficiente el disco duro donde esta almacenando los datos.
2. Tolerancia a errores: La capacidad que tiene el software para mantener un nivel de funcionamiento en caso de errores.
3. Recuperabilidad: La capacidad que tiene el software para restablecer su funcionamiento adecuado y recuperar los datos afectados en el caso de una falla.
4. Conformidad de la fiabilidad: La capacidad del software de cumplir a los estándares o normas relacionadas a la fiabilidad.

 USABILIDAD

La usabilidad es la capacidad del software de ser entendido, aprendido, y usado en forma fácil y atractiva. Algunos criterios de funcionalidad, fiabilidad y eficiencia afectan la usabilidad, pero para los propósitos de la ISO/IEC 9126 ellos no clasifican como usabilidad. La usabilidad está determinada por los usuarios finales y los usuarios indirectos del software, dirigidos a todos los ambientes, a la preparación del uso y el resultado obtenido.

 La usabilidad se divide en 5 criterios:

1. Entendimiento: La capacidad que tiene el software para permitir al usuario entender si es adecuado, y de una manera fácil como ser utilizado para las tareas y las condiciones particulares de la aplicación. En este criterio se debe tener en cuenta la documentación y de las ayudas que el software entrega.
2. Aprendizaje: La forma como el software permite al usuario aprender su uso. También es importante considerar la documentación.
3.  Operabilidad: La manera como el software permite al usuario operarlo y controlarlo.
4.  Atracción: La presentación del software debe ser atractiva al usuario. Esto se refiere a las cualidades del software para hacer más agradable al usuario, ejemplo, el diseño gráfico.
5. Conformidad de uso: La capacidad del software de cumplir los estándares o normas relacionadas a su usabilidad.

EFICIENCIA

La eficiencia del software es la forma del desempeño adecuado, de acuerdo a al número recursos utilizados según las condiciones planteadas. Se debe tener en cuenta otros aspectos como la configuración de hardware, el sistema operativo, entre otros.

La eficiencia se divide en 3 criterios:

1. Comportamiento de tiempos: Los tiempos adecuados de respuesta y procesamiento, el rendimiento cuando realiza su función en condiciones específicas. Ejemplo, ejecutar el procedimiento más complejo del software y esperar su tiempo de respuesta, realizar la misma función pero con más cantidad de registros.
2. Utilización de recursos: La capacidad del software para utilizar cantidades y tipos adecuados de recursos cuando este funciona bajo requerimientos o condiciones establecidas. Ejemplo, los recursos humanos, el hardware, dispositivos externos.
3. Conformidad de eficiencia: La capacidad que tiene el software para cumplir con los estándares o convenciones relacionados a la eficiencia.

CAPACIDAD DE MANTENIMIENTO

 La capacidad de mantenimiento es la cualidad que tiene el software para ser modificado. Incluyendo correcciones o mejoras del software, a cambios en el entorno, y especificaciones de requerimientos funcionales.

El mantenimiento se divide en 5 criterios:

1. Capacidad de ser analizado: La forma como el software permite diagnósticos de deficiencias o causas de fallas, o la identificación de partes modificadas.
2. Cambiabilidad: La capacidad del software para que la implementación de una modificación se pueda realizar, incluye también codificación, diseño y documentación de cambios. 
3. Estabilidad: La forma como el software evita efectos inesperados para modificaciones del mismo.
4. Facilidad de prueba: La forma como el software permite realizar pruebas a las modificaciones sin poner el riesgo los datos.
5. Conformidad de facilidad de mantenimiento: La capacidad que tiene el software para cumplir con los estándares de facilidad de mantenimiento.

PORTABILIDAD

 

La capacidad que tiene el software para ser trasladado de un entorno a otro.

La portabilidad se divide en 5 criterios:

1.  Adaptabilidad: Es como el software se adapta a diferentes entornos especificados (hardware o sistemas operativos) sin que implique reacciones negativas ante el cambio. Incluye la escalabilidad de capacidad interna (Ejemplo: Campos en pantalla, tablas, volúmenes de transacciones, formatos de reporte, etc.).
2.  Facilidad de instalación: La facilidad del software para ser instalado en un entorno específico o por el usuario final.
3.  Coexistencia: La capacidad que tiene el software para coexistir con otro o varios software, la forma de compartir recursos comunes con otro software o dispositivo.
4. Reemplazabilidad: La capacidad que tiene el software para ser remplazado por otro software del mismo tipo, y para el mismo objetivo. Ejemplo, la remplazabilidad de una nueva versión es importante para el usuario, la propiedad de poder migrar los datos a otro software de diferente proveedor.
5. Conformidad de portabilidad: La capacidad que tiene el software para cumplir con los estándares relacionados a la portabilidad.

CALIDAD EN USO

Calidad en uso es la calidad del software que el usuario final refleja, la forma como el usuario final logra realizar los procesos con satisfacción, eficiencia y exactitud. La calidad en uso debe asegurar la prueba o revisión de todas las opciones que el usuario trabaja diariamente y los procesos que realiza esporádicamente relacionados con el mismo software.

La calidad de uso se divide en 4 criterios:

1. Eficacia: La capacidad del software para permitir a los usuarios finales realizar los procesos con exactitud e integridad.
2. Productividad: La forma como el software permite a los usuarios emplear cantidades apropiadas de recursos, en relación a la eficacia lograda en un contexto específico de uso. Para una empresa es muy importante que el software no afecte al productividad del empleado
3.  Seguridad: Se refiere al que el Software no tenga niveles de riesgo para causar daño a las personas, instituciones, software, propiedad intelectual o entorno. Los riesgos son normalmente el resultado de deficiencias en la funcionalidad (Incluyendo seguridad), fiabilidad, usabilidad o facilidad de mantenimiento.
4.  Satisfacción: La satisfacción es la respuesta del usuario a la interacción con el software, e incluye las actitudes hacia el uso del mismo. A continuación se describe un cuadro donde podemos resumir las características y cada uno de sus atributos, este cuadro le ayudara a visualizar el proceso de evaluación.