Calidad: Propiedad o conjunto de propiedades inherentes a algo, que permiten juzgar su valor. Adecuación de un producto o servicio a las características especificadas en un contrato.

Norma: Regla que se debe seguir o a que se deben ajustar las conductas, tareas, actividades, etc. En calidad de software las normas son documentos que especifican requerimientos que pueden ser empleados en organizaciones para garantizar que los productos y/o servicios ofrecios por dichas organizaciones cumplan con su objetivo.

Estándar: Que sirve como tipo, modelo, norma, patrón o referencia. En calidad de software los estándares son acuerdos documentados que contienen especificaciones técnicas u otros criterios percisos para ser usados consistentemente como reglas, guías o definiciones de características para asegurar que los materiales, productos, procesos y servicios cumplan con su propósito.

Proceso: Conjunto de fases sucesivas que conducen a un final. Estas fases se llevan acabo con orden, dependencias, roles, responsabilidades, resultados, tiempos de ejecución y herramientas de apoyo. Hay procesos que pueden predefinirse o personalizarse.

Modelo: Conjunto de buenas prácticas para el ciclo de vida del software, enfocado en los procesos de gestión y desarrollo de proyectos.

Institutos que regulan la calidad:

• ISO: Organización Internacional de Normalización
• IEC: Comisión Electrotécnica Internacional
• IEEE: Instituto de Ingenieros Eléctricos y Electrónicos
• BSI: British Standards Institution
• NOM: Normas Oficiales Mexicanas

Anota los puntos anteriores en tu cuaderno.

Da clic aquí para descargar la presentación sobre las normas ISO

Elabora una tabla comparativa sobre las diferentes normas y estándares ISO mencionados en la presentación anterior.

• Estética: Apariencia sensorial
• Conformidad: con estándares
• Durabilidad: vida prevista (en tiempo de uso)
• Desempeño: Características esenciales que pueden ser medidas (consumo, potencia, aceleración, etc.)
• Confiabilidad: Probabilidad de que el producto no falle o funcione bien durante un período de tiempo.
• Servicio: Rapidez, atención, facilidad de reparación.
• Calidad percibida: Durante el uso en contextos específicos.

• Operación del producto
  1. Corrección: ¿Hace el software lo que yo quiero?
  2. Confiabilidad: ¿Lo hace de forma exacta todo el tiempo?
  3. Usabilidad: ¿Puedo ejecutarlo?
  4. Integridad: ¿Es seguro?
  5. Eficiencia: ¿Se ejecutará sobre mi hardware lo mejor posible?
• Revisión del producto
  1. Facilidad de recibir mantenimiento: ¿Puedo arreglarlo?
  2. Flexibilidad: ¿Puedo modificarlo?
  3. Susceptibilidad de someterse a pruebas: ¿Puedo probarlo?
• Transición del producto
  1. Portabilidad: ¿Puedo utilizarlo en otra máquina?
  2. Reusabilidad: ¿Puedo reutilizar parte del software?
  3. Interoperabilidad: ¿Puedo comunicarlo con otro sistema?

Las métricas de Proyecto se consolidan para crear métricas de proceso que sean públicas para toda la organización del software. El uso de métricas para el Proyecto tiene 2 aspectos fundamentales:

1. Minimizar la planificación del desarrollo haciendo los ajustes necesarios que eviten retrasos y reducir problemas/riesgos potenciales.
2. Evaluar la calidad de los productos en el momento actual y cuando sea necesario, modificando el enfoque técnico que mejore la calidad.

1. Evaluar el estado del proyecto.
2. Seguir la pista de los riesgos potenciales.
3. Detectar las áreas de problemas antes de que se conviertan en “críticas”.
4. Ajustar el flujo y las tareas del trabajo.
5. Evaluar la habilidad del equipo del proyecto en controlar la calidad de los productos de trabajo del software.

Las métricas del Proceso se recopilan de todos los proyectos y durante un largo período de tiempo. Su intento es proporcionar indicadores que lleven a mejorar los procesos de software a largo plazo. Se tendrán métricas asociadas a cada proceso del software (p.e. métricas de implementación). Estos indicadores de proceso permiten que una organización de Ingeniería de Software pueda tener una visión más profunda de la eficacia de un proceso ya existente y permiten que los gestores evalúen lo que funciona y lo que no.

En realidad, las medidas que recopila un equipo de proyecto y las convierte en métricas para utilizarse durante un proyecto, también pueden trasmitirse a los que tienen la responsabilidad de mejorar el proceso de software. Por esta razón, se utilizan muchas de las mismas métricas tanto en el dominio del proceso como en el del proyecto.

La única forma racional de mejorar cualquier proceso es medir atributos del proceso, desarrollar un juego de métricas significativas según estos atributos y utilizar las métricas para proporcionar indicadores que conducirán a una estrategia de mejora.

Las métricas del proceso se caracterizan por:

1. El control y ejecución del proyecto.
2. Medición de tiempos del análisis, diseño, implementación, implantación y post-implantación.
3. Medición de las pruebas (errores, cubrimiento, resultado en número de defectos y número de éxito).
4. Medición de la transformación o evolución del producto.

Las métricas de Producto son privadas para un individuo y a menudo se combinan para desarrollar métricas del proyecto que sean públicas para un equipo de software. Están enfocadas a predecir y controlar:

1. El tamaño (líneas de código, bytes de código, operadores y operandos).
2. La estructura (control de flujo, relación entre componentes, cohesión y acoplamiento).
3. La complejidad (combinación de tamaño y estructura).
4. Los índices para controlar la documentación.
5. La calidad (independencia, completo, entendible, aumentado).
6. La estabilidad (los cambios aumentan el número de fallas, los cambios se pueden dar por definición de requerimientos o por cambios del entorno).

1. Simple y fácil de calcular.
2. Empírica e intuitivamente persuasiva: Debe satisfacer las nociones intuitivas del desarrollador sobre el atributo del producto en evaluación.
3. Consistente y objetiva: Presentar resultados sin ambigüedad.
4. Consistente en el empleo de unidades y tamaños: Deben emplearse medidas que no conduzcan a extrañas combinaciones de unidades.
5. Independiente del lenguaje de programación.
6. Mecanismo para retroalimentación de calidad: Debe proporcionar información para obtener un producto final de mayor calidad.

Da clic aquí para acceder al documento con la información sobre las normas y estándaares en la calidad del producto, proceso y proyecto de software.

Elabora 20 preguntas y respuestas referentes a los modelos de calidad a nivel de los productos y procesos en el desarrollo de software mencionados en el enlace anterior.

Da clic aquí para leer el artículo cientifico.

En equipos de dos, elabora una presentación utilizando el artículo cientifico anterior en donde describas uno de los artefactos generados en la metodología:

1. Mejoramiento continuo (PDCA)
2. Tabla de control de riesgo
3. Historial de cambios
4. Petición de mejora
5. Adecuación de requisitos (Repertory grid)
6. Trazabilidad (IR-Kambas)
7. Control de versiones
8. Recolección y análisis de errores

Da clic aquí para descargar el formato de la evaluación

Elabora una matriz en donde incluyas las siguientes normas y estándares para proyectos de TI. En la matriz deberás incluir la definición de las siglas, la descripción, características importantes, organización a la que pertenece, principales áreas de TI que evalúan y tiempo estimado de implementación.

• ISO
• CMMI
• IEEE
• PSP
• TSP
• MOPROSOFT
• COBIT
• ITIL
• SPICE
• NOM
• IEC
• BSI

Da clic en este enlace para conocer el catálogo de normas ISO (ICS). Elabora una lista personalizada en tu cuaderno en donde incluyas el catálogo de normas ISO donde agregues un dibujo o ilustración referente a cada uno de las normas de la lista.

Da clic en este enlace para conocer las normas de ICS 35 Tecnologías de la Información. Después en tu cuaderno elabora un engranaje como el que se muestra en la siguiente imagen en donde incluyas las normas que aparecen en ICS 35 Tecnologías de la Información.

Da clic en este enlace para conocer acerca de Moprosoft

Da clic aquí para conocer acerca de Moprosoft a través de diagramas

1. Dibuja la arquitectura de Moprosoft (página 4)
2. Dibuja los procesos de Moprosoft (página 5)
3. Menciona los niveles de capacidad por proceso (página 8)
4. Menciona los modelos de referencia de Moprosoft (página 11)
5. Menciona el modelo de procesos para la industria de software MoProSoft, Estructura de procesos (página 15)

Da clic aquí para conocer acerca de CMMI a través de diagramas

1. ¿Qué es CMM? (Página 45)
2. Dibuja los niveles de CMM (página 51)
3. ¿Qué es CMMI? (página 56)
4. Dibuja la estructura del CMMI (página 58)
5. Dibuja las áreas del proceso por nivel de madurez (página 61)

Da clic aquí para descargar el documento sobre PMBOK.

Del enlace anterior, elabora en tu cuaderno un mapa conceptual hipermedial.

Da clic aquí para descargar el documento sobre ITIL.

Del enlace anterior, elabora en tu cuaderno un mapa conceptual de mandala.

Elabora un documento PDF en donde se va a determinar, seleccionando un caso práctico de un proyecto de desarrollo de software, las normas y estándares vistas en la segunda unidad aplicables a la documentación y diseño de un proyecto de T.I. El documento deberá incluir numeración de página, letra arial tamaño 14 y títulos en negritas con letra arial tamaño 16, texto justificado, títulos alineados a la izquierda y agregar ilustraciones:

1. Portada: Nombre de la escuela, logotipo de la escuela, nombre de la carrera, nombre de la asignatura, nombre del profesor, nombre del alumno, matrícula, grupo, lugar y fecha.

2. Índice

3. Introducción (mínimo una cuartilla)

4. Desarrollo: aquí se desarrolla por subtemas: primero se debe presentar el caso práctico, mencionar su objetivo y describir sus requisitos. Se debe indicar los módulos que lo conforman. Se debe incluir un diagrama de caso de uso completo del proyecto. Se debe incluir un diagrama de actividades del desarrollo, junto con la metodología a utilizar y las actividades que lo conforman. Después se debe describir cómo se identifican los estándares y normas aplicables a ese proyecto, luego se deben clasificar y describir los estándares empleados, y finalmente mencionar la importancia de su aplicación en proyectos de TI.

5. Conclusión (deben ser personales y mínimo una cuartilla)

6. Bibliografía (mínimo cinco referencias)

Enviar al correo tw-es-8@outlook.com con fecha de entrega para antes del día miércoles 25 de marzo.