Calidad de Software

Calidad de Software Manual de Aseguramiento de la Calidad Profesor: Fernando Lpez Gil Alumnos: Agustn Balmer Luis Alfredo Godoy
lvarez
Manual de Aseguramiento de la Calidad

Calidad de Software Balmer Agustn, Godoy Alzares Luis
Introduccin
Al evaluar el estado actual de la empresa se determina que se encuentra entre los niveles 2 y 3 del modelo CMMI. Se lleg a esta conclusin basndose en los requerimientos necesarios de cada nivel. A continuacin se encuentran las distintas reas de proceso necesarias para estar en el nivel 2 y se detallar la forma en que la empresa los cumple con cada punto: Gestin de Requisitos Planificacin de proyectos Monitorizacin y Control de proyectos Medicin y Anlisis Aseguramiento de la calidad Gestin de la configuracin
Gestin de Requisitos
El objetivo de la gestin de requisitos es gestionar los requisitos de los elementos del proyecto y sus componentes e identificar inconsistencias entre estos requisitos, el plan de proyectos y los elementos de trabajo. En la empresa, cada rea se encuentra muy bien estructurada jerrquicamente y los administradores son capaces de determinar la viabilidad de cada proyecto teniendo en cuenta su experiencia en la empresa.
Planificacin de proyectos
El objetivo de la planificacin de proyectos es establecer y mantener planes que define las actividades del proyecto. Las tareas que conlleva la planificacin de proyectos son:

Desarrollar un plan inicial del proyecto Establecer una relacin adecuada con todas las personas involucradas en el proyecto Obtener compromiso con el plan Mantener el plan durante el desarrollo del proyecto
Cada rea de la empresa se encuentra muy bien estructurada con mltiples proyectos completados. Los empleados tienen la experiencia suficiente como para manejar los planes de sus proyectos y los tiempos de cada tarea apropiadamente sin afectar otras reas en caso de problemas. Adems la relacin y coordinacin con los directivos es muy buena y no se presentan problemas a la hora de encarar nuevos proyectos.

Monitorizacin y Control de proyectos

El objetivo de este proceso es proporcionar una compresin del estado del proyecto para que se puedan tomar acciones correctivas cuando la ejecucin de proyecto se desve del plan. Los gerentes de cada rea mantienen reuniones semanales para observar el desarrollo de los proyectos y de esta forma control desvos y problemas que puedan afectar a otras reas de la empresa o a la viabilidad del mismo proyecto.
Medicin y Anlisis
La empresa debe desarrollar y sostener una capacidad de medicin que sea usada para ayudar a las necesidades de informacin de la gerencia. Los datos tomados para la medicin deben estar alineados con los objetivos de la empresa para proporcionar informacin til a la misma. Este es un punto dbil en la empresa ya que la documentacin y mtricas no estn estandarizadas en toda la empresa, esto deja lugar a mejoras sin embargo cada sector se maneja de forma adecuada independientemente del lo que pase en el resto de los sectores.
Aseguramiento de la calidad
El objetivo del aseguramiento de la calidad es proporcionar personas y gestin con el objetivo de que los procesos y los elementos de trabajo cumplan los procesos. Este es otro punto dbil en la empresa ya que cada sector maneja sus niveles de calidad basndose en la experiencia de sus empleados y no hay un sistema global de calidad.
Aseguramiento de la calidad
La empresa debe establecer y mantener la integridad de los elementos de trabajo identificando, controlando y auditando dichos elementos. En este caso se cuenta con una gran variedad de equipos y software los cuales fueron comprados o desarrollados por la empresa, se tiene un registro completo de cada modificacin en estos y cada cambio se registra para mantener la consistencia de estos datos.

Nivel 3 de CMMI
Alcanzar el nivel 3 de CMMI significa que la forma de desarrollar proyectos est definida, es decir, est establecida, documentada, y existen mtricas (obtencin de datos objetivos) para la consecucin de objetivos concretos. Esto no est completamente desarrollado en la empresa ya que no existe una estandarizacin para todos los procesos en esta. Los procesos que hay que implantar para alcanzar este nivel son: Gestin de requisitos Solucin tcnica Integracin del producto Verificacin Validacin Enfoque organizacional del proceso Definicin del proceso de la organizacin Formacin en la organizacin Gestin de riesgos Anlisis de decisiones y resolucin
Gestin de requisitos
El objetivo de este proceso es generar y analizar requisitos de clientes, del producto a desarrollar y de sus componentes. Se deber especificar un proceso de desarrollo de software bien definido que permita obtener las necesidades de los participantes, desarrollar los requisitos de los clientes e implementarlos en un sistema.
Solucin tcnica
El propsito de este proceso es desarrollar e implementar soluciones a los requisitos; las soluciones, diseos e implementaciones abarcan productos, componentes del producto y ciclos de vida asociados al producto. La empresa tiene gerentes de rea y administradores que se encargan de determinar cundo se requiere desarrollar o comprar un nuevo producto. Los desarrolladores de cada rea se encargan de del diseo y la implementacin en caso de desarrollo. Lo que falta desarrollar en esta rea es una estandarizacin del proceso de desarrollo.
Integracin del producto

El propsito es integrar el producto a partir de sus componentes, asegurar que el producto (como parte de la integracin) funciona correctamente, y entregar el producto. En la empresa hay empleados especficamente destinados a la capacitacin de los productos en funcionamiento que se encargan de viajar a las ubicaciones requeridas y explicar a los usuarios finales como utilizarlo. Lo que hace falta en este punto para facilitar la integracin del producto es una estandarizacin de los manuales de operacin para los usuarios. 3

Verificacin y Validacin
La verificacin es asegurar que los productos de trabajo seleccionados responden a los requerimientos especificados y la validacin debe demostrar que un producto o componente satisface su uso pretendido, en el ambiente operativo planeado. La empresa carece de mtodos detallados para verificar y validar, por lo tanto no tiene forma de asegurar que el producto desarrollado sea exactamente el requerido.
Gestin de riesgos
El objetivo de la gestin de riesgos es identificar problemas potenciales antes de que ocurran, de forma que las actividades asociadas a ese manejo de riesgos se puedan planificar y realizar segn se necesiten a lo largo de la vida del producto o proyecto para mitigar impactos adversos para la consecucin de los objetivos. Hace falta una gestin de riesgos detallada y no slo basarse en la experiencia de los administradores para poder determinar posibles riesgos.
Anlisis de decisiones y resolucin

El objetivo del anlisis de decisiones y la resolucin es analizar las posibles decisiones utilizando un proceso formal de evaluacin que evale las alternativas identificadas en base a criterios establecidos. En la empresa existen procesos de comunicacin (fallas, problemas, decisiones, etc.) pero no se encuentran correctamente estandarizados. La jerarqua de la empresa se encuentra bien detallada y las rdenes de los directivos llegan correctamente al resto de los empleados.
Definicin del proceso de la organizacin y enfoque organizacional

El objetivo de este proceso es establecer y mantener un conjunto utilizable de recursos organizacionales del proceso. Si bien cada sector tiene su forma de trabajo y lo hacen correctamente, los procesos deben estar estandarizados para que cualquier nuevo empleado pueda desempearse de la misma forma con la debida capacitacin. Deben identificarse todos los procesos de la empresa para poder aplicar mejoras sobre los mismos.
Formacin en la organizacin
El propsito de este proceso es desarrollar las habilidades y conocimientos de las personas para que puedan desarrollar sus roles de forma eficiente. En la empresa todos los empleados se encuentran altamente capacitados, sin embargo sern necesarios cursos de capacitacin para formar a los empleados en las nuevas formas de trabajo ajustadas a las normas de calidad. Todo nuevo empleado tambin deber ser capacitado con los mismos cursos.

Metas a para la empresa en distintos plazos

Corto plazo: los empleados sern capacitados completamente sobre la manipulacin de
documentacin, el desarrollo del trabajo, la conciencia de la calidad y la idea de Cero Defectos. (1 ao)
Mediano plazo: los procesos, el control y la produccin estarn completamente

estandarizados. (2 aos y medio)
Largo plazo: la empresa alcanzara el nivel de Cero Defectos (5 aos)
Etapas en que se dividir el proceso de aseguramiento de la calidad

Etapa Inicial (2 a 3 meses)
1 Formar un grupo ocupado de la calidad 2 Implementar mtricas 3 Realizar mediciones sobre los procesos 4 Evaluar los costos sobre el estado actual de la calidad de la empresa
Etapa de Capacitacin (6 meses a 1 ao)

5 Estandarizar los mtodos de documentacin en toda la empresa 6 Estandarizar los mecanismos de comunicacin 7 Estandarizar los procesos de desarrollo de software 8 Capacitar al personal sobre la creacin y manipulacin de documentacin 9 Capacitar sobre diseo y desarrollo 10 Estandarizar mtodos de verificacin y validacin sobre los productos
Etapa de la Calidad (1 ao)

11 Capacitar todo el personal sobre la calidad 12 Fijar Metas 13 Estandarizar los mtodos de control 14 Crear un comit de cero defectos 15 Implementar Estimacin de riesgos 16 Fijar un da de Cero Defectos
Etapa de la Evaluacin y Reajuste

17 Implementar la revisin de tcnicas y gestin en un tiempo determinado 18 Fijar trminos para realizar todo de nuevo

Etapa Inicial
Estas decisiones se llevaran a cabo dentro de 2 a 3 meses como mximo. En ese periodo la empresa deber cumplir con las metas planteadas. En esta etapa se realizaran las mediciones y controles para determinar en qu punto se encuentra la empresa sobre su calidad antes de iniciar los cambios, se evaluaran los resultados de acuerdo a las mtricas seleccionadas, y los costos de la calidad en este momento. La creacin de un grupo de la calidad marca el inicio de la nueva forma de pensar la calidad en la empresa, y este grupo se encargara de llevar adelante esto en cada sector.
1 Formar un grupo ocupado de la calidad

Propsito
Se formara un grupo para asegurar la calidad, el cual se dedicara a evaluar el estado de la calidad en cada sector, presentara propuestas, evaluara cambios y cada integrante ser el encargado de notificar a los empleados de su sector sobre las nuevas polticas y la capacitacin.
Justificacin
Debern comunicar la importancia y los beneficios que se lograran si cada uno se concientiza sobre la importancia de la calidad. Tomaran acciones necesarias en su rea y en la compaa.
Procedimiento
El equipo estar compuesto por el director general y el administrador de cada sector. Se designara un miembro que ser el lder del grupo, el cual asumir la responsabilidad de decisin sobre casos importantes o si el grupo no puede reunirse para debatir una idea. Estos representantes hablaran a nombre de su rea para comprometerse a tomar medidas.

2 Implementar mtricas
Propsito
Se deber medir el software para: Indicar la calidad del producto. Evaluar la productividad del agente que desarrolla el producto. Evaluar los beneficios en trminos de productividad y calidad mediante el uso de nuevos mtodos y herramientas de ingeniera de software. Establecer una lnea de base para la estimacin. Ayudar a justificar el uso de nuevas herramientas o de formacin adicional
Justificacin
Las mtricas del software se aplican para valorar cualitativamente algn factor relativo al mismo. No existen mtricas generales y nicas, an menos para la calidad, ya que se puede examinar el software a travs de mltiples perspectivas y con diferentes objetivos.
Procedimiento
A continuacin se detallan las distintas mtricas que sern tenidas en cuenta de acuerdo a la necesidad y el gusto del personal encargado de la evaluacin, la mtrica a elegir deber cumplir los siguientes requisitos: Simple y fcil de calcular Emprica Consistente y objetiva Independiente del lenguaje de programacin Que proporcione informacin til
Los pasos a seguir para utilizar las mtricas sern: Definir un conjunto limitado de medidas. Las medidas se normalizan usando mtricas. Se analizan los resultados y se comparan con promedios anteriores

Mtricas divididas de acuerdo a la fase del producto en la que se aplican
Fase de anlisis
Las mtricas a utilizar miden el tamao del software a desarrollar:
Punto funcin: Sirve para cuantificar la cantidad de funcionalidad que tiene un sistema a
partir de la descripcin del mismo. Se basa en la ponderacin de cinco elementos clave: Entradas de usuario Salidas de usuario Peticiones Archivos Interfaces externas
Mtrica bang: Sirve para calcular el tamao del software a desarrollar a partir del modelo
de anlisis.
Mtrica de calidad de especificacin: Mide la calidad del anlisis y de los requisitos

capturados. A pesar de medir factores cualitativos, propone mtricas como por ejemplo el nmero de requisitos donde los revisores han interpretado lo mismo.

Fase de diseo
Se trabajara con parmetros tpicos de la estructura de los programas (mtricas morfolgicas) o con medidas del grado de cohesin, acoplamiento y complejidad de los algoritmos. Estas mtricas son de caja negra en el sentido que no requieren ningn conocimiento del trabajo interno de un mdulo en particular del sistema.
Mtrica de complejidad de Card y Glass: esta mtrica se basa en dos factores,

calculados para cada mdulo a partir del diagrama de estructuras:
Complejidad estructural: nmero de mdulos que controla un mdulo dado Complejidad de datos: suma de variables de entrada y salida de un mdulo
(dividido por el nmero de mdulos que controla, para que no influya la complejidad estructural)
La complejidad del sistema se calcula como la suma de la complejidad estructural y la complejidad de datos de cada mdulo.
Mtrica de cohesin y acoplamiento: Estas mtricas sirven para cuantificar la cohesin

y acoplamiento de los mdulos en programacin estructurada. A partir de los parmetros de entrada, los parmetros de salida, las variables globales utilizadas y el fan-in y fan-out de los mdulos, genera un valor que es menor cuanto mejores son la cohesin y el acoplamiento.
Mtricas orientadas a objetos
Profundidad rbol de herencia: Esta mtrica se basa en la media de profundidad de la

jerarqua de herencias: cuanto mayor es la profundidad, menor es la calidad del software.
Nmero de hijos: Cuanto mayor es la media de clases derivadas de otra en la jerarqua

