Juan Carlos Olivares Rojas

Presentación del tema: "Juan Carlos Olivares Rojas"— Transcripción de la presentación:

1 Juan Carlos Olivares Rojas
Software Planning Juan Carlos Olivares Rojas MSN: @jcolivares Social Network: Facebook, LinkedIn. Hi5

2 Clase Pasada Obtener los requerimientos del Problema del Poker Planning Expresarlos en el documento de definición y especificación de requerimientos Aplicar otras técnicas de requerimientos a parte de casos de uso (especificarlo) Programar la especificación de la función conciliar()

3 Clase pasada Analizar diferentes tipos de requerimientos
¿Para especificar requerimientos se tiene que hacer un análisis? Retomar programa orientado a aspectos Analizar requermientos de proyectos con casos de uso.

4 ¿Qué es esto?

5 Especificación Formal
Es la mejor forma de indicar requerimientos, el detalle es que se requiere de un nivel de abstracción muy alto a veces más díficil de expresar el propio problema. Requerimiento: método de ordenamiento de forma ascendente. Entradas: dos arreglos de tamaño n: p y q, donde p es el arreglo original y q el resultado.

6 Especificación Formal
Salida: q[o] < q[1] < q[2] … < … q[n] ¿cuál es el problema? Es válido lo siguiente: public int [] ordenar(int p[]){ int q[] = new int [p.length]; for(int i=0; i<p.length; i++) q[i]=0; Return q;}

7 Planificación del tiempo
Para asegurar que un proyecto de software se realice de manera exitosa es necesario realizar la gestión del proyecto. La gestión de proyectos se compone como cualquier proceso administrativo de cuatro etapas claves: planeación, organización, control y dirección. Entre los recursos disponibles, el tiempo es la principal restricción de un sistema.

8 Planificación del tiempo
Aunque la administración del tiempo sea prioritario en el desarrollo de proyectos de software, los recursos humanos y materiales deben ser gestionados de forma adecuada. Todos estos recursos implican el uso de recursos económicos. La planeación es el primer acercamiento a la construcción de soluciones. Típicamente se compone de tres fases: Estimación, Itinerario, Seguimiento.

9 Planificación del tiempo
La estimación es la parte más difícil de la planeación dado que se tiene que definir Existen diferentes tipos de planeación en función al tiempo: operativa (táctica) y estratégica. ¿qué tipo de planeación se realiza cuando se desarrolla software? Planeación operativa.

10 Planificación del tiempo
La planificación de proyectos de software es complicada por que es un producto intangible y no hay un “proceso” estándar definido. La planeación parte del pleno entendimiento de lo que es el problema. La planeación tiene como finalidad el logro de objetivos: en nuestro caso el desarrollo exitoso de productos de software.

11 Planificación del tiempo
La planeación es un proceso que nos permite ver donde estamos, hacia donde queremos llegar y que se va a hacer para lograrlo (realización de un plan). Un plan generalmente es un documento escrito que sirve de guía de desarrollo para cumplir las metas del proyecto. Es un proceso iterativo el cual termina hasta que el proyecto mismo haya terminado.

12 Planificación del tiempo
El éxito o fracaso de un proyecto de software depende en gran parte de la planificación, ya que con ayuda de ésta se pueden evitar problemas como: Retraso de tiempo de entrega Sobrepasar el presupuesto Baja calidad del producto Alto costo de mantenimiento, etc.

13 Planificación Planificación del tiempo (calendarización) GESTION DE
PROYECTOS Propuesta Planificación Supervisión Personal Informal PLANIFICACIÓN Estimación de costos (esfuerzo) Gestión de riesgos y control de calidad Gestión de la configuración de sw

14 Gestión de Proyectos El proceso de gestión de proyectos consiste básicamente en: Establecer las prioridades de un proyecto Hacer la valoración inicial de las actividades del proyecto Definir los hitos del proyecto y productos a entregar Mientras el proyecto no se haya terminado o cancelado repetir Bosquejar la programación en el tiempo del proyecto Iniciar actividades conforme a la programación

