Proceso de desarrollo de Sistemas Embebidos Y aseguramiento de calidad Dr. Leonardo R. Chapela Castañares [email protected]

Número 6 Julio 2014

Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  05  /  noviembre  de  2013  

 

Los cuadernos de trabajo presentan resultados de investigaciones preliminares, que ofrecen algún tipo de información o interpretación relevante dentro de una problemática específica y permiten que los autores reciban comentarios sobre el texto. Su propósito es contribuir al debate informando sobre diversos temas relacionados con las tecnologías de información y comunicación, campo de atención del INFOTEC. Las opiniones vertidas en el documento, el estilo y la redacción son de exclusiva responsabilidad de sus autores. Los comentarios sobre el contenido deberán hacerse llegar directamente a los mismos. ® D.R. Fondo de Información y Documentación para la Industria INFOTEC Av. San Fernando 37, Col. Toriello Guerra, Delegación Tlalpan CP 14050, México, DF Tel. (55) 5624 2800 www.infotec.com.mx   Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

2  

 

Índice I.- Introducción Esquema del ciclo de desarrollo de sistemas embebidos II.- Modelo de administración del ciclo de vida del desarrollo de sistemas embebidos 1.- Administración de procesos de desarrollo de software 2.- Gestión de requerimientos y su solución 3.- Administración de proyectos 4.- Aseguramiento de calidad del software 5.- Proceso de ejecución de proyectos de desarrollo de SE III.- Aseguramiento de la calidad (SEQA) del desarrollo de sistemas embebidos Políticas de calidad SEQA Objetivos del aseguramiento de calidad - SEQA Alcance: aseguramiento de la calidad de procesos SE 1 2

Organización del grupo SEQA Actividades de SEQA

2.1 2.2 2.3 2.4 2.5 3

Documentación de la actividad de SEQA

3.1 3.2 3.3 4

Estándares, convenciones y métricas Productos de SEQA Manejo y comunicación de resultados

CALENDARIO DE ACTIVIDADES y RECURSOS DE SEQA

4.1 4.2 5

Planeación del aseguramiento de la calidad Actividades genéricas de aseguramiento de la calidad Revisión de la gestión de proveedores ACQ Revisión de la administración del proyecto Documentación de no conformidades

Agenda Recursos de la actividad seqa

Capacitación del aseguramiento de calidad de SE

5.1 5.2

Entrenamiento Soporte

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

3  

 

6

AUTORIZACIÓN Y COMUNICACIÓN DEL PLAN SEQA

ANEXOS: 1. 2. 3. 4. 5.

Esquema del proceso del ciclo de desarrollo de sistemas embebidos Descripción de los procesos de desarrollo de sistemas embebidos Análisis de metodologías de desarrollo de SW Matriz del aseguramiento de la calidad (SEQA) del ciclo de desarrollo de SE Guía de procedimientos del aseguramiento de la calidad de SE de INFOTEC

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

4  

 

I.- Introducción El desarrollo de los sistemas embebidos, se distingue por sus componentes tanto de hardware como de software así como su integración. Dicho desarrollo se puede representar esquemáticamente empleando para ello una abstracción de la secuencia de los procesos y subprocesos que participan en el ciclo de vida de dicho desarrollo.

Cabe advertir, que dicha secuencia ve los procesos mutuamente excluyentes y los agrupa en macroprocesos, sin embargo, en la realidad estos interactúan entre sí durante todo el ciclo de vida del desarrollo de los sistemas embebidos. Los macroprocesos son: I.- Administración del Ciclo de Vida II.- Análisis y Diseño III.- Desarrollo de Hardware IV.- Desarrollo de Software V.- Integración y Pruebas   Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

5  

 

VI.- Administración del Prototipo VII.- Producción en Serie Cada uno de estos macroprocesos agrupa los procesos y subprocesos que lo distinguen. Un proceso o subproceso se define con base en las actividades y prácticas mutuamente relacionadas o que interactúan efectiva, las cuales transforman elementos de entrada en resultados que, cuando se realizan de forma satisfacen los objetivos planteados para dicho proceso. Aun cuando los procesos describen el comportamiento de cualquier institución, los procedimientos y prácticas involucradas deben ser analizadas e interpretadas en su contexto y circunstancias internas. Esquema del ciclo de desarrollo de sistemas embebidos El propósito del Esquema del Ciclo del Proceso de Desarrollo de Sistemas Embebidos (SE), en este trabajo, consiste en servir de marco de referencia para la identificación de requerimientos académicos y competencias asociadas, así como para la elaboración de programas de posgrado en sistemas embebidos. En el Anexo 1, se presenta ampliamente el esquema y en el Anexo2, se describen en detalle los procesos de cada macroproceso.

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

6  

 

II.- Modelo de administración del ciclo de vida del desarrollo de sistemas embebidos La definición y especificación de las Áreas Clave de la Administración del Desarrollo de SE, que se presentan en este apartado, se basan en el análisis de las metodologías de los diversos modelos de desarrollo de software existentes a nivel internacional. Los modelos analizados son: § CMMI DEV (Software Engineering Institute - SEI) § Business Analysis - BABoK (International Institute of Business Analysis IIBA) § Project Manager - PMBoK (Project Manager Institute - PMI) § AGILE / SCRUM § Team Software Process - TSP (Software Engineering Institute - SEI) § Personal Software Process (Software Engineering Institute - SEI) § Semantics (Infotec) En el Anexo 3, se presenta el análisis detallado de estas metodologías. A continuación se presenta una breve descripción las Áreas Clave seleccionadas: 1.- Administración de Procesos de Desarrollo de Software Actualmente, existen varios Modelos de Administración de Procesos de Software, sin                         coinciden en que el objetivo primordial consiste en incrementar la embargo          todos productividad y disminuir los costos de las empresas desarrolladoras, a través de prácticas para el mejoramiento continuo de sus procesos de desarrollo.

       Fallas  Internas   Productividad          Fallas  Externas  

Mejora   de  

 

Costos      

Prevención  

Beneficios de la Administración de Procesos de Software: §

Permite la estandarización y optimización de procesos y recursos en las empresas.

§

Aplicación de normas internacionales de calidad en el ciclo de vida del SE.   Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

7  

 

§

La calidad del software, proporciona a las empresas de desarrollo una mejor y más sólida posición competitiva a nivel internacional.

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

8  

 

Sistema de Administración de Procesos La Administración de Procesos puede ser utilizada por la alta dirección con el fin de conducir a la institución hacia una mejora en su desempeño. El enfoque sistémico, permite: Identificar, entender y gestionar los procesos interrelacionados como un sistema, lo cual contribuye a la eficacia y eficiencia de una institución en el logro de sus objetivos. El desempeño de la institución mejora continuamente cuando las actividades y los recursos relacionados se gestionan como un proceso y la toma de decisiones eficaces se basa en el análisis de los datos e información. Los principios de la administración de procesos determinan el nivel de implementación o institucionalización que se pretende lograr; informal; controlado y planeado; estandarizado; optimizado, etc. De esta forma, dichos principios de la permiten orientar y/o asegurar que el proceso logrará el nivel de implementación propuesto.

La filosofía de la mejora de procesos se basa en la premisa de que ‘El uso de las mejores prácticas con un enfoque disciplinado y documentado, garantiza la calidad del producto y para ello se deberá de evaluar los procesos, procedimientos y recursos involucrados’. Dicha evaluación, a su vez, se deberá basar en métricas cuantitativas, cuyos indicadores orienten la ‘mejora continua’. Prácticas Clave (basadas en CMMi): i. ii. iii. iv. v. vi.

Planeación estratégica Selección, contratación y capacitación organizacional Evaluación del desempeño de procesos y recursos - Sistema de Indicadores Implementación y supervisión de normas y estándares Operar un esquema modular de procesos y dominios de especialización Sistema de Mejora Continua de los procesos de desarrollo

2.- Gestión de Requerimientos y su Solución Propósito.- Recopilar, documentar, analizar y controlar los requerimientos de software a fin de mantener la integridad sobre los productos de la organización y mantener la consistencia entre los planes, los productos de trabajo y las actividades de los proyectos de nuevo desarrollo, mantenimiento adaptativo, evolutivo y correctivo.

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

9  

 

Lineamientos (mínimos) Establecer un proceso para analizar los requerimientos del producto en cuanto a software, hardware y otros componentes del sistema que sean necesarios para desarrollar el producto. Garantizar la administración, documentación y rastreabilidad de requerimientos durante el ciclo de desarrollo/implantación, efectuando los cambios necesarios en todos los documentos y procesos que se necesite. Identificar y garantizar los recursos que se requieran para la definición de requerimientos, identificando también todas las herramientas que soporten estas actividades. Prácticas Clave (basadas en BABok - IIBA y/o CMMi 2 y 3) ii. iii.

iv. v.

vi.

Análisis Empresarial - Business Case y alcance del producto Recolección y análisis de Requerimientos - Identificación de clientes y usuarios; requerimientos funcionales, interfaces externas, requerimientos de rendimiento y de bases de datos; estándares aplicables; y atributos de software del sistema. - Documentación Especificación y administración de requerimientos - Documentación Arquitectura del SE - Diagnóstico y solución técnica - Estimaciones de tamaño de los productos a generar - Estimación del esfuerzo de desarrollo/implantación - Definición del equipo de desarrollo y esquema de organización (célula) Validación de Soluciones - Estrategia de desarrollo/implantación - Plan de pruebas y calidad

3.- Administración de Proyectos Propósito.- Estimar, planear y administrar los proyectos de desarrollo e implementación, de acuerdo a los requerimientos y procesos establecidos, manteniendo un estricto control de los cambios. Así como, detectar las desviaciones del proyecto y aplicar acciones correctivas. Lineamientos (mínimos) El proceso de planeación del proyecto, deberá garantizar su realización con base a los requerimientos documentados y aprobados por el cliente, así como mantener su consistencia a través del proceso de desarrollo/implantación.   Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

10  

 

Aprobar la planeación en todas sus fases e identificar las responsabilidades del equipo de desarrollo y del cliente. Generar y describir un proceso que permita verificar el estatus del proyecto y que las actividades cumplan con los objetivos del proyecto; identificando cualquier riesgo y las acciones de mitigación respectivas. Todo proyecto deberá contar con un plan de configuración del software y un proceso de control de cambios de versiones. Todos los cambios serán evaluados para calcular el impacto del cambio en la planeación del proyecto. Identificar y garantizar los recursos que se requieran para realizar la planeación, su seguimiento y los cambios, identificando también todas las herramientas que soporten estas actividades. Prácticas Clave (basadas en CMMi 2) i.

ii.

iii.

Planeación y Seguimiento - Tareas, agenda y presupuesto - Identificación de riesgos y de acciones de mitigación - Medición y Análisis de cumplimiento, trabajo realizado y fondos utilizados Revisiones e inspecciones - Monitoreo de la planeación - Monitoreo de los riesgos - Monitoreo de la calidad Administración de la Configuración del SE y del Control de Cambios.

4.- Aseguramiento de Calidad del Software Propósito.- Revisar y auditar las actividades y productos de software para asegurar que cumplen con los estándares, procedimientos y políticas definidas, así como proporcionar una visibilidad adecuada sobre los procesos y los productos. Lineamientos (mínimos) La administración del aseguramiento de la calidad, se planeará durante las etapas iniciales del proyecto.

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

11  

 

Establecer un proceso que permita el aseguramiento de la calidad de los procesos en uso, además de la generación de estándares y procedimientos para cumplir con las actividades de calidad planeadas. La calidad deberá medirse cuantitativamente: defectos detectados y corregidos, tiempo invertido, etc. Identificar y garantizar los recursos requeridos para realizar el aseguramiento de la calidad, identificando también las herramientas que soporten estas actividades. Prácticas Clave (basadas en CMMi 2) i. ii. iii.

iv. v.

Planeación del Aseguramiento de la Calidad Estándares, convenciones y métricas Revisiones y Auditorías - Auditoría de productos - Revisiones técnicas - Revisiones de cumplimiento de contrato - Revisión de procesos Productos del aseguramiento de calidad y manejo de resultados Recursos, herramientas y capacitación

5.- Proceso de Ejecución de Proyectos de Desarrollo de SE Propósito: Producir soluciones de alta calidad a través de todo el ciclo de vida de desarrollo de sistemas, dentro del presupuesto establecido y en el tiempo previsto, promoviendo: § La detección temprana de problemas § Eliminación o mitigación de riesgos § Entrega de soluciones incorporando valores de negocio a los usuarios § Con una visión estratégica de negocio (Arquitectura empresarial) Desarrollo de aplicaciones, mantenimiento y soporte de sistemas § Desarrollo de aplicaciones a la medida: Sistemas web, Sistemas de software cliente/servidor, Modernización de sistemas legados § Desarrollo de aplicaciones basadas en distintas tecnologías ‘Código Abierto’ § Desarrollo en varias plataformas móviles y diversos dispositivos (teléfono, Tablets, dispositivos portátiles, etc.) § Servicios de comercio electrónico (eCommerce) desarrollado bajo una amplia variedad de estándares § Soluciones para procesamiento de grandes volúmenes de datos, generando información en tiempo real para facilitar la toma de decisiones en las organizaciones.   Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

12  

 

Lineamientos (mínimos) Establecer un proceso de desarrollo de software que sea confiable, es decir, que asegure la calidad de la solución, y que ofrezca reducción de costos y el cumplimiento de rigurosos plazos de entrega, estableciendo una metodología con actividades y entregables bien definidos para: § §

Aprovechar la infraestructura tecnológica del Infotec, así como sus bases de conocimiento en distintos dominios Aplicar las mejores prácticas en desarrollo de aplicaciones, en diversas plataformas cubriendo las necesidades de los distintos clientes, internos y externos.

Contar con herramientas y ambientes de administración de proyectos y desarrollo de software, contar con equipos de desarrollo que dominen diversas tecnologías libres y propietarias; y contar con equipos de trabajo habilitados en distintas metodologías de desarrollo. Prácticas Clave (basadas en CMMi 2) i.

Vigilar el desarrollo del proyecto contra el plan establecido - Vigilar Parámetros del proyecto, compromisos, riesgos del proyecto, manejo de datos - Vigilar participación del cliente - Ejecutar revisiones de progreso y cumplimiento de etapas

ii.

Supervisar acciones correctivas hasta el cierre del proyecto - Analizar incidentes - Ejecutar acciones correctivas

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

13  

 

III.- Aseguramiento de la calidad (SEQA) del desarrollo de Sistemas Embebidos En este apartado se describen las actividades del Aseguramiento de Calidad de Sistemas Embebidos (SEQA), que se deberán llevar a cabo durante el ciclo de vida de los proyectos de desarrollo de Sistemas Embebidos de INFOTEC. El mapeo de dichas actividades y el ciclo de vida, se presenta en el Anexo 4.- Matriz del Aseguramiento de la Calidad (SEQA) del Ciclo de Desarrollo de Sistemas Embebidos.

Políticas y Objetivos de calidad SEQA -     Política de Aseguramiento de la Calidad del Desarrollo de SE - SEQA Asegurar que el desarrollo de Sistemas Embebidos, cumpla plenamente con los compromisos acordados con el cliente y satisfagan sus necesidades, mediante procedimientos que aseguren la calidad de dichos sistemas. Los procedimientos de Aseguramiento de la Calidad, deberán documentarse y deberán conocerlos todas aquellas personas involucradas en estas actividades. Políticas Generales § El Aseguramiento de la Calidad, deberá aplicarse en todos los proyectos de SE de

INFOTEC, distinguiendo: (i) la Gestión de la Calidad de Desarrollos Propios (PQA) y (ii) la Gestión de Calidad de Adquisiciones Subcontratadas a Proveedores (ACQ) § Para cada proyecto de desarrollo de SE, deberán planearse (presupuestarse, administrarse y

documentarse) las actividades del SEQA y deberá contar con un Grupo de Aseguramiento de la Calidad (Grupo SEQA), que garantice el cumplimiento de las políticas de Calidad a lo largo de todo el ciclo de vida del proyecto. § Los requerimientos, compromisos y acuerdos con el cliente, se deberán documentar y dar

seguimiento efectivo a su cumplimiento y resultados esperados.   Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

14  

  § Las actividades y productos de trabajo que se lleven a cabo, deberán cumplir con los

procedimientos establecidos, los estándares aplicables y apegarse estrictamente a los requerimientos del SE. Dichas actividades y sus resultados deberán ser registrados, administrados y comunicados a los grupos e individuos involucrados. § La Gerencia de Desarrollo deberá proveer los recursos necesarios para la realización de las

actividades de Aseguramiento de Calidad, y la Subgerencia deberá establecer los mecanismos de capacitación para la realización de dichas actividades. § El grupo de SEQA, así como los roles y responsabilidades de cada miembro del grupo,

debe darse a conocer a todos los individuos que participan en el proyecto.

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

15  

 