de herencias, ms probabilidades hay de que se haya realizado un mal diseo.
Acoplamiento entre clases: Cuanto ms clases se relacionen entre s para realizar una
funcin, mayor ser el acoplamiento y menor la calidad del software.

Fase de codificacin
Las mtricas de la fase de codificacin intentan dar una medida de la complejidad del software construido.
Complejidad ciclomtica y esencial: Las mtricas de complejidad ciclomtica y esencial

fueron desarrolladas para medir la complejidad lgica de un programa. Se basan en pintar el flujo de control como un grafo, donde los nodos son instrucciones y estn conectadas si una se puede ejecutar despus de otra. La complejidad ciclomtica mide el nmero de ciclos que existen en el grafo de control. La complejidad esencial, el mximo nmero de anidamiento de estructuras de control.
Evaluacin General
Correccin: es el grado en que el software desempea la funcin para la que fue creado
y se mide en defectos por KLOC.
Facilidad de Mantenimiento: es la sencillez con que un programa puede corregirse si se

encuentra un error; al adaptarse si su entorno cambia o mejorar si el cliente cambia los requisitos y se mide en forma indirecta en TMC (tiempo medio de cambio).
Integridad: es la habilidad de un sistema para proteger sus diferentes componentes

contra los procesos o elementos que no tengan derecho de acceso a los mismos.
Facilidad de Uso: es el intento por cuantificar la sencillez de una aplicacin al utilizarla.
10

Establecimiento de una lnea base

Es la recopilacin de mtricas que sirven para establecer indicadores en el desarrollo de un proyecto de software. La recoleccin requiere una investigacin histrica de proyectos pasados para reconstruir los datos requeridos, el clculo de mtricas que pueden abarcar una amplio rango de medidas y la evaluacin de los datos se centra en razones intrnsecas de datos obtenidos. El establecimiento de una lnea base ayuda a los gestores de proyecto como desarrollar estimaciones de proyecto significativas, producir sistemas de alta calidad, liberar el producto a tiempo, etc. Una lnea base permite controlar los cambios sin impedir seriamente los cambios justificados, adems consiste en la obtencin de datos recopilados en proyectos previos de desarrollo de software.
Para ser eficaz

Los datos deben ser razonablemente precisos. Los datos deben recopilarse de todos los proyectos que sean posibles. Las medidas deben ser consistentes. Las aplicaciones deben ser similares al trabajo que se estimar.
11

3 Realizar mediciones sobre los procesos

Propsito
Una vez establecidas las mtricas y los objetivos mensurables solo queda realizar las mediciones para determinar el estado de la calidad de la compaa antes de iniciar los cambios para evaluar los puntos fuertes y los dbiles de la empresa en cuanto a la calidad de los procesos y el producto.
Justificacin
Se establecern mediciones de calidad para cada rea donde estas no existan y se revisaran donde si existan. Se registrara el estado de calidad para poder determinar donde es necesario mejorar, donde es necesario realizar acciones correctivas, y documentar mejoras reales. Esto lograra formalizar el sistema de medicin de la compaa, fortaleciendo las funciones de inspeccin y prueba asegurando mediciones apropiadas. Se deber exponer los grficos de las mediciones de forma clara y visible.
Procedimiento
Los tipos de medicin se basaran estndares establecidos, los cuales sern: Estndares histricos: basados en registros e informacin concernientes a las experiencias pasadas de la organizacin. Estndares externos: provenientes de otras organizaciones u otras unidades de la misma organizacin. Estndares de ingeniera: la capacidad de las mquinas, suelen venir especificadas por los fabricantes.
Establecimiento de Estndares Un estndar ser una unidad de medida que servir como modelo, gua o patrn con base en la cual se efecta la medicin. Los estndares son criterios establecidos contra los cuales pueden medirse los resultados, representan la expresin de las metas de planeacin de la empresa o departamento en trminos tales que el logro real de los deberes asignados pueda medirse contra ellos.
12

Calidad de Software Balmer Agustn, Godoy Alzares Luis Mediciones Medicin preliminar: Tiene lugar antes de emprender operaciones e incluye la creacin de polticas, procedimientos y reglas diseadas para asegurar que las actividades planeadas sern ejecutadas con propiedad. La consistencia en el uso de las polticas y procedimientos es promovida por los esfuerzos de la medicin. Medicin concurrente: Esta medicin tiene lugar durante la fase de la accin de ejecutar los planes e incluye la direccin, vigilancia y sincronizacin de las actividades, segn ocurran. Medicin de retroalimentacin: Este tipo de medicin se enfoca sobre el uso de la informacin de los resultados anteriores, para corregir posibles desviaciones futuras del estndar aceptable.
Atributos de una Buena Medicin

Las mediciones deben ser transparente y entendibles para quienes debern hacer usos de ellas, y adicionalmente deber reunir y tener ciertos atributos indispensables que a continuacin se sealan:
Pertinencia
Las mediciones que se realicen deben ser tomadas en cuenta y tener importancia en las decisiones que se toma sobre la base de la misma. El grado de pertinencia de una medicin debe revisarse peridicamente, ya que algo que sea muy importante en un momento determinado, puede dejar de serlo al transcurrir el tiempo. Es de resaltar, adems, que el grado de pertinencia de una medicin, es relativa al conjunto de mediciones a realizar, debido a los recursos y capacidades de procesamiento y direccin que se tenga.
Precisin
El grado en que la medida obtenida refleje fielmente la magnitud que queremos analizar o corroborar, se interesa conocer un proceso, tomar decisiones para tener resultados esperados. Para lograr la precisin de una medicin, deben darse los siguientes pasos: Realizar una buena definicin operativa de las unidades de escala de medicin, nmero y seleccin de las muestras, clculo de las estimaciones. Elegir un instrumento de medicin con el nivel de apreciacin adecuado. As mismo asegurar que el dato dado por el instrumento de medicin, sea bien recogido por el operador, gerente, oficinista o inspector a cargo de hacerlo.
13

Oportunidad
La medicin es informacin para el logro del conocimiento profundo de los procesos, que permitir tomar decisiones ms adecuadas, bien sea para corregir estableciendo la estabilidad deseada del sistema, bien sea para prevenir y tomar decisiones antes de que se produzca la anormalidad indeseada o ms an, para disear incorporando elementos que impiden que las caractersticas deseadas se salgan fuera de los lmites de tolerancia. Por ello, la necesidad de contar oportunidades con la informacin procesada de la manera ms adecuada que nos dan las mediciones, es un requisito al que deben atenerse quienes diseen un sistema de medicin.
Confiabilidad
Caracterstica no est desvinculada de las anteriores, especialmente de la precisin, se refiere fundamentalmente al hecho de que la medicin en la empresa no es un acto que se haga una sola vez, por el contrario es un acto repetitivo y de naturaleza realmente peridica. Si se quiere estar seguro que lo que se mida sea la base adecuada para las decisiones que se tomen, se deber revisar peridicamente todo sistema de medicin.
Economa
Se refiere a la proporcionalidad que debe existir entre los costos incurridos entre la medicin de una caracterstica o hechos determinados y los beneficios y relevancia de la decisin que soportamos con los datos obtenidos.
Herramientas para asegurar la calidad de las mediciones Las herramientas de calidad que se utilizaran son las siguientes:
Hoja de Control Histograma Diagrama de PARETO Diagrama de Causa-Efecto Diagrama de Dispersin
Hoja de Control: sirve para reunir y clasificar las informaciones segn determinadas
categoras, mediante la anotacin y registro de sus frecuencias bajo la forma de datos. Una vez que se ha establecido el fenmeno que se requiere estudiar e identificadas las categoras que los caracterizan, se registran estas en una hoja, indicando la frecuencia de observacin.
14

Histograma: presentacin de una serie de medidas clasificadas y ordenadas, es

necesario colocar las medidas de manera que formen filas y columnas. La manera ms sencilla es determinar y sealar el nmero mximo y mnimo por cada columna y posteriormente agregar dos columnas en donde se colocan los nmeros mximos y mnimos por fila de los ya sealados. Tomamos el valor mximo de la columna X+ (medidas mximas) y el valor mnimo de las columnas X- (medidas mnimas) y tendremos el valor mximo y el valor mnimo. Teniendo los valores mximos y mnimos, podemos determinar el rango de la serie de medidas, el rango no es ms que la diferencia entre los valores mximos y mnimos.
Diagrama de Pareto: se utiliza para priorizar los problemas o las causas que los genera,
es una grfica en donde se organizan diversas clasificaciones de datos por orden descendente, de izquierda a derecha por medio de barras sencillas despus de haber reunido los datos para calificar las causas. De modo que se pueda asignar un orden de prioridades.
Diagrama de Causa-Efecto: sirve para solventar problemas de calidad. Diagrama de Dispersin: es el estudio de dos variables, estas dos variables se pueden
tomarse como una caracterstica de calidad y un factor que la afecta. Dos caractersticas de calidad relacionadas. Dos factores relacionados con una sola caracterstica de calidad.
15

4 Evaluar los costos sobre el estado actual de la calidad de la empresa

Propsito
Se evaluaran los costos de la calidad en el estado actual de la empresa para generar una nocin del estado en que se encuentra la calidad y los costos que genera la ausencia de ella.
Justificacin
El costo de calidad es una medida que dir donde es rentable realizar acciones correctivas. En base a esta evaluacin la empresa conocer el costo de no tener calidad antes de realizar las modificaciones deseadas, de acuerdo a esos e podrn presentar propuestas, evaluar los cambios, saber en qu punto conviene econmicamente y en cual no realizar modificaciones, y tener idea de todo lo que simplificara la empresa si se realizara cada trabajo en un excelente nivel de calidad.
Procedimiento
Se determinaran los costos de calidad teniendo en cuenta determinados costos que afectan este clculo.
Costos de prevencin: es el costo de todas las actividades llevadas a cabo para

prevenir errores de diseo y desarrollo, mano de obra, compras, y otros aspectos del inicio y creacin de un producto. Investigacin de mercados Revisin (del diseo del producto, del proceso de aprovisionamiento, del proceso de fabricacin, comercializacin y administracin) Desarrollo de productos Evaluacin de proveedores Planificacin de la calidad Formacin Redacciones de manuales de calidad Control estadstico de procesos Coste funcionamiento departamento calidad Auditoras del sistema de calidad Mantenimiento preventivo Manuales de prevencin Sistemas de sugerencias Equipos de mejora Reuniones de calidad Otros costes de prevencin 16

Costos de evaluacin: estos costos se dan al realizar pruebas, inspecciones y otras

evaluaciones planeadas que se usan para determinar si el producto cumple los requisitos. Son importantes todos los documentos que describen el cumplimiento de productos con los requisitos. Mantenimiento de laboratorios, calibracin Ensayos Homologaciones y certificaciones externas Auditoras de calidad de productos Inspeccin de materias primas en recepcin Inspeccin de productos durante el proceso Formacin de empleados para la evaluacin Amortizacin y mantenimiento de equipos de medida Otras inspecciones
Costos de falla: los costos de falla estn relacionados con cosas que se encuentran que
no se desempean de acuerdo a los requisitos, as como la evaluacin y aspectos de consumidor que originan ciertas fallas. Se incluyen todos los materiales y mano de obra utilizada
Costos de fallos internos

Costes internos por fallos de producto (defectuosos, daados, ...) Costes por fallos de compras Sustitucin o eliminacin de materiales comprados Desperdicios Reparacin y reelaboracin de operaciones/productos Re inspecciones y pruebas Rebajas por mala calidad Prdidas de trabajo por errores internos Reproceso Desmotivacin de empleados Anlisis de fallos Subactividad de equipos o personas Otros costes por fallos internos
17

Costos de fallos externos

Gestin de quejas/reclamaciones Devolucin de productos Costes de garantas Sanciones Concesiones en el precio por no cumplir los requisitos del cliente Prdida de ventas Servicio posventa Indemnizaciones Campaas de sustitucin de productos defectuosos Pleitos Reproceso Desperdicios Imagen negativa Otros costes por fallos externos
18

Etapa de Capacitacin
Esta etapa durara de 6 meses a 1 ao. En este lapso la empresa garantizara la capacitacin de los usuarios sobre los mtodos para realizar su trabajo, manipular informacin de la empresa y comunicar problemas. Debido a que se estandarizara la documentacin usada, se realizara una capacitacin para informar y ensear al personal sobre cmo se manejara la informacin de ahora en ms. La otra etapa de la capacitacin ir dirigida a los mecanismos de desarrollo y control del producto en el cual se indicara a los empleados como realizar su tarea de acuerdo a los nuevos estndares.
5 Estandarizar los mtodos de documentacin en toda la empresa

Propsito
La documentacin se generar con un mismo mtodo en toda la empresa. El objetivo de la documentacin es registrar un evento, proceso o funcionamiento para que sea posible una fcil revisin de estos. Se generara documentacin en los siguientes casos: Manuales Procedimientos Fallas Software
Se almacenar en formato digital en el sistema de la empresa y no se imprimirn copias a menos que sea por pedido explcito. Los empleados recibirn la capacitacin para el procedimiento de generacin de documentacin en un curso especial para este objetivo. Cada nuevo empleado deber completar el curso para garantizarse que conoce el funcionamiento de sistema con el que se documenta. Se comenzar un procedimiento de revisin de la documentacin para determinar si se est cumpliendo con el estndar de documentacin establecido. Dentro de los primeros 2 meses de haber comenzado el nuevo procedimiento de generacin de documentacin el proceso de revisin ser cada vez ms peridico, pero nunca dejar de aplicarse.
19

Los distintos elementos a documentar son los siguientes: Fallos: todo tipo de problemas que se presenten dentro y fuera de sistemas junto con la
solucin encontrada. Cuando se presenten, se utilizarn los canales de comunicacin necesarios para que el encargado de resolverlo sea informado. Cuando se encuentre la solucin al problema se adjuntar al informe del fallo para que sea de utilidad en caso de que vuelva a ocurrir.
Software: sistemas desarrollados por la empresa. Se deber detallar especificaciones

que puedan ser entendidas por usuarios, analistas y programadores. Esta documentacin sirve para dejar constancia de que es lo que debe hacer un sistema, ya sea para futuras revisiones o modificaciones. Tambin se utiliza durante el proceso de desarrollo, para realizar el anlisis y la programacin del sistema.
Manuales de usuario: en cada rea de la empresa se tendr disposicin la