15 Gestión de Proyectos Fin mientras Esperar (por un momento)
Revisar el progreso del proyecto Revisar los estimados de los parámetros del proyecto Actualizar la programación del proyecto Renegociar las restricciones del proyecto y los productos a entregar Si surgen problemas entonces Iniciar la revisión técnica Fin si Fin mientras

16 Gestión de Proyectos Durante la recolección de requerimientos, se listan todos los elementos que se deben entregar del proyecto: actividades e hitos. Los hitos se convierten en la métrica fundamental que permite medir el grado de avance del proyecto. Más que los hitos son los “entregables del proyecto”. Un hito es un punto de control.

17 Planificación del Proyecto
Entregables del proceso de Planificación

18 Planificación del Proyecto
Ejemplo de una actividad de planeación: Instalar un Sistema de cómputo. ¿Qué se puede Observar? Que es incorrecta ¿Por qué? Cada actividad realizada debe tener asignada un recurso humano responsable de hacerlo, recursos materiales (infraestructura) y financieros para llevarlo acabo.

19 Planificación del Proyecto
Reformulando la actividad: Instalar un sistema de control computarizado en el Departamento de Control Escolar de cada Escuela, Unidad o Centro para el 31 de diciembre de 2006, que no requiera más de 500 horas de trabajo de análisis de sistemas y operaciones con más de 10% de paro durante los tres primeros meses. El responsable de esta actividad es el Ing. Fernando Martínez

20 Planificación del Proyecto
Existen varias formas de representar una planeación: Pueden representarse como una lista de actividades priorizadas, como un programa de actividades, como un calendario de actividades, como una matriz de responsabilidades, etc. Lo importante es la especificación de las actividades a realizar así como los recursos utilizados y productos esperados.

21 Planificación del Proyecto
Generalmente se inicia con lo que se conoce como diagrama de planeación, el cual es otra técnica de organización en la cual nos centramos en cada tarea. También recibe el nombre de diagrama de actividades. En esta etapa se debe definir que actividades se pueden realizar sin depender de ninguna, que actividades para realizarse dependen de otras y finalmente que actividades pueden realizarse simultáneamente (en paralelo).

22 Diagrama de Planeación
Los diagramas de actividades se pueden resumir en una matriz de tiempos, en donde básicamente se debe indicar las tareas, la estimación de tiempo y las relaciones con otras tareas (entregables representados con las letras M). Tarea T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 Duración (días) 8 15 10 5 20 25 7 Dependencias (M1) T2,T4 (M2) T1,T2 (M3) (M5) T3, T6 (M4) T5, T7 (M7) (M6) (M8)

23 Matriz de Tiempo La matriz del tiempo debe contener al menos los siguientes campos: EDT/WBS (Código de la actividad), el nombre de la actividad y la duración en días. La duración del tiempo puede ser estimada o fija. Se considera que un tiempo es fijo aquel que no puede realizarse en menos tiempo o que tiene que realizarse en una fecha indicada.

24 Matriz de Tiempo El tiempo puede ser calculado en base a la siguiente fórmula: En donde: te = Tiempo estimado to = Tiempo optimista tm = Tiempo promedio tp = tiempo pesimista Esta matriz del tiempo puede ser expresada de mejor forma de forma gráfica y de manera conjunta con un diagrama de Gantt.

25 Diagrama de Gantt Se recomienda usarlos cuando son menos de 20 actividades y el tiempo es breve.

26 Diagrama de Planeación
Se deben considerar siempre la asignación de recursos humanos a las actividades. Tarea Ingeniero T1 Jane T2 Anne T3 T4 Fred T5 Mary T6 T7 Jim T8 T9 T10 T11 T12

27 Diagrama PERT El manejo de redes de actvidades con PERT permite utilizar mejores modelos matemáticos de estimación.

