Class 20, 21: Pruebas del SW

ACTIVIDADES REALIZADAS

Panel y videoconferencia sobre pruebas del software, se termino con una explicacion de diapositivas y un crucigrama para evaluar los conocimientos adquiridos

ESTRATEGIAS UTILIZADAS

¿Que tipos de prueba de programa deben ser considerados ?

• Caja negra. No esta basada en el conocimiento del código o diseño interno, determina la funcionalidad del sistema.

•Caja blanca. Esta basada en la lógica interna de la aplicacion y el código. Hace una cobertura de declaraciones del código, ramas, caminos y condiciones.

•Unidad de testeo o prueba. Es la escala mas pequeña de la prueba, esta basada en la funcionalidad de los módulos del programa, como funciones, procedimientos, módulos de clase, etc. En ciertos sistemas también se verifican o se prueban los drivers y el diseño de la arquitectura.

•Integración incremental. Cuando nuevas funciones son ingresadas al sistema se hace la prueba basándose en la funcionalidad, la dependencia con otros módulos y la integración con el programa completo.

•Prueba de integración. Se basa en las pruebas de conexiones y comunicaciones entre diferentes módulos. Es esencial en sistemas de cliente_servidor o red.

•Prueba funcional. La caja negra hace la prueba funcional de los requerimientos de la aplicacion y generalmente es realizada por el programador, en cambio, la prueba funcional es realizada por los testers.

•Prueba de sistema. Es una prueba de caja negra incluyendo todos los componentes del sistema desde el hardware a la documentación.

•Prueba de fin a fin. Es similar a la prueba de sistema pero esta involucra la interacción con otros hardwares, bases de datos y redes.

•Prueba de sanidad. Determina si la nueva versión de un software esta bien realizada y si necesita un nuevo esfuerzo en la prueba de software. Por ejemplo la nueva versión de un programa cumple con casi todos los requisitos pero destruye la base de datos al leerla, por lo tanto se dice que este software no esta en una condición sana.

•Prueba de regresión. Es una nueva revisión en las pruebas del programa luego de que este haya sufrido algún cambio o por apuros de tiempo o la modificación fue en el ambiente en que se desenvuelve. Actualmente aparecieron herramientas automatizadas que hacen que este tipo de pruebas no lleve demasiado tiempo.

INTERVIENE LA INGENIERA YURAIMA SOBRE EL TEMA O SOBRE LA PREGUNTA QUE SE LANZO Y DA SU OPINION O COMPLEMENTA LO QUE TIENE QUE VER SOBRE CUALES TIPOS DE PRUEBAS HAY

•Prueba de aceptación. Es la prueba final basada en las especificaciones del usuario o basada en el uso del programa por el usuario final luego de un periodo de tiempo.

•Prueba de carga. Esta basada en las aplicaciones bajo cargas pesadas , generalmente usadas en sitios web y en servidores con gran cantidad de datos donde se determina en cuales puntos existen degradaciones del sistema.

•Prueba de estrés. Es una prueba de carga y perfomance basada en la funcionalidad del sistema bajo cargas pesadas , un gran numero de repeticiones, manejo de grandes datos y demasiadas preguntas a bases de datos grandes.

•Prueba de perfomance. Es una de las pruebas finales y sirve para definir los requerimientos y la calidad del software, en base a las pruebas de carga y estrés. Incluye entrevistas con el usuario y programador.

•Prueba de instalación y desinstalación. Determina la eficiencia de los procesos que instalan y desinstalan las aplicaciones del programa.

•Prueba de recuperacion. Es la prueba que evalúa que tan bien se recupera el sistema luego de bloqueos , fallas del hardware u otros problemas catastróficos.

•Prueba de seguridad. Evalúa que tan bien el sistema se protege contra accesos , internos o externos, no autorizados, esta prueba requiere sofisticadas tecnicas y herramientas.

•Prueba de compatibilidad. Evalúa el desempeño del software en diferentes hardwares , sistemas operativos , redes, etc.

•Prueba de exploración. Es una prueba informal del software que no esta basada en ningún plan o caja de prueba y a menudo los testers aprenden del programa al explorar todas las aplicaciones posibles.