documentacin necesaria acerca del sistema que se utilice en cada caso. Tambin sern utilizados en la capacitacin de los empleados y se actualizar con cada cambio del sistema. En caso de que este no sea desarrollado por la empresa, el manual de usuario ser un requerimiento de la compra.
Manuales de instruccin al operador: cada sistema de la empresa contar con

documentacin sobre el funcionamiento de este que ayudar a la hora de resolucin de problemas. Al igual que con el manual de usuario, el de instruccin al operador ser un requerimiento en la compra.
Manuales de procedimiento: cada sector debe contar con documentacin detallada de

los procesos habituales que se realizan en l. Debe describir de las actividades paso por paso especificando el desarrollo en tiempo y forma, indicando las personas involucradas y responsables para su realizacin. Se utilizar junto con el manual de usuario para capacitar nuevos empleados pero tambin para organizar las actividades en base a una secuencia y flujo para evitar omisin de procedimientos o saltos en las acciones.
Caso especial: Memorandos internos de la empresa o cualquier tipo de documentacin

requerida especficamente por un administrador.
20

Procedimiento Documentacin de fallas

Cada vez que sea necesario documentar un problema el encargado de hacerlo deber llenar el siguiente formulario: Fecha y hora en la que ocurri el problema. Nombre del empleado que lo encontr. rea de la empresa. Causa del fallo. Nivel de urgencia. Equipo que genero el evento Descripcin del evento Solucin en caso de haberla
Los campos del formulario se completarn a medida que transcurra el proceso de reporte de fallas. El procedimiento especfico a seguir para completar la documentacin de fallos se encuentra relacionado con el proceso de comunicacin que debe seguir la empresa, y los pasos a seguir se detallan all (Punto 6).
Documentacin de software
Durante un proyecto de desarrollo de software se especificarn los siguientes documentos: Especificaciones Funcionales Documentacin del sistema Documentacin de Programas
El proceso de documentacin de software se encuentra fuertemente relacionado con el proceso de desarrollo de software y los pasos necesarios para generar la documentacin se detallan junto con este (Punto 7).
21

Documento de especificaciones funcionales

El propsito de las especificaciones funcionales de un programa es describir el procedimiento a seguir para usar el mismo. Adems, las especificaciones funcionales proveen suficiente informacin para que el Analista pueda convertir estas especificaciones en un diseo detallado del programa, as como para que el usuario pueda evaluarlo y asegurarse que el mismo satisface sus necesidades. Tambin servirn como base para la elaboracin del Manual del Usuario y el Manual de Instrucciones al Operador. Las especificaciones funcionales debern ser escritas en forma clara, concisa y en un lenguaje carente de tecnicismos, capaz de ser entendido por los usuarios. Servir de instrumento de negociacin entre la Oficina de Sistemas de Informacin y el usuario, al momento de modificar o desarrollar la programacin.
Contenido
1. Descripcin General del Programa: esta seccin presentar brevemente la descripcin del programa. Deber ser escrita en el lenguaje propio del usuario, sin entrar en detalles ni tecnicismos. 2. Flujograma: deber contener un diagrama que describa grficamente la actividad del programa incluyendo documentos producidos, datos de entrada y fuentes que la proveen, informes del sistema y la disposicin final de los resultados de los mismos. 3. Mensajes y formatos de pantalla: si el sistema es en lnea, deber incluir los formatos de las diferentes pantallas. Tambin deber incluir los diferentes tipos de mensajes, ya sean estos de error, notificacin de una situacin en especfico o de requerimiento de alguna pantalla. Si el sistema no es en lnea, deber incluir los diferentes tipos de mensajes y las posibles contestaciones a los mismos. 4. Elementos de Datos (Diccionario): debern definirse todos los tipos de archivo a ser utilizados por el programa. Deber incluirse para cada elemento de datos incluido en cada archivo una Copia de la librera y una Definicin del DBD. 5. Planes de Resguardo (Backup): en cada proceso se indicar los archivos de resguardo y su periodo prescriptivo. 6. Frecuencia: en la solicitud de desarrollo de programacin se indicarn la fecha lmite para completar el desarrollo. En la documentacin operacional se indicar la frecuencia de procesamiento.
22

Documentacin de programas
El objetivo de la documentacin de programas es familiarizar a analistas y programadores con lo que hace cada programa en particular. La documentacin de programas es una extensin de la documentacin del sistema. El programador convierte las especificaciones de programas en lenguaje de computador. El programador deber trabajar conjuntamente con las especificaciones de programas y asegurarse que el programa cumpla con las mismas. Cualquier cambio que surja como resultado de la programacin, deber ser expuesto y aceptado antes de aplicar el cambio. La documentacin de programas es tcnica y detallada y no necesita estar escrita en una manera entendible al usuario.
Contenido
1. Nombre del Programa: indicar cdigo que identifica el programa y el ttulo del programa. 2. Descripcin: indicar la funcin que realiza el programador. 3. Fecha de Efectividad: fecha a partir de la cual se comienza a ejecutar en produccin la versin modificada o desarrollada del programa. 4. Archivo de Entrada (Librera/Definicin DBD/Descripcin de Archivo) 5. Archivos de Salida: indicar el nombre y copia de la librera/DBD/Descripcin de los archivos. 6. Informes y/o Totales de Control: se indicar el nombre de los informes y se incluir ejemplo de los informes y/o totales de control producidos por el programa, utilizando los datos de prueba. 7. Nombre del Programador: deber indicar el nombre del programador que escribi el programa o que efectu el cambio, segn sea el caso. 8. Fecha: indicar fecha en que se escribi el programa o que se efectu el cambio, segn sea el caso. 9. Tablas: en caso que aplique, se incluir detalle de las diferentes tablas y cdigos usados; con los valores, explicaciones y su uso en el programa. 10. Lista de Programas: deber incluir copia de la ltima compilacin del programa con todas las opciones. Cotejar que la secuencia del programa sea correcta. 11. Lista de Datos de Prueba: se incluir una copia de los datos usados para prueba.
23

Calidad de Software Balmer Agustn, Godoy Alzares Luis 12. Mensajes al Operador: en caso que aplique, deber definir todos los mensajes al operador por consola y las posibles contestaciones con una breve explicacin de cada una de ellas. 13. Parmetros: se acompaar una lista detallada de todos los parmetros para ejecutar el programa (JCL, Command Procedures, etc.)
Manual de usuario
El propsito del Manual del Usuario es proveer ayuda al usuario para poder utilizar el sistema. Las especificaciones funcionales servirn como documento base para que el analista escriba el manual del usuario. Deber estar escrito en una forma clara y en un lenguaje entendible por el usuario.
Contenido
1. Descripcin General Programa: presentar brevemente los objetivos y funciones que habr de realizar el programa. 2. Modelo de ejecucin: para cada opcin del programa donde se indicarn los parmetros o datos necesarios. Para programas en lnea, se indicarn las opciones de men y/o los datos requeridos por el programa para su ejecucin. 3. Formularios y Transacciones: se incluir copia de cada formulario y/o transacciones utilizados por el sistema. Se ofrecer una breve explicacin de cada formulario y se especificar lo siguiente: Cmo completar cada formulario Cualquier detalle en cuanto al manejo de la informacin
Deber explicar en detalle cmo completar cada campo. Si el sistema es en lnea, deber incluir cada pantalla que se utiliza en el sistema. Indicar lo siguiente: Cdigo de la Pantalla Nombre de la Pantalla Propsito Entradas Instrucciones para cada campo Mensajes de cada transaccin
24

Manual de instrucciones al operador

Este manual proveer instrucciones de cmo correr el sistema. El analista deber trabajar en conjunto con las especificaciones funcionales, diseo del sistema y documentacin de programas para escribir el Manual de Instrucciones al Operador. Este Manual deber estar estructurado de manera tal que sirva de ayuda al adiestramiento del personal.
Contenido
1. Descripcin del Programa: incluir descripcin narrativa del programa y qu debe hacer el Operador antes y mientras ejecuta los programas del sistema. 2. Flujograma General del Programa: deber incluir copia del Flujograma General del Programa, tal como aparece en el Manual de Diseo del Sistema. Este flujograma reflejar la interrelacin de programa a programa con los archivos correspondientes. Adems, se indicar la frecuencia de cada programa, disposicin de cada archivo, etiquetas de archivos de salida en cinta magntica, destino de cada copia de los informes y algn comentario especfico de cada uno de los programas. 3. Parmetros para ejecutar programas: se deber incluir una lista de todos los parmetros para ejecutar cada programa. 4. Mensajes al Operador: indicar una lista detallada de todos los mensajes, tal como aparecen en la consola, las posibles contestaciones y el por qu de dichas respuestas. Esto se har para cada programa. 5. Planes de Resguardo (Backup): deber incluir instrucciones especficas de los procedimientos a seguir para el mantenimiento de un resguardo (Backup). 6. Instrucciones Especiales: en esta seccin se deber incluir un itinerario de fechas para ejecutar cada programa (frecuencia), fecha de cierre, flujo de documentos, control de cintas (ciclo de retencin), formas especiales de impresora y algn otro comentario que se crea pertinente.
25

Documentacin del sistema

El objetivo primordial del manual de diseo del sistema es el de proveer a los programadores suficiente informacin para escribir los programas de aplicaciones en lenguaje de computador. Este manual forma parte de las especificaciones funcionales, ya que convierte la definicin orientada al usuario en una definicin orientada a sistemas computadorizados. El Analista que est desarrollando el diseo del sistema deber trabajar conjuntamente con las especificaciones funcionales y enmendarlas, si fuera necesario. Cualquier cambio a las especificaciones funcionales, como resultado del diseo del sistema, debe ser aprobado antes de proceder a actualizar el documento original. El Manual del sistema deber contener la documentacin de cada uno de los programas que lo componen.
Contenido
1. Introduccin: se incluir una descripcin breve de la situacin que motiv la creacin del sistema. Se acompaar, si aplica, la base legal que justifique dicho sistema. 2. Descripcin General del Sistema: deber presentar descripcin narrativa del sistema y sus funciones. Adems, se incluirn todos los programas que componen el sistema y su respectiva documentacin. 3. Flujograma: se incluir flujograma general del sistema, en el cual se identificarn los programas para usos, archivos e informes que componen el mismo. 4. Formato de Archivos, Bases de Datos y/o Bloques de Datos: Formato de Archivos, Bases de Datos a ser utilizados por el sistema, debern ser definidos y debe incluirse una breve descripcin de cada uno de ellos. Se deber incluir el nombre del archivo y extensin, as como la siguiente informacin para cada uno: copia de la librera, definicin de DBD y Definicin de los campos de aquellos archivos que no estn configurados en libreras o que no estn definidos en DBB (Data Base Definition). 5. Formato de Pantallas: si el sistema es en lnea, deber incluir formato de las pantallas que sern utilizadas por el sistema. 6. Especificaciones de Programas: para cada programa se debe incluir lo siguiente. a. Identificacin del Programa (cdigo): descripcin, tipo de programa, nombre de Archivos de Entrada, nombre de Archivos de Salida, base de Datos (cuando aplique) y nombre de Informes
26

Calidad de Software Balmer Agustn, Godoy Alzares Luis b. Descripcin del Programa: Narrativa de las funciones del programa. Se incluir la definicin de lo que hace el programa. Deber ser lo ms clara, organizada y precisa posible, adems de estar bien presentada. c. Formato de Pantallas: si el sistema es en lnea, deber incluir formato de las pantallas utilizadas por el programa. d. Formato de Archivos de Entrada y/o Salida (librera,DBD o definicin) y
Definicin de la Base de Datos(cuando aplique).

e. Formato de Informes: se incluirn formatos de los informes que producir el programa. Este manual debe ser creado y mantenido, por lo tanto, durante dos semanas cada equipo de programacin tendr reuniones en las cuales se encargarn de crear dicho manual de acuerdo a la forma de trabajo. Los administradores de cada rea se encargarn de supervisar el trabajo y coordinarlo para que todos aporten a un mismo manual.
Manual de procedimientos y responsabilidades

Este manual de procedimientos debe ser una herramienta eficaz donde quede plasmada una descripcin precisa de cmo deben realizarse las actividades dentro de la empresa. Este documento queda como una fuente permanente de consulta para el cumplimiento correcto de cada actividad realizada por esta direccin. Dentro de este documento se da a conocer de manera amplia cada actividad as como los responsables de cada rea que las llevan a cabo. As mismo, se especifica documentacin, personas involucradas as como el tiempo y las herramientas necesarias y obligatorias para cada actividad. Es necesario que este manual sea sometido a una revisin peridica para la corroboracin de su cumplimiento y de ser necesario, realizar una actualizacin para efectos de cambio ya sea en las actividades existentes como en la creacin de nuevos procedimientos.
27

Contenido
1. Nombre del Procedimiento: cada procedimiento estar identificado con un nombre, el cual permitir ubicarlos ms fcilmente dentro del Manual. 2. Objetivo: define el fin o propsito que persigue el procedimiento descrito. 3. Normativa: incluye los criterios o lineamientos generales de accin que se determinan en forma explcita, para facilitar la cobertura de responsabilidad de los diferentes participantes en los procedimientos. 4. Puestos que intervienen: son todas aquellas personas que se relacionan directamente con la ejecucin del procedimiento descrito. 5. Formularios, documentos: son todos aquellos que sirven de base y que complementan la ejecucin del procedimiento, adems sirven de apoyo a la realizacin de las labores. 6. Descripcin del Procedimiento: es la descripcin detallada del procedimiento, que se presenta por partes. Dicha descripcin se organiza de la siguiente manera: un encabezado del procedimiento, el cuadro o cuerpo del procedimiento conformado por tres columnas a saber: paso, descripcin y responsable. Al igual que con el manual de sistemas, este manual debe ser creado pero cada rea necesita el suyo propio. Durante dos semanas los empleados del sector tendrn reuniones en las cuales discutirn y se dividirn trabajo para crear el manual. Dicho manual debe ser revisado y mantenido, cada vez que se produzca un cambio en los procesos realizados por el sector. Tambin se realizarn revisiones peridicas para controlar que los procesos se estn realizando en tiempo y forma y que la documentacin es acorde a lo que el sector debe hacer.
28