28 Time Boxing Se tiene bien definido las fechas de entrega y a partir de allí se realiza una planeación hacia atrás. En metodologías ágiles se cuenta con un tiempo predeterminado, por ejemplo, los sprints en scrum son de 21 días.

29 WBS Es una técnica de planeación en la cual se puede describir y cuantificar la cantidad de trabajo a realizar. Es una estructura tipo árbol en la cual se esquematizan y jerarquizan cada una de las actividades a realizar. Es muy parecido a un organigrama con la diferencia que aquí los nodos son tareas.

30 WBS Se debe cumplir la regla de que todas los nodos hijos de un padre la suma de sus ponderaciones dan 100% las actividades del padre. Las tareas de WBS llevan una numeración que indica su orden y anidamiento, muy parecido a un índice temático.

31 WBS Las ramas de cada árbol se les llama paquete y deben ser totalmente independientes de otros paquetes. Las actividades de mayor nivel (de preferencias todas) deben ser medibles para poder cuantificar el grado de avance. Las actividades deben presentar resultados tangibles.

32 WBS

33 WBS

34 Evaluación del costo beneficio
En todo proyecto que se desarrolle siempre es importante conocer si es realmente es costo-efectivo el desarrollo de software tanto a nivel de cliente como a nivel de desarrollo. Para poder evaluar un proyecto se necesita que esté terminado. Generalmente la evaluación se da antes de que comience el proyecto de allí la importancia que tiene la estimación en el desarrollo de software

35 Evaluación del costo beneficio
Para poder estimar, se necesita medir. Para poder medir se necesita de un patrón de comparación denominado métrica. Las métricas del software son amplias y variadas.

36 Métricas del Software Las métricas además de ayudarnos a medir nos sirve de base para la calidad. Las métricas son la base de la estimación.

37 Métricas del Software Cuando se recopila un solo aspecto de los datos se está hablando de medidas. Ejemplo: número de líneas de código o número de errores.

38 Métricas del Software Un ingeniero de software recopila medidas y desarrolla métricas para obtener indicadores. Un indicador: es una métrica o una combinación de métricas que proporcionan un visión profunda del proceso y proyecto del software o del producto en si mismo. Hay dos tipos de indicadores o métricas: Indicadores de proceso e indicadores del proyecto

39 Métricas del Software Las carácterísticas deseables para las métricas son: Objetiva. Sencilla, definible con precisión para que pueda ser evaluada. Fácilmente obtenible (a un coste razonable). Válida, la métrica debería medir exactamente lo que se quiere medir y no otra cosa. Robusta. Debería de ser relativamente insensible a cambios poco significativos en el proceso o en el producto.

40 Métricas del Software • Las Métricas de producto pueden medir la complejidad del diseño, el tamaño del producto final (fuente u objeto) o el número de páginas de documentación producida. • Las Métricas de proceso, son tiempo de desarrollo total, esfuerzo en días/hombre o meses/hombre de desarrollo del producto, tipo de metodología utilizada o nivel medio de experiencia de los programadores.

41 Métricas del Software Existen otras formas de clasificación por ejemplo basadas en propiedades objetivas y subjetivas:. Por ejemplo, el tamaño del producto medido en líneas de código (LOC) es una medida objetiva del producto, y una medida subjetiva sería el nivel de experiencia de un programador es una medida subjetiva.

42 Métricas Orientadas al Tamaño
Las Líneas de Código (LOC) son la medida más utilizada para determinar la longitud del código fuente. La definición más común es la siguiente: • Una línea de código es cualquier línea de un texto de un programa que no es un comentario o línea en blanco, sin tener en cuenta el número de instrucciones o parte de instrucciones en la línea. Esta medida se suele representar por NCLOC (No Comentary Lines of Code).

43 Métricas Orientadas al Tamaño
• Si queremos conocer la longitud real del programa esta sería: LOC = NCLOC + CLOC donde CLOC es el número de líneas de comentarios • Una medida indirecta de la densidad de comentarios sería: CLOC / LOC