Objetivos Generales del Aseguramiento de Calidad - SEQA Revisar y auditar las actividades y productos del Sistema Embebido para asegurar que cumple con los estándares, procedimientos y políticas definidas, así como proporcionar una visibilidad adecuada de los procesos que están siendo utilizados y de los productos construidos. Objetivos Particulares: ü Gestión de la Calidad de Desarrollos Propios* (PQA) Implica el establecimiento de procedimientos y actividades que permitan realizar revisiones y auditorias a los procesos y productos de trabajo propios, involucrados en el ciclo de vida de proyectos de desarrollo de sistemas embebidos de INFOTEC, para asegurar su calidad. * Basada en CMMI-DEV™ del SEI, el cual orienta al desarrollo de software con calidad. El modelo se centra en los procesos de ingeniería de software, organización y aseguramiento de la calidad. ü Gestión de Calidad de Adquisiciones Subcontratadas* (ACQ) Consiste en definir el trabajo a contratar, seleccionar proveedores y administrarlos de forma eficiente, con el objeto de asegurar el cumplimiento de los compromisos en tiempo y forma, así como las metas de calidad establecidas. * Basada en CMMI-ACQ™ del SEI, el cual orienta la adquisición de productos y servicios. El modelo se centra en los procesos del adquirente y en la administración eficiente de proveedores. Alcance: Aseguramiento de la calidad de procesos SE El alcance de las actividades de SEQA, se establece en términos de los procesos del ciclo de vida de proyectos SE de Infotec© (Anexo 4) y de las fases (ver punto 3.1) en las que se llevarán a cabo las revisiones y auditorías respectivamente, de la siguiente manera: -

Desarrollos  Propios  (PQA)   Adm.,  del  Ciclo  de  Vida  del  Desarrollo  Propio   Requerimientos,  Arquitectura  y  Diseño   Administración  del  Prototipo     Adquisiciones  Subcontratadas  (ACQ)   Adm.,  del  Ciclo  de  Vida  de  la  Adquisición   Ingeniería  de  Hardware:  Estándares,  Semiconductores;  Hardware  Nodes  y     Prototipo  de  Hardware     Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

16  

 

1

Ingeniería  de  Software:  Estándares,  Aplicaciones  (desarrollo  de  SW),  Integración   SW/HW  y  Pruebas  del  Prototipo   Producción  Masiva     ORGANIZACIÓN DEL GRUPO SEQA

Ø

Estructura

Ø

Roles y Responsabilidades

Gerente de Desarrollo • Provee los recursos necesarios para la realización de las actividades de SEQA, así como los mecanismos de capacitación para dichas actividades. • Se mantiene informado acerca del estado actual del proyecto y soluciona problemáticas. • Verifica de forma periódica las actividades de SEQA. • Mantiene informada a la Dirección Ejecutiva. Subgerencia de Adm., de Proyectos y Calidad • Mantiene informada a la Gerencia del estado actual del proyecto. • Verifica que se haya dado solución total a las no conformidades encontradas. Grupo de Aseguramiento de la Calidad (SEQA) • Aplica los procedimientos de aseguramiento de calidad a todos los proyectos SE. • Reporta a la subgerencia sobre sus actividades y hallazgos. • Registra y da seguimiento a la corrección de las no conformidades encontradas.

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

17  

 

Líder de Proyecto SE • Brinda soporte al Grupo SEQA para efectuar las actividades de calidad en su proyecto. • Hace cumplir las políticas y lineamientos de calidad establecidas en la institución. • Promueve la ejecución de cambios para corregir las no conformidades encontradas. 2

Actividades de SEQA*

2.1

Planeación del aseguramiento de la calidad -   Elaborar los Planes de Calidad del proyecto, en términos de los procesos del ciclo de vida de los proyectos SE (punto 1.2) y de las fases preestablecidas, de la siguiente manera: - P1  Plan  PQA  General  de  Desarrollos  Propios   i. Adm. del Ciclo de Vida del Desarrollo Propio - P2  Plan  PQA:  Requerimientos,  Arquitectura  y  Diseño   i. Especificación de Requerimientos del SE ii. Arquitectura del Sistema iii. Diseño SW / HW - P3  Plan  PQA:  Administración  del  Prototipo   - A1  Plan  ACQ  General  de  Adquisiciones  Subcontratadas     i. Adm. del Ciclo de Vida de la Adquisición - A2  Plan  ACQ:  Ingeniería  de  Hardware     i. Estándares ii. Semiconductores iii. Hardware Nodes iv. Prototipo de Hardware - A3  Plan  ACQ:  Ingeniería  de  Software   i. Estándares del Software y del Sistema ii. SW de Aplicación (desarrollo de SW) iii. Integración SW/HW y Pruebas del Prototipo - A4  Plan  ACQ:  Producción  Masiva     Cada uno de estos planes, deberá incluir: - Objetivos  y  alcance   - Responsabilidades  del  grupo  de  SEQA   - Definición  de  actividades  de  revisión  y  auditoría   - Mecanismos  de  registro  y  seguimiento  a  no  conformidades   - Productos  de  SEQA  a  generar   - Estimación  de  los  recursos  requeridos   - Agenda  de  trabajo  de  SEQA   - Revisión,  autorización  y  comunicación  del  plan.    

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

18  

 

*Ver, Anexo 5, Guía de Procedimientos SEQA   2.2 Actividades Genéricas de aseg. de la calidad -

2.2.1

Revisión de Actividades

Las revisiones se refieren al cumplimiento de los procesos y estándares definidos por INFOTEC en cada una de las actividades del proyecto, para ello se necesita: a) Preparación de Revisiones Preparar los recursos y documentación necesarias para realizar las revisiones. b) Determinar las actividades que serán revisadas, tanto de desarrollos internos como de las adquisiciones subcontratadas. La función del grupo de SEQA es asegurar que estas actividades serán cumplidas. c) Elaborar Listado de Verificaciones y Agenda de las Revisiones. ü Plan de Proyecto ü Especificación de Requerimientos ü Mesa de Control de Cambios ü Documentos de Riesgos ü Documento de Estimaciones(tiempos y recursos) ü Documentación Técnica ü Reportes de Estado del Proyecto ü Plan de Adm., de la Configuración Se deben incluir los formatos que serán utilizados en las revisiones. -

2.2.2

Auditoria de Productos y/o Entregables

Las auditorías son realizadas sobre los productos de trabajo y/o los entregables para verificar el cumplimiento de los estándares y con los requerimientos establecidos. a) Preparación de Auditorías Preparar los recursos necesarios para la realización de: i.

Verificación del Cumplimiento de Requerimientos Asegurar que los productos de trabajo seleccionados cumplen con sus requerimientos específicos, estándares y políticas establecidas. Planear la verificación de los productos seleccionados - Identificar los requerimientos que deben ser satisfechos por cada producto a ser verificado   Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

19  

 

- Documentar los métodos, entradas y salidas y los criterios de verificación para cada producto y evaluar los resultados obtenidos - Definir un equipo de personas para verificar los productos seleccionados contra los requerimientos y documentar los resultados - Procedimiento (criterios) para comparar los resultados de las verificaciones contra lo esperado ii.

Validación del Producto con el Usuario / Cliente Mostrar que un desarrollo, producto o servicio cumple con su uso intencionado y la regla de negocio, cuando es colocado en su ambiente establecido. Planear la validación de los productos seleccionados - Seleccionar los productos a ser validados - Revisar los criterios, restricciones y métodos de validación con los interesados - Documentar los escenarios operacionales, procedimientos, entradas y salidas y los criterios para la validación y evaluar los resultados obtenidos - Definir un equipo de personas para las auditorías - Formatos para documentar las desviaciones obtenidas y darles seguimiento b) Determinar los productos que serán auditados, tanto de desarrollos internos como de las adquisiciones subcontratadas. La función del grupo de SEQA es asegurar que estas actividades serán cumplidas. c) Elaborar Listado de Verificaciones y Agenda de las auditorías. Se deben incluir los formatos que serán utilizados en las auditorías.

2.3

Resvisión de la gestión de proveedore ACQ

 

-

2.3.1

Especificación del Proyecto de Adquisición

Determinar que trabajos deberán ser adquiridos o subcontratados, de acuerdo a sus características estrategias, técnicas y funcionales. Planear el Proyecto de Adquisición.- La propuesta y el plan de trabajo deberán especificar cómo se desarrollará el proyecto y los términos y condiciones, de negocio y técnicos que se deberán observar; los requerimientos del producto, estándares aplicables y los criterios de aceptación de productos. Estos documentos serán la base para el seguimiento del proyecto. Selección del Proveedor.- Preparar un paquete de requerimientos (RFP), estimar tiempos y costos de realización y seleccionar los proveedores y establecer el contrato. -

2.3.2

Gestión Técnica de la Adquisición   Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

20  

 

Evaluar la solución técnica del proveedor y gestionar las interfaces de la solución. Planear el análisis de las soluciones técnicas - Seleccionar las soluciones técnicas a ser analizadas (productos, componentes, manuales, planes, etc.), determinar qué aspectos serán analizados, así como las entradas y salidas para el análisis - Procedimiento para verificar que cada solución técnica satisface los requerimientos y para la Identificación y prevención de Riesgos - Definir un equipo de personas para que lleven a cabo revisiones técnicas de los avances y productos finales - Identificar con qué otros productos o servicios y unidades organizativas interactúa la solución técnica La función del grupo de SEQA es asegurar que estas actividades serán cumplidas. El tipo y alcance de las revisiones técnicas depende en gran parte del tamaño, alcance y riesgos del proyecto. -

2.3.3

Monitoreo del Servicio del Proveedor - ACQ

Monitorear el avance y rendimiento del proveedor (agenda, esfuerzo, costo), y asegurar que actúa de acuerdo a los términos establecidos en el contrato. Planear el seguimiento a los avances y cumplimiento del proveedor - Procedimiento para monitorear el avance y rendimiento del proveedor (agenda, esfuerzo, costo) de acuerdo al contrato - Procedimiento para mitigar los riesgos que se identifiquen y atender a los que se presenten - Confirmar que todas las licencias, patentes y garantías se hayan establecido Gestionar las facturas del proveedor - Revisar que las facturas tengan toda la documentación de soporte y que se paguen en tiempo y forma y que estén soportados por la aprobación del entregable o producto 2.4 Revisión de la administración del proyecto Asegurar que la Administración del Proyecto lleve a cabo sus tareas de: Planeación y Seguimiento del Proyecto SE; Administración de Requerimientos, Configuración y Cambios; Monitoreo del Cumplimiento de Compromisos: Acuerdo para desarrollos internos (PQA) o del Contrato de adquisiciones con proveedores (ACQ); Seguimiento de las tareas de SEQA, de acuerdo a los Planes de Aseguramiento de la Calidad, establecidos.

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

21  

 

-

2.4.1

Plan SEQA

El Administrador del Proyecto será responsable de asegurar el cumplimiento de dichos procesos por parte del grupo de SEQA. Se deben incluir los formatos que serán utilizados para realizar las revisiones.

-

Plan PQA General del Desarrollo Propio Plan PQA: Requerimientos, Arquitectura y Diseño

Plan PQA: Administración del Prototipo

-

-

2.4.2

Plan ACQ General de Adquisiciones Plan ACQ: Ingeniería de Hardware Plan ACQ: Ingeniería de Software Plan ACQ: Producción Masiva

Planeación y Seguimiento de Proyectos (PSP) de SE

Planeación de la Revisión del proceso de PSP. Es responsabilidad de la Administración del Proyecto planearlo y darle seguimiento; desarrollar los planes para el proyecto; el grupo de SEQA participará en la elaboración y revisión de los planes y estándares del proyecto. El grupo de SEQA, deberá asegurar el cumplimiento de dichos procesos por parte del Administrador del Proyecto. Se deben mencionar los formatos que deberán ser utilizados para realizar las revisiones. -

2.4.3 Administración de Requerimientos, Configuración y Cambios Planeación de las Revisiones del proceso de Administración de Requerimientos Los requerimientos del SE deberán ser especificados, documentados, registrados, administrados y controlados (su trazabilidad y cambios), así mismo deberá ser verificado su cumplimiento. Por lo que SEQA deberá de revisar que dichas actividades se llevaron a cabo y se realizaron con base a las políticas, lineamientos y procedimientos establecidos. Planeación de las Revisiones del proceso de Gestión de la Configuración El proceso de pretende, administrar y controlar la integridad de los productos generados en el desarrollo del SE. Así mismo, debe controlar los cambios en los productos y reportar el estado de implementación de dichos cambios.   Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

22  

 

El grupo de SEQA será responsable de asegurar el cumplimiento de dichos procesos por parte del Administrador del Proyecto. Se deben incluir los formatos que serán utilizados para realizar las revisiones. -

2.4.4 Cumplimiento de Compromisos: Acuerdo PQA o Contrato ACQ Planear las revisiones periódicas del Estado del Proyecto La Administración del Proyecto deberá reportar formalmente: -

Estado del Proyecto.- Cualquier desviación de los planes o cambios a los acuerdos establecidos deberá ser reportado Cumplimiento.- Identificación del nivel de cumplimiento del proyecto con la organización y el proceso del proyecto establecido. Áreas Problema.- Identificación de problemas potenciales y actuales del proyecto basados en el análisis de revisiones técnicas. Riesgos.- Identificación de riesgos basados en la participación y evaluación del progreso del proyecto y áreas problema.

El grupo de SEQA será responsable de asegurar el cumplimiento de dichos procesos por parte del Administrador del Proyecto. Se deben mencionar los formatos que deberán ser utilizados para realizar las revisiones.

2.5

DOCUMENTACIÓN DE NO CONFORMIDADES

Documentar en forma detallada los resultados de cada una de las revisiones y auditorías realizadas a fin de obtener el grado de cumplimiento de cada proceso o producto. Los resultados deberán ofrecer una amplia visión respecto a cómo se están llevando a cabo las actividades en INFOTEC y de los proveedores y verificar el cumplimiento de lo estipulado en los procesos y políticas de calidad. Planear las revisiones periódicas del proceso de No Conformidades - Realizar la revisión y las adecuaciones necesarias a los procesos, según sea requerido; para verificar que pueden ser aplicados en el actual proyecto. - Documentar las adecuaciones en el borrador del Plan SEQA.

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

23  

 

Planear el procedimiento de documentación de no conformidades - Vaciar la información de cada Listado de Verificación a la hoja de registro correspondiente. - Clasificar las no conformidades: de Formato, Diseño y Defecto - Registrar las observaciones o comentarios necesarios. - Graficar los resultados. - Obtener el grado de cumplimiento de cada uno de los procesos y productos.. 3 3.1

Documentación de la actividad SEQA Estándares, convenciones y métricas

Identificar los estándares convenciones y métricas, tanto de INFOTEC como del cliente, que deban ser utilizados en la realización del proyecto, por fase y/o por producto. Estándares - Estándares y nomenclaturas - Políticas, procesos y metodologías de desarrollo de SE - Criterios y procedimientos de aceptación de requerimientos, pruebas y productos. - Planear y definir las condiciones de las pruebas de aceptación. Métricas - Indicar las métricas a aplicar en el proyecto y en el aseguramiento de la calidad, así como el detalle del método de recopilación y consolidación de las mismas. Métricas sobre los tiempos y costos del proyecto, el costo de la calidad, el número de defectos encontrados por fase, así como del número de defectos encontrados en cada módulo clasificados por tipos de defectos, etc. Métricas para las revisiones y auditorías, se deberá recopilar el número de horas y recursos destinados para dicha actividad, el número de productos evaluados, el tamaño de los mismos y el número de no conformidades encontradas.

3.2

Productos de SEQA

Especificar la documentación que deberá de producirse como resultado de las actividades de aseguramiento de calidad. - Revisar los formatos existentes para realizar las revisiones, auditorías, reportes de no conformidades, reportes ejecutivos, etc., y determinar cuáles serán aplicados. - Realizar las adecuaciones necesarias.   Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

24  

 

- Determinar la nomenclatura estándar a aplicar para los productos de SEQA. - Documentar lo anterior en el borrador del plan. - Los productos que se generen de las actividades de calidad deberán ser administrados y controlados bajo el Sistema de Administración de la Configuración del Sistema.3.3 MANEJO Y COMUNICACIÓN DE RESULTADOS

  -

Planear el procedimiento de manejo y comunicación de resultados - Revisar los mecanismos establecidos para la documentación y el seguimiento a las no conformidades, para verificar que puedan ser aplicados en el proyecto. - Revisar el proceso de documentación de las no conformidades. - Revisar el procedimiento de comunicación de las no conformidades. - Revisar el procedimiento de seguimiento de las no conformidades. - Revisar el procedimiento para escalar las no conformidades no resueltas.

3.3.1 Seguimiento a No Conformidades

No Conformidad, se refiere a la evidencia encontrada durante una revisión o auditoria, que sugiere que los procesos o los productos de trabajo del proyecto no se están siguiendo de manera correcta Planear el procedimiento de Registro y Seguimiento a No Conformidades - Revisar el proceso de monitoreo y verificación de su total resolución. Si se identifican no conformidades en algún producto: este no deberá ser liberado hasta que sean resueltas; deberán monitorearse para verificar que se les dé una solución satisfactoria; deberán ser clasificadas y priorizadas de acuerdo a su relevancia en el desarrollo del proyecto; y deberán tener fecha compromiso para su corrección, se les deberá dar seguimiento y verificar su cumplimiento. Si una no conformidad no ha sido resuelta, deberá turnarse a un nivel superior. -

3.3.2 Reportes de Resultados Reportes de Resultados Describir los reportes que deberán generarse como resultado de las actividades de SEQA, su periodicidad, el responsable de elaborarlos y a quién va dirigidos. (Reporte de No Conformidades, Reporte de Resultados SEQA y Reporte Ejecutivo). Método de Retroalimentación Describir los métodos y la frecuencia en que se va a proveer la retroalimentación sobre las actividades de aseguramiento de calidad con el grupo de ingeniería y otros grupos involucrados en el proyecto.

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

25  

  Método de Comunicación Definir el método y la frecuencia para comunicar los resultados de las actividades de SEQA al grupo de ingeniería y otros grupos involucrados. 4