Responsables
La documentacin de software, incluyendo la que se realiza para: los programas, la especificacin de requerimientos, manuales de usuario y manuales de instrucciones es creada durante el desarrollo de un sistema. En caso de que el nuevo sistema sea comprado y no enlatado, estos documentos sern un requerimiento en la compra. En caso de que sea enlatado se puede prescindir de la documentacin de los programas ya que el software no podr ser modificado. El mantenimiento y modificacin de este tipo de documentacin se realizar cada vez que se presente una modificacin del sistema o parte de l. Tambin deber revisarse cada vez que alguien reporte una falla que afecte al software o a la documentacin. Los procedimientos de mantenimiento de manuales de sistemas y procedimientos se realizarn peridicamente, los administradores de cada rea son los encargados de decidir qu cambios deben realizarse en la documentacin de acuerdo a como cambien los procesos del sector. La documentacin de fallas debe realizarse cada vez que un empleado reporte una falla. El empleado deber reportar cualquier evento o situacin que no le permite realizar su trabajo en condiciones apropiadas. Ser responsabilidad del grupo que asegura la calidad chequear que cada sector presente la documentacin de la forma estandarizada realizando un control semanal de la documentacin. El administrador de cada sector delegar la tarea de controlar la documentacin a un miembro de su equipo. Cada semana elegir a un miembro distinto. Esta persona controlar que cada miembro del equipo este siguiendo el estndar de creacin de documentacin durante el desarrollo del proyecto y adems de la documentacin creada por la ocurrencia de fallos. Se presentarn correcciones al administrador cuando sea necesario que se encargue de que la norma se aplique correctamente. Este tambin se encargar de chequear los procedimientos de su rea para notar cambios en la forma en que se realizan y corregir el comportamiento o el manual en caso de que sea necesario.
29

6 Estandarizar los mecanismos de comunicacin

Propsito
El propsito de este documento es identificar y planificar eficientemente las responsabilidades, decisiones, acciones y canales de comunicacin involucrados para manejar y mitigar un incidente. Un plan de respuesta a incidentes bien planificado generar los siguientes beneficios: Minimizar el dao que un incidente podra causar en un momento especfico de confusin. Una poltica planificada por adelantado es superior a una conceptualizada en el momento de crisis. Los detalles que normalmente podran pasarse por alto se pueden documentar en el plan. Permite adelantar la aportacin de las dems dependencias de la institucin en las acciones para resolver un incidente. Establece y comunica las posibles consecuencias que puede generar un incidente a la Administracin universitaria.
La ventaja ms significativa de tener un plan de respuesta a incidentes integrado a las polticas, planes y procedimientos es la reduccin significativa de riesgos. La empresa deber adquirir un sistema de seguimiento de fallas del estilo de TrackIt para la estandarizacin de la documentacin y mejor tiempo de respuesta ante incidentes.
Alcance
Este documento de poltica y procedimiento para manejar incidentes aplica a los servicios y sistemas de las reas funcionales de toda la empresa desde la fecha de emisin del mismo. Alcanza las actividades relacionadas con: Comunicar la poltica, los objetivos y las metas a todo el personal, as como informar sobre la evolucin de los desarrollos de la empresa a todas las partes interesadas. Decidir y responder a las preocupaciones del personal. Comunicar los resultados de carcter general de las auditoras y revisiones del sistema de gestin a todas las personas implicadas. Dar a conocer las polticas y los aspectos ms relevantes del sistema de gestin.
30

Calidad de Software Balmer Agustn, Godoy Alzares Luis Se excluir de esta poltica y procedimiento todo incidente que resulte o que provenga de los siguientes: Informacin no electrnica. Copiadoras y Fax (excepto asuntos relacionados con el proceso de imprimir). Seguridad fsica. Plan de contingencia y recuperacin de desastres.
Definicin de un Incidente
Se define como incidente a cualquier evento inesperado que podra poner en riesgo una operacin, sistema o servicio. Una violacin a la poltica de seguridad de las computadoras, servidores o redes. Otros eventos adversos que estn cubiertos por esta poltica y procedimiento pueden incluir: Daos realizados a las partes de un sistema Infeccin maliciosa a travs de virus, spyware o malware Deteccin de intrusos
Los incidentes pueden estar clasificados como crtico o no-critico. Los incidentes crticos requieren una respuesta inmediata por parte de un equipo constituido para manejar esta clase de incidentes ya que representan situaciones de alto riesgo o de naturaleza sensitiva. Los incidentes clasificados como no-crticos representan poco o un nivel aceptable de riesgo por lo tanto puede atenderse por la persona designada a estos fines. Se considerar un incidente como crtico cuando el mismo est tipificado con antelacin o cuando un oficial universitario as lo indique.
31

Definicin de una Respuesta Apropiada a un Incidente Crtico

A travs de las acciones que llevemos a cabo una vez se identifica un incidente, comienza un proceso de comunicacin, manejo y mitigacin del posible dao. Por tal razn, es importante identificar los elementos que se consideran una respuesta apropiada a un incidente, segn aplique. 1. Determine si efectivamente hubo un incidente y su extensin 2. Asuma el control del incidente e involucre al personal apropiado para manejar la situacin. 3. Informe a la gerencia sobre el incidente y cmo usted proceder a resolverlo 4. Abra un incidente en el programado TrackIt 5. Recopile informacin, entreviste a testigos, recopile evidencia y documente 6. Controle el dao que pudiese provocar el incidente a la mayor brevedad posible para evitar su desplazamiento, diseminacin o caos 7. Ejecute el plan de mitigacin o procedimiento para resolver el incidente 8. Proteja los derechos de empleados, estudiantes y visitantes establecidos por ley y por las polticas institucionales 9. Documente todas las acciones y resultados en el programado TrackIt 10. Evale en conjunto con la gerencia si fue efectivo las acciones llevadas a cabo
Tipos de Incidentes
Cada incidente nos presenta una problemtica diferentes con formas determinadas para identificar y responder al mismo. A continuacin ofrecemos una lista como ejemplo de los diversos tipos de incidentes: Cancelacin de una corrida de programa Acceso no autorizado Virus, spyware o malware. Uso inapropiado de los recursos de la red Falla de la red de comunicaciones Falla en el cuadro telefnico Falla en los programas de aplicaciones o bases de datos Mltiples tipos
32

Severidad de un Incidente y Tiempo de Respuesta

En adicin a identificar el tipo de incidente, hay que determinar la severidad de un incidente para determinar la prioridad con el mismo deber ser atendido. Primero, se considerar de severidad uno (1) cualquier incidente que afecte a uno o ms sistemas crticos. Segundo, se considerar de severidad dos (2) cualquier incidente que afecte a un sistemas utilizado por el usuario. Tercero, se considerar de severidad tres (3) cualquier incidente que afecte algn recurso o sistema de menor importancia en la operacin continua de la UPRB. A continuacin le ilustramos en la siguiente tabla: Severidad 1 2 3 Categora Crtico Normal No crtico Tiempo de Respuesta Tipo de Accin Inmediata Continua hasta su resolucin dentro del mismo da Hasta dos das Resolucin dentro del horario regular de laborables servicio Hasta cuatro das Resolucin dentro del horario regular de laborables servicio
Procedimiento de Administracin y Utilizacin de los Recursos

I. Se entra en el sistema TrackIt el incidente o situacin. Si la notificacin proviene de un usuario, se le pide que especifique lo ms detallado posible el problema o situacin para saber cmo manejar el mismo. Se determina bajo que categora, rea o tipo de trabajo cae: (Ejemplo: Crtico, Normal, Apoyo Tcnico, Operaciones, Programacin, etc.) Telecomunicaciones Computadora Programacin Sistemas Administrativos Operaciones y Produccin Hardware Impresoras
II. El Supervisor del rea es el encargado de determinar a quin se informar para la resolucin del problema. Lo asigna al personal responsable que aplique, y le da seguimiento para que se cumpla en un tiempo razonable. III. Se evala el incidente y se toman las siguientes acciones: a. Se hace diagnstico b. Se corrige el incidente y se documenta. c. Se hacen recomendaciones de ser necesario en cuanto a programados y equipo segn lo que aplique y que cumpla con los estndares mnimos (cambio de equipo, compra de programados y decomisar equipo) . d. Se coteja si aplica Garanta Contrato de Mantenimiento. 33

IV. Se enviar evidencia al usuario de como se resolvi el incidente situacin. V. Peridicamente se har un anlisis y se producirn estadsticas para saber que incidentes son ms recurrentes, que equipos son los generan ms problemas, que oficinas requieren mayor apoyo tcnico etc.
34

7 Estandarizar los procesos de desarrollo de software Propsito

El objetivo del proceso estandarizado de desarrollo de software es la produccin eficaz y eficiente de un producto software que rena los requisitos necesarios. Este proceso es intensamente intelectual, afectado por la creatividad y juicio de las personas involucradas. El conjunto de actividades que se encuentran en el proceso desarrollo de software son: 1. Especificacin de software: se debe definir la funcionalidad y restricciones operacionales que debe cumplir el software. 2. Diseo e Implementacin: se disea y construye el software de acuerdo a la especificacin. 3. Validacin: el software debe validarse, para asegurar que cumpla con lo que quiere el cliente. 4. Evolucin: el software debe evolucionar, para adaptarse a las necesidades del cliente.
Justificacin
Lo que se busca con el proceso estandarizado es: Mejorar la calidad de los productos de software Aumentar la productividad y trabajo de los ingenieros del software. Facilitar el control del proceso de desarrollo de software. Suministrar a los desarrolladores las bases para construir software de alta calidad en una forma eficiente. Definir una disciplina que garantice la produccin y el mantenimiento de los productos software desarrollados en el plazo fijado y dentro del costo estimado.
Los elementos involucrados se describen a continuacin: Un marco comn del proceso, definiendo un pequeo nmero de actividades del marco de trabajo que son aplicables a todos los proyectos de software, con independencia del tamao o complejidad. Un conjunto de tareas, cada uno es una coleccin de tareas de ingeniera del software, hitos de proyectos, entregas y productos de trabajo del software, y puntos de garanta de calidad, que permiten que las actividades del marco de trabajo se adapten a las caractersticas del proyecto de software y los requisitos del equipo del proyecto. Las actividades de proteccin, tales como garanta de calidad del software, gestin de configuracin del software y medicin, abarcan el modelo del proceso. Las actividades de proteccin son independientes de cualquier actividad del marco de trabajo y aparecen durante todo el proceso.
35

Calidad de Software Balmer Agustn, Godoy Alzares Luis Proceso de desarrollo en espiral Cada ciclo de desarrollo se divide en cuatro fases: 1. Definicin de objetivos: Se definen los objetivos. Se definen las restricciones del proceso y del producto. Se realiza un diseo detallado del plan administrativo. Se identifican los riesgos y se elaboran estrategias alternativas dependiendo de estos. 2. Evaluacin y reduccin de riesgos: Se realiza un anlisis detallado de cada riesgo identificado. Pueden desarrollarse prototipos para disminuir el riesgo de requisitos dudosos. Se llevan a cabo los pasos para reducir los riesgos. 3. Desarrollo y validacin: Se escoge el modelo de desarrollo despus de la evaluacin del riesgo. El modelo que se utilizar (cascada, sistemas formales, evolutivo, etc.) depende del riesgo identificado para esa fase. 4. Planificacin: Se determina si continuar con otro ciclo. Se planea la siguiente fase del proyecto. El ciclo de vida inicia con la definicin de los objetivos. De acuerdo a las restricciones se determinan distintas alternativas. Se identifican los riesgos al sopesar los objetivos contra las alternativas. Se evalan los riesgos con actividades como anlisis detallado, simulacin, prototipos, etc. Se desarrolla un poco el sistema. Se planifica la siguiente fase. El estndar identifica al menos los siguientes roles:
Jefe de proyecto: responsable de la provisin del servicio de desarrollo o de

mantenimiento de aplicaciones demandado por el cliente y de la calidad de los productos obtenidos. Usuario final: la persona que utiliza y explota el producto o aplicacin. Proveedor: tercero responsable de suministrar todo o parte del servicio de desarrollo de aplicaciones solicitado por el cliente. Analista responsable del proyecto: responsable de la entrega del servicio de desarrollo de aplicaciones contratado por el cliente. Se refiere al tcnico de anlisis que gestiona y participa en la provisin del servicio. Responsable del sistema: responsable de la entrega del servicio de desarrollo o de mantenimiento de aplicaciones convenido. Se refiere al jefe de proyecto asignado por el proveedor externo como responsable ltimo del servicio ante el jefe de proyecto. Responsable del mdulo: responsable del desarrollo de un mdulo o subsistema en los que se descompone el sistema software. Se refiere al analista o analistaprogramador asignado por el proveedor externo para la construccin de un mdulo.
36

Desarrollador: responsable del desarrollo de un conjunto de artefactos que

componen un mdulo o subsistema. Se refiere al analista-programador o programador asignado por el proveedor externo para la construccin de un mdulo. Tester: responsable del diseo y ejecucin de las pruebas, y del clculo de los indicadores. Se refiere al equipo de pruebas (responsable de pruebas e ingenieros de pruebas). Oficina de evaluacin: evala los niveles de calidad obtenidos para el producto software obtenido e informa al CAB sobre dichos resultados.
Proceso de reporte de errores de software
Usuario Tctico: reporta problema con la funcionalidad esperada de la aplicacin e

indica el impacto a la misma.
Lder de Proyecto: recibe reporte del problema y captura la informacin requerida para
identificar al problema en el formato Reporte de problema. Notifica al desarrollador para generar solucin del problema.
Desarrollador: Recibe reporte de Problema y busca una posible solucin temporal al

mismo. No existe solucin temporal: inicia el anlisis de causa raz. Si existe solucin temporal: indica al usuario Tctico la solucin a aplicar y trabaja en el anlisis de causa raz.
Desarrollador: identifica causa raz del problema y realiza correcciones necesarias al