44 Métricas Orientadas al Tamaño
• ¿Es malo tener tantos comentarios? No. Se debe tener una buena documentación. Los comentarios deben de ser como notas taquigráficas. El problema es considerar los comentarios como métrica para estimar el desarrollo de software. Aunque una buena documentación sea en código o no tiene su costo.

45 Otras métricas Cuando se habla de otras partes del desarrollo del ciclo de vida del software también se pueden cuantificar su proyecto: Realizando un buen modelado los costos son calculados de mejor forma. Visión Diagrama Elemento básico Funcional Diagrama de FD Burbuja Diccionario de datos Dato elemental Datos Diagrama E/R Objetos y Relac. Estado Diagrama de Trans. Estados Estado y transiciones

46 Otras métricas La tarea de determinar costos de un proyecto de software no es tan fácil como parece. En general el costo total de un software está determinado por dos indicadores clave: Esfuerzo para completar una actividad Tiempo calendario se necesita para completar una actividad.

47 Mét. Orientadas a la Función
Es un método para cuantificar el tamaño y la complejidad de un sistema software en términos de las funciones que el usuario desarrolla o desarrollará. Se entiende por funciones a las entradas, salidas, archivos, etc. La métrica por función mejor conocida es el punto de función aunque suelen manejarse muchas métricas como los Puntos de Caso de Uso y Objetos.

48 Más Métricas Existen otras métricas para determinar el tamaño y la complejidad del software. Por ejemplo SIZE1 muestra el número de líneas con “;” que para lenguajes que tienen este terminador de instrucciones funciona de buena forma. La métrica más exacta en cuanto al tamaño es la Complejidad Ciclomática

49 Más Métricas La Complejidad Ciclomática de McCabe (V(G)) evalua la complejidad del software en base a considerar el flujo de un programa como un grafo. V(G)= A – N + 2 Donde A es el número de arcos y N el número de nodos del grafo. Se deben de tomar en cuenta las condicionales

50 Más Métricas Estructuras de Decisión x x x Hacer ... hasta x
Mientras x hacer... Secuencia Si x entonces...

51 Más Métricas Se pueden sacar como corolarios las siguientes fórmulas
V(G) = r, donde r es el número de regiones cerradas del grafo V(G) = c + 1, donde c es el número de nodos de condición Entre más alto es V(G) mayor es la complejidad. Se recomienda que sea menor que 10.

52 Más Métricas ¿Cuál es el software Simple y cual el complejo?

53 Ejemplo Abrir archivos Leer archivo ventas Limpiar línea de impresión WHILE (haya registro ventas) DO Total nacional = 0; Total extranjero = 0; WHILE (haya reg. ventas) y (mismo producto) if (nacional) then sumar venta nacional a total nacional

54 Más Métricas ELSE sumar venta extranjero a total extranjero ENDIF Leer archivo de ventas ENDWHILE Escribir linea de listado Limpiar área de impresión ENDWHILE; Cerrar archivos

55 Más Métricas

56 Estimación Es la predicción de los recurso necesarios para desarrollar un proyecto: capitual intelectual, tiempo, esfuerzo, costos, herramientas, etc. Existen diversas técnicas de estimación entre las que destacan: Opinión de expertos: se basa en la experiencia profesional de un grupo de expertos. La técnica delphi es la más apropiada.

57 Estimación Se recomienda que se consense con varios expertos.
Analogía: se basa en la experiencia de proyectos anteriores por lo que es una mejor aproximación que la opinión de expertos. Descomposición: consiste en dividir el proyecto en pequeños subproyectos a fin de estimar de forma más exacta.

58 Estimación En general se a cuantificado en un 40% el conjunto de actividades que tipicamente no se colocan en una planeación:, leer código, revisar, reunirse, etc. Aproximadamente un 30% del tiempo de los programadores se dedican a actividades personales. Modelos matemáticos: generalmente basados en ecuaciones.

