O GoConqr está de visual novo! Conte para nós o que você achou.

Fluxograma

Primer parte

Sebastiàn Joo Espanhol

Conteúdo do fluxograma

  1. Definición de calidad

  2. Desde el punto de vista tracendental

    la calidad es algo que se reconoce de inmediato, pero que no es posible definir explícitamente

  3. Desde el punto de vista del Usuario

    Si un producto satisface sus metas especificas , tiene calidad.

  4. Desde el punto de vista del fabricante

    Si un producto cumple con las especificaciones originales, tiene calidad.

  5. Desde el punto de vista del producto.

    La calidad tiene que ver con las

    características inherentes (funciones y características) de un producto.

  6. Desde el punto de vista basado en el valor

    Es lo que un cliente está

    dispuesto a pagar por un producto.

  7. Calidad del software

  8. Es un

    proceso eficaz del software aplicado de modo que crea un producto

    útil que da un valor medible a quienes lo generan y a quienes lo

    utilizan

  9. Calidad del diseño

    Es el

    grado en el que el diseño cumple las funciones y características

    especificadas en el modelo de requerimientos

  10. Calidad de

    conformidad

    Es que tanto sla implementación se

    apega al diseño y que tanto el sistema resultante cumple las metas de requerimientos y desempeño.

  11. Costos de la calidad

  12. La calidad tiene un costo que puede estudiarse en términos

    de prevención, evaluación y falla.

  13. Costos de prevención

    Incluyen

    todas las acciones de la ingeniería de software diseñadas para prevenir

    los defectos.

  14. Costos de evaluación

    Evalúan los productos del trabajo de software para determinar su calidad.

  15. Costos de falla

    Incluyen el precio interno

    de fallar y los efectos externos que precipitan la mala calidad.

  16. Calidad orientada a producto y proceso

  17. La

    ingeniería de software permiten analizar el problema y diseñar una

    solución sólida, ambas actividades críticas de la construcción de software de alta calidad.

  18. Un producto útil entrega contenido, funciones y características que el usuario final desea, ademas de

    ser confiable y libre

    de errores.

  19. Aseguramiento de la calidad del software

  20. Consiste en un conjunto de funciones de auditoría y reportes para evaluar la eficacia y completitud de las acciones de control de calidad.

  21. La meta del aseguramiento de la calidad es proveer al equipo administrativo y técnico la información sobre la calidad del producto para tener perspectiva y confianza en

    que las acciones necesarias para lograr la calidad del

    producto funcionan.

  22. Mejora continua de la calidad

  23. La administración total de la calidad,

    Six Sigma y otras filosofías similares alimentan la cultura de mejora continua.

    Esto ayuda a dar enfoque a desarrollos mas eficaces.

  24. Modelo de mejora de procesos de

    desarrollo

  25. El mejoramiento del proceso de software abarca un conjunto de actividades que conducirán

    a un mejor proceso de software y en consecuencia, a software de mayor calidad. Es un proceso iterativo y continuo

  26. Algunas organizaciones de software tienen poco más que un proceso de software.

    Conforme trabajan para mejorar sus prácticas de ingeniería del software, deben abordar las debilidades en sus procesos existentes e intentar mejorar su enfoque para el

    trabajo de software

  27. Se puede dividir en 5 pasos:

    1) valoración del proceso de software actual

    2) educación y capacitación de profesionales y

    gerentes

    3) selección y justificación de elementos de proceso, métodos de ingeniería del

    software y herramientas

    4) implementación del plan MPS

    5) evaluación y afinación con

    base en los resultados del plan.

  28. Unos de los elementos clave de cualquier plan MPS son la educación y la

    capacitación, actividades que se enfocan en mejorar el nivel de conocimiento

    de administradores y profesionales.

  29. Componentes y relaciones

    entre las áreas de proceso

  30. El mapa de caminos MPS comienza con la valoración, es una serie de

    actividades de evaluación que descubren tanto fortalezas como debilidades

    en el proceso de software existente.

    Como consecuencia de la valoración, una organización de software puede

    desarrollar un plan MPS global.

  31. Niveles de madurez y

    capacidad

  32. El modelo de madurez de capacidad – CMM del Software Engineering Institute sugiere cinco niveles

    de madurez:

  33. Nivel 1, inicial. Pocos procesos definidos, y el éxito depende más del esfuerzo individual que de seguir un proceso y usar un esfuerzode equipo

  34. Nivel 2, repetible. Se establecen procesos de administración de proyecto básicos para rastrear

    costo, calendario y funcionalidad.

  35. Nivel 3, definido. Los procesos para administración e ingeniería se documentan, estandarizan

    e integran en un proceso de software estándar para la organización.

  36. Nivel 4, gestionado. Métricas de proceso de software y de calidad de producto detalladas

    establecen el cimiento de evaluación cuantitativa.

  37. Nivel 5, optimizado. La organización tiene sistemas de realimentación cuantitativa en su

    lugar para identificar las debilidades del proceso y fortalecer esos puntos de manera proactiva.

  38. Principales modelos y estándares de calidad de software

  39. Aunque los CMM y CMMI del SEI son los marcos conceptuales

    MPS de mayor aplicación, se han propuesto algunas alternativas

    que están en uso.

  40. SPICE: una iniciativa internacional para dar apoyo a la valoración de proceso ISO y a estándares de proceso de ciclo de vida

  41. ISO/IEC 15504 para Valoración de Proceso de Software

  42. Bootstrap: un marco conceptual MPS para

    organizaciones pequeñas y medianas que se adecua a SPICE

  43. PSP y TSP: marcos conceptuales MPS individuales y específicos de equipo que se enfocan en procesos micro, un enfoque más riguroso del desarrollo de

    software acoplado con medición

  44. TickIT: método de auditoría que valora el

    cumplimiento de una organización al Estándar ISO 9001:2000

  45. Métodos de evaluación de modelos de calidad

  46. Cualitativamente, quienes impulsan MPS arguyen que un proceso de software mejorado conducirá a calidad de software mejorada. Afirman que

    el proceso mejorado dará como resultado la implementación de mejores filtros de calidad, mejor

    control de cambio y menos reelaboración técnica

  47. Los beneficios incluyen los ahorros en costo asociados con productos de mayor calidad (menos defectos), menos reelaboración, esfuerzo reducido asociado con cambios e ingreso que se acumula por menor tiempo de llegada al mercado

  48. Los costos incluyen tanto costos MPS directos como indirectos que tienen que ver con un mayor enfasis en el control de calidad

  49. Aseguramiento de la

    calidad del software

  50. El ACS incluye procedimientos para la aplicación eficaz de métodos y herramientas, supervisa las actividades de control de calidad, tales como las revisiones técnicas y las pruebas del software, procedimientos para la administración del cambio, y procedimientos para asegurar el cumplimiento de las normas y

    mecanismos de medición y elaboración de reportes.

  51. Para llevar a cabo el aseguramiento de la calidad del software de manera adecuada, deben recabarse, evaluarse y divulgarse datos sobre el proceso de la ingeniería de software.

  52. Las actividades del ASC son las siguientes:

    Estándares, • Revisiones y auditorías, pruebas, colección y análisis de los errores, administración del cambio, educación, administración de los proveedores, administración de la seguridad, seguridad y administración de riesgos

  53. Aseguramiento estadístico de la

    calidad del software

  54. El aseguramiento estadístico de la calidad del software refleja una tendencia

    creciente en la industria para que se vuelva más cuantitativo respecto de la calidad

  55. Se recaba y clasifica la información acerca de errores y defectos del software .

  56. Se hace un intento por rastrear cada error y defecto hasta sus primeras causas

  57. Se usa el Principio de Pareto, se identifica 20

    por ciento de las causas de errores yd efectos las pocas vitales

  58. Una vez identificadas las pocas causas vitales, se corrigen los problemas que han dado origen a los errores y defectos

Informações

Descrição
Fluxograma sobre Primer parte, criado por Sebastiàn Joo em 05-10-2024.
Criado por
Sebastiàn Joo
Visualizações
3
Avaliação

Fale Conosco

Sobre o que é sua mensagem?

O que você acha do novo visual?

Você gostou?