sistema. Notifica al Tester para su validacin y registra en el Reporte de Problema la causa raz y el tiempo utilizado en la solucin.
Tester: valida con base en el Reporte de Problema que los cambios corrigen el problema
reportado. No se corrige el problema: inicia al desarrollador validar los cambios. Si se corrige el problema: indica al Lder de Proyecto el resultado y lo registra en el formato de Reporte de Pruebas.
Lder de Proyecto: genera control de cambios correspondiente para solicitar la

instalacin de las correcciones en produccin.
Usuario Tctico: recibe notificacin del Lder de proyecto de que se ha solucionado el

problema y valida la aplicacin. No se corrige el problema: inicia al Lder de Proyecto validar los cambios. Si se corrige el problema: indica al Lder de Proyecto el resultado y da su Vo. Bo. en el formato de Reporte de Pruebas.
Lder de Proyecto: registra en la bitcora de seguimiento el Problema.
37

Calidad de Software Balmer Agustn, Godoy Alzares Luis Procesos organizativos: engloba los procesos ms relacionados con la gestin y preparacin, necesarios para el desarrollo del sistema El jefe de proyecto deber definir las necesidades del sistema a construir, adquirir o mantener, indicando adems en el pliego de bases tcnicas la obligatoriedad de adscripcin a los presentes estndares. Se deber indicar tambin el valor NAC (nivel de aseguramiento de la calidad) asignado al proyecto. La fase de Requisitos de usuario que consta de las actividades de Definicin de Sistema y la de Establecimiento de Requisitos debern ser realizadas por el analista responsable del proyecto. Las actividades de Identificacin de subsistemas de anlisis, Anlisis de casos de uso y la de Anlisis de clases debern tambin ser realizadas por el analista responsable del proyecto. El jefe de proyecto deber decidir la idoneidad de la contratacin de un equipo adicional que acte como Oficina Tcnica de Calidad para el proyecto, por lo tanto, distinto al que realizar las actividades de ingeniera, y al que realizar las tareas de pruebas. Incluso se podra decidir que las tareas de pruebas pasen a ser responsabilidad de dicha Oficina Tcnica de Calidad. En cualquier caso se deber asegurar que dicho rol queda cubierto. Se ha establecer el conjunto de herramientas que se deber disponer en base al perfil del usuario asignado. Todos los perfiles (jefe de proyecto, analista, o desarrollador) contarn con un mismo conjunto bsico de herramientas, amplindose ste para el perfil de desarrollador. Procesos operativos: define los procesos a realizar desde el punto de vista de la construccin del sistema software durante cada fase del ciclo en espiral. Proceso de definicin de objetivos
Usuario Tctico: Elabora Oficio de Solicitud de desarrollo de sistema de informacin y la

enva al Lder de Proyecto para iniciar el proceso.
Lder de Proyecto: Elabora el documento de Acuerdo para Desarrollo de Sistemas y lo

firma de comn acuerdo con el Usuario Tctico, solicitando al Usuario Tctico la elaboracin del documento Especificacin de Requerimientos. Archiva documento de Acuerdo para el Desarrollo recibido para su control.
Usuario Tctico: Instruye al Usuario Operativo para elaborar documento de

Especificacin de requerimientos.
Usuario Operativo: elabora el documento de Especificacin de Requerimientos

detallando a fondo los requerimientos primarios y lo entrega al Lder de Proyecto para su revisin. 38

Lder de Proyecto: recibe documento de Especificacin de Requerimientos e indica en el

Plan de Desarrollo de Software el alcance, el tiempo estimado de duracin de las fases y el tiempo estimado de desarrollo del proyecto. Instruye al Analista para revisin del documento. Archiva el Plan de Proyecto para su control.
Analista: recibe el documento de Especificacin de Requerimientos, realiza un anlisis

detallado del mismo y retroalimenta al usuario en caso de existir correcciones en el documento. Una vez validado el documento, realiza especificacin de casos de uso principales y elabora la primera versin del documento de Anlisis, generando los casos de uso para los requerimientos principales.
Desarrollador: recibe el documento de Anlisis disea y genera prototipo de interfaz de

usuario documentando la seccin de interfaz de usuario en el documento de Diseo. Elabora plan de la prxima fase y busca junto con los involucrados en el proyecto el acuerdo de Objetivos del Ciclo de Vida, generando una minuta de reunin. No existe acuerdo: determina la viabilidad del proyecto y en su caso elabora Control de Cambios necesario y el plan de la prxima iteracin para lograr el acuerdo de Objetivos del Ciclo de Vida. Si existe acuerdo: instruye al equipo del proyecto continuar con la fase de Elaboracin del mismo. Proceso de evaluacin y reduccin de riesgos
Desarrollador: recibe instruccin de continuar con el proyecto, genera el diseo para los
casos de uso principales y en la seccin de Diseo arquitectnico y Diseo de casos de uso del documento de Diseo.
Analista: recibe instruccin de continuar con el proyecto y solicita al Usuario Operativo la

definicin de requerimientos secundarios.
Usuario Operativo: elabora la segunda versin del documento de Especificacin de

Requerimientos con los requerimientos secundarios finalizando el documento y lo entrega al analista.
Analista: recibe documento de Especificacin de Requerimientos, realiza un anlisis

detallado del mismo y retroalimenta al usuario en caso de existir correcciones en el documento. Una vez validado el documento, realiza especificacin de casos de uso faltantes y elabora la versin final del documento de Anlisis.
Lder de Proyecto: recibe documento de Anlisis final y elabora la versin final del Plan
de Desarrollo de Software estableciendo los tiempos definitivos por cada fase y los responsables de cada actividad.
39

Desarrollador: con base en el documento de Diseo, genera componentes del sistema

de informacin para probar el diseo y captura en el documento de Componente lo referente al prototipo desarrollado.
Responsable de Pruebas: con base en el documento de Anlisis, elabora la primera

versin del documento Plan de Pruebas llenando nicamente las actividades para probar la funcionalidad de los casos de uso principales.
Lder de Proyecto: elabora plan de la prxima fase y busca junto con los involucrados en
el proyecto el acuerdo de Arquitectura del Ciclo de Vida. No existe acuerdo: determina la viabilidad del proyecto y en su caso elabora el control de cambios correspondiente y el plan de prxima iteracin para lograr acuerdo de Arquitectura del Ciclo de Vida. Si existe acuerdo: instruye al equipo del proyecto continuar con la fase de Construccin del mismo. Proceso de desarrollo y validacin
Desarrollador: recibe el documento de Anlisis validado junto con el usuario, analiza y

determina si es necesario detallar ms algn caso de uso. No es necesario ms detalle: elabora la versin final del documento de Diseo, especificando la funcionalidad de los casos de uso secundarios. Si es necesario ms detalle: solicita al Analista refinar el documento de Anlisis.
Lder de Proyecto: el Lder de Proyecto se asegura que la arquitectura del sistema de

informacin sea acorde a la infraestructura que se tiene para soportarlo.
Responsable de Pruebas: Recibe el documento de final de Anlisis y elabora la versin

final del Plan de Pruebas detallando las fechas de prueba de los casos de uso secundarios.
Desarrollador: con base en el documento de Diseo, genera componentes del sistema

de informacin para cubrir toda la funcionalidad deseada del sistema y elabora los documentos de Componente y Registro de Rastreo.
Responsable de Pruebas: recibe componentes listos para ejecutarse por parte del
Desarrollador, realiza las pruebas planeadas y determina si las pruebas fueron exitosas. No, fueron exitosas las pruebas: solicita correcciones al desarrollador. Si, fueron exitosas las pruebas: elabora documento con Reporte de Pruebas y entrega el mismo al Lder de Proyecto.
Lder de Proyecto: recibe documento de Reporte de Pruebas, elabora plan de la prxima

fase y busca junto con los involucrados en el proyecto el acuerdo de Capacidad Operacional Inicial.
40

No existe acuerdo: determina la viabilidad del proyecto y en su caso elabora el control

de cambios correspondiente y el plan de prxima iteracin para lograr acuerdo de Capacidad Operacional Inicial. Si existe acuerdo: instruye al equipo del proyecto continuar con la fase de Transicin del mismo y al Usuario Operativo para que ejecute las pruebas de aceptacin. Proceso de la Fase de Transicin y Planificacin
Lder de Proyecto: enva oficio de notificacin al soponsor de trmino de desarrollo de la

aplicacin especificando que se da inicio a la etapa de pruebas de aceptacin.
Usuario Operativo: recibe instruccin de realizar las pruebas de aceptacin del sistema
por parte del Lder de Proyecto. Ejecuta pruebas de aceptacin en base a su requerimiento inicial.
Desarrollador: recibe instruccin del Lder de Proyecto de continuar y elabora los

documentos de Manual de Usuario y Manual de Operacin del sistema y los enva al Lder de Proyecto.
Usuario Operativo: Enva retroalimentacin de pruebas realizadas al Lder de Proyecto. Lder de Proyecto: recibe retroalimentacin de pruebas y determina si las pruebas
fueron exitosas. No, fueron exitosas las pruebas: solicita correcciones al desarrollador. Si, fueron exitosas las pruebas: da por terminadas las pruebas de aceptacin.
Lder de Proyecto: recibe documentos Manual de Usuario y Manual de Operacin y

busca junto con los involucrados en el proyecto el acuerdo de Liberacin del Producto. No existe acuerdo: determina la viabilidad del proyecto y en su caso elabora el control de cambios correspondiente y el plan de prxima iteracin para lograr acuerdo de Liberacin del Producto. Si existe acuerdo: elabora documento de Aceptacin y lo enva al usuario Tctico para su firma.
Usuario Tctico: recibe documento de Aceptacin, lo valida y lo enva al Lder de

Proyecto. Archiva el documento de Aceptacin para su control y enva cuestionario de Satisfaccin del Usuario.
Lder de Proyecto: en caso de no recibir respuesta en quince das hbiles del oficio de
notificacin, cierra el expediente de esta fase sin la carta de aceptacin. En caso contrario, recibe documento de Aceptacin firmado y el Cuestionario de Satisfaccin archivndolos para su control. Elabora documento de Lecciones Aprendidas, y da por terminado el desarrollo del sistema de informacin. En ambos casos registra en el aplicativo de Programas de Trabajo la aplicacin desarrollada.
41

8 9 Capacitar al personal sobre la creacin y manipulacin de documentacin y capacitar sobre diseo y desarrollo
Objetivos
La capacitacin es la base fundamental de la calidad. Por muy bueno que sea el sistema de la calidad, si el personal no est suficientemente capacitado el sistema no funcionar. Los objetivos del proceso de capacitacin sern: Preparar al personal para la ejecucin inmediata de las diversas tareas del cargo. Proporcionar oportunidades para el desarrollo personal continuo, no solo en su cargo actual, sino tambin en otras funciones en las cuales puede ser considerada la persona. Entrenarlos para que elaboren y mantengan la documentacin de la forma estandarizada de la empresa. Cambiar la actitud de las personas, bien sea para crear un clima ms satisfactorio entre los empleados, aumentar su motivacin o hacerlos ms receptivos a las tcnicas de supervisin y gerencia. Entrenar a los empleados en las tcnicas estandarizadas de desarrollo de software. Proporcionar a la empresa recursos humanos altamente calificados en trminos de conocimiento, habilidades y actitudes para un mejor desempeo de su trabajo. Desarrollar el sentido de responsabilidad hacia la empresa a travs de una mayor competitividad y conocimientos apropiados. Se estimulara a los empleados a trabajar conscientemente para minimizar la cantidad de errores. Se hablar sobre la importancia de los cero defectos y el plan a futuro de la empresa de llegar a ese nivel.
Proceso de capacitacin Al comienzo se seleccionar el personal que realizar la capacitacin, el equipo deber estar formado por personas con conocimiento sobre los temas a tratar, muy buena capacidad de expresarse, predisposicin, y con una forma entretenida de presentar los temas. Este equipo estar compuesto por personal del grupo de calidad, y personal especficamente seleccionado para la capacitacin, los cuales sern contratados externos a la empresa de ser necesario.
42

Calidad de Software Balmer Agustn, Godoy Alzares Luis La capacitacin constar de tres momentos: 1. Presentacin de los participantes que realizarn la capacitacin, presentacin de las expectativas sobre esta capacitacin y una pequea introduccin sobre los temas a tratar. 2. Desarrollo de los contenidos donde se desarrollaran los distintos temas con el uso de tcnicas y ejercicios. 3. Evaluacin de los contenidos, formas de trabajo y metodologas empleadas en el proceso de capacitacin. Ser bienvenida la participacin individual o grupal, la comunicacin o comprensin de conceptos que ayuden a conseguir los objetivos propuestos. El equipo de capacitacin se encargar de: Organizar el taller, la inauguracin, explicar los objetivos y la metodologa a utilizar Planificar las estrategias e instrumentos de comunicacin ms adecuados a las actividades de capacitacin. Estimular y orientar la reflexin y las actividades, juntar, integrar y sintetizar los aportes Detectar los conflictos latentes, ofreciendo respuestas adecuadas y evitando introducir sus propias opiniones como medio de poner fin a los conflictos. Proporcionar indicaciones e instrucciones claras y precisas sobre el uso de los materiales. Disponer de los recursos necesarios para el desarrollo de la capacitacin. Elaborar un informe del taller que incluya la evaluacin de los participantes con observaciones y recomendaciones. Elaborar los certificados de participacin que se entregarn al final de la actividad.
Con respecto a los contenidos: Es importante la motivacin para aprender. El taller debe funcionar como espacio de creacin e intercambio de experiencia entre los presentes. Son importantes los conocimientos previos y la experiencia de cada persona. Las propuestas de trabajo, los estudios de caso, los ejemplos de anlisis tendrn relacin directa con el entorno profesional y social de los participantes. Se favorecern todas las tcnicas de observacin, anlisis, expresin y comunicacin. Al final de cada mdulo se realizar una sntesis y se elaborarn conclusiones.
43

Tcnicas para usar en la capacitacin: el equipo de calidad utilizara distintas tcnicas