59 Estimación Los modelos matemáticos pueden ser generalmente algorítmicos y empíricos. Los modelos empíricos pueden ser parametrizados y no parametrizados. En general los modelos empíricos parametrizados tienen una ecuación de la siguiente forma: E = A + B X (ev) c

60 Estimación Donde A y B: son constantes obtenidas empíricamente
E: esfuerzo en meses/persona ev: variable de estimación (LDC o PF) Existen muchos modelos matemáticos para estimar costos de proyectos de software: COCOMO, COSIMO, SLIM, etc. En este curso se describirá COCOMO II

61 Desarrollar o Comprar En muchas ocasiones es más aconsejable adquirir un producto de software que desarrollarlo. Los gestores son los que tienen que tomar esta decisión y deben tener en cuenta lo siguiente: Comprar/alquilar el software ya desarrollado con licencia y que se ajuste a las especificaciones.

62 Desarrollar o Comprar Comprar componentes de software parcial o totalmente experimentados y luego modificarlos para ajustarse con las especificaciones. Encargar la construcción del software a una empresa externa. En cualquiera de las tres alternativas, un factor importantísimo es la disponibilidad de recursos humanos, Técnicos/hardware/ software.

63 Estudio de viabilidad El proceso de ingeniería de requerimientos comienza con un estudio de viabilidad. Este es un estudio corto que ayuda a resolver si un nuevo sistema de software es o no candidato para desarrollarse de acuerdo a los recursos y restricciones impuestas por al organización. Llevar a cabo un estudio de factibilidad comprende la evaluación y recolección de información y la redacción de informes.

64 Estudio de viabilidad Viablidad Técnica Viabilidad Económica Operativa

65 Viabilidad Económica En caminada en verificar si existe el suficiente recurso económico para llevar acabo el proyecto. Toma consideraciones como: VPN (Valor Presente Neto) TIR (Tasa Interna de Retorno) TREMA (tasa mínima atractiva de retorno) ROI (Retorno de Inversión) Punto de Equilibrio Estudio de Mercado Estimación de Costos Análisis de Sensibilidad

66 Viabilidad Técnica En caminada los recursos tecnológicos, humanos (capacidades). Los recursos tecnológicos pueden estar dados con respecto al hardware y software. Los recursos humanos enfocados al conocimiento y dominio de las tecnologías. Todos estos recursos implican costos.

67 Viabilidad Operativa Enfocado a determinar si la organización a la cual va dirigido el desarrollo puede utilizar o no los sistemas. En muchas ocasiones los sistemas funcionan de manera adecuada pero no existe el apoyo ni la logística necesaria para que se puedan llevar acabo.

68 Gestión configuración software
Los cambios durante el proceso de construcción de un software: Son inevitables Provocan confusión e incertidumbre Pueden ocurrir en cualquier momento Estos cambios aumentan conforme avanza el tiempo. Gestión de riesgos

69 Gestión configuración software
“El arte de coordinar el desarrollo de software para minimizar…la confusión, se denomina gestión de la configuración. La gestión es el arte de identificar, organizar y controlar las modificaciones que sufre el software…la meta es maximizar la productividad minimizando errores.” Babich [BAB86]. Gestión de riesgos

70 Gestión configuración software
La planificación de la GCS empieza durante las primeras fases del proyecto y debe definir el o los documentos que se controlarán. Aquellos documentos que puedan requerirse para el futuro mantenimiento del software, deberán ser identificados y especificados como documentos de control. Gestión de riesgos

71 Gestión configuración software
El plan de la GCS incluye: La identificación de los ECS La asignación de responsabilidades Las políticas de la GCS La definición de archivos de la GCS que deben ser controladas. La definición de la base de datos Puede incluir información de software externo, proceso de auditoría, etc. Gestión de riesgos

72 Gestión configuración software
El proceso se puede definir en cinco tareas de GCS: Identificación Control de versiones Control de cambios Auditorias de configuración Generación de informes Gestión de riesgos