Calendario de actividades y recursos de SEQA

4.1

Agenda

Planear la elaboración de la agenda de actividades de SEQA, que muestre las fechas de las revisiones y auditorías a realizar así como los recursos y costos estimados. E Integrar o hacer referencia a la agenda de trabajo en el borrador del plan. La agenda deberá incluir las siguientes actividades (ver Apartado 3) i. Planeación del aseguramiento de la calidad ii. Actividades genéricas del aseguramiento de la calidad iii. Revisión de la gestión de proveedores acq iv. Revisión de la administración del proyecto La planeación de la agenda de trabajo, deberá realizarse en conjunto con el líder de proyecto para verificar que las fechas de revisiones y auditorías no tengan conflicto con otras actividades ya programadas. 4.2

RECURSOS DE LA ACTIVIDAD SEQA

Identificar y estimar los recursos humanos y sus perfiles, así como los materiales (HW, SW) y económicos que serán necesarios para desarrollar las tareas de SEQA. Para ello, se deberá de determinar: - Tamaño de los productos a generar. - Esfuerzo (número de horas/hombre) a realizar en las tareas de SEQA. - Recursos humanos requeridos para llevar a cabo las tareas de SEQA. - Herramientas que se utilizarán de apoyo a las tareas de SEQA. - Infraestructura necesaria para realizar las tareas de SEQA. - Costos de las actividades de SEQA. Documentar recursos requeridos en el borrador del plan. Estas estimaciones deberán realizarse de manera simultánea con el resto de las estimaciones generales del proyecto (desarrollo, pruebas, prototipo, instalación, etc.) y estarán basadas en la Estructura de Desglose de Tareas definida por el líder de proyecto.

5

Capacitación del aseguramiento de calidad de SE

5.1

Entrenamiento   Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

26  

  Describir los requerimientos de capacitación de los responsables de realizar las actividades de SEQA, de acuerdo a su perfil y necesidades del proyecto. Elaborar el programa de capacitación de SEQA, e incluirlo en la agenda de actividades de SEQA. 5.2

Soporte

Mencionar quién o qué área dará soporte al área de SEQA y describir las actividades de soporte que el área de SEQA debe brindar al resto del equipo de desarrollo. Identificar las herramientas especiales, técnicas y metodologías que soportan al SEQA, establecer sus propósitos, y describir su uso. 6

Autorización y comunicación del plan SEQA   Revisar el Plan de Aseguramiento de Calidad (ver Punto 3.1) con los grupos involucrados, presentarlo ante la dirección para su autorización y darlo a conocer a fin de que se identifiquen las actividades y responsabilidades del grupo de calidad para con el proyecto. -

Citar a los grupos involucrados junto con el gerente para revisar el plan. Realizar cualquier ajuste derivado de esta revisión. Recabar firmas de autorización de los responsables de cada área. Presentar plan a la dirección. Recabar firma de autorización de la dirección Dar a conocer el Plan de Aseguramiento de Calidad autorizado. Archivar el Plan SEQA en la línea base de planeación.

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

27  

 

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

28  

 

ANEXOS: 1. Esquema del proceso del ciclo de desarrollo de sistemas embebidos

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

29  

 

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

30  

 

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

31  

 

2. Descripción de los procesos de desarrollo de sistemas embebidos

DESCRIPCIÓN DE PROCESOS ....................................................................................... 5 Macroproceso I. Administración del Ciclo de Vida de Sistemas Embebidos¡Error! Marcador no definido. Proceso: Administración del ciclo de vida ...................................................................... 6 Macroproceso II. Análisis y diseño Proceso: Especificación de requerimientos ..................................................................... 7 Proceso: Arquitectura ...................................................................................................... 8 Proceso: Diseño ............................................................................................................... 9 Macroproceso III. Desarrollo de Hardware Proceso: Diseño de Hardware.......................................................................................... 9 Proceso: Semiconductores ............................................................................................. 38 Proceso: Estándares del Hardware ................................................................................ 39 Proceso: Prototipo de Hardware .................................................................................... 40 Macroproceso IV. Desarrollo de Software Proceso: Estándares del software .................................................................................. 42 Proceso: Software de Aplicación ................................................................................... 43 Macroproceso V. Integración y Pruebas Proceso: Prototipo del Sistema Embebido..................................................................... 45   Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

32  

 

Macroproceso VI. Administración del Producto Proceso: Producto del Sistema Embebido ..................................................................... 47 Macroproceso VII. Manufactura en Serie Proceso: Producción ...................................................................................................... 48 Aplicaciones de los Sistemas Embebidos

18

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

33  

 

Descripción de procesos Macroproceso I. Administración del ciclo de vida de los sistemas embebidos MACROPROCESO

PROCESO

I.- ADM. CICLO DE VIDA

ADM. DEL CICLO DE VIDA Adm. de Requerimientos Adm. de Cambios Adm. Datos del Producto

SUBPROCESO

Adm. de la Configuración Adm. de Casos de Uso Adm. de Certificaciones Adm. del Proyecto Cost Assesment Process

Proceso: Administración del Ciclo de Vida Los subprocesos que incluye el proceso de Administración del ciclo de vida de los sistemas embebidos son: § Administración de requerimientos. Considera la gestión de requerimientos complejos de operaciones críticas y de restricciones técnicas y del mercado. Permite garantizar la trazabilidad de requerimientos a lo largo del ciclo de vida del sistema embebido. § § §

§ § § §

Administración de cambios. Plantea el control de solicitudes y aprobaciones de cambio, así como apoyar la continuidad del flujo de trabajo. Administración de datos del producto. Se ocupa de la documentación técnica del usuario, así como para mantenimiento, procedimientos diversos y capacitación, inventario de componentes, información de la parametrización establecida, etc. Administración de la configuración (tanto para hardware como software). Gestionar el uso eficiente de los recursos administrando los costos y las versiones de la programación. Controla los códigos de identificación, procesos, formatos y herramientas, que integran el proceso de desarrollo de producto. Administración de casos de uso. Administración de certificaciones. Permite garantizar la confiabilidad y seguridad del sistema, basada en la normatividad y regulación, validación y verificación técnica, así como en evaluaciones independientes y de organismos de certificación. Administración del proyecto. Actividades de control del proyecto, incluyendo la planeación, el monitoreo, evaluación y mitigación de riesgos así como la calidad del prototipo y/o producto. Proceso de Estimación de Costos. Se lleva a cabo el cálculo de los costos directos (fijos y variables) así como los indirectos del producto a través del ciclo de desarrollo.

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

34  

 

Macroproceso II. Análisis y diseño

II.- ANÁLISIS Y DISEÑO

MACROPROCESO

PROCESO

SUBPROCESO

ESPECIFICACIÓN DE REQUERIMIENTOS

ARQUITECTURA

del SISTEMA

del SOFTWARE

del HARDWARE

del SISTEMA

Analisis de Requerimientos del Sistema

Requerimientos Funcionales

Requerimientos Funcionales

Arquitectura lógica del sistema

Medio Ambiente Contextual (Dinámica Funcional)

Medio Ambiente Contextual (Dinámica Funcional)

Arquitectura técnica del sistema

Requerimientos No-Funcionales

Requerimientos No-Funcionales

División funcional SW/HW

del SOFTWARE

DISEÑO

del HARDWARE

ALTO NIVEL (SW y HW)

de DETALLE

Especificación de Especificación de la arquitectura del la arquitectura de SW Hardware

Componentes del SW

Diseño de Tareas

Soluciones de HW (Board, FPGA, EPLD, DSP, Analog & RF Design)

Mapeo componentes de SW a ECU

Selección Monitor, Kernel o Sistema Operativo

Requerimientos Requerimientos de la Arquitectura de la Arquitectura

Requerimientos Físicos

Requerimientos de Empaque (Case Enclosure)

Requerimientos del Ciclo de Vida

Requerimientos del Ciclo de Vida

Requerimientos del Negocio

Requerimientos del Negocio

Estudios de Factibilidad

Estudios de Factibilidad

Proceso: Especificación de Requerimientos Este proceso considera tres componentes: Sistema, Software y Hardware. Se detallan los subprocesos que incluye cada uno: a) Especificación de requerimientos del Sistema: §

Análisis de Requerimientos del Sistema Embebido en el contexto de la aplicación y uso del mismo.

b) Especificación de requerimientos del Software: §

Requerimientos Funcionales. Emplea un método de análisis específico para sistemas embebidos. Los requisitos funcionales de alto nivel, se definen a través de casos de uso.

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

35  

 

§

Medio Ambiente Contextual (Dinámica Funcional). El sistema debe ser capaz de manejar la dinámica del entorno de sensores y controles mientras proporciona una correcta funcionalidad, así como compatibilidad con el entorno físico (temperatura, interferencias electromagnéticas, humedad, etc.) y del entorno normativo.

§

Requerimientos No-Funcionales. Permite comprender los problemas de mapeo del modelo conceptual al modelo de diseño.

§

Requerimientos de la Arquitectura. Considera alternativas de software-hardware, analógicas, de energía, mecánicas, de redes, así como de hardware digital y el software.

§

Requerimientos Físicos. Reconoce el consumo de energía; la seguridad y fiabilidad; el tamaño físico y peso; geometrías; solidez física (modelaje térmico, etc.).

§

Requerimientos del Ciclo de Vida. Administración de la cadena de componentes; línea de productos, costo de modelos vs costo unitario; actualizaciones; permite garantizar la compatibilidad de funcionalidad, interface y tiempos; disponibilidad de componentes a largo plazo, etc.

§

Requerimientos del Negocio. Identifica características de robustez del producto vs costos; diseño frente a costo de producción; rediseño rápido ante cambios; reducción de componentes y de piezas de repuesto, etc.

§

Estudios de Factibilidad. Incluye el análisis de la factibilidad técnica y económica del desarrollo del producto.

c) Especificación de requerimientos del Hardware: § § § § §

Requerimientos Funcionales Medio Ambiente Contextual (Dinámica Funcional) Requerimientos No-Funcionales Requerimientos de la Arquitectura Requerimientos de Empaque (Case Enclosure)

§ § §

Requerimientos del Ciclo de Vida Requerimientos del Negocio Estudios de Factibilidad

Proceso: Arquitectura del Sistema Embebido Este proceso considera tres componentes: Sistema, Software y Hardware. Se detallan los subprocesos incluye cada uno: a) Arquitectura del Sistema: Esta abarca: la arquitectura lógica del sistema, la arquitectura técnica del sistema y la División funcional SW/HW b) Arquitectura del Software:

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

36  

 

Las Arquitecturas de Software Embebido comprenden. Simple control loop; Interrupt controlled system; y Preemptive multitasking or multi-threading Nota. - la elección del un RTOS (Real Time Operating System) debe hacerse antes de empezar al proceso de desarrollo de aplicación, con base en los requerimientos actuales lo cual en gran parte restringe las opciones futuras. §

Especificación de la arquitectura del SW

La especificación incluye la estandarización del diseño de procesadores y periféricos: Digital Signal Processing; FPGA Design; Board Design; and Analog & RF Design. c) Arquitectura del Hardware: §

Especificación de la arquitectura de Hardware

Proceso: Diseño Este proceso considera dos componentes: Diseño de Alto Nivel (SW y HW) y Diseño de Detalle. Se mencionan los subprocesos que incluye cada uno: a) Diseño de Alto Nivel (SW y HW): El Diseño de alto nivel, implica optimizar el tamaño, costo, fiabilidad y el rendimiento de los sistemas embebidos, y para ello, se utilizan compiladores, ensambladores y depuradores. § Componentes del SW § Soluciones de HW (Board, FPGA, EPLD, DSP, Analog & RF Design) § Selección de Monitor, Kernel o Sistema Operativo b) Diseño de Detalle: Este diseño pretende lograr sincronización, relación de dependencias, asignación de memoria y modelo de ejecución; tomando en cuenta las restricciones de tiempo-real, de complejidad, seguridad, energía (power), temperatura, costos y de otros recursos. Las actividades del diseño de detalle, también incluyen; el Diseño de Tareas, el Mapeo componentes de SW a HW, el diseño de la implementación, verificación y análisis.

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

37  

 

Macroproceso III. desarrollo de hardware

III.- DESARROLLO DE HARDWARE

MACROPROCESO

DISEÑO DE HARDWARE

SEMICONDUCTORES

ESTÁNDARES DEL HARDWARE

PROTOTIPO DE HARDWARE

PROCESO Modelado

Síntesis

Diseño Físico

Processor Core (microprocessors, microcontrollers)

System-on-a-Chip processor (SoC)

Field Programmable Gate Arrays (FPGA)

Application-Specific Integrated Circuit (ASIC)

Digital Signal Processor (DSP)

Electronic Network Control Units Systems (HW) (ECU)

Buses

Sensores

PCB

Construcción del Prototipo

Case Enclosure

Verificación y Pruebas

Diseño del Reuso

Pruebas:

SUBPROCESO

Movil

ECU Architecture:

Diseño

Prototipado

Diseño

Diferenciado

Mechanical

Files (Gerrber)

Integración del Prototipo

Muestras

Estándar

Electrical

Funcional, Paramétrica, Tolerancia Integración y Regresión

Validación con Usuarios

Digital Hardware

Software

Safety Assesment Process

Proceso: Diseño de Hardware Este proceso considera tres componentes: Modelado, Síntesis y Diseño Físico. Se puntualizan los subprocesos que incluye cada uno: a) Modelado y Síntesis En esta tarea se emplean los Modelos de Power consumption, CPU consumption, Memory use, Network bandwidth, Scheduler, etc. b) Diseño Físico Este puede ser: Móvil, Diferenciado o Estándar Proceso: Semiconductores Este proceso considera cinco componentes: a) Processor Core (microprocessors, microcontrollers) Microcontrolador: Es un circuito integrado o chip que incluye las unidades funcionales de una computadora: microprocesador (CPU), memoria y unidades de I/O (entrada/salida). Microprocesador: Es un chip que incluye básicamente la CPU y circuitos relacionados con los buses de datos y memoria. Para poder realizar su tarea se necesitan chips adicionales (sistema mínimo) tales como memoria, circuitos de entrada salida E/S (I/O) y reloj. Muchos de los procesadores se engloban dentro de la filosofía CISC (Complex Instruction Set Computers). También se pueden encontrar en el mercado algunos que operen bajo la filosofía RISC (Reduced Instruction Set Computers); dedicados a la telefonía móvil. b) System-on-a-Chip processor (SoC) El SoC, incluye procesador y periféricos, memoria flash externa de almacenamiento y DRAM para memoria de tiempo de ejecución. El SoC puede implementarse como un

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

38  

 

circuito integrado de aplicación específica (ASIC) o utilizando una matriz de compuertas programables (FPGA). c) Field Programmable Gate Arrays (FPGA) Un FPGA es un dispositivo semiconductor que puede ser programado después de su fabricación; permite a las características del programa de productos y funciones, adaptarse a las nuevas normas, y reconfigurar el hardware para aplicaciones específicas, incluso después de que el producto ha sido instalado en el campo. La tecnología FPGA da libertad al diseñador sobre la arquitectura, si se necesitan más recursos se puede migrar directamente a dispositivos más grandes sin modificar el diseño. FPGA es chip de silicio reprogramable y reconfigurable (nondigital) y una tecnología que convierte los diagramas gráficos de bloque en circuitos digitales de hardware. Es un circuito integrado y procesador, que combina el potencial de ASIC y de los processorbased systems (PBS). Lo atractivo de estos circuitos es la capacidad de ejecutar varios procesos de manera concurrente, similar al multiprocesamiento. d) Application-Specific Integrated Circuit (ASIC) ASIC es un circuito integrado para un uso específico (i.e., un chip diseñado para funcionar exclusivamente en un GPS). Los ASIC están diseñados para usar un lenguaje de descripción de hardware (HDL, Verilog o VHDL). En un entorno distribuido y heterogéneo, el Middleware proporciona interfaces estándares de alto nivel para los desarrolladores de aplicaciones e integradores, para que las aplicaciones puedan ser fácilmente elaboradas, reutilizadas e interoperables. e) Digital Signal Processor (DSP) Los DSP, son microcontroladores o microprocesadores diseñados específicamente, tanto en arquitectura hardware como de instrucciones, para realizar tareas típicas de procesamiento digital de señales en tiempo real. DSP, es un sistema para operaciones numéricas a muy alta velocidad, especialmente de señales analógicas en tiempo real, que puede trabajar con datos en paralelo y un diseño e instrucciones específicas. Como todo sistema basado en procesador programable necesita una memoria donde almacenar los datos con los que trabajará, lo que lo distingue de otro tipo de procesadores. Proceso: Estándares del Hardware Este proceso considera lo siguientes: a) Electronic Control Units (ECU) ECU es una combinación de componentes de hardware y de software embebidos. Es un término genérico para cualquier sistema integrado que controla uno o más subsistemas eléctricos en un automóvil. La estructura del ECU, consiste en componentes de hardware y de software: i).- Microcomputadora (MCU) & Chip de Memoria; Electronic buses, Sensores y Actuator; ii).- Operating System (OS); Driver Software (controla el hardware); Application Software (funcionalidad), y Software Standards (AUTOSAR y GENIVI)   Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

39  

 

b) Buses, Sensores y Actuadores Los Buses son la interconexión de la red de hardware; los Sensores miden la presión, temperatura, velocidad, etc., (on-chip o separado), y el Actuator Transforma señales eléctricas en trabajo mecánico (separado) Existe una amplia gama de ‘buses’ y ‘networks’, que van desde ‘on-chip buses’ hasta internet: Controller Area Network (CAN); OSEK; FlexRay; LIN; Sensor Networks and Network Processor c) Network Systems (HW) -