eligiendo las ms adecuadas para cada actividad, en pequeos grupos de reflexin, de manera individual, o en plenaria para rescatar informacin en colectividad. Algunas de las tcnicas usadas son: Trabajos en grupo: Permite abordar brevemente los temas propuestos de manera individual contribuyendo al mismo tiempo a elaborar una opinin de grupo. De esta forma se propicia la cooperacin y la evaluacin de las ideas de los otros participantes. Lluvia de ideas: Es una forma creativa y participativa de abordar asuntos. Estudios de caso: Permiten estimular la reflexin individual y la discusin de grupo en la bsqueda de soluciones alternativas.
Los contenidos y duracin de los cursos a realizar son los siguientes: Administracin de Requerimientos Desarrollo del propsito de la administracin de requerimientos y la necesidad de identificar las inconsistencias entre los requerimientos, los planes y los productos de trabajo generados por un proyecto. Desarrollo del Objetivo especfico de la Administracin de Requerimientos y los lineamientos para su cumplimiento Desarrollo de las prcticas especficas de la Administracin de requerimientos: Obtener un entendimiento de los Requerimientos Obtener un compromiso con los requerimientos Administrar los cambios a los requerimientos Mantener una trazabilidad bidireccional entre los requerimientos y los dems productos de trabajo. Identificar inconsistencias entre los requerimientos y los productos de trabajo del proyecto. Objetivos Genricos y la Administracin de Requerimientos Concepto de Lnea Base de Requerimientos Clasificacin de los Requerimientos Priorizacin de Requerimientos Roles y Responsabilidades asociados a la Administracin de Requerimientos Controles relacionados a la Administracin de Requerimientos Duracin: 8 horas
44

Calidad de Software Balmer Agustn, Godoy Alzares Luis Planificacin de Proyectos Desarrollo del propsito de la Planificacin de Proyectos y la necesidad de establecer y mantener planes para las actividades a desarrollar en el proyecto. Desarrollo de los Objetivos especficos de la Planificacin de Proyectos y los lineamientos para el cumplimiento de los mismos Establecer Estimaciones Desarrollar un Plan de Proyecto Obtener un compromiso con el Plan Desarrollo de las prcticas especficas de la Planificacin de Proyectos: Establecer el Alcance del Proyecto Establecer estimaciones de Productos de Trabajo y atributos de tareas Definir el Ciclo de Vida del Proyecto Determinar estimaciones de Esfuerzo y Costo Establecer un Cronograma y un Presupuesto Identificar los Riesgos del Proyecto Planificar la Administracin de los Datos del Proyecto Planificar los Recursos del Proyecto Establecer un Plan de Proyecto Revisar los planes que afectan al Proyecto Reconciliar tareas y niveles de Recursos Obtener un compromiso con el Plan Objetivos Genricos y la Planificacin de Proyectos Administracin de Riesgos Los Ciclos de vida del Proyecto Roles y Responsabilidades asociados a la Planificacin de Proyectos Controles relacionados a la Planificacin de Proyectos Duracin: 8 horas
45

Calidad de Software Balmer Agustn, Godoy Alzares Luis Monitoreo y Control de Proyectos Desarrollo del propsito del Monitoreo y Control de Proyectos y la necesidad de proveer una comprensin del progreso que permita tomar acciones correctivas cuando la performance del proyecto se desve significativamente con respecto a lo planificado. Desarrollo de los Objetivos especficos del Monitoreo y Control de Proyectos y los lineamientos para el cumplimiento de los mismos Monitorear el Proyecto contra el Plan Gestionar Acciones Correctivas hasta su cierre Desarrollo de las prcticas especficas del Monitoreo y Control de Proyectos: Monitorear los Parmetros de la Planificacin del Proyecto Monitorear los Compromisos Monitorear los Riesgos del Proyecto Monitorear la Administracin de Datos del Proyecto Conducir Revisiones de Progreso Conducir Revisiones ante Hitos Tomar Acciones Correctivas Gestionar Acciones Correctivas Objetivos Genricos y el Monitoreo y Control de Proyectos Administracin de Riesgos Los Ciclos de vida del Proyecto Roles y Responsabilidades asociados a la Monitoreo y Control de Proyectos Controles relacionados a la Monitoreo y Control de Proyectos Duracin: 8 horas
46

Calidad de Software Balmer Agustn, Godoy Alzares Luis Administracin de la Configuracin Desarrollo del propsito de la Administracin de la Configuracin y la necesidad de establecer y mantener la integridad de los productos de trabajo, utilizando identificacin, control, contabilidad de estado y auditorias de configuracin. Desarrollo de los Objetivos especficos de la Administracin de la Configuracin y los lineamientos para el cumplimiento de los mismos Establecer Lneas Base Realizar un Seguimiento y Control de Cambios Establecer Integridad Desarrollo de las prcticas especficas de la Administracin de la Configuracin: Identificar tems de Configuracin Establecer un Sistema de Administracin de la Configuracin Crear o Liberar Lneas Base Seguimiento de Requerimientos de Cambio Control de los tems de Configuracin Establecer Registros de la Administracin de la Configuracin. Realizar Auditoras de Configuracin Objetivos Genricos y la Administracin de la Configuracin Concepto de tems de Configuracin Concepto de Ambientes Circuito de Cambios Roles y Responsabilidades asociados a la Administracin de la Configuracin Controles relacionados a la Administracin de la Configuracin Duracin: 8 horas Aseguramiento de la Calidad de Productos y Procesos Desarrollo del propsito del Aseguramiento de la Calidad de Productos y Procesos y la necesidad proveer una adherencia objetiva a los Productos y Procesos. Desarrollo de los Objetivos especficos del Aseguramiento de la Calidad de Productos y Procesos y los lineamientos para el cumplimiento de los mismos Evaluar Objetivamente Procesos y Productos de Trabajo Proveer un entendimiento Objetivo Desarrollo de las prcticas especficas del Aseguramiento de la Calidad de Productos y Procesos: Evaluar Objetivamente Procesos Evaluar Objetivamente Productos de Trabajo y Servicios Comunicar y asegurar la resolucin de No Conformidades Establecer Registros del Aseguramiento de la Calidad de Productos y Procesos. Objetivos Genricos y el Aseguramiento de la Calidad de Productos y Procesos Informes de Calidad Roles y Responsabilidades asociados al Aseguramiento de la Calidad de Productos y Procesos Controles relacionados al Aseguramiento de la Calidad de Productos y Procesos 47

Calidad de Software Balmer Agustn, Godoy Alzares Luis Duracin: 8 horas Medicin y Anlisis Desarrollo del propsito de Medicin y Anlisis. Desarrollo de los Objetivos especficos de medicin y Anlisis Alinear las actividades de medicin y anlisis Establecer objetivos de medicin. Proveer resultado de las mediciones Desarrollo de las prcticas especficas de Medicin y anlisis y los lineamientos para el cumplimiento de los mismos. Establecer objetivos de medicin. Especificar mediciones. Especificar procedimientos de recoleccin y almacenaje. Especificar procedimiento de anlisis. Recolectar datos de mediciones. Analizar datos de mediciones. Almacenar datos de mediciones y resultados. Comunicar los resultados. Objetivos Genricos en medicin y anlisis Roles y Responsabilidades asociados Controles relacionados Duracin: 8 horas
48

10 Estandarizar mtodos de verificacin y validacin sobre los productos

Objetivos
Los procesos de validacin y la verificacin se utilizan para: La evaluacin de productos Determinar si se satisfacen las necesidades del negocio Si se est desarrollando acorde a las especificaciones.
El proceso de desarrollo adoptado por un proyecto depender de los objetivos y metas que tenga el proyecto.
Validacin
El propsito de la Validacin en CMMI es demostrar que un producto o componente del mismo satisface el uso para el que se cre al situarlo sobre el entorno previsto. Las dos metas que se pretenden cumplir en esta rea son: preparar la validacin y validar los productos y/o sus componentes. Las actividades de preparacin de la validacin incluyen establecer y mantener el entorno de validacin, procedimientos y criterios. Cualquier producto o componente del producto puede ser objeto de validacin, incluyendo mantenimiento, sustituciones o productos de formacin. Los entornos usados para realizar la integracin y verificacin de los productos pueden compartirse con las actividades de validacin y as reducir costes y mejorar la eficiencia y la productividad. Las prcticas relacionadas con esta meta son: Establecer un entorno de validacin: establecer y mantener el entorno necesario que soporte la validacin. Establecer procedimientos y criterios de validacin: establecer y mantener procedimientos y criterios de validacin que estn alineados con las caractersticas de los productos seleccionados, las restricciones del cliente sobre validacin, los mtodos y el entorno de validacin.
Los productos y componentes de productos son validados para asegurar que son apropiados para usarse en su entorno operativo. Las actividades de validacin se realizan a travs del ciclo de vida del producto, y las prcticas a realizar son: Realizar validacin: Esta prctica permite la realizacin de la validacin de acuerdo a los mtodos, los procedimientos y los criterios. Analizar los resultados de las actividades de validacin 49

Verificacin
El propsito de la Verificacin en CMMI es asegurar que los productos seleccionados cumplen los requisitos especificados. Esta rea de proceso tiene tres metas: Preparacin de la verificacin Realizacin de revisiones entre pares Verificacin de los mtodos de la seleccin de productos
Para la preparacin la verificacin las prcticas a seguir son: Seleccionar productos para la verificacin: permite la identificacin de los productos de trabajo a verificar, los mtodos a usar para realizar la verificacin y los requisitos a satisfacer por cada producto de trabajo seleccionado. Establecer el entorno de verificacin: permite establecer y mantener el entorno que ser usado para llevar a cabo la verificacin. Establecer criterios y procedimientos de verificacin: permite el desarrollo de los procedimientos y de los criterios de verificacin que estn alineados con los productos de trabajo, requisitos, mtodos y caractersticas seleccionados del entorno de verificacin. Las revisiones entre pares incluyen un examen metodolgico de los productos para identificar posibles defectos del producto o recomendar cambios necesarios. Las revisiones entre pares se aplican sobre los productos seleccionados, y las prcticas a seguir son: Preparar revisiones entre pares. Dirigir revisiones entre pares: conducir las revisiones entre pares e identificar temas resultantes de la revisin. Analizar los datos de las revisiones entre pares: analizar los datos obtenidos de las prcticas anteriores.
La verificacin de los mtodos, procedimientos y criterios se usa para verificar los productos seleccionados y cualquier mantenimiento asociado, formacin y servicios de soporte, usando para ello el entorno de verificacin apropiado. Realizar la verificacin de los productos seleccionados. Analizar los resultados de las actividades de verificacin.
50

Actividades de validacin y verificacin

Las tareas realizadas en los procesos de validacin y verificacin utilizadas para la eliminacin de errores son las pruebas y las revisiones. Las pruebas se encuentran ms relacionadas con el proceso de validacin y las revisiones son tarea ms orientadas al proceso de verificacin.
Pruebas
En las primeras etapas del proceso de desarrollo de deber definir el contenido de un plan de pruebas y de un informe de pruebas. El plan de pruebas es un documento que describe los siguientes puntos de las actividades de prueba: Alcance, Enfoque, Recursos y Planificacin
Identifica, entre otros elementos de pruebas: Caractersticas a probar Tareas de pruebas Quin realizar cada tarea El entorno de pruebas Riesgos requeridos en el plan de contingencia Tcnicas de diseo de pruebas Criterios de entrada y salida a utilizar
El informe de pruebas son documentos que recogen informacin del tipo: Objetivo y alcance de las pruebas Resultados obtenidos durante la realizacin de pruebas Evaluaciones de los elementos de pruebas respecto a sus correspondientes criterios de salida Resultado final de las prueba
51

Los objetivos del proceso de pruebas sern: Establecer la participacin de los roles implicados. Definir el alcance, momento y caractersticas de las diferentes pruebas a realizar. Definir los contenidos de los manuales de usuario y de administracin. Establecer los requisitos necesarios para la aceptacin del producto antes de su promocin a la siguiente fase del ciclo de vida de desarrollo. Definir el ciclo de vida de gestin de un caso de prueba. Establecer los mecanismos de resolucin de casos fallidos producidos en las pruebas del software. Presentar tcnicas y estrategias aplicables en la elaboracin y ejecucin de las pruebas del software.
Las pruebas a llevar a cabo se realizarn dividiendo el esfuerzo total en una secuencia de fases o niveles. Cada fase cubre un objetivo de prueba a alto nivel:
Pruebas unitarias, de componente o de subsistema: Se prueban porciones del

sistema mientras son creadas, se buscan errores de cada pieza del sistema bajo pruebas antes de que se produzca la integracin de las mismas.
Pruebas de integracin: Se prueba una coleccin de unidades, subsistemas o

componentes que se estn comunicando o interactuando, buscando errores en las relaciones y conexiones entre pares y grupos de estas piezas del sistema bajo prueba.
Pruebas de sistema: Se prueba el sistema entero, buscando errores en el

comportamiento, funciones y respuestas particulares y globales del sistema bajo prueba como un todo.
Pruebas de aceptacin o piloto: No buscan errores o fallos. El objetivo es demostrar

que el producto est listo para el paso a produccin.
Revisiones El propsito y beneficios de las revisiones son:

Mejorar la calidad y el entendimiento de los entregables. Identificar y gestionar las expectativas de los involucrados en el negocio. Validar que los entregables soporten la solucin final. Identificar tareas de alto riesgo. Formar al equipo de proyecto y a los involucrados en el negocio. Detectar problemas relacionados con la calidad de forma temprana en el desarrollo de los entregables. 52

Las revisiones seguirn el siguiente proceso bsico:

1. 2. 3. 4. Identificar los entregables a revisar. Desarrollar la lista de participantes en la revisin. El documento bajo revisin es estudiado por los revisores. Los revisores identifican los problemas o temas a tratar en la revisin y se lo comunican al autor de forma verbal o mediante un documento. 5. El autor responde a los comentarios y actualiza el documento segn corresponda.
Algunas de las guas a seguir para llevar a cabo una revisin exitosa son:
Dar formacin al personal sobre los roles de cada uno dentro de la revisin. Estos roles pueden variar de una revisin entre pares a la siguiente. Registrar los defectos y problemas en tablas con datos sobre localizacin del defecto, descripcin del defecto (tipo y origen), comentarios y elementos de accin. Deben registrarse datos consistentes y suficientes (realizando una inspeccin formal por ejemplo). Gestionar y controlar la revisin por pares. Es importante incorporar la planificacin de la revisin dentro de los planes y la planificacin de desarrollo del proyecto, para ayudar a la asignacin adecuada de tiempo y evitar que se salte la preparacin de la misma.
53

Validacin y verificacin del proceso de adquisicin

Los productos, o componentes de productos, son seleccionados para ser validados por el adquiridor dependiendo de los atributos del proyecto. La seleccin de los mtodos ms apropiados para llevar a cabo la validacin se basa en elegir el mejor procedimiento para predecir cmo de bien el producto o servicio adquirido satisfar las necesidades de las partes involucradas en el negocio. En el acuerdo con el proveedor normalmente se recogen los distintos aspectos de la validacin: Lista de productos adquiridos a validar por el adquiridor antes de la aceptacin formal. Lista de productos a validar por el proveedor junto con los clientes, usuarios y dems involucrados en el negocio, utilizando estndares, procedimientos, mtodos y herramientas de validacin aplicables. Mtricas a recoger y a proporcionar por el proveedor con respecto a las actividades de validacin. Rol que tendr el proveedor en la validacin del producto o componentes del producto. Entornos de validacin a utilizar por el adquiridor. Procedimientos y criterios de validacin aplicables al proveedor.
Los proveedores deberan estar involucrados en la seleccin de los mtodos de verificacin para asegurarse de que son apropiados para el entorno de los proveedores. Las actividades de verificacin incluyen: Revisin del paquete de solicitud. Planes y acuerdos con proveedores. Documentos de requisitos. Restricciones de diseo desarrolladas por el adquiridor. Otros productos de trabajo desarrollados por el adquiridor.
54

Etapa de la Calidad
Este periodo durara un ao. En esta etapa la empresa les dar a conocer a sus empleados las nuevas expectativas sobre la calidad y les transmitir la importancia de ella y el rol de cada uno para poder alcanzarla. Se alentara a los empleados a alcanzar metas personales dentro de la empresa apuntando a mejorar la calidad en cada momento. Se estandarizara el control en la empresa siguiendo las mtricas y las mediciones antes fijadas y se har un control sobre los riesgos de iniciar un nuevo proyecto. Por ltimo se fijara un da para recordar la importancia de la mentalidad Cero Defectos.
11 Capacitar todo el personal sobre la calidad

Propsito
Concientizacin de la calidad: se comunicara a los empleados los datos obtenidos por las mediciones sobre el estado de calidad de la empresa, y se har notar lo que cuesta no tener calidad. Los supervisores de cada rea estarn entrenados para orientar a sus empleados y comunicarles y hacerles sentir la preocupacin por mejorar la calidad. Se fomentara el hbito de hablar positivamente acerca de la calidad, y se impulsara a modificar o aclarar ciertas actitudes sobre la calidad. Es una forma de sentar la base para seguir los pasos hacia la accin correctiva y la eliminacin de la causa de errores. Para la accin correctiva se valorara la opinin de los empleados sobre los problemas que los aquejan, no solo los encontrados por inspeccin, auditoria o autoevaluacin, sino tambin los menos obvios que requieren atencin. Si un problema no puede resolverse, ser pasado al siguiente nivel de supervisin. Se realizaran reuniones peridicas de supervisin en al cuales se trataran los distintos problemas encontrados. Las reuniones deben llevarse a cabo, de no ser as el equipo de esa rea deber tomar medidas para que se convoquen. Esto permite adquirir el hbito de identificar problemas y corregirlos dado que los individuos se dan cuenta que los problemas sacados a la luz son tratados y solucionados.
Justificacin
Para lograr calidad es relevante la capacitacin del personal y sta debe ser a su vez integrada, para lo cual debe basarse en los Procedimientos Normalizados de Operaciones que contemplen tanto las Buenas Prcticas de Calidad como aquellos aspectos de la calidad no incluidos hasta el momento.
55

Procedimiento
Capacitacin inicial general. Capacitacin inicial especfica. Capacitacin peridica. Capacitacin extraordinaria.
La capacitacin inicial (general y especfica) es recibida por los trabajadores de nuevo ingreso con el objetivo de poseer los conocimientos bsicos en estos aspectos y les posibilite trabajar conociendo los riesgos existentes en su rea de trabajo y las formas y mtodos para prevenirlos y combatirlos. Sin la aprobacin de estos elementos y conceptos fundamentales, el trabajador no estar apto para ocupar la responsabilidad que se le desea asignar. De la misma forma pero con un carcter peridico, los trabajadores debern recibir una capacitacin sobre mtodos y tcnicas de avanzada en materia de calidad que les permita mantener y profundizar sus conocimientos relacionados con su rea y puesto y con los procedimientos seguros de trabajo. La periodicidad de esta capacitacin deber ser establecida por los centros de acuerdo a las caractersticas y complejidad de los procesos y al estado de calificacin del personal pero al menos debe ser como mnimo una vez al ao. No obstante lo anterior, en caso de que sea necesario debido a cambios de procesos, de equipamiento, de los procedimientos establecidos por el rea o centro, de nuevas disposiciones y reglamentaciones establecidas por los organismos nacionales e internacionales, etc. se deber realizar una capacitacin extraordinaria si no fuera posible esperar por la que con carcter peridico se imparte. Para el logro de la capacitacin de los trabajadores se utilizan diferentes bases, entre las que se encuentran: Normas, regulaciones y recomendaciones de organismos nacionales e internacionales Procedimientos Normalizados de Operaciones (PNO) Manual de calidad del centro Buenas Prcticas de Produccin (BPP) Planes de emergencia Inspecciones de calidad Investigacin de incidentes, accidentes y exposiciones
Las normas, disposiciones y regulaciones nacionales e internacionales debern estar contenidas en los PNO, que deben basarse en la BPP.
56

Calidad de Software Balmer Agustn, Godoy Alzares Luis La capacitacin del personal debe ser tal que se integre en ella, adems de la Calidad, la de produccin, etc., de forma tal que el trabajador al culminar su perodo pueda ser capaz, a la vez que conoce como realizar el proceso de produccin para obtener mayor y mejor calidad, los mtodos seguros de trabajo que garanticen lo anterior y se reduzcan o eliminen la probabilidad de ocurrencia de hechos que pudieran traer problemas. Estructura de la capacitacin La estructura de la capacitacin que se propone partiendo del principio de garantizar calidad es la siguiente: Capacitacin inicial: Es recibida por todos los trabajadores de nuevo ingreso quienes al concluir la misma debern examinar como va de comprobacin de que posee los conocimientos necesarios para comenzar su trabajo. Capacitacin peridica: En la prctica se comprueba si la aplicacin de los conocimientos que adquiri durante la capacitacin inicial son o no satisfactorios. De serlo as, no es necesario volver a capacitar el trabajador. Capacitacin extraordinaria: Es recibida por todos los trabajadores en los casos en que ocurran situaciones no previstas que indiquen la necesidad de ejecutarla (cambio de proceso, equipamiento, materiales, sustancias, inclusin de nuevas normas, regulaciones, recomendaciones tanto de carcter nacional como internacional, etc.). A nivel de rea se debern contar con inspectores de Calidad y entrenadores que recibirn de forma obligatoria curso de capacitacin peridica y de superacin con el objetivo de ampliar sus conocimientos. Estos inspectores y entrenadores sern los responsables de impartir la capacitacin peridica y extraordinaria al resto de los trabajadores de sus reas como una va ms de lograr la participacin de todos en aras de fomentar cada vez ms la Seguridad Integrada.
57

12 Fijar Metas
Propsito
Los supervisores pedirn en las reuniones a sus empleados que establezcan las metas por las cuales les interesara luchar por alcanzar. Estas metas debern ser especficas y cuantificables, y debern ser de plazos entre 30, 60 o 90 das por lo general.
Justificacin
Esto permite que los empleados piensen en alcanzar las metas y realizar tareas especficas en equipos. Se deber implantar un programa de reconocimiento a aquellos que alcancen sus metas o realicen actuaciones sobresalientes
Procedimiento Identificacin del objetivo(s)

Hay dos aspectos fundamentales en la identificacin de objetivos: 1. Deben ser especficos y mensurables: no basta con establecer que es lo que se quiere lograr, hay que determinar el valor especfico que se quiere alcanzar. 2. Deben establecerse positivamente: se vern como hechos ya consumados, as se enfatiza en el logro de los objetivos.
Identificacin de los beneficios y los beneficiarios

Ya identificados los objetivos se procede a determinar cules sern los beneficios que se obtendrn. Al alcanzar metas se estarn dando pasos hacia un mejor estado, ya sea en el nivel de inventarios, en las ventas anuales, en la reduccin de desperdicios en los procesos, etc. Sea cual fuere el mbito en el que se establezcan las metas siempre habrn beneficios y siempre habr alguien que obtenga estos beneficios, si son generales perfecto, pero si son particulares hay que identificarlos y enlistarlos para poder darlos a conocer, no slo a quienes se beneficiarn sino a la organizacin en su conjunto.
58

Fijacin de lmites de tiempo

Adelantados los primeros dos pasos se deben fijar lmites de tiempo para la consecucin de cada objetivo. Cuando se establece un determinado lapso de tiempo se est creando sentido de urgencia para realizar las acciones a que haya lugar, es recomendable, en proyectos cortos (mximo 120 das) trabajar sobre una base diaria mientras que en proyectos de mayor duracin la base podra ser semanal o quincenal. Resulta adecuado elaborar cronogramas que permitan dividir el objetivo en pedazos pequeos, as se cierra la posibilidad de sentir que no se podr conseguir el objetivo final, ya que se estar trabajando en el da a da por conseguir objetivos ms pequeos que sumados permitirn lograr el ms importante
Identificacin de los principales obstculos

Hay que saber cules son los posibles problemas que se podrn encontrar en el camino hacia su consecucin, de otro modo no se podrn realizar planes o adelantar estrategias para resolverlos.
Identificacin de las habilidades y el conocimiento requerido

Determinar qu habilidades y conocimientos habr de poseer quienes desarrollen el proyecto, el encargado del proyecto no tiene que ser un experto en todas las reas, lo que si tiene que tener es la habilidad para encontrar la informacin que necesita y la capacidad para identificar qu habilidades y conocimientos son requeridos.
Identificacin de individuos o grupos con las cuales trabajar

Si se acude a la gente apropiada se encontrar la solucin adecuada
Desarrollo del plan de accin

Las metas no se conseguirn con el simple hecho de determinarlas especficamente o sabiendo cules son las barreras a franquear, se alcanzarn si se ejecuta un plan de accin juicioso paralelo a un cronograma. Muchas de las tareas a adelantar debern fraccionarse en estos siete pasos y se convertirn en pequeos objetivos, la verdad es que el plan de accin es el trabajo diario bajo unas condiciones de planeacin previa que contemplen desde las labores a desarrollar, el tiempo que se les dedicar, las personas que las ejecutarn, hasta las contingencias que se puedan presentar y sus posibles soluciones. La planeacin apropiada evita una ejecucin deficiente.
59

13 Estandarizar los mtodos de control

Propsito
Definir los patrones de desempeo Monitorear el desempeo Comparar el desempeo con los estndares Emprender la accin correctiva para garantizar el logro de los objetivos
La finalidad es asegurar que los resultados de aquello que se plane, organiz y dirigi, se ajusten tanto como sea posible a los objetivos establecidos. Justificacin
El control es una etapa que consiste en el estudio de estndares, medicin y correccin de actividades que permitan el logro de metas propuestas por la misma. Es fundamentalmente, un proceso que gua la actividad ejecutada hacia un fin determinado y comprueba si la actividad controlada consigue o no los objetivos o los resultados esperados.
Procedimiento
El control estar formado cuatro fases las cuales se repetirn en ciclos:
Establecimiento de estndares o criterios: Los estndares representan el desempeo

deseado. Los criterios representan las normas que guan las decisiones. Son disposiciones que proporcionan medios para establecer qu deber hacerse y cul es el desempeo o resultado que se aceptar como normal o esperado. Constituyen los objetivos que el control deber asegurar o mantener. Los estndares pueden estar expresados en tiempo, dinero, calidad, unidades fsicas, costos.
Observacin del Desempeo: Para controlar el desempeo es necesario conocer algo

respecto a ste. El proceso de control permite ajustar las operaciones a determinados estndares previamente establecidos, y funciona basado en la informacin que recibe. La observacin o verificacin del desempeo o del resultado busca obtener informacin precisa sobre la operacin que se est controlando.
60

Comparacin del desempeo con el estndar establecido: Toda actividad

experimenta alguna variacin, error o desviacin. Es importante determinar los lmites de esa variacin aceptada como normal o deseable. No toda variacin exige correcciones, solo aquellas que sobrepasan los lmites normales. El control separa lo que es excepcional para que la correccin se concentre nicamente en las excepciones o desviaciones. Por tanto, el desempeo debe compararse con el estndar para verificar eventuales desviaciones o variaciones. La comparacin del desempeo con el estndar establecido se lleva a cabo, generalmente, por medio de graficas, informes, indicadores, porcentajes, medidas estadsticas, etc. Estos medios de presentacin son tcnicas al servicio del control para tener mayor informacin sobre lo que se debe ser controlado.
Accin Correctiva: El objetivo del control es mantener las operaciones dentro de los
estndares establecidos para conseguir los objetivos de la mejor manera. Las variaciones, errores o desviaciones deben corregirse para que las operaciones se normalicen. La accin correctiva busca que lo realizado corresponda exactamente con lo que se pretenda realizar.
61

14 Crear un comit de cero defectos