73 Gestión de Riesgos La administración de riesgos incluye la detección de riesgos y el control de los mismos. ¿Qué es el riesgo? Es la probabilidad de que una actividad no deseada ocurra. Todas las actividades tienen riesgo. No existe una actividad 100% ni 0% riesgosa. Gestión de riesgos

74 Gestión de Riesgos Gestión de riesgos

75 Gestión de Riesgos Gestión de riesgos

76 Gestión de Riesgos Los riesgos son generalmnete calculados por el producto de la probabilidad de ocurrencia de la amenaza vs los impactos que tendría el activo de materializarse dicha amenaza. Los riesgos generalmente son calculados a nivel estadístico como el número de frecuencia en que ha ocurrido un evento contra el número total de eventos disponibles. Gestión de riesgos

77 Gestión de Riesgos Existen muchas metodologías para calcular el riesgo. Todas ellas dependen de los usuarios dado que se estiman. Los riesgos se estiman en niveles generalmente: alto, medio y bajo. Aunque las escalas pueden variar. Lo más importante es tener un plan de contingencia. Gestión de riesgos

78 Gestión de Riesgos Gestión de riesgos

79 Gestión de Riesgos Nivel de Riesgo Impacto Frecuencia Muy Alto Alto
Medio Bajo Gestión de riesgos

80 Otra categoría de riesgos
Son aquellos que se pueden descubrir con una cuidadosa evaluación del plan del proyecto de su entorno técnico Riesgos conocidos Tipos de Riesgos Son aquellos que podemos extrapolar de proyectos anteriores o de nuestra experiencia Riesgos predecibles Son extremadamente difíciles de identificar Riesgos impredecibles *Los riesgos se deben identificar y tratar de minimizarlos **Se deben priorizar los riesgos

81 Ejemplo de Riesgos Riesgo Tipo de riesgo Rotación del personal
Proyecto Cambio de administración Hardware indisponible Cambio de requerimientos Proyecto y producto Retrasos en la especificación Subestimación del tamaño Bajo desempeño de la herramienta CASE Producto Cambio de tecnología Negocio Competencia del producto

82 EJEMPLOS DE POSIBLES RIESGOS
Ejemplo de Riesgos TIPO DE RIESGO EJEMPLOS DE POSIBLES RIESGOS Tecnología: se derivan de tecnología de SW o HW la base de datos que se utiliza en el sistema no puede procesar tantas transacciones por segundo como se esperaba los componentes de software a reutilizar tienen defectos que limitan su funcionalidad Personal: asociadas al equipo de desarrollo imposible contratar personal con los conocimientos requeridos personal clave enfermo o no disponible en momentos críticos Organizacionales: al entorno donde se desarrolla el software la organización se reestructura y una nueva administración se responsabiliza del proyecto los problemas financieros de la organización reducen el presupuesto del proyecto Herramientas: asociado a herramientas case y de apoyo las herramientas CASE generan código ineficiente las distintas herramientas CASE no se pueden integrar Requerimientos: derivado de los cambios requeridos por el cliente cambios de requerimientos que precisan modificaciones en el diseño los clientes no comprenden el impacto de los cambios en los requerimientos Estimación: derivado de los estimados administrativos y los recursos requeridos el tiempo requerido para desarrollar el software está subestimado la tasa de reparación de defectos está subestimada el tamaño del software está subestimado

83 Riesgos en OpenUP RIESGOS
1. Riesgos relacionados con nuevas tecnologías. 2. Riesgos relativos a la arquitectura. 3. Riesgos relativos a construir el sistema adecuado, es decir, que cumpla con su objetivo y con sus usuarios. 4. Riesgos relativos al rendimiento. Riesgos técnicos RIESGOS 1. Gente sin experiencia en el proyecto 2. El calendario propuesto del cliente es muy corto. 3. El cliente no realiza las aprobaciones en el tiempo establecido 4. Existan terceras personas subcontratadas con las que no se ha trabajado antes. Riesgos No técnicos