•Prueba de anuncio. Es similar a la prueba de exploración pero los testers deben tener suficiente noción sobre el funcionamiento del programa antes de comenzar esta prueba. Incluye reunión con analistas y programadores.

•Prueba de usuario. Determina si el usuario se desenvuelve satisfactoriamente con el programa.

•Prueba de comparación. En esta prueba se comparan los pro y los contra del programa con los programas creados con la competencia.

•Prueba alfa. Es la prueba cuando la aplicacion esta cerca de la entrega al usuario. Se hacen pequeños cambios generalmente en el diseño de interfaces. Esta prueba es hecha por usuarios.

•Prueba beta. Es la búsqueda de bugs en el programa completo. Generalmente es hecha por usuarios.

•Prueba de mutación. Esta prueba esta basada en la introducción deliberada de diferentes códigos externos al programa (bugs) para reexaminar si estos bugs pueden ser detectados. Requiere gran disponibilidad de recursos de computación.

3. ¿CUALES SON LOS TEMAS QUE SE DEBEN IMPLEMENTAR  EN UNA ESTRATEGIA DE ÉXITO PARA UNA PRUEBA DE SOFTWARE?

•             Especificar los requisitos del producto de manera cuantificable mucho antes de que empiecen las pruebas

•             Establecer explícitamente los objetivos de la prueba

•             comprender cuales son los usuarios del software y desarrollar un perfil

•             desarrollar un plan de pruba que destaque

•             construir un software robusto diseñado para probarse a si mismo

•             usar revisiones tecnicas fromales y efectivas como filtro previo a la prueba.

•             realizar revisiones tecnicas formales para evaluar la estrategia de prueba

•             desarrollar un enfoque de mejora continua para el proceso de prueba.

EJERCICIO DE APAREAMIENTO

1. Prueba de caja blanca	3	Es un proceso que puede planearse y especificarse sistemáticamente.
2. depuración	4	No esta basada en el conocimiento del código o diseño interno, determina la funcionalidad del sistema.
3. prueba	1	Esta basada en la lógica interna de la aplicación y el código. Hace una cobertura de declaraciones del código, ramas, caminos y condiciones.
4.prueba de caja negra	5	Se basa en las pruebas de conexiones y comunicaciones entre diferentes módulos. Es esencial en sistemas de cliente_servidor o red.
5. prueba de integración	7	Es la prueba cuando la aplicación esta cerca de la entrega al usuario. Se hacen pequeños cambios generalmente en el diseño de interfaces. Esta prueba es hecha por usuarios.
6. Prueba beta	6	Es la búsqueda de bugs en el programa completo. Generalmente es hecha por usuarios.
7. Prueba alfa	2	es la acción que lo elimina lo errores que son encontrados durante las pruebas, puede y debe  ser un proceso ordenado, sigue siendo un arte

Class 19: Tipo de Metricas

ACTIVIDADES REALIZADAS

Se hablo y socializo sobre las  Métricas Técnicas del Software.

ESTRATEGIAS UTILIZADAS

Los siguientes contenidos se presentaron:

Métricas de proyecto y de proceso

Nuestros objetivos son establecer:

   Métricas del proyecto à indicadores del proyecto

   Métricas del proceso à indicadores del proceso

         Los indicadores del proyecto permiten al gestor:

   Evaluar el estado del proyecto en curso

   Seguir la pista de riesgos potenciales

   Detectar áreas problemáticas antes de que se conviertan en críticas

   Ajustar el flujo y las tareas de trabajo

   Evaluar la habilidad del equipo del proyecto en controlar la calidad de los productos de trabajo de la IS

 Los indicadores del proceso permiten:

   Al gestor, evaluar lo que funciona y lo que no

   A la organización, tener una visión profunda de la eficacia de un proceso ya existente

Técnicamente no existe gran diferencia entre las métricas del proyecto y del proceso

    Podemos concebir las métricas del proceso como recopilaciones de métricas del proyecto

Métricas de proyecto y de proceso

 Métricas del proceso à indicadores del proceso à mejora en el proceso

    Cuestiones

 Si la gestión se basa en el personal, problema y proceso,