Propsito
Se seleccionara a tres miembros del equipo de calidad para estudiar formas de implantar el programa de Cero Defectos en la empresa.
Justificacin
Cero defectos no es un programa de motivacin. El propsito es comunicar a los empleados la nocin de que todo el mundo deber hacer las cosas bien a la primera vez.
Procedimiento
Se deber hacer una orientacin formal a todos los niveles gerenciales. Cada gerente deber entender los pasos como para explicrselo a sus subordinados. Se establecer un da de Cero Defectos para establecer el concepto de Cero Defectos como estndar de desempeo. Este da se dedicara a explicar el concepto, y de esta forma todos entienden de la misma manera. Los supervisores debern explicar a sus subordinados y realizar algn cambio en el rea para que todos reconozcan que es un da de actitud nueva. Establecer este da genera un nfasis y un recuerdo sobre lo que se espera en la empresa.
62

15 Implementar Estimacin de riesgos

Propsito
Se implementara un sistemas de estimacin de riesgos para lo cual se determinara una persona dedicada a realizar y presentar informes. Las decisiones administrativas quedaran en manos de la direccin y las decisiones operativas se evaluaran con los administradores de cada sector. Se evaluara el uso y la compra de software necesario para realizar determinado clculo. Antes de encarar un proyecto se deber realizar el anlisis de riesgo para dicho proyecto y se presentaran informes sobre la conveniencia o no de realizar dicho proyecto.
Justificacin
La administracin de riesgo del proyecto tiene un impacto positivo en la seleccin de proyectos, en la determinacin del alcance de los proyectos, y desarrollar estimados ms reales de costos y plazos. Las herramientas del anlisis de riesgo y administracin de riesgo permiten responder preguntas como cunto tiempo tomara el proyecto, cual ser el costo total, si la ejecucin permitir obtener el producto deseado de acuerdo a las especificaciones requeridas.
Procedimiento
Para llevar adelante esto se deber tener en cuenta los siguientes elementos:
Metodologa: Se debe establecer cmo la administracin de riesgo ser ejecutada en el

proyecto. Determinar qu herramientas y fuentes de informacin est disponible y aplicable.
Roles y responsabilidades: Determinar quines son las personas responsables de

implementar las tareas especficas y proporcionar los informes relacionados a la administracin de riesgo.
Presupuesto y plazos: Determinar cules son los costos y plazos estimados para
ejecutar las tareas relacionadas con los riesgos.
Categora de riesgos: Determinar cules son las categoras de los riesgos que sern
identificados.
Probabilidad de riesgo e impacto: Cules son las probabilidades y los impactos de los
riesgos que sern evaluados. Cules son las tcnicas cualitativas o cuantitativas que sern utilizadas para evaluar los riesgos.
Documentacin de los riesgos: Determinar los formatos de los reportes y los procesos
que sern utilizados para las actividades de la administracin de riesgos.
63

Identificacin de riesgos
Se cuenta con varias herramientas y tcnicas para identificar riesgos. Los administradores de proyectos debern empezar el proceso de identificacin de los riesgos revisando la documentacin, y la informacin reciente e histrica relacionada a la organizacin, y los supuestos que pueden afectar el proyecto. Despus de identificar los riesgos potenciales, los administradores del proyecto podrn utilizar diferentes tcnicas para identificar los riesgos. Las tcnicas sugeridas son: Tormenta de ideas El mtodo Delphi Entrevistas Anlisis causa efecto Anlisis FODA (Fortalezas, debilidades, oportunidades, y amenazas).
Anlisis cualitativo de riesgos

Evala la probabilidad y el impacto de la identificacin de riesgos para determinar su magnitud y probabilidad. Para poder evaluar cuantitativamente los riesgos se contara con tres herramientas: La matriz de probabilidad e impacto para calcular los factores de riesgos La tcnica de seguimiento de los diez factores de riesgo ms importantes La evaluacin del juicio de expertos.
Anlisis cuantitativo de riesgos:

No siempre se puede realizar. Las tcnicas de anlisis cuantitativo ms utilizadas son: El anlisis de rboles de decisin La simulacin El anlisis de sensibilidad.
Planificacin de la respuesta de los riesgos

Luego de planificar los riesgos se deber desarrollar una apropiada estrategia para poder enfrentarlos.
64

Calidad de Software Balmer Agustn, Godoy Alzares Luis Las cuatro estrategias de respuesta riesgos negativos son: a. Evitar los riesgos o eliminar una amenaza especfica, generalmente se logra al eliminar sus causas. b. Aceptar los riesgos o aceptar las consecuencias si el riesgo ocurriese. c. Transferir los riesgos o trasladar la consecuencia de un riesgo y la responsabilidad por su administracin a terceros. d. Mitigar los riesgos o reducir el impacto de un evento riesgoso al reducir la probabilidad de su ocurrencia. Las cuatro estrategias para enfrentar los riesgos positivos son: a. Explotacin del riesgo para asegurarnos que el riesgo positivo ocurra. b. Compartir el riesgo o asignar la propiedad del riesgo a un tercero. c. Mejora del riesgo o cambiar el tamao de la oportunidad al identificar y maximizar los inductores claves de un riesgo positivo. d. Aceptar el riesgo tambin se aplica a los riesgos positivos cuando el equipo del proyecto no puede o escoge no tomar ninguna accin para enfrentar el riesgo.
Monitoreo y control de los riesgos.

El monitoreo y control de los riesgos involucra la ejecucin de los procesos de la administracin de riesgo para responder a los eventos riesgosos. Ejecutar los procesos de la administracin de riesgos significa asegurar que el reconocimiento de los riesgos es una actividad permanente ejecutada por todos los miembros del equipo a lo largo de la vida del proyecto. Se deber tener en cuenta las variables independientes y las dependientes.
Variables independientes Las variables del entorno de la empresa. Estas variables estn referidas a aquellos
factores y/o variables exgenas que influyen sobre el desempeo de la empresa y del xito del proyecto. Entre estas variables se tiene: la cultura organizacional, estndares de la industria, la infraestructura, los recursos humanos, las condiciones del mercado, entre otros.
Los activos de los procesos de la organizacin. Estos activos de la empresa y son

utilizados para lograr el xito del proyecto. Entre los activos ms relevantes podremos citar: las normas y procedimientos administrativos de la empresa, requerimientos de comunicacin de la empresa, procedimientos de control financiero de la empresa, procedimientos de administracin de riesgos, entre otros.
65

Variables dependientes Riesgo de la variabilidad del costo. Cuando se planifica un proyecto de tecnologa de
informacin se presupuesta su costo. El administrador del proyecto enfrenta el riesgo que el costo pueda ser mayor o menor.
Riesgo de la variabilidad del plazo o tiempo. Cuando se planifica un proyecto de

tecnologa de informacin se estima el tiempo o el plazo en el cual se culminar el proyecto. El administrador del proyecto enfrenta el riesgo que el tiempo o el plazo puedan ser mayores o menores.
Riesgo de la variabilidad de la calidad del proyecto. Cuando se planifica un proyecto

de tecnologa de informacin se fijan metas para lograr ciertos estndares de calidad. El administrador del proyecto enfrenta el riesgo que las metas de calidad se satisfagan, las excedamos, o no se logren.
66

16 Fijar un da de Cero Defectos

Propsito
Establecer un da en el ao donde se recuerde la importancia de trabajar con la mentalidad de Cero Defectos.
Justificacin
Al fijar una fecha en el ao para recordar la meta de Cero Defectos en la empresa se crea una forma de recordar a los empleados hacia donde tiene que apuntar, y al conmemorarla cada ao se realza la importancia y se asegura que no sea olvidada por el personal.
Procedimiento
Se elegir un da en el cual se realizara en conmemoracin a la idea de la empresa una jornada de concientizacin, la cual se realizara fuera de la empresa, en un lugar relajado y que permita la interaccin de los individuos. En este da se explicara la idea de la empresa, las metas y las expectativas, y como cada uno de los empleados debe cumplir su roll conscientemente debido a la importancia que cada uno tiene dentro de la empresa. Esta jornada se repetir todos los aos para que no se olviden los conceptos y se genere una alta importancia por dedicarle un da entero a esta.
67

Etapa de evaluacin y reajuste

En esta etapa se evaluaran todas las herramientas utilizadas por la empresa en cada rea, los mecanismos de gestin y las metas a seguir. Se tomaran decisiones sobre mejoras, o cambios de ser necesarios y se ajustaran los mtodos utilizados de acuerdo a lo necesitado en ese momento.
17 Implementar la revisin de tcnicas y gestin en un tiempo determinado

Propsito
Las tcnicas utilizadas en el diseo, desarrollo, produccin, mantenimiento y dems procesos de la empresa debern ser revisadas cada cierto periodo. Tambin se evaluaran las tcnicas de gestin utilizadas por la direccin y los administradores.
Justificacin
Estas revisiones evaluaran si las tcnicas utilizadas estn actualizadas, si no quedaron obsoletas, si todava cumplen su funcin de la manera esperada y si se pueden mejorar o reemplazar.
Procedimiento
La evaluacin la realizara el administrador de cada rea junto con personal externo al rea que tenga conocimientos como para interpretar los resultados y proponer mejoras. Cualquier cambio se presentara a la direccin la cual elegir si dar la orden teniendo en cuenta las opiniones de los administradores y su propio conocimiento. De ser necesaria alguna modificacin, se evaluaran las nuevas tcnicas antes de reemplazar las actuales para determinar si a corto plazo no se presentaran los mismos problemas que se encuentran con los mtodos actuales.
68

18 Fijar trminos para realizar todo de nuevo

Propsito
Actualizar los mecanismos de la empresa, los procedimientos y los conocimientos que el empleado deber tener.
Justificacin
Despus de un cierto periodo, los conocimientos adquiridos por la capacitacin y las modificaciones implementadas se irn perdiendo debido a la inclusin de nuevo personal, o modificaciones en los sectores o en la administracin, cualquier cambio de estndares o un nuevo sistema de procesos a seguir. Todo esto genera la necesidad de realizar una nueva evaluacin, control, revisin de mtricas y procedimientos, y capacitacin.
Procedimiento
Se fijara un lapso en el cual se deber realizar todo de nuevo, siempre teniendo en cuenta otros tiempos donde la capacitacin o los cambios se realizaran por condiciones especiales. Es necesario integrar un nuevo equipo de representantes y volver a empezar. Por ejemplo, el da CD deber ser conmemorado como un aniversario. No se necesita ms que una simple notificacin. O se podr ofrecer una comida especial a todos los empleados. La idea es que el proceso de mejoramiento de calidad es permanente.
69

Calidad de Software

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Calidad de Software

Загружено:

Авторское право:

Доступные форматы

Calidad de Software Manual de Aseguramiento de la Calidad Profesor: Fernando Lpez Gil Alumnos: Agustn Balmer Luis Alfredo Godoy

Manual de Aseguramiento de la Calidad

Manual de Aseguramiento de la Calidad

Monitorizacin y Control de proyectos

Manual de Aseguramiento de la Calidad

Integracin del producto

Manual de Aseguramiento de la Calidad

Anlisis de decisiones y resolucin

Definicin del proceso de la organizacin y enfoque organizacional

Manual de Aseguramiento de la Calidad

Metas a para la empresa en distintos plazos

Mediano plazo: los procesos, el control y la produccin estarn completamente

Largo plazo: la empresa alcanzara el nivel de Cero Defectos (5 aos)

Etapas en que se dividir el proceso de aseguramiento de la calidad

Etapa de Capacitacin (6 meses a 1 ao)

Etapa de la Calidad (1 ao)

Etapa de la Evaluacin y Reajuste

Manual de Aseguramiento de la Calidad

1 Formar un grupo ocupado de la calidad

Manual de Aseguramiento de la Calidad

Manual de Aseguramiento de la Calidad

Mtricas divididas de acuerdo a la fase del producto en la que se aplican

Mtrica de calidad de especificacin: Mide la calidad del anlisis y de los requisitos

Manual de Aseguramiento de la Calidad

Mtrica de complejidad de Card y Glass: esta mtrica se basa en dos factores,

Mtrica de cohesin y acoplamiento: Estas mtricas sirven para cuantificar la cohesin

Mtricas orientadas a objetos

Profundidad rbol de herencia: Esta mtrica se basa en la media de profundidad de la

Nmero de hijos: Cuanto mayor es la media de clases derivadas de otra en la jerarqua

Manual de Aseguramiento de la Calidad

Complejidad ciclomtica y esencial: Las mtricas de complejidad ciclomtica y esencial

Facilidad de Mantenimiento: es la sencillez con que un programa puede corregirse si se

Integridad: es la habilidad de un sistema para proteger sus diferentes componentes

Facilidad de Uso: es el intento por cuantificar la sencillez de una aplicacin al utilizarla.

Manual de Aseguramiento de la Calidad

Establecimiento de una lnea base

Para ser eficaz

Manual de Aseguramiento de la Calidad

3 Realizar mediciones sobre los procesos

Manual de Aseguramiento de la Calidad

Atributos de una Buena Medicin

Manual de Aseguramiento de la Calidad

Manual de Aseguramiento de la Calidad

Histograma: presentacin de una serie de medidas clasificadas y ordenadas, es

Manual de Aseguramiento de la Calidad

4 Evaluar los costos sobre el estado actual de la calidad de la empresa

Costos de prevencin: es el costo de todas las actividades llevadas a cabo para

Manual de Aseguramiento de la Calidad

Costos de evaluacin: estos costos se dan al realizar pruebas, inspecciones y otras

Costos de fallos internos

Manual de Aseguramiento de la Calidad

Costos de fallos externos

Manual de Aseguramiento de la Calidad

5 Estandarizar los mtodos de documentacin en toda la empresa

Manual de Aseguramiento de la Calidad

Software: sistemas desarrollados por la empresa. Se deber detallar especificaciones

Manuales de usuario: en cada rea de la empresa se tendr disposicin la

Manuales de instruccin al operador: cada sistema de la empresa contar con

Manuales de procedimiento: cada sector debe contar con documentacin detallada de

Caso especial: Memorandos internos de la empresa o cualquier tipo de documentacin

Manual de Aseguramiento de la Calidad

Procedimiento Documentacin de fallas

Manual de Aseguramiento de la Calidad

Documento de especificaciones funcionales