CU: Computational Unit El CU, agrupa los circuitos básicos para realizar los cálculos esenciales del DSP: Data Address Unit, MAC Unit, Arthmetic Logic Unit (ALU), shifter, Instruction, Control Unit. - DMA: Direct Memory Access El DMA permite que grandes cantidades de información sean transferidas, a o desde, la memoria, sin necesidad de utilizar un procesador. Los datos se transfieren a la memoria DMA, mientras se libera el CPU para otras tareas. Una vez completa la transferencia de datos, el CPU se interrumpe para permitir la limpieza. FPU: FLOATING POINT UNIT La Unidad de Punto Flotante (FPU) se dedica a las operaciones de un procesador: suma, resta, multiplicación, división y raíz cuadrada. - Memory Caches El caché es una memoria especial de alta velocidad, de volumen bajo. El Nivel 1 (L1 o caché primario), está incorporado en el chip del procesador, el nivel 2 (L2) es memoria entre el CPU y la memoria RAM (pero no está en el chip de la CPU), el Nivel 3 (L3) está lentamente reemplazando la función de caché L2. - MOTES: Wireless Sensor Networking WSN El uso de miniaturización, hace posible el mapeo de subsistemas inalámbricos completos con sensores sofisticados, que permite medir un sinnúmero de cosas en el mundo físico y actuar a través de sistemas de monitoreo y control. Estos motes son completamente auto contenidos y de muy bajo consumo de batería. - Periféricos Los sistemas embebidos, se comunican con el mundo exterior a través de periféricos: Communication Interfaces (SCI); Universal Serial Bus (USB); Multi Media Cards (SD Cards, Compact Flash etc.); Networks: Ethernet, LonWorks; Fieldbuses: CAN-Bus, LINBus; Timers: PLL(s), Capture/Compare and Time Processing Units; Discrete IO: aka General Purpose Input/Ouput (GPIO); Analog to Digital / Digital to Analog (ADC/DAC); Debugging Proceso: Prototipado de Hardware Este proceso considera cinco componentes con sus respectivos subprocesos: a) Printed Circuit Board (PCB)   Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

40  

 

La placa de circuito impreso o placa de cableado grabado se utiliza para soportar mecánicamente y conectar eléctricamente componentes electrónicos usando vías o pistas de señales grabadas en hojas laminadas de cobre. El diseño del hardware se realiza en los circuitos integrados o en una placa de circuito impreso (PCB). El Formato o Estándar se conoce como "Embedded Gerber" o "RS274X". b) Construcción del Prototipo El prototipo permite identificar los problemas y hacer cambios, antes de construir el producto final, ya que modela los factores de riesgo (interacción humana con la unidad, la velocidad de respuesta, herramientas, velocidad de código, tamaño del código, habilidad de las personas, tiempo de mercado, etc.). c) Case Enclosure Gabinete o cubierta especializada, diseñada para contener el producto del sistema embebido. d) Verificación y Pruebas §

Verificación de la relación entre una especificación (normalmente una fórmula lógica temporal) y la correspondiente implementación. Esto incluyen la Verificación del Modelo (a través de técnicas de teoría de autómatas, demostración automática de teoremas y enfoques que integran los métodos) y el Código Máquina o Conjunto de Instrucciones que corresponden al patrón de bits de un comando específico del procesador (DSP, FPGA, procesadores de red, etc.).

§

Las Pruebas pueden consistir en: térmicas, vibración, etc.

e) Diseño del Reúso

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

41  

 

Macroproceso IV. Desarrollo de software IV.- DESARROLLO DE SOFTWARE

MACROPROCESO

ESTÁNDARES DEL SOFTWARE

SW DE APLICACIÓN

PROCESO Sistema Operativo

Middleware

Firmware

Modelado

Generación de Código

Prototipo

Inter-task Communication and Synchronisation

Executable Image

ROM

Definición Modular SW

Modelo de Aplicación

Prototipado

Scheduler

Hardware 'aware' Compiler

Flash

Características y Tareas

Codificación abstracta

Sistema Operativo y Aplicaciones

Casos de Uso

Flujo de datos

Verificación y Pruebas

Diseño del Reuso

Pruebas: Funcional, Paramétrica, Tolerancia Integración y Regresión

Validación con Usuarios

SUBPROCESO Memoty Management

File system

Optimización de iteraciones

Device drivers

Estructura de Datos

Proceso: Estándares del software Este proceso considera tres componentes: Sistema Operativo, Middleware y Firmware. Se puntualizan los subprocesos que incluye cada uno: a) Sistema Operativo Los Sistemas Operativos para aplicaciones embebidas, generalmente permiten satisfacer una serie de requisitos no funcionales: consumo de energía, consumo de CPU, uso de memoria , ancho de banda de red en algunas aplicaciones distribuidas, como los sistemas de automoción, ancho de banda de red y el ‘scheduler’. - Operating Systems.- VxWorks 5.x, 6.x, QNX, Integrity, OSE, pSOS, CMX, Linux / RTLinux / RTAI / XENOMAI, Windows, Unix (HP-UX, Solaris, IRIX) - Real Time Operating Systems.- VxWorks, pSOS, Ecos, Nucleus, Proprietary - Embedded OS.- Linux, WinCE, Windows Embedded, CE.NET 4.x, QNX, Symbian - Inter-task Communication and Synchronisation.- Cuando la propia aplicación necesita satisfacer las restricciones de tiempo real, los servicios pueden incluir: Bloqueo de memoria; Operaciones Sincrónicas y Asincrónicas de I/O; Señales y mensajes; Exclusión mutua de servicios (MutEx); Administración de memoria y archivos. - Scheduler .- Su principal función es decidir qué tareas deben ejecutarse. - Earliest Deadline First (EDF); Least Slack Time First (LSF); Rate Monotonic Scheduling (RMS); Controller Synthesis Non Real-time.- Round Robin - Memory Management .- Previamente, la memoria generalmente se asignaba de manera fija, para garantizar un menor tiempo de ejecución. Actualmente se requiere administrar grandes cantidades de memoria en sistemas embebidos, simplemente porque no existen limitaciones de la memoria, consumo de energía y de tiempo de ejecución.   Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

42  

 

-

-

File System Management .- Sistemas embebidos que requieren almacenamiento no volátil de datos (datos que no desaparecen cuando se apaga) suelen usan memoria flash para esto. Para administrar los datos, existen varios formatos de archivo propietarios sistema; el más común es TINY file system. Controlador de Dispositivo (Device Drivers).- Proporciona una interfaz de programación de alto nivel. Un controlador de dispositivo es específico para un determinado sistema operativo, el cual permite adjuntar, leer y escribir datos desde las aplicaciones del software y cambiar el comportamiento del dispositivo periférico.

b) Middleware El Middleware proporciona interfaces de alto nivel, estándar y uniformes para los desarrolladores de aplicaciones e integradores, para que aplicaciones pueden ser fácilmente compuestos, reutilizables, puertos y hechos para interoperar. Las instrucciones de la máquina son las instrucciones de nivel más bajo en el sistema y son ejecutables a nivel de hardware. El software de aplicación y el software del sistema se traducen a la máquina por el compilador (sabe qué instrucciones de máquina utilizar, el diseño de la memoria, etc.). Cada modelo de procesador tiene su propio código máquina o conjunto de instrucciones. c) Firmware Firmware se refiere al código contenido en una memoria de lectura que establece la lógica que controla los circuitos electrónicos de un dispositivo. El concepto representa el límite de la frontera entre hardware y software, y se ha ampliado para explicar cualquier instrucción incluida en ROM o contenido programable de un dispositivo de hardware (cargadores de arranque, código máquina para un procesador, instrucciones de máquina del procesador para el BIOS, configuraciones y datos para los circuitos).

Proceso: Software de Aplicación Este proceso considera cinco componentes: Modelado, Generación de Código, Prototipo, Verificación y Pruebas así como Diseño del Reuso. Se puntualizan los subprocesos: a) Modelado El modelado incluye los componentes de software, las propiedades visibles externamente de los componentes y las relaciones entre ellos. El arquitecto debe tener conocimiento claro de los requisitos del sistema y limitaciones tanto de hardware como de software. (i) Se elabora una arquitectura de software básica, esencialmente las principales grandes estructuras del sistema, para ser refinada en módulos, luego más tarde en funciones y tareas, (ii) Identificar los módulos, por ejemplo: por la agrupación de funciones y tareas. Identificar las tareas que ejecutará las funciones del software. Definir claramente el papel de cada tarea en su módulo; (iii) Los casos de uso se pueden utilizar

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

43  

 

para comprender mejor el comportamiento del sistema y las interacciones entre el sistema y sus usuarios. b) Generación de Código Los diseños de los sistemas embebidos están relacionados con el tamaño, tiempo, potencia, confiabilidad y movilidad y es necesaria una perspectiva de diseño que evalúe el costo-rendimiento de software bajo diversas alternativas. La generación del código, incluye: el Modelo de Aplicación; Codificación abstracta; Análisis del control flujo de datos; Optimización de iteraciones y ‘llamadas’; Estructura de Datos para el modelo de HW. El Análisis del Control del Flujo de Datos, permite comprobar el cumplimiento de las especificaciones en la estructura del SW, a través de una representación gráfica de todas las rutas en que podría pasar durante la ejecución del programa. Así como, verificar el cumplimiento de las operaciones de datos en términos de la interfaz y la validez de los dominios. Las Estructuras de Datos, se generan en base al diseño de software - analysis of loop iterations or optimization of functions calls - mejor comportamiento real del sistema. c) Prototipo El Prototipado del Software, es un paso esencial en la creación de sistemas embebidos de calidad y en un buen ambiente de trabajo. El prototipo permite identificar los problemas y hacer cambios, antes de construir el producto final, ya que modela los factores de riesgo (interacción humana con la unidad, la velocidad de respuesta, herramientas, velocidad de código, tamaño del código, habilidad de las personas, tiempo de mercado, etc.). d) Verificación y Pruebas Las pruebas de software (Funcional, Paramétrica, Tolerancia, Integración y Regresión), comprueban que cierto módulo cumple con los requisitos establecidos. El objetivo no es encontrar cada error de software que existe, sino descubrir situaciones que podrían afectar negativamente la usabilidad y mantenimiento. Y la validación es el proceso de establecer pruebas documentadas del software con el usuario. e) Diseño del Reuso Diseñar un tipo de reutilización, donde una arquitectura de conjunto se reutiliza, no sólo una pieza de código. La arquitectura del software incluye la estructura del sistema y subsistema de sistema y consiste de componentes de software y/o hardware y las relaciones entre ellos. Al igual que hay limitaciones para escribir código reutilizable, existen limitaciones en las arquitecturas para que sean reutilizables. Estas limitaciones se refieren no sólo a la funcionalidad básica del sistema, sino también a su estilo, forma y la naturaleza de los componentes que utiliza.

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

44  

 

Macroproceso V. Integración y pruebas

MACROPROCESO

V.- INTEGRACIÓN Y PRUEBAS

PROTOTIPO DEL SISTEMA EMBEBIDO

PROCESO Integración SW Prueba y Validación y HW

SUBPROCESO

Estabilización y Mantenimiento

Control de Cambios

Proceso: Prototipo del Sistema Embebido Este proceso considera tres componentes: a) Integración de Software y Hardware El hardware se construye en una arquitectura reconfigurable (RIO), que cuenta con potentes procesadores de punto flotante (FPU), FPGA reconfigurable y I/O modular. Plataformas integradas incluyen arquitectura de hardware, arquitectura de software embebido, metodologías de diseño, pautas de diseño y estándares de modelado, caracterización de IP y soporte y verificación de diseño b) Prueba y Validación -

Embedded debugging, puede agruparse en las siguientes áreas: Interactive resident debugging; External debugging; In-circuit debugger (ICD); In-Circuit Emulator (ICE); Simulation de todos los aspectos del hardware. Reliability. El sistema debe mantenerse funcionando por razones técnicas, de seguridad o económicas. Conformal Coating: Comúnmente utilizado para ambientes de alta humedad. Bonding, Underfill & Ruggedization: Utilizados para entornos industriales y militares de de baja, mediana o alta vibración.

c) Estabilización y Mantenimiento Las fallas, por lo general son el resultado de: Errores de diseño, las cuales representan un alto porcentaje de las fallas catastróficas que se producen; restricciones en tiempo real, de seguridad, de energía; y de las características de la complejidad del sistema, entre otras.

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

45  

 

Macroproceso VI. Administración del protopito MACROPROCESO

VI.- ADMINISTRACIÓN DEL PRODUCTO

PRODUCTO DEL SISTEMA EMBEBIDO

PROCESO Certificaciones

Propiedad Intelectual

Liberación del Prototipo

Adm. del Producto

Registros

Documentación y Resguardo

Administración de la Adquisición

SUBPROCESO Patentes

Administración de Proveedores

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

46  

 

Proceso: Producto del Sistema Embebido Este proceso considera cuatro componentes: Certificaciones, Propiedad Intelectual, Liberación del Prototipo y Administración del Producto. Se puntualizan los subprocesos que incluye cada uno: a) Certificaciones Verificar (evaluar) que el producto o entregable cumple con las normas establecidas y estándares técnicos requeridos. b) Propiedad Intelectual La propiedad intelectual se divide en dos categorías: la propiedad industrial, que incluye las invenciones, patentes, marcas, dibujos y modelos industriales e indicaciones geográficas de procedencia; y el derecho de autor, que abarca las obras literarias y artísticas. Se requiere de la obtención de un registro o patente. c) Liberación del Prototipo La implementación de un sistema embebido, varía ampliamente según al sector industrial; hay sectores que siguen el esquema tradicional de implementación, pero en los sectores más recientes o emergentes (teléfonos móviles, tarjetas inteligentes, etc.) el despliegue es de productos masivos. d) Administración del Producto -

-

Administración de la Adquisición.- Incluye los siguientes aspectos: Identificación y Selección del Proveedor, Análisis de la Solución Técnica del Proveedor; Monitoreo del Servicio del Proveedor; Verificación del Cumplimiento de Requerimientos; Validación de la Adquisición con el Usuario Administración de Proveedores.- Incluye los siguientes aspectos: Establecimiento de Acuerdos con el Proveedor; supervisión del Cumplimiento de los Acuerdos; Coordinación del Trabajo del Proveedor.

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

47  

 

Macroproceso VII. Manufactura en serie MACROPROCESO

VII.- MANUFACTURA EN SERIE

PRODUCCIÓN

PROCESO Capacidad Técnica del Proveedor

Calidad y Madurez de Procesos

Entrega y Validación

Implementación en Serie

Configuración

SUBPROCESO

Instalación

Validación de la Implementación

Estabilización

Proceso: Producción Este proceso considera cuatro componentes: Capacidad Técnica del Proveedor, Calidad y Madurez de Procesos, Entrega y Validación, finalmente Implementación en Serie. Se puntualizan los subprocesos que incluye cada uno: a) Capacidad Técnica del Proveedor La capacidad técnica del proveedor depende de: Experiencia y especialidad; infraestructura instalada y nivel de servicio; definición e integración técnica de los entregables; y Metodología de Desarrollo del proyecto (Estrategia de desarrollo, Administración del proyecto y de la comunicación, gestión de riesgos y Aseguramiento de la calidad). b) Calidad y Madurez de Procesos La madurez de procesos se determina de acuerdo al cumplimiento de un conjunto de prácticas que habrán de ser: Definidas en un procedimiento documentado; Provistas de los medios y formación necesarios; Ejecutadas de un modo sistemático, universal y uniforme (institucionalizadas); Medidas; y Verificadas. La calidad está basada en la premisa de que la calidad de los productos depende de la calidad de cada uno de los procesos de desarrollo del producto. c) Entrega y Validación La verificación consiste en cerciorarse que el producto o entregable cumple con requerimientos y La Validación que cumple con el uso requerido por el usuario. d) Implementación en Serie §

Configuración; Instalación; Validación de la Implementación, Estabilización

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

48  

 

Aplicaciones de los sistemas embebidos APLICACIONES (USOS)

Comunicaciones

Controles Industriales

Electrónica Automotriz

Electro Domésticos

Salud y Medicina

Entretenimient o

Localización

Transporte

Seguridad y Vigilancia

Defensa (ejercito y marina)

Telemetría