¿por qué nos centramos en mejorar el proceso?

  ¿Por qué el proceso es un factor clave y controlable para mejorar la calidad del software y el rendimiento de la organización?

Métricas del proceso

  

    ¿Cómo medir el proceso?

   Las métricas del proceso se extraen de las métricas del proyecto

   En cualquier caso hay métricas privadas y otras públicas

• Métricas privadas (de uso individual):

•  Índices de defectos (individual, por módulo)

•  Errores encontrados durante el desarrollo

• Públicas para el equipo:

•  Índices de defectos

•  Errores encontrados en revisiones técnicas del proyecto

•  LDC

•  Puntos de función por módulo y función

Métricas del proceso

   Las métricas del proceso pueden ser muy útiles, pero hay que saber interpretarlas

    Normas básicas de interpretación:

  Utilizar el sentido común al interpretar los datos de métricas

  Proporcionar una realimentación regular a particulares y equipos

  No utilizar métricas para evaluar a particulares

  Establecer métricas claras y objetivos para alcanzarlas

 No utilizar métricas para amenazar a particulares o equipos

  Si una métrica identifica un área problemática no se debería considerar como negativa

• Considerarlos como un indicador de mejora de proceso

   Hay que interpretar todas las métricas en su conjunto, y no primar una en particular

• No obsesionarse con una sola métrica, excluyendo otras importantes

Métricas del proceso y mejora del proceso

    La utilización de métricas e indicadores fiables da lugar a una mejora estadística del proceso del software (MEPS)

   Esta mejora se basa en un análisis de fallos que identifica la causa y origen de errores y defectos para varios proyectos de software

  Error: fallo en un producto generado durante el proceso de

IS que es detectado antes de la entrega al cliente

   Defecto: fallo detectado después de la entrega al cliente.

Métricas del proceso y mejora del proceso

 Análisis de fallos:

1.   Se categorizan por origen todos los errores y defectos de varios proyectos

2.   Se registra el coste de corregir cada error y defecto

3.   Los errores y defectos de cada categoría se cuentan y se ordenan de mayor a menor coste

4.   Se computa el coste global de errores y defectos de cada categoría

5.   Los datos resultantes se analizan para detectar las categorías que producen el coste más alto para la organización

6.   Se desarrollan planes para modificar el proceso con el propósito de eliminar (o reducir la frecuencia de apariciones de) la clase de errores y defectos que sean más costosos

Métricas del proyecto

    Las métricas del proceso son estratégicas:

  Determinan el curso del proceso de producción de software

 Las métricas del proyecto son tácticas:

   Permiten adaptar el flujo de trabajo del proyecto actual y las actividades técnicas

 La primera aplicación de las métricas del proyecto ocurre durante la estimación

Se realiza a partir de datos históricos.  A medida que avanza el proyecto, las medidas del esfuerzo y el tiempo se comparan con las de planificación. El gestor utiliza estos datos para supervisar y controlar el avance

Utilización de las métricas del proyecto:

 Para minimizar la planificación del desarrollo

• Haciendo los ajustes necesarios que eviten retrasos y mitiguen problemas y riesgos potenciales

 Evaluar la calidad de los productos en el momento actual

• Modificando el enfoque técnico para mejorar la calidad, si es necesario

Mejor calidad -> Menos defectos -> Menos trabajo -> Menor coste

Métricas del software

 Como el contexto de uso identifica al tipo de métrica, nos referiremos a las métricas del producto y del proceso como métricas del software.

ACTIVIDADES INDEPENDIENTES

Aplicar metricas de diseño a la pagina de la universidad y la pagina de Ingenieria de Sistemas

Class 18: Metricas

ACTIVIDADES REALIZADAS

Socialización de los aspectos más importantes de las Métricas Técnicas del Software.

ESTRATEGIAS UTILIZADAS

Presentación de los siguientes contenidos:

Objetivo

• Cómo medir el progreso de un proyecto de software

Introducción

 La existencia de medidas numéricas facilita el conocimiento de un fenómeno

 Las métricas del software ayudan en el proyecto:

•  En la estimación, control de calidad, evaluación de productividad y control de proyectos
•  En la evaluación de la calidad de los productos y trabajos técnicos
•  En la toma de decisiones tácticas según avanza el proyecto

 Las métricas del software permiten mejorar el proceso

 Hay cuatro razones para medir:

 Caracterizar

• Para comprender mejor los procesos, los recursos, los entornos y establecer las líneas base para comparaciones con evaluaciones futuras

 Evaluar

• Para determinar el estado con respecto al diseño
• Para valorar la consecución de objetivos de calidad
• Para evaluar el impacto de la tecnología y las mejoras del proceso

 Predecir

• Para poder planificar
• Para la extrapolación de tendencias

 Mejorar

• La calidad del producto
•  El rendimiento del proceso

Medidas, métricas e indicadores

Una medida proporciona una indicación cuantitativa de la extensión, cantidad, dimensiones, capacidad o tamaño de algunos atributos de un proceso o producto

 Ejemplo: un programa tiene 10.000 líneas de código (LDC)

 Medición es el acto de determinar una medida

 Ejemplo: Ana será la encargada de medir las LDC de cada módulo del sistema

Una métrica es una medida cuantitativa del grado en que un sistema, componente o proceso posee un atributo dado n   Una métrica relaciona medidas individuales sobre algún aspecto

 Ejemplo: la productividad de este proyecto fue de 500 (LDC/persona-mes)

 Las medidas no sirven para comparar, necesitamos métricas

 En el país A ganan 1000 ($/pm), y en el país B ganan 1500 ($/pm)

¿viven mejor en el país B que en el país A?

 Un bocata cuesta 3$ en el país A, y en el país B cuesta 5$.

Echemos cuentas:

• País A: 1000($/pm)/3($/BM) = 333,33 (BM/pm)
•  País B: 1500($/pm)/5($BM) = 250 (BM/pm)

Conclusión: no sabemos donde se vive mejor, pero en el país A una persona durante un mes puede comer un 33% más de bocatas que en el país B

Medidas, métricas e indicadores

Es decir:

• La medida captura una característica individual
• La medición permite capturar dicha característica
• La métrica permite relacionar y comparar mediciones

Medidas, métricas e indicadores

Las métricas son el fundamento de los indicadores

 Un indicador es una métrica o combinación de métricas que proporcionan una visión profunda del proceso del software, del proyecto de software o del producto en sí

Ejemplo: en el país A, no han aumentado los sueldos en los últimos tres años, pero el índice Bocatas se ha duplicado en ese periodo

Ejemplo: la productividad media de nuestra empresa es de

500(LDC/pm) y en el último proyecto ha sido de

250(LDC/pm)

 Un indicador permite al gestor ajustar el producto, el proyecto o el proceso para mejorar

Ejemplo: en 4 equipos de proyecto software, el de menor productividad no usa una técnica que usan los otros. Se deduce que puede ser recomendable utilizar esa técnica en ese equipo.

ACTIVIDADES INDEPENDIENTES

Investigar mas sobre metricas

Class 17: Ideal

ACTIVIDADES REALIZADAS

Exposicion por parte de los compañeros Marta Delgado y Diego Contreras presentaron en diapositivas los objetivos, descripción, arquitectura, desarrollo e historia del modelo de calidad IDEAL.

ESTRATEGIAS UTILIZADAS

 Presentación de los siguientes contenidos académicos: 

Modelo de Mejoramiento de Procesos de Software o SPI ( Software ProcessImprovement) creado por el SEI, como Sustento para las practicas del CMM.

Iniciar (initiating)

Establecer Fundamentos Básicos para garantizar el éxito de la implantación de todo el modelo.

Ofrecimiento a la Gerencia de todos los Objetivos estratégicos que serán Beneficiados por este esfuerzo

Garantía por parte de la alta gerencia en cuanto a disponibilidad de recursos, infraestructura y priorización del proyecto.

Iniciar (initiating)

Actividades a realizar en esta Fase:

Estímulo.

Establecimiento del Contexto.

Asegurar Apoyo Gerencial.

Infraestructura.

Diagnosticar

Actividades a realizar en esta Fase:

Evaluar y caracterizar practicas

Desarrollar recomendaciones

Documentar resultados

Establecer

Actividades a realizar en esta Fase:

Equipos de accion

Plan de accion

ACTUAR

Actividades a realizar en esta Fase:

Planificar, Ejecutar y seguir la instalacion

Proyectos Piloto

Refinar Solucion

Implementacion

Class 16: CMMI

ACTIVIDADES REALIZADAS

Ex`posicion por parte de los compañeros Pablo Barrera, Daniela García y Leidy Cortés por medio de diapositivas los objetivos, descripción, arquitectura, desarrollo e historia del modelo de calidad CMMI.

ESTRATEGIAS UTILIZADAS

 Presentación de los siguientes contenidos académicos: 

•El CMMI es un enfoque de mejora de procesos que provee a las organizaciones de los elementos esenciales para un proceso efectivo.

•El CMMI es el Modelo de Madurez de Capacidades Integrado.

•Fue desarrollado por el SEI (Software Enginnering Institute).

•Mide la madurez del desarrollo del software en una escala del 1 al 5.

•Integra disciplinas como sistemas y software en un solo marco de trabajo.

•Describe formas efectivas y probadas de hacer las cosas, no es un enfoque radical.

  

 

ORIGENES

Modelo lanzado a partir del 2001 dejando atrás su antecesor padre el comúnmente llamado CMM, que surgió sobre un  requerimiento del Gobierno Federal de los Estados Unidos de América, en el que se desarrolló una primera definición de un modelo de madurez de procesos en el desarrollo de software que era el llamado CMM o SW-CMM.

Ante el  gran numero de factores que dificultaban el desarrollo en la época se buscaba algo que regulara los procesos y cada uno de los pasos en el desarrollo. De igual manera ha surgido en nuestra actualidad los siguientes datos:

v El 25% de todos los proyectos sw se cancelan.

v Las compañías entregan productos a sus clientes con un 15 % de errores no eliminados.

v Muchas organizaciones dedican entre el 30 y 40% de su tiempo y dinero a corregir el producto desarrollado

v En los proyectos software se cumplen los plazos en un 50% de las  ocasiones

 

 

OBJETIVOS

 

• Producir servicios y Productos de alta calidad.
• Crear valor para los accionistas.
• Mejorar la satisfacción del cliente.
• Incrementar la participación en el mercado.
• Ganar reconocimiento en la industria.

 

 

Procesos y Áreas de Proceso

Un proceso…

• agrupa una serie de actividades o acciones, que realizamos sobre unas entradas, para conseguir generar una salida acorde a nuestros objetivos.

• Un proceso incluye Técnicas, Materiales, Herramientas y Personas.

Las Áreas de Proceso de CMMI

 Representan un conjunto de actividades que nos facilitan el camino de la mejora, nos marcan los objetivos a cumplir.

Class 15: Bootstrap

ACTIVIDADES REALIZADAS

Exposicion del modelo Bootstrap por parte de los compañeros Jonathan Rozo y Karina Buitrago por medio de diapositivas.

ESTRATEGIAS UTILIZADAS

MODELO DE CALIDAD BOOTSTRAP

El Estándar Europeo para Evaluación y Mejoras de Procesos de Desarrollo de Software (Bootstrap) es otra de las iniciativas para resolver la crisis del desarrollo de software; mediante prácticas, herramientas y estándares de calidad internacional; mide, evalúa y propone mejoras al proceso de desarrollo de SW que siguen las Unidades de Producción de Software (UPS) de las empresas.

Surge como parte del programa estratégico Europeo para investigación en TI, tiene como principio el reducir costos y mejorar la calidad previendo problemas, en lugar de reaccionar a ellos donde su objetivo es desarrollar un método para la evaluación de procesos de desarrollo de SW.

OBJETIVOS DE BOOTSTRAP

EL MODELO BOOTSTRAP tiene los siguientes objetivos:

Ø  Proporcionar apoyo a la evaluación de capacidad de proceso entre las mejores prácticas de una reconocida ingeniería de software.

Ø  Incluir estándares de software reconocida internacionalmente como fuentes para identificar las mejores prácticas.

Ø  Apoyar la evaluación de como el estándar de referencia ha sido puesta en práctica en la organización.

Ø  Asegurar la fiabilidad de la evaluación.

Ø  Identificar, en la organización, procesos fuertes y débiles.

Ø  Apoyar planificación de mejora con resultados convenientes y confiables.

Ø  Apoyar el logro de los objetivos de la organización planeando acciones de mejora.

Ø  Ayudar a aumentar la eficiencia de los proceso poniendo en práctica la exigencias de estándares en la organización.

CARACTERISTICAS DEL BOOTSTRAP

Las principales características de BOOTSTRAP

El proceso de evaluación: el proceso de evaluación es parte de la mejora. Los resultados de evaluación proporcionan la entrada principal para el plan de acción de mejora y proporciona la reacción de las actividades de mejora puestas en práctica.

Durante una evaluación BOOTSTRAP los procesos organizativos son evaluados para definir cada proceso. La evaluación de capacidad de proceso está basada en el modelo de proceso de BOOTSTRAP.

El modelo de proceso: el modelo de proceso de BOOTSTRAP define niveles de capacidad y procesos. La capacidad de procesos son basados en los siguientes niveles de Capacidad:

• Nivel 0: Proceso Incompleto

• Nivel 1: Proceso de Desempeño

• Nivel 2: Proceso Administrativo

• Nivel 3: Proceso Establecido

• Nivel 4: Proceso Previsible

• Nivel 5. Proceso de Optimización

Cuestionarios: una parte principal de la evaluación es reunir datos. La metodología de BOOTSTRAP proporciona dos cuestionarios, uno para juntra datos sobre la organización de desarrollo de software y el otro para juntar datos sobre el proyecto.

Tanteando, la posición y representación de resultados: los resultados de evaluación son la base para la planificación de mejora de procesos, pero este paple puede ocurrir sólo si los datos de evaluación son confiables y proporcionan una representación buena de la capacidad de la organización. La fiabilidad y la repetibilidad son obtenidas por:

• Asegurar que los asesores tienen el mismo background y usan el mismo acercamiento (este es garantizado por el proceso de acreditación del asesor de BOOTSTRAP), y

• Aplicando tanteo preciso y posición de reglas.

CRONOLOGIA

AÑO	DESCRIPCION
1930	W. A. Shewhart propone primeros conceptos sobre evaluación y mejoras en procesos.
1982	W. E. Deming y J. M. Juran añaden nuevos conceptos: mejora continua y calidad total.
1987	W. S. Huphrey añade nuevos conceptos sobre procesos de software
1987	Se publica la norma ISO 9001
1989	Inicia el proyecto Espirit No.5441, que después se convertiría en Bootstrap.
1991	Se publica la versión 1.0 de CMM
1992	Se publica la versión 2.22 de Bootstrap
1992	Inicia SPICE
1993	Se publica la versión 1.1 de CMM
1993	Se constituye el Bootstrap Institute

EL BOOTSTRAP INSTITUTE

Tras concluir el proyecto inicial  de  ESPIRIT 5441, sus miembros constituyen el  Bootstrap Institute como un nuevo Grupo de Interés  Económico  Europeo.

Actualmente este instituto es quien dirige los  destinos  de la metodología y está constituido por

  

Arquitectura del Modelo de Procesos de BOOTSTRAP

Usando la tríada presentada como punto de partida, se define una arquitectura en forma de árbol que identifica las categorías de proceso, las áreas de proceso, los procesos y las mejores prácticas. En general, se utiliza el proceso de evaluación del método Bootstrap para medir el estado actual de la práctica de desarrollo de software dentro de una organización. La evaluación se basa en un cuestionario que está formado por listas de verificación (checklists) de acuerdo con unos atributos clave, de esta manera se calcula la media agregada por atributos clave y consecuentemente el nivel de madurez, basándose en los cinco niveles de madurez del CMM.

ESTRUCTURA DE BOOSTRAP

El modelo de procesos de Boostrap 3.2 tiene la siguiente estructura

1- Organización

ORG.1 – Ingeniería del Negocio

ORG.2 – Gestión de Recursos Humanos

ORG.3 – Gestión de la Infraestructura

2- Metodología

2.1- Ciclo de Vida Dependiente

ENG.0 – Definición de desarrollo

ENG.1 – Análisis de Requerim. del Sistema

ENG.2 – Diseño de la Arquitectura del Sist.

ENG.3 – Análisis de los Requerim. del SW

ENG.4 – Diseño de la Arquitectura del SW

ENG.5 – Diseño Detallado del SW

ENG.6 – Implementación y Prueba del SW

ENG.7 – Prueba e Integración del SW

ENG.8 – Prueba e Integración del Sistema

ENG.9 – Mantenimiento

ENG.10 – Migración

ENG.11 – Retiro

2.2- Ciclo de Vida Independiente

2.2.1- Gestión

MAN.0 – Gestión

MAN.1 – Gestión del proyecto

MAN.2 – Gestión de la Calidad

MAN.3 – Gestión de riesgos

MAN.4 – Gestión de subcontrato

MAN.5 - Gestión de reuso

2.2.2- Soporte

SUP.1 – Documentación

SUP.2 – Gestión de la configuración

SUP.3 – Aseguramiento de la calidad

SUP.4 – Verificación

SUP.5 – Validación

SUP.6 - Revisión completa

SUP.7 – Auditoria

SUP.8 – Resolución de problemas

2.2.3- Cliente Proveedor

CUS.1 – Adquisición

CUS.2 – Gestión de la necesidad del cliente

CUS.3 – Suministro

CUS.4 – Operación de software

CUS.5 – Atención al cliente

2.3- Relacionado a proceso

PRO.1 – Definición de proceso

PRO.2 – Mejora de proceso

PRO.3 – Evaluación de proceso

PRO.4 – Medición 91

3- Tecnología

TEC.1 – Innovación tecnológica

TEC.2 - Soporte tecnológ. para los procesos del ciclo de vida

TEC.3 – Soporte tecnológico para los procesos independientes del ciclo de vida

TEC.4 – Herramienta de integración

La categoría de Organización (Organization) tiene 3 procesos, los cuales tienen una correspondencia con la ISO 15504 v.-98, que presenta algunos cambios respecto a la v.2.0 de la misma norma.

ORG.1 Business Engineering (Ingeniería de negocio), se corresponde con Organisational Alignment. Este proceso sirve para asegurar que todo en la organización tiene una visión común respecto a los objetivos de negocio de la misma.

ORG.2 Human Resource Management (Gestión de los recursos humanos), se corresponde con el proceso del mismo nombre, y que debe permitir conseguir las habilidades individuales y definición de roles necesarios en la organización.

ORG.3 Infraestructure Management (Gestión de la infraestructura), se corresponde con Infraestructure, que se usa para establecer y mantener una infraestructura estable y fiable que de soporte a los demás procesos. Esto puede incluir hardware, software, métodos, herramientas, técnicas, etc.

La categoría de Metodología (Methodology) se divide en procesos dependientes del ciclo de vida, independientes del ciclo de vida y relacionados con los procesos.

1- Life Cycle Dependent (Dependientes del ciclo de vida): está formada por procesos que directamente especifican, implementan o mantienen el producto de software, su relación con el sistema y su documentación.

2- Life Cycle Independent (Independientes del ciclo de vida), se subdivide en:

a) Management (Gestión o administración): procesos utilizados en la gestión del proyecto o algún proceso en el ciclo de vida del software.

b) Support (Soporte): formada por procesos que dan soporte a cualquiera del resto de procesos (incluidos los de soporte), en distintos puntos del ciclo de vida del software.

c) Customer-Supplier (Cliente-Proveedor): está formada por procesos que afectan directamente al cliente, soportan el desarrollo y la transición del software al cliente; y permiten la correcta operación y uso del producto y/o servicio del software.92

3- Process-Related (Relacionados con los procesos): estos procesos también tienen correspondencia directa con los de la ISO 15504 v.-98:

PRO.1 Process Definition (Definición de procesos), se corresponde con Improvement/ Process Establishment, que implica establecer y mantener un conjunto de procesos en la organización junto con la mejora continua de los mismos.

PRO.2 Process Improvement (Mejora de procesos), se corresponde tanto con Improvement Process como con Assessment Process, en los que se determina las fortale zas y debilidades de los procesos para poder así utilizarlo en la mejora de los mismos.

PRO.3 Process Assessment (Evaluación del proceso)

PRO.4 Measurement (Medición)

La categoría Tecnología cuenta con cuatro procesos, que no tienen una correspondencia directa con los de la ISO 15504. Aunque no existe una correspondencia podemos decir que los procesos TEC.2 y TEC.3 pueden ser considerados como parte del proceso de Infraestructura. Por su parte los procesos de “Innovación Tecnológica” e “Integración de herramientas” tienen un alcance distinto, el primero está referido a la forma en la que entran las nuevas tecnologías en la organización, mientras que la segunda busca incrementar el grado de integración de las herramientas en la organización.

ETAPAS DE BOOSTRAP

• Ø  Preparación
• Ø  Ejecución de la evaluación
• Ø  Determinación del nivel de madurez y capacidades;
• Ø  Presentación de los resultados de la evaluación.

En la Etapa de Preparación se planean los pasos de la evaluación y se recoge la información sobre el contexto. El enfoque es respecto de las necesidades específicas y los objetivos de la organización, lo cual determina la definición y el alcance de la evaluación.

Esto incluye encontrar a quién entrevistar, qué unidades organizacionales involucrar y la documentación a ser usada. La metodología Bootstrap y el método de evaluación se presentan para gestionar y proveer de personal técnico para crear una conciencia y conseguir un compromiso con la evaluación.

En esta etapa se realizan las siguientes tareas: (1) un entrenamiento inicial para tener claros los objetivos; (2) se seleccionan los proyectos a ser evaluados para obtener la mejor cobertura de la UPS, (3) se define el personal

de evaluación para minimizar la subjetividad, (4) se define el personal a ser evaluado para obtener la mejor cobertura de los roles involucrados en los proyectos seleccionados y (5) se hace el acuerdo de confidencialidad.

En la Etapa de Ejecución, la información sobre los procesos de la organización es recogida a través de entrevistas y evaluaciones de documentos disponibles. Esto se hace a nivel organizacional y de proyecto. A los entrevistados siempre se les pide que apoyen sus respuestas con evidencias. Las tareas de esta etapa son: (1) una breve reunión de apertura, para obtener un enfoque del personal a ser entrevistado, (2) completar los cuestionarios con características generales de la UPS, (3) completar los cuestionarios del proyecto elegido, incluyendo la evaluación de cómo es aplicado el proceso de producción, (4) revisión preliminar de la evaluación y (5) reunión final, con el fin de presentar los resultados de la evaluación y obtener el consenso para poder pasar a la fase de mejoras.

En la Etapa de Determinar el nivel de madurez y capacidades, es donde se califica cada pregunta con uno de los 5 valores posibles: nulo, débil, regular, extenso o no aplica. Para cada atributo clave se obtiene un nivel de madurez, aplicando un algoritmo numérico, dando como resultado uno de estos niveles: 1-inicial, 2-repetible, 3-definido, 4- administrado o 5-optimizado. Estos niveles de madurez están subdivididos en cuatro. Los procesos de organización y metodología se califican de 1 a 5, mientras que el de tecnología se califica sólo con dos niveles A o B.

En la Etapa de Presentación de los resultados de la evaluación, la organización recibe 2 reportes, uno con los resultados de la evaluación de la UPS y otro con los resultados del proyecto evaluado. El correspondiente a la UPS contiene información como: un resumen ejecutivo, los objetivos de la UPS, los puntos débiles y fuertes, un plan de acción recomendado, etc. El reporte del proyecto contiene: comentarios del proyecto actual detallando lo referente a la organización, metodología y tecnología, los niveles de madurezpara el proyecto, el plan de acción recomendado, etc.

VENTAJAS

• Ø  No lucrativo
• Ø  Fundamentado en modelos ISO 9000 y CMM
• Ø  Tecnología de punta
• Ø  No implica esfuerzo adicional para mejorar y obtener una certificacion
• Ø  ISO 9000

CONCLUSIONES

Ø  Enfocado a pequeñas y medianas empresa.

Ø  Valora la madurez global de una Organización

Ø  Examina procesos individuales de software y valora la conveniencia y el impacto de nuevas tecnología.