84 Control de Riesgos Riesgo Estrategia
Problemas financieros de la organización Preparar un documento breve para la dirección de la empresa que muestra que el proyecto hace contribuciones muy importantes a las metas del negocio Problemas de reclutamiento organizar cursos de capacitación para el personal ya existente, investigar la posibilidad de contratar en otras regiones o países Enfermedad del personal reorganizar el equipo de tal forma que se solapen el trabajo y los miembros del equipo comprendan el trabajo de los demás Componentes defectuosos reemplazar los componentes defectuosos con los comprados de fiabilidad conocida Cambios en los requerimientos rastrear la información para valorar el impacto de los requerimientos, maximizar la información oculta en ellos Reestructuración organizativa preparar un documento breve para la dirección de la empresa que muestra que el proyecto hace contribuciones muy importantes a las metas del negocio Rendimiento de la base de datos investigar la posibilidad de comprar una base de datos con el rendimiento preciso Tiempo de desarrollo subestimado alertar al cliente de las dificultades potenciales y las posibilidades de retraso

85 Para ello debemos probar sus especificaciones
¿Qué tiene más calidad? Los dos tienen la misma calidad siempre y cuando cumplan con sus requerimientos Para ello debemos probar sus especificaciones

86 Calidad del software Introducción
La calidad es un concepto muy asbtracto de definir. Algunas definiciones básicas de calidad: Cualidad o conjunto de cualidades de una persona o cosa que permiten compararla con otras de su especie. Enfocadas al cumplimiento de los requerimientos.

87 Calidad del software Introducción
Orientados hacia la satisfacción del cliente. Orientados hacia la productividad (0 defectos) Tipos de Calidad GESTIÓN DE LA CALIDAD

88 Calidad del software Introducción
Algunos ejemplos de falta de calidad en el software: El programa no está probado El sistema operativo está incompleto No están escritos los requisitos Estamos fuera de tiempo en un proyecto

89 Control de Calidad Es una actividad que se debe desarrollar a lo largo del proceso de desarrollo de software, el cual incluye: Políticas de calidad Métodos y herramientas de software efectivo Revisiones Técnicas Formales Prueba Multiescalares Documentación Manejo de métricas e indicadores etc.

90 Control de Calidad La calidad debe de ser mensurable.
La garantía o aseguramiento de la calidad (QA , Quality Assurance) sólo se puede realizar a través de un proceso de seguimiento, por lo tanto la calidad también se planea en el sentido de las técnicas que se usarán para lograr el éxito del proyecto. La calidad como todo proceso tiene costo, pero es más costoso no tener calidad.

91 Control de Calidad El proceso más básico de control de calidad es la inspección, que en el área de desarrollo de software son los RTF. Los RTF sirven de filtro para detectar y corregir defectos. Generalmente se aplican en la etapa de diseño que es donde hay más errores de desarrollo (50-60%). Se debe de revisar al producto no al personal.

92 Control de Calidad El proceso más básico de control de calidad es la inspección, que en el área de desarrollo de software son los RTF. Los RTF sirven de filtro para detectar y corregir defectos. Generalmente se aplican en la etapa de diseño que es donde hay más errores de desarrollo (50-60%). Se debe de revisar al producto no al personal.

93 Control de Calidad Se debe tener una agenda (plan de trabajo)
Se deben evitar impugnaciones Los problemas se enuncian más no se resuelven en ese momento Deben existir reuniones periódicas El control de calidad por excelencia es el control estadístico.

94 Referencias (Weitzenfeld, 2007) Ingeniería de Software Orientada a Objetos con UML, Java e Intrnet, Thomson. (ITM 2007) Material de Libro de Texto de la materia de Planificación y Modelado, Instituto Tecnológico de Morelia. (Sánchez, M. 2009) Material del Curso de Planificación y Modelado.

95 ¿Preguntas?