La aplicación de los sistemas embebidos es muy diversa y en distintos sectores, se relacionan los más importantes: MEDIOS DE TRANSPORTE Sector Aeroespacial § Existirán redes de comunicación avanzadas que permitirán la comunicación: entre vehículos (p.ej. coche-coche; avión-avión, etc.), entre componentes del mismo vehículo, usuario-vehículo y vehículo-infraestructura. § Se generalizará la utilización de HW y SW abierto de uso comercial para sistemas embebidos que ejecutan funciones con implicaciones en la seguridad de vuelo. § Se implantarán sistemas globales de tráfico aéreo interactivos que permitirán un incremento sustancial de la densidad del tráfico y su seguridad. § Aparecerán sistemas embebidos en los aviones de transporte de viajeros que permitirán ofrecer nuevos servicios a los viajeros (conexión a internet, telefonía, etc.). Sector Ferroviario § Se implantará el sistema europeo ERMTS que controlara la seguridad en la conducción de forma dinámica, así como compartir infraestructuras entre los diversos países con independencia de los operadores ferroviarios. § Los sistemas de control ferroviario serán muy seguros, incluyendo comunicaciones trentierra, control de velocidad, distancia entre vehículos y gestión de flotas. § Se implantarán sistemas de conducción automática en el transporte público ferroviario (tren y metro), gracias a que los sistemas expertos serán cada vez más inteligentes y fiables. Esto permitirá aumentar la seguridad (evitando los fallos humanos). Sector Automoción § Los sistemas X-by-Wire, que permiten la sustitución de los enlaces mecánicos e hidráulicos por sofisticados sistemas eléctricos. § La conducción autónoma se convertirá en una realidad para reducir el número de accidentes, gracias a que los sistemas embebidos serán más inteligentes y fiables. § La electrónica de potencia entrará de forma definitiva con la llegada masiva de la tecnología de propulsión híbrida. § Algunos aspectos clave: tecnología insulated-gate bipolar transistors (IGBTs), fuentes de tensión de 200 a 800V, etc. § AUTOSAR se impondrá como estándar, de momento en procesadores 32 bits. Se creará una red de proveedores de módulos y fabricantes de herramientas AUTOSAR.   Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

49  

 

§ OSGi y tecnologías java serán usadas en entornos automoción para implementar algunos servicios multimedia, de comunicaciones para la eficiencia vial (del tráfico, etc.). SALUD § Las redes inalámbricas de trasmisión de datos sanitarios serán seguras, con garantía de funcionamiento, tendrán un acceso restringido y asegurarán la privacidad de los datos. § Los sistemas sensoriales embebidos funcionarán como sistemas de autodiagnóstico sin necesidad de asistencia por parte de personal clínico especializado. § Los sistemas multisensoriales permitirán mejorar el diagnóstico, el tratamiento y el postseguimiento de las enfermedades incorporando la detección y el tratamiento. § Los sensores de señales vitales unidos a la localización permitirán una atención mucho más rápida y efectiva en situaciones de emergencia. § Las prótesis humanas estarán dotadas de inteligencia, de forma que mejorarán su funcionalidad y, por tanto, la calidad de vida de los pacientes. AUTOMATIZACIÓN INDUSTRIAL § Las partes o componentes de sistemas incorporarán sistemas embebidos dotados de sensores para conocer su comportamiento, realizar autodiagnósticos, almacenar su historial de fabricación y mantenimiento, facilitando la construcción de grandes sistemas y el control de su funcionamiento. § La gestión de almacenes y de logística de la empresa se hará mediante sistemas embebidos en los productos y en los sistemas de transporte internos para permitir seguir las existencias y hacer la gestión de pedidos de forma automática. § Los sistemas de control industrial podrán ser controlados en tiempo real, incluso a kilómetros de distancia, gracias al uso de servicios Web en tiempo real. § Los sistemas de fabricación serán flexibles y autoconfigurables. INFRAESTRUCTURA PÚBLICA Y SERVICIOS Será obligatorio que los contadores de la luz, agua y gas tengan capacidad de ser leídos de forma remota y automática, evitándose la lectura manual y supervisión (por ejemplo para detección temprana de averías) de los mismos. Se implantarán masivamente dispositivos embebidos en las infraestructuras de iluminación pública para su control óptimo. Las señales de tráfico y las infraestructuras se comunicarán directamente con los vehículos para transmitirles información, así como con los sistemas de gestión de tráfico para informar en tiempo real sobre el estado del tráfico y las incidencias. Se integrarán mecanismos de seguridad biométrica en los procesos de negocio, personalizando la información al usuario final y adaptándose al dispositivo. ENERGÍA Los sistemas embebidos permitirán la integración y gestión de la generación distribuida presentando un alto grado de confiabilidad y contribuyendo a los aspectos de mantenimiento y calidad de servicio de la red energética.

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

50  

 

Se generalizará el uso de tecnologías inalámbricas para el control de infraestructuras energéticas, superando los actuales problemas de seguridad. En las redes de energía se implantarán dispositivos electrónicos como interfaz de almacenamiento energético. En los hogares, edificios y distritos, mediante el uso de sistemas embebidos, se realizará una selección del momento de consumo más conveniente evaluando la necesidad y la oportunidad para el estado de la red. Asimismo se podrá seleccionar el origen de la energía, evaluando la ventaja económica y de calidad. BIENES DE CONSUMO Se generalizará el uso de identificación RFID (Radio frequency identification technology) para gestión de logística, adaptación de funcionalidad y oferta de servicios. Existirá una trazabilidad completa de bienes de consumo en base a tecnologías de identificación. Los sistemas de información y entretenimiento (infotainment) serán generalizados, ubicuos y permitirán modelos de negocio tipo productor/consumidor (prosumer). MEDIO AMBIENTE Los sistemas sensoriales embebidos estarán emplazados físicamente en el medioambiente y llevarán a cabo una medida on-line del grado de contaminación (en aguas, suelos, etc.), la medición de variables meteorológicas y previsión del fenómeno de inversión térmica. Se diseñarán e implantarán sistemas embebidos que alerten de un alto riesgo medioambiental en el mismo instante en que empiece a producirse y también permitirán monitorizarlo (por ejemplo en caso de un incendio o un vertido tóxico). FUERZAS DE SEGURIDAD Se generalizará el uso de aviones/helicópteros sin piloto (UAV) para misiones de seguridad, con funciones de reconocimiento, identificación e inteligencia. Se desarrollará un sistema de comunicaciones celular de banda ancha, que sustituya al actual TETRA, y que permita la implementación de nuevos servicios para las Fuerzas de Seguridad (y otros servicios profesionales). El equipamiento del miembro de las fuerzas de seguridad integrará sensores, proceso y presentación gráfica, de forma que le ayude en sus misiones de patrulla. Estos sistemas del tipo `soldado del futuro”, estarán enlazados con el vehículo de patrulla, que servirá de enlace de comunicaciones entre el agente (y sus sensores) y la central. El desarrollo de una nueva generación de sensores permitirá crear sistemas de detección automática de explosivos que se instalarán en estaciones y aeropuertos, controlándose el movimiento de este tipo de materiales de forma generalizada y automatizada. ____________________ Nota.- La definición de los conceptos básicos de los Procesos y Subprocesos, se basó principalmente en las siguientes fuentes bibliográficas: ü

Embedded Systems Guide: Common Technical Baseline http://www.embedded-systems-portal.com/CTB/Terms,-3.html

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

51  

  ü

Embedded Systems Glossary. Barr Group http://www.barrgroup.com/Embedded-Systems/Glossary-H Apuntes de Sistemas Embebidos (2009) de Benito Úbeda Miñarro, U. de Murcia España. http://ocw.um.es/ingenierias/sistemas-embebidos/material-de-clase-1/sseet01.pdf

ü

CMMI for Development y CMMI for Acquisition (CMMI-ACQ) Capability Maturity Model® Integration. Carnegie Mellon® Software Engineering Institute (SEI). http://www.sei.cmu.edu/solutions/solutions.cfm

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

52  

 

3. Análisis de metodologías de desarrollo de SW

METODOLOGIAS DE DESARROLLO SW a).- MODELOS DE DESARROLLO DE SW CMMI DEV (Software Engineering Institute - SEI) Áreas de Proceso (nivel) 1.        Requirements Development (3) 2.        Requirements Management (2) 3        Technical Solution (3) 4.          Project Planning (2) 5.          Project Monitoring and Control (2) 6.          Supplier Agreement Management (2) 7.          Configuration Management (2) 8.          Quality Assurance (2) 9.          Risk Management (3) 10.    Verification (3) 11.    Validation (3) BUSINESS ANALYSIS - BABoK (International Institute of Business Analysis – IIBA) Áreas de Conocimiento 1.- Planeación y Administración del Analista 2.- Planeación y Monitoreo del BA - Planes Específicos; Técnicas de Estimación; Programa y Agenda 3.- Análisis Empresarial - Alcance del Producto; Business Case; Determinación de la Solución 4.- Elicitación de Requerimientos - Estándares de Documentación 5.- Análisis de Requerimientos - Estándares de Documentación 6.- Diagnóstico y Validación de Soluciones - Diseño, Testing e Implementación; Plan de Calidad de la Solución 7.- Gestión y Comunicación de Requerimientos PROJECT MANAGER - PMBoK (Project Manager Institute - PMI) Áreas de Conocimiento 4. Gestión de la Integración (Planeación y Ejecución) del Proyecto.   Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

53  

  5. Gestión del Alcance (Requisitos y Programa) del Proyecto. 6. Gestión del Tiempo (Cronograma) del Proyecto. 7. Gestión de los Costos y Presupuesto del Proyecto. 8. Gestión de la Calidad del Proyecto. 9. Gestión de los Recursos Humanos del Proyecto. 10. Gestión de las Comunicaciones del Proyecto 11. Gestión de los Riesgos del Proyecto. 12. Gestión de las Adquisiciones del Proyecto. AGILE / SCRUM Áreas de Proceso a.- Priorización de Requerimientos (Product Backlog) b.- Planificación de Entregas c.- Estimación de Tiempos d.- Planificación de Sprints: (Metas, participantes, acciones, y fechas) e.- Tabla de Tareas (burn-down chart) f.- Scrum diario g.- Diagrama de Seguimiento h.- Retrospectivas de Sprint (mejoras) i.- Pruebas: Desarrollo guiado por pruebas (TDD) Team Software Process - TSP (Software Engineering Institute - SEI) ROL (áreas de proceso) 1.- Planeación y monitoreo 2.- Interface Usuario 3.- Diseño y Arquitectura 4.- Calidad 5.- Pruebas 6.- Soporte 7.- Implementación 8.- Procesos Personal Software Process (Software Engineering Institute - SEI) Procesos Personales i.- Planeación del trabajo Personal ii.- Medición del tamaño y del proceso iii.- Estimación del tamaño y del esfuerzo iv.- Seguimiento del calendario v.- Planificando para la calidad del software vi.- Métricas sobre la eficacia de los procesos vii.- Gestión de defectos viii.- Desarrollo de equipos

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

54  

  SEMANTICS (Infotec) Servicios a.- Desarrollo de Ontología (modelo de funcionalidades de la aplicación) b.- Desarrollo del Parser (plataforma de SemanticWebBuilder para la aplicación) c.- Capacitación y entrenamiento básico al personal del cliente

b).- RESUMEN: PROS Y CONS   CMMI DEV - Software Engineering Institute (SEI) • El Modelo CMMi-Dev, abarca todos los procesos del Ciclo de Vida del Desarrollo SW • Su implementación es tardada y costosa, su uso es burocrático y requiere de un grupo de apoyo especializado • El nivel de institucionalización requiere de certificación de los procesos • Este modelo es muy importante en caso de que el cliente requiera la certificación. BUSINESS ANALYSIS - International Institute of Business Analysis (IIBA) • El Modelo de Business Análisis (BABOK), abarca el análisis y especificación de los Requerimientos de Software del Cliente y su solución. • La implementación y uso de este modelo requiere de un grupo de apoyo especializado • La certificación es a nivel individual a través de examen, pero requiere horas de práctica comprobables para obtenerla. • Este modelo se complementa con la Adm., de proyectos, Arquitectura Empresarial, Gestión de Datos y la Calidad del SW. PROJECT MANAGER - Project Manager Institute (PMI) • El Modelo PMBoK de Adm., de Proyectos es genérico (no específico para software) y se refiere a la adm., del Ciclo de Vida de cualquier proyecto. • La implementación y uso de este modelo requiere de un grupo de apoyo especializado • La certificación es a nivel individual a través de examen. • Este modelo, por lo general se emplea limitadamente en la administración del contrato con el cliente (legal, entregables y cobranza), sin usarlo en todas sus dimensiones. AGILE / SCRUM • El Modelo AGILE cubre, a nivel individual y de grupo, el proceso de desarrollo de SW. Este modelo reduce la burocracia de los modelos del SEI (agiliza el desarrollo del SW) • Existen diversos organismos (que reclaman la paternidad) y certifican 'Scrum Master', 'Scrum Coach' y 'Scrum Practitioner' • Se enfoca al resultado con una gran interacción del equipo, pero no quedan claros los roles ni el cumplimiento de las fases de la Adm. del Ciclo de Vida, la Especificación de Requerimientos y la Arquitectura y Diseño del Sistema   Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

55  

  Team Software Process - TSP (SEI) • El TSP está enfocado a lograr la mayor calidad y el mínimo de errores. • Se concentra en la administración del proceso de desarrollo de SW y que la calidad se logre individual y grupalmente. • La certificación es a nivel individual a través de examen. • Su  implementación  es  tardada  y  costosa,  su  uso  es  poco  flexible  y  dependiente  a  una   única  herramienta,  sin  embargo  el  código  puede  reutilizarse  . • Se enfatiza a cubrir el proceso de manera integral más que a la especialización de cada etapa pero manteniendo un liderazgo situacional a uno o varios roles. • Este modelo puede ser muy importante en proyectos 'grandes' o 'delicados' Personal Software Process - PSP (SEI) • El Modelo PSP garantiza planeación y disciplina en el desempeño individual para el desarrollo de SW • La certificación es a nivel individual a través de examen • El PSP es independiente de cualquier modelo de desarrollo de SW SEMANTICS (Infotec) • No queda clara la metodología de requerimientos, ni la de desarrollo, ni la capacitación requerida. • El Modelo Semántico a pesar de que es código abierto, su instrumentación mantiene una completa dependencia a los desarrolladores originales; para cualquier modificación se requiere estar capacitado en el desarrollo Ontológico y en el analizador sintáctico o Parser (compilador que construye un árbol de derivación de la plataforma SWB)

c).- CONCLUSION: Modelo de Desarrollo de SW Para el caso de INFOTEC, donde todas estas metodologías coexisten en mayor o menor grado, se propone el siguiente esquema: 1.- La implementación y certificación de los procesos de CMMi-Dev de nivel 2 (Planeación, monitoreo y control de proyectos, Gestión de versiones y cambios; Aseguramiento de la calidad y Gestión del contrato con el proveedor), así como la institucionalización de un grupo STAFF de Adm., de Proyectos de SW, especializados en CMMi2. 2.- La implementación de la metodología de Análisis de Negocios (BA) y la institucionalización de un grupo STAFF de analistas especializados (análisis de requerimientos, arquitectura, solución y diseño de sistemas) y certificados en la materia. 3.- Fomentar que todos los programadores se capaciten en PSP. Posteriormente habrá un mapa de ruta para certificarse en TSP, para proyectos 'grandes' o 'de alta precisión'.

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

56  

  4.- Ya con la especificación clara de los requerimientos, se podrán utilizar los actuales grupos de programadores con diversas metodologías, de acuerdo a las necesidades de cada proyecto. Sin embargo, se propone iniciar con la metodología de desarrollo AGILE/SCRUM, que evita. 4. Matriz del aseguramiento de la calidad (SEQA) del ciclo de desarrollo de sistemas embebidos (ver esta matriz en el anexo de Excell)

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

57  

E D LO IC A VID

C

Requerimientos No-Funcionales

Requerimientos del Ciclo de Vida

Requerimientos del Negocio

Estudios de Factibilidad

Estudios de Factibilidad

Adm. de Casos de Uso

Requerimientos de Empaque (Case Enclosure)

Requerimientos del Negocio

Requerimientos Físicos

Especificación de la arquitectura de Hardware

ARQUITECTURA

Seguimiento

Field Programmable Gate Arrays (FPGA)

SEMICONDUCTORES

System-on-a-Chip processor (SoC) Sensores

Tier 1

ESTÁNDARES DEL HARDWARE

Ingeniero de HW Embedded

Buses

Seguimiento

Hardware Nodes

Hardware Nodes

Prototipado

Diseño

Muestras

Validación con Usuarios

Funcional, Paramétrica, Tolerancia Integración y Regresión

Pruebas:

Verificación y Pruebas

PROTOTIPO DE HARDWARE

Tier 2 & 3

PROTOTIPO DE HARDWARE

Ingeniero de Producto

Integración del Prototipo

Case Enclosure

PROTOTIPO DE HARDWARE

Construcción del Prototipo

Requerimientos y Selección del Proveedor

Files (Gerrber)

Diseño

PCB

PROCESOS DEL DESARROLLO DE SE

PROVEEDOR (Supply Chain)

** ADMINISTRACIÓN DE PROVEEDORES (ACQ-SEI)

* ASEGURAMIENTO DE LA CALIDAD (SQA-SEI)

y Reporte de Resultados

* 9 Seguimiento a No Conformidades

OEM y Tier 1

ADM. DEL CICLO DE VIDA

ESPECIFICACIÓN DE REQUERIMIENTOS ARQUITECTURA

OEM, Tier 1

Seguimiento a No Conformidades

Validación con el Usuario

Validación

con el Usuario / Cliente

No Conformidades

Verificación del Cumplimiento de Requerimientos

Verificación

** 8. Validación del Producto

de Requerimientos

** 7. Verificación del Cumplimiento

y Gestión de Facturas

DISEÑO HW

SEMICONDUCTORES

Proveedor de Semiconductores

ESTÁNDARES DEL HARDWARE

Tier 1

Seguimiento a No Conformidades

Validación con el Usuario

PROTOTIPO DE HARDWARE

Tier 2 & 3

Gestión Técnica de la Adquisición

Verificación del Cumplimiento de Requerimientos

Productos de Trabajo y Entregables

Revisión de Actividades

Hardware Nodes

Sensor networking

Memory Caches

Floating Point Unit (FPU)

Direct Memory Access (DMA)

Computational Unit (CU)

Digital Signal Processor (DSP)

Products

Hardware Nodes

Monitoreo del Servicio del Proveedor

Requerimientos y Selección del Proveedor

SEMICONDUCTORES

Proveedor de Semiconductores

SEMICONDUCTORES

Safety Assesment Process

Software

Digital Hardware

Electrical

Mechanical

ECU Architecture:

Electronic Control Units (ECU)

ESTÁNDARES DEL HARDWARE

Network Systems (HW)

Plan SQA: Ingeniería de Hardware

Application-Specific Integrated Circuit (ASIC)

Ingeniero (externo) de HW Embedded

Processor Core (microprocessors, microcontrollers)

Gestión Técnica de la Adquisición

Tier 1

PT y Entregables

Revisión de Actividades

Seguimiento

Tier 1

DISEÑO HW

Ingeniero de HW Embedded

Estándar

Diferenciado

Movil

Diseño Físico

Monitoreo del Servicio del Proveedor

DISEÑO

DISEÑO

Síntesis

DISEÑO HW

** 6. Monitoreo del Servicio del Proveedor

Productos de Trabajo y Entregables

Diseño de Tareas

Mapeo componentes de SW a ECU

Modelado

O E LL R O A R W R A RD ES HA - D DE

III.

** 5. Gestión Técnica de la Adquisición

y Selección del Proveedor

** 4. Requerimientos de la Adquisición

PROCESOS DEL DESARROLLO DE SE

y Entregables

* 3. Auditoria a Productos de Trabajo

PT y Entregables

Revisión de Procesos y Actividades Revisión de Actividades

Revisión de Procesos y Actividades

- Ingeniería y Desarrollo

Soluciones de HW

Selección Monitor, Kernel o Sistema Operativo

de DETALLE

DISEÑO

ALTO NIVEL (SW y HW)

Componentes del SW

Arquitecto de SE

Especificación de la arquitectura del SW

OEM, Tier 1

División funcional SW/HW

Arquitectura técnica del sistema

Arquitectura lógica del sistema

- Adm., de la Configuración y Cambios

Seguimiento

Plan General SQA

ARQUITECTURA

IS O LIS Ñ A E N DIS Y

A

del SISTEMA del SOFTWARE del HARDWARE

II.-

Plan SQA: Requerimientos, Arquitectura y Diseño

ESPECIFICACIÓN DE REQUERIMIENTOS

ADM. DEL CICLO DE VIDA

OEM y Tier 1

Analista de Requerimientos

Adm., Proyecto y Aseg., Calidad

Cost Assesment Process

(Thiers)

Requerimientos del Ciclo de Vida

Aseguramiento de la Calidad

Adm. de Proveedores

Adm. de Certificaciones

Requerimientos de Requerimientos de la Arquitectura la Arquitectura

Adm. de Datos del Producto

Requerimientos No-Funcionales

Requerimientos Funcionales

Medio Ambiente Contextual (Dinámica Funcional)

Requerimientos Funcionales

Medio Ambiente Contextual (Dinámica Funcional)

Planeación y Seguimiento del Proyecto

Adm. de Requerimientos

Analisis de Requerimientos del Sistema

Adm. de la Configuración y Control de Cambios

del SOFTWARE del HARDWARE

ESPECIFICACIÓN DE REQUERIMIENTOS

del SISTEMA

Adm. del Proyecto

ADM. DEL CICLO DE VIDA

.,

M

D A

- Adm., de Requerimientos y Arquitectura

- Planeación y Seguimiento de Proyectos

* 2. Revisión de Procesos y Actividades

* 1. Planeación de las Actividades de SQA

PROCESOS CMMi - SEI, del ASEGURAMIENTO DE LA CALIDAD

PROVEEDOR (Supply Chain)

PROCESOS DEL DESARROLLO DE SE

PERFILES: Recursos Humanos

SUBPROCESO

PROCESO

I.-

Diseño del Reuso

Databases

GUI

Hardware 'aware' Compiler

Executable Image

Flash

ROM

Firmware

Modelo de Aplicación

Prototipado

Sistema Operativo y Aplicaciones

Validación con Usuarios

Paramétrica, Tolerancia Integración y Regresión

Pruebas: Funcional,

Verificación y Pruebas

Monitoreo del Servicio del Proveedor

Gestión Técnica de la Adquisición

Requerimientos y Selección del Proveedor

SW DE APLICACIÓN

Tier 2 & 3

SW DE APLICACIÓN

Ingeniero de SW Embedded

Estructura de Datos

Optimización de iteraciones

Flujo de datos

Codificación abstracta

Prototipo

SW DE APLICACIÓN

Generación de Código

Plan SQA: Ingeniería de Software

Casos de Uso

Características y Tareas

Definición Modular SW

Modelado

O LL RE O R WA R A FT ES O D ES D

Tier 2 & 3

SW DE APLICACIÓN

Seguimiento a No Conformidades

Validación con el Usuario

Verificación del Cumplimiento de Requerimientos

ESTÁNDARES DEL SOFTWARE

Tier 1

PT y Entregables

Revisión de Actividades

Seguimiento

Tier 1

ESTÁNDARES DEL SOFTWARE

Ingeniero de SW de Soporte

Device drivers

File system

Memoty Management

Scheduler

Inter-task Communication and Synchronisation

Middleware

ESTÁNDARES DEL SOFTWARE

Sistema Operativo

.IV

Diseño del Reuso Prueba y Validación

DEL

Control de Cambios

Estabilización y Mantenimiento

Tier 2

Revisión de Actividades

Seguimiento

OEM

PRODUCTO: SISTEMA EMBEBIDO

OEM

Productos de Trabajo y Entregables

Seguimiento a No Conformidades

Validación con el Usuario

INTEGRACIÓN Y PRUEBAS DEL PROTOTIPO

Administración de Proveedores

Administración de la Adquisición

Adm. del Producto

PRODUCTO: SISTEMA EMBEBIDO

Verificación del Cumplimiento de Requerimientos

Monitoreo del Servicio del Proveedor

Gestión Técnica de la Adquisición

Requerimientos y Selección del Proveedor

Documentación y Resguardo

Liberación del Prototipo

Adm., del Proyecto y Aseg., Calidad

Patentes

Registros

Propiedad Intelectual

PRODUCTO: SISTEMA EMBEBIDO

Certificaciones

Plan SQA: Administración del Producto

INTEGRACIÓN Y PRUEBAS DEL PROTOTIPO

Tier 1

INTEGRACIÓN Y PRUEBAS DEL PROTOTIPO

Ingeniero Especialista

Protección y Seguridad

INTEGRACION Y PRUEBAS PROTOTIPO

Integración SW y HW

N IÓ TO C C A U - R D VI. IST RO IN P M L D DE

A

Entrega y Validación

PRODUCCIÓN

Calidad y Madurez de Procesos

Estabilización

Validación de la Implementación

Instalación

Configuración

Implementación en Serie

PRODUCCIÓN

PRODUCTOR

Seguimiento a No Conformidades

Validación con el Usuario

Verificación del Cumplimiento de Requerimientos

Monitoreo del Servicio del Proveedor

Gestión Técnica de la Adquisición

Requerimientos y Selección del Proveedor

PRODUCTOR

Plan SQA: Producción Masiva

PRODUCTOR

PRODUCCIÓN

Capacidad y Calidad de Procesos y RH

Capacidad Técnica del Proveedor

A R TU IE .- C ER VII UFA S N EN A

M

IC PL A

ES N ) IO S C O A S (U

OEM

OEM

Localización

MACRO PROCESO

Entretenimiento

Anexo 4.- MATRIZ DEL ASEGURAMIENTO DE LA CALIDAD (SEQA) DEL CICLO DE DESARROLLO DE SISTEMAS EMBEBIDOS

 

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

58  

Defensa (ejercito y marina)

Seguridad y Vigilancia

Telemetría

Transporte

Salud y Medicina

Electro Domésticos

Comunicaciones Controles Industriales Electrónica Automotriz

 

5. Guía de procedimientos del aseguramiento de la calidad de sistemas embebidos de INFOTEC Historia  de  Cambios     Código  del  Documento  

Descripción  del  Cambio  

Fecha  

   

 

 

               

 

 

 

 

 

 

 

 

   

 

 

    Aprobado  por:     Nombre              

Role(s)  dentro  del  proyecto    

 

Firma      

 

 

 

 

 

 

    Lista  de  distribución     Nombre  

Fecha    

Role(s)  dentro  del  proyecto  

Fecha  Recibido  

Firma    

   

 

 

 

           

 

 

 

 

 

 

 

 

 

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

59  

         

 

 

 

Derechos   reservados.   Ninguna   parte   de   este   documento   puede   ser   reproducida,   transmitida   o   almacenada   por  medios  mecánicos,  fotográficos,  electrónicos  u  otros,  sin  permiso  expreso  del  propietario  de  los  derechos   de  copia.   © INFOTEC 2013

 

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

60  

 

Contenido      

PD-­‐SEQA-­‐01   ACTIVIDADES  GENÉRICAS  DEL  ASEGURAMIENTO  DE  CALIDAD     PD-SEQA-01-01 REVISIÓN DE ACTIVIDADES DE INGENIERÍA DE SW / HW PD-SEQA-01-02 AUDITORÍA DE PRODUCTOS DE TRABAJO - PD-­‐SEQA-­‐01-­‐02i      VERIFICACIÓN  DEL  CUMPLIMIENTO  DE  REQUERIMIENTOS   PD-SEQA-01-02ii VALIDACIÓN DEL PRODUCTO, CON EL USUARIO PD-SEQA-01-03 AUDITORÍA DE ENTREGABLES

  PD-­‐SEQA-­‐02     REVISIÓN  DE  LA  GESTIÓN  DE  PROVEEDORES  ACQ     PD-SEQA-02-01 PD-SEQA-02-02 PD-SEQA-02-03 PD-SEQA-02-04

ESPECIFICACIÓN DEL PROYECTO DE ADQUISICIÓN SELECCIÓN DEL PROVEEDOR GESTIÓN TÉCNICA DE LA ADQUISICIÓN MONITOREO DEL SERVICIO DEL PROVEEDOR - ACQ

  PD-­‐SEQA-­‐03   REVISIÓN  DE  LA  ADMINISTRACIÓN  DEL  PROYECTO     -

-

PD-­‐SEQA-­‐03-­‐01      REVISIÓN  DE  PROCESOS   Administración  de  Requerimientos  del  SE   Planeación  de  Proyectos  SE   Seguimiento  de  Proyectos  de  SE   Administración  de  la  Configuración  del  SE     Adquisiciones  con  Proveedores   PD-­‐SEQA-­‐03-­‐02      MONITOREO  DEL  PLAN  SEQA     PD-­‐SEQA-­‐03-­‐03      REVISIÓN  DE  LA  PLANEACIÓN  Y  SEGUIMIENTO  DEL  PROYECTO   PD-­‐SEQA-­‐03-­‐04      REVISIÓN  DE  LA  ADMINISTRACIÓN  DE  REQUERIMIENTOS   PD-­‐SEQA-­‐03-­‐05      VERIFICACIÓN  DEL  CUMPLIMIENTO  DE  COMPROMISOS  

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

61  

 

  PD-­‐SEQA-­‐04   REGISTRO  Y  SEGUIMIENTO  A  NO  CONFORMIDADES     PD-SEQA-04-01 PD-SEQA-04-02 PD-SEQA-04-03 PD-SEQA-04-04

REGISTRO Y CLASIFICACIÓN DE NO CONFORMIDADES CORRECCIÓN DE LAS NO CONFORMIDADES SEGUIMIENTO PERIÓDICO A LAS NO CONFORMIDADES REPORTE DE NO CONFORMIDADES

   

Formatos    

Glosario      

 

 

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

62  

 

PD-­‐SEQA-­‐01   ACTIVIDADES  GENÉRICAS  DEL  ASEGURAMIENTO  DE  CALIDAD      

PD-SEQA-01-01 REVISIÓN DE ACTIVIDADES DE INGENIERÍA DE SW / HW Propósito   Verificar   que   las   actividades   referentes   a   la   Ingeniería   de   SW/HW   estén   siendo   realizadas   de   acuerdo  a  los  estándares  existentes  de  Infotec.     Procedimiento 1. Validar  las  actividades  realizadas  siguiendo  el  formato  de  verificación  (SEQA_FM01).   2. Solicitar  y  revisar  la  documentación  o  alguna  otra  evidencia  que  respalde  la  realización  de  cada   una  de  las  actividades  de  ingeniería.   3. Registrar  los  resultados  de  la  revisión  en  el  formato  de  verificación  (SEQA_FM01).     Observaciones  

•

La revisión no debe confundirse con la actividad de pruebas.  

  ACTIVIDADES  DE  INGENIERÍA  DE  SW  /  HW    

  ESPECIFICACIÓN  DE  REQUERIMIENTOS     SISTEMA     Análisis  de  Requerimientos  del  Sistema     SOFTWARE     Requerimientos  Funcionales   Medio  Ambiente  Contextual  (Dinámica  Funcional)   Requerimientos  No-­‐Funcionales   Requerimientos  de  la  Arquitectura   Requerimientos  Físicos   Requerimientos  del  Ciclo  de  Vida   Requerimientos  del  Negocio     Estudios  de  Factibilidad   HARDWARE   Requerimientos  Funcionales   Medio  Ambiente  Contextual  (Dinámica  Funcional)     Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

63  

  -

Requerimientos  No-­‐Funcionales  

-

Requerimientos  de  la  Arquitectura   Requerimientos  de  Empaque  (Case  Enclosure)   Requerimientos  del  Ciclo  de  Vida   Requerimientos  del  Negocio     Estudios  de  Factibilidad  

   

 

 

ARQUITECTURA    

SISTEMA     Arquitectura  lógica  del  sistema     Arquitectura  técnica  del  sistema       División  funcional  SW/HW     SOFTWARE     Especificación  de  la  arquitectura  del  SW     HARDWARE   Especificación  de  la  arquitectura  de  Hardware    

 

DISEÑO    

ALTO  NIVEL  (SW  y  HW)   Componentes  del  SW     Soluciones  de  HW    (Board,  FPGA,  EPLD,  DSP,  Analog  &  RF  Design)   Selección  Monitor,  Kernel    o  Sistema  Operativo   DETALLE     Diseño  de  Tareas   Mapeo  componentes  de  SW  a  ECU   DISEÑO  HW   Modelado   Síntesis   Diseño  Físico:  Móvil,  Diferenciado,  Estándar    

 

ESTÁNDARES  DEL  HARDWARE    

Network  Systems  (HW)   Electronic  Control  Units  (ECU)   ECU  Architecture:     Mechanical   Electrical   Digital  Hardware   Software  

                 

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

64  

  Safety  Assesment  Process   Buses   Sensores  

 

 

  ESTÁNDARES  DEL  SOFTWARE  

    SISTEMA  OPERATIVO   Inter-­‐task  Communication  and  Synchronization     Scheduler   Memory  Management   File  system   Device  drivers   MIDDLEWARE   Executable  Image     Hardware  'aware'  Compiler     GUI     DATABASES  FIRMWARE   ROM   Flash          

PD-SEQA-01-02 AUDITORÍA DE PRODUCTOS DE TRABAJO Propósito  

Realizar   la   auditoría   de   los   productos   de   trabajo   seleccionados   para   verificar   su   apego   a   los   estándares  definidos  en  los  planes  del  proyecto  y  validar  su  contenido.     Procedimiento  

1. 2. 3. 4. 5.  

Preparar  la  documentación  de  la  auditoría.   Genera  un  listado  de  la  documentación  a  revisar  de  cada  producto  de  trabajo   Verificar  la  disponibilidad  de  los  productos  a  auditar.   Registrar  las  no  conformidades  en  el  formato  de  verificación  (SEQA_FM02).   Revisar  las  no  conformidades  con  el  responsable  del  producto  para  aclarar  dudas.  

Observaciones  

•

Los productos seleccionados deberán estar identificados en el Plan de Verificación SEQA

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

65  

 

 

   

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

66  

 

PRODUCTOS  

   

SEMICONDUCTORES    

-

Processor  Core  (microprocessors,  microcontrollers)   System-­‐on-­‐a-­‐Chip  processor  (SoC)     Field  Programmable  Gate  Arrays  (FPGA)       Application-­‐Specific  Integrated  Circuit  (ASIC)    

   

HARDWARE  NODES          

-

Digital  Signal  Processor  (DSP)   Computational  Unit    (CU)   Direct  Memory  Access  (DMA)     Floating  Point  Unit  (FPU)     Memory  Caches     Sensor  networking  

   

SW  DE  APLICACIÓN    

Modelado   Definición  Modular  SW   Características  y  Tareas   Casos  de  Uso   Generación  de  Código   Modelo  de  Aplicación   Codificación  abstracta   Flujo  de  datos   Optimización  de  iteraciones   Estructura  de  Datos   Prototipado   Verificación  y  Pruebas   Pruebas:  Funcional,  Paramétrica,  Tolerancia    Integración  y  Regresión      

PROTOTIPO      

-

Integración  SW  /  HW       Protección  y  Seguridad  EGRACION     Prueba  y  Validación       Estabilización  y  Mantenimiento     Control  de  Cambios     Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

67  

   

  PRODUCCIÓN  EN  SERIE     Capacidad  Técnica  del  Proveedor   Configuración   Instalación   Validación  de  la  Implementación   Estabilización   Calidad  y  Madurez  de  Procesos   Entrega  y  Validación       Implementación  en  Serie  

     

  PD-­‐SEQA-­‐01-­‐02i      VERIFICACIÓN  DEL  CUMPLIMIENTO  DE  REQUERIMIENTOS  

-

Propósito  

Asegurar  que  los  productos  de  trabajo  seleccionados  cumplen  con  sus  requerimientos  específicos,   estándares  y  políticas  establecidas.     Procedimiento  

1. Verificar  que  los  requerimientos  han  sido  satisfechos  por  cada  producto   2. Aplicar  los  criterios  establecidos  para  comparar  los  resultados  de  las  verificaciones  contra  lo   esperado     3. Documentar  los  resultados  en  el  formato  de  verificación  (SEQA_FM02).     Observaciones  

Realizar esta actividad a partir de la Plan de Verificación (productos seleccionados)

•  

 

 

 

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

68  

 

PD-SEQA-01-02ii VALIDACIÓN DEL PRODUCTO, CON EL USUARIO Propósito  

Mostrar   que   un   desarrollo,   producto   o   servicio   cumple   con   su   uso   intencionado   y   la   regla   de   negocio,  cuando  es  colocado  en  su  ambiente  establecido.     Procedimiento  

1. Verificar  la  disponibilidad  de  los  productos  seleccionados.   2. Verificar  que  esta  actividad  se  lleva  a  cabo  en  los  escenarios  operacionales,  procedimientos,   entradas  y  salidas.   3. Aplicar  los  criterios  establecidos  para  comparar  los  resultados  de  las  verificaciones  contra  lo   esperado     4. Documentar  los  resultados  en  el  formato  de  verificación  (SEQA_FM02).     Observaciones  

Realizar esta actividad a partir de la Plan de Verificación (productos seleccionados)

•      

PD-SEQA-01-03 AUDITORÍA DE ENTREGABLES Propósito  

Evaluar   todos   aquellos   productos   finales   que   vayan   a   ser   liberados   y   entregados   al   cliente   para   verificar  que  cumple  con  las  especificaciones  y  estándares  definidos.     Procedimiento  

1. 2. 3. 4.

Verificar  la  disponibilidad  de  los  productos  que  serán  entregados  al  cliente.   Revisar  ortografía,  formato,  diseño  y  presentación  de  cada  producto.   Verificar  que  se  cumplió  la  verificación  de  requerimientos  y  la  validación  ante  el  usuario.   Registrar  las  no  conformidades  en  el  formato  de  verificación  (SEQA_FM02).    

Observaciones  

• •

Esta actividad deberá realizarse antes de la entrega de cualquier producto al cliente y debe ser calendarizada. Si se encuentran no conformidades en algún producto, este no deberá ser entregado hasta que estas sean resueltas.

    Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

69  

 

 

     

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

70  

 

PD-­‐SEQA-­‐02   REVISIÓN  DE  LA  GESTIÓN  DE  PROVEEDORES  ACQ      

PD-SEQA-02-01 ESPECIFICACIÓN DEL PROYECTO DE ADQUISICIÓN Propósito  

Verificar la especificación de los trabajos a ser adquiridos o subcontratados, de acuerdo a sus características estrategias, técnicas y funcionales.  

Procedimiento  

1. Verificar  que  el  Proyecto  de  Adquisición  fue  debidamente  planeado:   - Se  especificaron  los  requerimientos  de  negocio,  técnicos  y  funcionales   - Se  determinaron  prioridades  y  restricciones  que  debe  observar  el  proveedor.   - Se  especificaron  los  productos  de  trabajo  (entregables)  que  deberán  ser  generados   - Se  estimaron  metas  de  rendimiento,  tiempos  y  costos  de  realización   - Se  establecieron  estándares  y  procedimientos  que  deberán  ser  observados.   2. Revisar  que  se  documentaron  los  puntos  anteriores  en  las  bases  de  licitación  y  fueron  revisados   por  todos  los  grupos  o  áreas  involucradas    

Observaciones • Proyectos de Adquisición: Semiconductores, Hardware Nodes; SW de Aplicación; Integración y Pruebas del Prototipo; Producción en Serie  

     

PD-SEQA-02-02 SELECCIÓN DEL PROVEEDOR Propósito  

Verificar que la Selección del Proveedor fue debidamente ejecutado.  

Procedimiento  

1. Verificar  que  se  preparó  un  paquete  de  requerimientos  (RFP)   2. Verificar  que  se  evaluaron  las  propuestas  de  los  proveedores   3. Revisar  que  se  estableció  el  contrato.    

Observaciones • El RFP deberá especificar de forma detallada como se desarrollará el proyecto y el contrato deberá incluir los compromisos de negocio y técnicos que deberán observar ambas partes. Estos documentos serán la base para el seguimiento de todo el proyecto.   Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

71  

     

PD-SEQA-02-03 GESTIÓN TÉCNICA DE LA ADQUISICIÓN Propósito  

Evaluar la solución técnica del proveedor y gestionar las interfaces de la solución.  

Procedimiento  

1. Seleccionar  las  soluciones  técnicas  (productos,  componentes,  manuales,  etc.),  determinar  los   aspectos  a  ser  analizados,  así  como  las  entradas  y  salidas  del  análisis   2. Procedimiento   para   verificar   que   cada   solución   técnica   satisface   los   requerimientos   y   para   la   Identificación  y  prevención  de  Riesgos   3. Identificar  con  otros  productos  o  unidades  organizativas  interactúa  la  solución  técnica    

Observaciones  

La función de SEQA es asegurar que estas actividades sean cumplidas. El tipo y alcance de las revisiones técnicas depende del tamaño, alcance y riesgos del proyecto.

•      

PD-SEQA-02-04 MONITOREO DEL SERVICIO DEL PROVEEDOR - ACQ Propósito  

Monitorear   el   avance   y   rendimiento   del   proveedor   (agenda,   esfuerzo,   costo),   y   asegurar   que   actúa   de  acuerdo  a  los  términos  establecidos  en  el  contrato.    

Procedimiento  

1. Establecer   un   procedimiento   para   monitorear   el   avance   y   rendimiento   del   proveedor   (agenda,   esfuerzo,  costo)  de  acuerdo  al  contrato   2. Verificar  la  disponibilidad  de  los  productos  que  serán  entregados  por  el  proveedor.   3. Verificar  que  se  cumplió  la  verificación  de  requerimientos  y  la  validación  ante  el  usuario.   4. Registrar  las  no  conformidades  en  el  formato  de  verificación  (SEQA_FM02).   5. Confirmar  que  todas  las  licencias,  patentes  y  garantías  se  hayan  entregadas   6. Gestionar  las  facturas  del  proveedor    

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

72  

  Observaciones  

• • •

Esta actividad deberá realizarse antes de la entrega/recepción de cualquier producto del proveedor y debe ser calendarizada. Si se encuentran No Conformidades en algún producto, este no deberá ser recibido hasta que estas sean resueltas. Revisar que las facturas tengan toda la documentación de soporte y que se paguen en tiempo y forma y que estén soportados por la aprobación del entregable o producto

   

 

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

73  

 

PD-­‐SEQA-­‐03   REVISIÓN  DE  LA  ADMINISTRACIÓN  DEL  PROYECTO      

-

PD-­‐SEQA-­‐03-­‐01      REVISIÓN  DE  PROCESOS  

Propósito  

Asegurar  que  la  Administración  del  Proyecto  lleve  a  cabo  sus  tareas  de:  Planeación  y  Seguimiento   del   Proyecto   SE;   Administración   de   Requerimientos,   Configuración   y   Cambios;   Monitoreo   del   Cumplimiento   de   Compromisos:   Acuerdo   para   desarrollos   internos   (PQA)   o   del   Adquisiciones   con   proveedores  (ACQ);  Seguimiento  de  las  tareas  de  SEQA,  de  acuerdo  a  los  Planes  de  Aseguramiento   de  la  Calidad,  establecidos.    

Procedimiento 1. Verificar  la  ejecución  de  los  procesos.   2. Solicitar  y  revisar  la  documentación  o  alguna  otra  evidencia  que  respalde  la  realización  de  cada   uno  de  los  procesos   3. Registrar  los  resultados  de  la  revisión  en  el  formato  de  verificación  (SEQA_FM03).    

Observaciones   Administración  de  Requerimientos  del  SE   ¿Se  conocen  y  se  llevan  a  cabo  las  políticas  de  Administración  de  Requerimientos?   ¿Se  asigna  a  un  responsable  la  administración  de  requerimientos  del  proyecto?   ¿Se   realizan   reuniones,   entrevistas   o   diálogos   directos   con   el   usuario   para   la   recopilación   de   requerimientos?   ¿Se  cuenta  con  un  documento  de  Descripción  de  Requerimientos  (DR)  detallado  del  proyecto  aprobado   por  el  usuario?   ¿La   DR   es   revisada   y   aprobada   por   el   grupo   de   trabajo   asignado   al   proyecto   antes   de   ser   presentada   con  el  usuario?   ¿Las  solicitudes  de  cambio  a  requerimientos  son  clasificadas  y  validadas  por  el  director  de  proyectos?   ¿Las   solicitudes   de   cambio   que   representan   una   nueva   funcionalidad   o   cambios   significativos   son   evaluadas  por  la  Mesa  de  Control  de  Cambios  del  proyecto?   ¿Se  tiene  y  se  mantiene  actualizada  una  matriz  de  rastreabilidad  de  requerimientos  del  proyecto?   ¿Los  requerimientos  se  utilizan  como  base  para  la  planeación  y  ejecución  del  proyecto?   ¿Se  estimaron  metas  de  rendimiento,  tiempos  y  costos  de  realización?    ¿Se  les  da  seguimiento?   ¿Se  tiene  una  línea  base  de  requerimientos  donde  se  guardan  los  principales  productos  generados  en   este  proceso?   ¿Los  cambios  a  los  requerimientos  son  reflejados  en  los  planes  y  productos  de  trabajo?   ¿Los  requerimientos  incluyen  los  criterios  de  aceptación    que  serán  usados  para  validar  que  el  producto     Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

74  

  de  software  cumple  con  los  requerimientos  especificados?   ¿Se  elaboran  Casos  de  Uso  y  son  debidamente  Administrados?           Planeación  de  Proyectos  SE   ¿Se  conocen  y  se  llevan  a  cabo  las  políticas  de  Planeación  de  proyectos?   ¿El  subgerente  de  proyecto  coordina  las  actividades  de  planeación  con  los  grupos  involucrados?   ¿Se  tiene  registro  de  los  compromisos  por  parte  de  los  involucrados  en  el  desarrollo  del  proyecto?   ¿Se  asignan  responsables  de  la  elaboración  de  las  estimaciones  del  proyecto?   ¿Los  grupos  involucrados  en  el  proyecto  identifican  y  evalúan  los  riesgos?   ¿Se  elabora  el  plan  de  proyecto  de  acuerdo  a  las  políticas  y  estándares  establecidos?   ¿Se  cuenta  con  una  agenda  de  trabajo  donde  se  detallan  por  lo  menos  las  actividades,  fechas  de  inicio  y   término,  productos,  responsables  y  puntos  de  control?   ¿Se  planean  las  actividades  de  administración  de  la  configuración  del  proyecto?   ¿Se  planean  las  actividades  de  aseguramiento  de  la  calidad  del  proyecto?   ¿El   plan   de   trabajo   y   anexos   son   revisados   con   el   grupo   de   trabajo   del   proyecto   antes   de   ser   presentados  a  la  gerencia?   ¿El  plan  de  proyecto  está  autorizado  por  la  gerencia  y  subgerencia  de  desarrollo?   ¿Se  informa  al  grupo  de  trabajo  del  proyecto  los  cambios  que  se  realizan  al  plan  y  anexos?   ¿Se  tiene  una  línea  base  donde  se  guardan  los  principales  productos  generados?       Seguimiento  de  Proyectos  de  SE   ¿Se  conocen  y  se  llevan  a  cabo  las  políticas  de  Seguimiento  de  proyectos?   ¿Se  lleva  un  registro  y  análisis  de  métricas  del  proyecto,  en  esfuerzo,  tiempo  y  presupuesto?   ¿Se  realizan  comparaciones  entre  las  métricas  reales  del  proyecto  y  las  estimaciones  planeadas?   ¿Se  llevan  a  cabo  revisiones  técnicas  por  parte  de  una  persona  con  suficiente  experiencia?   ¿Las  acciones  correctivas  para  disminuir  las  desviaciones  entre  lo  planeado  y  lo  ejecutado  son  revisadas   con  el  grupo  de  trabajo  del  proyecto?   ¿Se  elaboran  reportes  de  estado  del  proyecto  en  los  puntos  de  control  planeados  en  la  agenda?   ¿Se  llevan  a  cabo  reuniones  con  la  gerencia  para  la  evaluación  de  los  reportes  de  estado?   ¿Se  actualizan  el  plan  de  proyecto  y  anexos  conforma  a  las  acciones  correctivas  establecidas?   ¿Se  le  da  seguimiento  al  cumplimiento  de  los  compromisos  establecidos  en  el  proyecto?   ¿Se  mantiene  informado  al  usuario  de  los  ajustes  a  los  compromisos  establecidos?       Administración  de  la  Configuración  del  SE   ¿Se  conocen  y  se  llevan  a  cabo  las  políticas  de  Administración  de  la  Configuración?   ¿Se   tienen   creadas   las   líneas   base   del   proyecto   conforme   lo   establecido   en   la   planeación   de   la   administración  de  configuración?   ¿Se  les  asigna  un  identificador  único  a  los  elementos  de  configuración  del  proyecto?  

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

75  

  ¿Se  tienen  reportes  de  contenido  de  las  líneas  base  del  proyecto?   ¿Se  tienen  reportes  de  estado  de  los  elementos  de  configuración?   ¿Se  tiene  el  registro  de  las  solicitudes  de  cambio  a  elementos  de  líneas  base  del  proyecto?   ¿Se  realizan  las  auditorias  de  las  líneas  base  conforme  a  lo  establecido  en  el  plan  de  proyecto?   ¿Se  siguen  los  estándares  de  codificación  establecidos  para  el  proyecto?   ¿Se  siguen  los  estándares  de  nomenclatura  establecidos  para  el  proyecto?   ¿Se  lleva  un  registro  de  las  actividades  de  la  administración  de  configuración  del  proyecto?   ¿Se  mantiene  actualizado  el  repositorio  del  proyecto?   ¿Se  lleva  un  adecuado  control  de  versiones  de  los  productos  de  trabajo  del  proyecto?   ¿Se  les  da  un  adecuado  seguimiento  a  las  solicitudes  de  cambio  a  elementos  de  configuración?          

 

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

76  

    Adquisiciones  con  Proveedores   ¿Se  evalúa  que  el  producto  cumple  con  las  normas  y  estándares  técnicos  requeridos?   ¿Se  obtiene  el  registro  de  la  Propiedad  Intelectual?  La  propiedad  intelectual  se  divide  en  dos  categorías:   la  propiedad  industrial,  que  incluye  las  invenciones,  patentes,  marcas,  dibujos  y  modelos  industriales  e   indicaciones   geográficas   de   procedencia;   y   el   derecho   de   autor,   que   abarca   las   obras   literarias   y   artísticas.   ¿Se   implementa   el   sistema   embebido?   Hay   sectores   que   siguen   el   esquema   tradicional   de   implementación,  pero  en  los  más  recientes  o  emergentes  (teléfonos  móviles,  tarjetas  inteligentes,  etc.)   el  despliegue  es  de  productos  masivos.   ¿Se  administra  la  adquisición?  Incluye,  identificación  y  selección  del  proveedor,    análisis  de  la  solución   técnica   del   proveedor;   monitoreo   del   servicio   del   proveedor;   verificación   del   cumplimiento   de   requerimientos;  validación  de  la  adquisición  con  el  usuario   ¿Se  administra  a  los  proveedores?  Incluye,  establecimiento  de  acuerdos  con  el  proveedor;  supervisión   del    cumplimiento  de  los  acuerdos;  coordinación  del  trabajo  del  proveedor          

PD-­‐SEQA-­‐03-­‐02      MONITOREO  DEL  PLAN  SEQA    

-

Propósito  

Asegurar  el  cumplimiento  de  dichos  procesos  por  parte  del  grupo  de  SEQA.      

Procedimiento  

1. Verificar  que  SEQA  cuenta  con  los  siguientes  planes:   - Plan  PQA:  General  del  Desarrollo  Propio;  Requerimientos,  Arquitectura  y  Diseño;  y   Administración  del  Prototipo   - Plan  ACQ:  General  de  Adquisiciones;  Ingeniería  de  Hardware,  Ingeniería  de  Software;  y   Producción  Masiva     2. Registrar  las  no  conformidades  en  el  formato  de  verificación  (SEQA_FM03).    

Observaciones  

•

El Administrador del Proyecto será responsable de asegurar el cumplimiento de dichos procesos por parte del grupo de SEQA.

   

 

 

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

77  

 

PD-SEQA-03-03 REVISIÓN DE LA PLANEACIÓN Y SEGUIMIENTO DEL PROYECTO Propósito  

Participar   en   las   actividades   de   planeación   del   proyecto   para   verificar   que   se   cumple   con   las   políticas   y   estándares   definidos   por   la   dirección.   Y   verificar   que   la   Administración   del   Proyecto   le   da   seguimiento    

Procedimiento 1. 2. 3. 4. 5.

Verificar  que  el  Plan  del  Proyecto  cumple  con  las  políticas  establecidas.   Verificar  que  se  toman  en  cuenta  estándares  y  procedimientos  impuestos  por  el  cliente.   Verificar  que  el  plan  de  proyecto  está  completo.   Revisar  que  se  cumple  con  el  proceso  de  seguimiento  del  proyecto   Registrar  las  no  conformidades  en  el  formato  de  verificación  (SEQA_FM03).    

Observaciones En general SEQA debe participar en toda la planeación del proyecto para asegurarse que se siguen los procesos establecidos, pero esta participación no debe limitarse a la elaboración del plan de proyecto sino que debe extenderse a la planeación de actividades de Administración de Requerimientos, Configuración y Seguimiento.

•

   

  PD-SEQA-03-04 REVISIÓN DE LA ADMINISTRACIÓN DE REQUERIMIENTOS Propósito  

Asegurar  que  la  Administración  del  Proyecto  cumple  con  la  Adm.,  de  Requerimientos    

Procedimiento  

1. Verificar  que  los  requerimientos  han  sido  especificados,  documentados,  administrados        y   controlados  (su  trazabilidad).     2. Verificar  el  control  de  cambios  en  los  requerimientos  y  reportar  su  estado.     3. Registrar  las  no  conformidades  en  el  formato  de  verificación  (SEQA_FM03).   -

 

Observaciones •

SEQA deberá de revisar que dichas actividades se llevaron a cabo y se realizaron con base a las políticas, lineamientos y procedimientos establecidos

      Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

78  

   

 

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

79  

 

PD-SEQA-03-05 VERIFICACIÓN DEL CUMPLIMIENTO DE COMPROMISOS Propósito  

Asegurar  que  tanto  el  grupo  interno  de  desarrollo  y/o  el  proveedor  de  la  adquisición,  cumplieron   cabalmente  con  sus  compromisos.      

Procedimiento  

1. Verificar  que  la  Administración  del  Proyecto  haya  reportado  periódicamente:   - Estado  del  Proyecto.-­‐  Cualquier  desviación  de  los  planes  o  cambios  a  los  acuerdos   establecidos  deberá  ser  reportado     - Cumplimiento.-­‐  Identificación  del  nivel  de  cumplimiento  del  proyecto  con  la  organización  y  el   proceso  del  proyecto  establecido.   - Áreas  Problema.-­‐  Identificación  de  problemas  potenciales  y  actuales  del  proyecto  basados  en   el  análisis  de  revisiones  técnicas.   - Riesgos.-­‐  Identificación  de  riesgos  basados  en  la  participación  y  evaluación  del  progreso  del   proyecto  y  áreas  problema.   2. Registrar  las  no  conformidades  en  el  formato  de  verificación  (SEQA_FM03).   -   Observaciones •

SEQA debe verificar que la Adm., del Proyecto se aseguró que tanto el grupo interno de desarrollo y/o el proveedor cumplieron con sus compromisos.

 

 

 

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

80  

 

PD-­‐SEQA-­‐04   REGISTRO  Y  SEGUIMIENTO  A  NO  CONFORMIDADES      

PD-SEQA-04-01 REGISTRO Y CLASIFICACIÓN DE NO CONFORMIDADES Propósito  

Registrar   y   clasificar   en   una   base   de   datos   (tracker)   las   no   conformidades   obtenidas   en   las   actividades  de  auditorías  y  revisión  para  poder  darles  seguimiento.     Procedimiento  

1. Extraer   las   no   conformidades   reportadas   y   registrarlas   dentro   del   sistema   de   control   de   no   conformidades  (tracker).   2. Clasificar  y  priorizar  la  no  conformidad.   3. Registrar  área  responsable  de  solución.   4. Registrar  fecha  de  próxima  revisión.   5. Asignar  el  estado  de  “abierta”  a  la  no  conformidad.   6. Enviar  e-­‐mail  al  responsable  de  solucionar  la  no  conformidad  el  folio  correspondiente.     Observaciones •

La Clasificación se deberá hacer bajo los siguientes criterios. 01 - Objetivos del requerimiento. 02 - Administración (organización, tareas y responsabilidades) 03 - Control de documentación. 04 - Aplicación de estándares, prácticas y métricas. 05 - Revisiones y auditorias. 06 - Pruebas 07 - Sistema de Monitoreo (Reporte, seguimiento y acciones correctivas) 08 - Uso de herramientas, técnicas y metodologías. 09 - Capacitación y entrenamiento. 10 - Control de medios e insumos (HW, passwords,etc.) 11 - Administración de Riesgos. 12 - Administración SEQA.

•

La priorización se realizará bajo los siguientes parámetros: Alta Media Baja

•

à Si la no conformidad detiene el flujo operativo. à Si se refiere al NO apego a procesos y/o procedimientos. à Si se refiere al NO apego a estándares.

Las no conformidades deberán ser registradas y administradas utilizando el tracker.

    Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

81  

   

 

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

82  

 

PD-SEQA-04-02 CORRECCIÓN DE LAS NO CONFORMIDADES Propósito  

Corregir  las  no  conformidades  encontradas  en  las  actividades  o  productos  auditados                                    y   actualizar  su  estado  en  el  control  de  no  conformidades.    

Procedimiento  

1. Consultar  el  control  para  revisar  la  no  conformidad  registrada.   2. Corregir  el  producto  o  realizar  las  actividades  omitidas,  según  el  reporte.   3. Actualizar  el  estado  de  la  no  conformidad  de  “abierta”  a  “corregida”.    

Observaciones Esta actividad la deberá realizar aquellas personas que hayan tenido algún error u omisión en sus productos o actividades de desarrollo.

•    

 

PD-SEQA-04-03 SEGUIMIENTO PERIÓDICO A LAS NO CONFORMIDADES Propósito  

Monitorear  periódicamente  el  estado  de  las  no  conformidades  registradas  en  el  tracker.    

Procedimiento  

1. 2. 3. 4. 5.

Identificar  no  conformidades  “abierta”    en  el  control  y  revisar  fecha  de  próxima  revisión.   Asignar  responsable  de  revisión  SEQA  en  caso  de  que  corresponda.   Identificar  no  conformidades  con  estado  de  “corregida”  en  el  control.   Verificar    que  las  no  conformidades    han  sido  resueltas.   Actualizar  datos  y  estado  de  la  no  conformidad  conforme  a  resultado  de  la  revisión.  

 

Observaciones • •

En  caso  de  generarse  nuevas  “no  conformidades”  se  deberá  repetir  el  proceso  desde                la   actividad  Registro  de  las  no  conformidades.   Si  una  no  conformidad  no  es  resuelta  de  acuerdo  a  los  criterios  abajo  mencionados,  deberá  ser   turnada  a  un  nivel  de  organización  superior.     Prioridad  alta   à  si  en  la  primera  revisión  de  seguimiento  no  ha  sido  resuelta   Prioridad  media   à  si  en  la  segunda  revisión  de  seguimiento  no  ha  sido  resuelta   Prioridad  baja  

à  si  en  la  tercera  revisión  de  seguimiento  no  ha  sido  resuelta.  

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

83  

     

 

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

84  

 

PD-SEQA-04-04 REPORTE DE NO CONFORMIDADES Propósito:   Generar   reportes   del   estado   actual   que   guardan   los   reportes   de   no   conformidades   para   supervisar   su  seguimiento.     Ver:     Reporte  Resultados  (SEQA_FM05).   Reporte  Ejecutivo  (SEQA_FM06).          

 

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

85  

 

ANEXO  FORMATOS:       SEQA_FM01_VerifActividad    

 

      Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

86  

 

SEQA_FM02_AuditaProducto      

      SEQA_FM03_VerifProcesos     Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

87  

 

 

        SEQA_FM04_NoConformidad     Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

88  

 

   

          SEQA_FM05_RptResultado     Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

89  

 

   

                  SEQA_FM06_RptEjecutivo    

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

90  

   

 

             

 

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

91  

 

GLOSARIO Entregable   El   cumplimiento   o   logro   de     un   objetivo   debe   ser   evidente   a   través   de   la   creación   de   uno   o   más   entregables.  De  esta  manera,  el  entregable  cumple  con  un  objetivo  específico,  alcanzable  y  realista;   medible  en  términos  de  productos  o  servicios  a  entregar.    

Nota.-­‐  En  la  planeación  y  seguimiento  de  un  proyecto,  los  entregables,  marcan  un  acontecimiento  (hito)  que   sirve  de  punto  de  referencia    

  Alcance  del  Servicio   Se   especifica   el   ámbito   conceptual,   espacial   y   temporal   del   servicio   o   producto,   así   como   las   limitaciones  (lo  que  queda  fuera  del  proyecto);  los  supuestos  bajo  los  cuales  se  realizará  el  servicio  o   producto;  y  las  restricciones  administrativas  y  técnicas  que  existan.    

Forma:  Documento  físico,  archivo  electrónico,  excel,  mapa,  etc.       Lugar  físico,  local,  remoto,  (especificar).   Frecuencia  o  periodicidad  

  Criterio  de  Aceptación   Forma   o   modo   en   que   será   evaluado   el   cumplimiento   del   compromiso   u   objetivo   especificado   en   los   requerimientos.  Unidad  de  medida  o  indicador  (eficiencia,  velocidad,  cobertura,  etc.)  con  la  cual  que   el  cliente  estaría  satisfecho  en  el  desempeño  o  cumplimiento  de  sus  requerimientos.         Riesgos  de  Incumplimiento   Factores  que  pueden  incidir  o  limitar  el  logro  del  objetivo  del  servicio  y  que  deberán  de  prevenirse  

  Requerimiento   Característica,   cualidad,   propiedad   o   especificación   de   ciertas     funciones,   flujos   de   información,   operaciones  o  comportamientos  que  deberá  cumplir,  tener  o  realizar  el  producto  o  servicio.    

Nota.-­‐  Los  entregables  están  asociados  a  las  características  y  funciones  requeridas  del  producto  o  servicio.  

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

92  

 

APÉNDICE: ACRÓNIMOS Y TÉRMINOS ACQ ACS AP AR CMMi ERS HW PPS PQA SPS SEQA SW

Gestión de Proveedores (adquisiciones subcontratadas) Administración de la Configuración del Sistema Administración del Proyecto Administración de Requerimientos Modelo Integrado de Madurez de Capacidades (CMMi, en inglés) Especificación de Requerimientos del Sistema Hardware Planeación de Proyectos del Sistema Gestión de la Calidad de Procesos SE (desarrollos propios) Seguimiento de Proyectos del Sistema Aseguramiento de la Calidad del Sistema Embebido Software

Actividad: Las actividades son unidades de trabajo relacionadas lógicamente dentro de una fase. Aprobación: Cuando el responsable de aceptar el producto, verifica que este cumple con los criterios o características de aceptación definidas para el producto. Aseguramiento de la Calidad del Software: Todas las acciones tomadas para dar confianza de que un producto de software contiene todos los requerimientos técnicos establecidos, y, un conjunto de actividades diseñadas con el propósito de evaluar el proceso por el cual el producto de software es desarrollado y mantenido. Auditoría: Es una evaluación sistemática e independiente que se realiza a los productos de trabajo para verificar su conformidad con las políticas, estándares, guías y procedimientos establecidos. Esta verificación abarca forma y contenido de los productos de trabajo. Calidad: La totalidad de características de un producto o servicio que es capaz de satisfacer las necesidades establecidas o implicadas. Calidad del software: Capacidad del producto de software para satisfacer los requerimientos especificados. Ciclo de Vida del Producto: Etapas por las que atraviesa un producto, desde que es concebido como idea hasta que es retirado o desechado. El ciclo de vida típicamente incluye las siguientes fases: conceptual, análisis de requerimientos, diseño, construcción, pruebas, instalación, operación y mantenimiento. Cliente: Entidad o entidades para quien los requerimientos van a ser satisfechos en el sistema que será definido y desarrollado. Criterio de Aceptación: Son las condiciones bajo las cuales el cliente admitirá el software entregado. Consistencia: El grado de uniformidad, estandarización y libertad de contradicciones entre documentos o componentes de un sistema. Check-in: Recepción de productos nuevos, modificados o corregidos. Checklist: Lista de preguntas para la revisión del estado actual de un producto o proceso. Check-out: Extracción de productos de la biblioteca para su revisión y/o corrección.

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

93  

  Fase: Las fases describen los niveles altos de las actividades (Fase de Análisis, de Diseño, etc.) Hito: Un evento programado utilizado para conocer el estado del proyecto. Inspección: Es un examen para verificar que el software satisface sus especificaciones, sus requerimientos de calidad y que cumple con los estándares y regulaciones del proyecto. Su objetivo es detectar e identificar anomalías. Biblioteca: Conjunto de documentos y archivos organizados en carpetas según la naturaleza de los mismos, relacionados al desarrollo del proyecto. Línea Base: Es la especificación de un producto que ha sido formalmente revisado y aprobado, de tal forma que sirve como base para todo el desarrollo del proyecto y que puede ser cambiado solo formalmente bajo el proceso de control de cambios. Es una “fotografía” en el tiempo de la situación que guardan los productos de trabajo en un momento dado del proceso de desarrollo, provee un punto de control oficial para el trabajo subsecuente y sólo se le pueden aplicar cambios autorizados y controlados. Metodología: Una metodología es la aplicación de un método y una o más técnicas en el desarrollo de un proyecto. Donde los métodos son marcos de referencia con una serie de pasos a seguir y las técnicas son maneras de implementar los métodos. En la utilización de las técnicas pueden omitirse algunas partes. Métricas de software: Las medidas numéricas de productos y procesos que se hacen para el proyecto. El uso de medidas numéricas puede introducir precisión y claridad al proceso en lugar de una opinión, informalidad, e interpretaciones abiertas. No Conformidad: Cuando la evidencia encontrada durante una revisión o auditoria, sugiere que los procesos de la organización o los productos de trabajo del proyecto no se están siguiendo de manera correcta. Plan de Proyecto: Es el documento que define el trabajo a hacer y cómo se va a hacer. Política: Un principio o guía, típicamente establecido por la Dirección, la cual es adoptada por una organización o proyecto para influenciar y determinar decisiones. Política de Calidad: Las intenciones y objetivos de una organización referentes a la calidad. Proceso: Conjunto de actividades y prácticas mutuamente relacionadas o que interactúan, las cuales transforman elementos de entrada en resultados y que cuando se realizan de forma efectiva satisfacen los objetivos planteados para dicho proceso. Proyecto: Un trabajo multitarea de una sola duración que tiene fechas de comienzo y finalización bien definidas, un alcance de trabajo a ser realizado, un presupuesto asignado y un nivel de rendimiento especificado. Requerimiento: Condición o capacidad necesitada por el usuario para resolver un problema o alcanzar un objetivo y que debe ser cumplida por un sistema o componente de sistema para satisfacer un contrato, estándar, especificación u otro documento formal impuesto. Requerimientos de software (Requerimientos del sistema asignados al software): El subconjunto de requerimientos del sistema que van a ser implementados en componentes de software del sistema. Requerimientos del sistema: Una condición o capacidad que debe ser cumplida o procesada por un sistema o componente para satisfacer una condición o capacidad requerida por un usuario para resolver un problema. Requerimientos funcionales: Aquellos que describen lo que el software debe hacer.

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

94  

  Requerimientos técnicos: Aquellos requerimientos que imponen restricciones en cómo deben ser implementados los requerimientos funcionales o dictan condiciones que el sistema debe cumplir. Por ejemplo: rendimiento, capacidad, restricciones de calidad, etc. Requerimientos de Negocio: Aquellos requerimientos u objetivos de negocio que no son necesariamente parte del software pero que pueden llegarse a cumplir como parte de la ejecución de un proyecto Requerimientos de Entrega: Aquellos requerimientos no técnicos que se refieren a las condiciones para la entrega de los productos, la puesta en marcha y la liberación del software. Requerimientos de Interfaces: Aquellos requerimientos de interfaces con otros sistemas, productos de software y/ bases de datos existentes. Requerimientos de migración: Aquellos requerimientos de extracción y/o, conversión de datos necesarios para el correcto funcionamiento del software. Restricción: Es una limitación o factor conocido que tendrá impacto en la realización del proyecto. Revisión: Proceso de evaluación mediante el cual se pretende verificar que las actividades descritas en los procesos de la organización son llevadas a cabo de una manera consistente. Revisiones administrativas: Monitorear el progreso, determinar el estado de planes, calendario de tareas y el sistema de asignación de recursos, o para evaluar la efectividad de los enfoques usados, acciones correctivas o cambios en el alcance del proyecto para el logro del objetivo propuesto. Revisión técnica: es evaluar un producto de software para determinar si éste es apropiado para su uso, e identificar discrepancias en las especificaciones y estándares. Riesgo: Es una potencial dificultad o impedimento al proyecto que podría causar no alcanzar el éxito deseado. Suposición: Es algo dado por hecho que es usado como base para gestionar el proyecto. Tarea: Las tareas son los componentes de las actividades que son trabajadas por una o dos personas. El trabajo es hecho en las tareas, donde se coloca el tiempo de inicio y finalización. Validación: Confirmar que se construyeron los productos de trabajo que satisfacen el uso previsto en el ambiente previsto Versión: Es la etiqueta que se le asigna a un elemento de configuración ya sea electrónica o manualmente y que identifica únicamente a un Elemento de configuración y a sus características físicas y funcionales. Verificación: Confirmar que los productos de trabajo se construyeron correctamente (reflejan los requerimientos especificados). La verificación incluye a la inspección y pruebas.

  Fondo  de  Información  y  Documentación  para  la  Industria   Cuaderno  de  trabajo.  Número  04  /  julio  de  2013  

95