IEEE Gestión de proyectos de Software

IEEE Gestión de Proyectos de Software

Un proyecto de software puede verse como un proceso que consume recursos y está sujeto a influencias externas (requisitos en constante cambio, costos, plazos y recursos) y / o internas (dificultades técnicas de producción, sobreestimación de la productividad, etc.).

Tiene una serie de objetivos específicos que normalmente se entrega en un periodo determinado de tiempo, con un coste y con niveles (o atributos) de calidad, asumiendo algunos riesgos la persona quien realiza el proyecto.

Los proyectos de software a veces forman parte de proyectos más grandes. En estos casos, la gestión de proyectos de software puede ser un componente separado de un plan más amplio o puede incorporarse al plan a nivel del sistema de gestión de proyectos.

La idea original o necesidad de un proyecto de software puede provenir de ciertos aspectos como:

• Una propuesta generada dentro de la propia organización de desarrollo.
• La comprobación de que el software existente ha quedado desfasado, es decir, no cumple nuevos requisitos.
• Una petición específica de un cliente o usuario.
• Una necesidad detectada por el departamento de ventas.
• El personal de mantenimiento de las aplicaciones existentes, que realiza una recomendación específica.
• Una conclusión a partir de la información obtenida de los usuarios.

Es importante saber que antes de desarrollar un proyecto se debe evaluar su viabilidad de acuerdo con los siguientes aspectos:

• Económico: ¿es positiva la relación costes/beneficios?
• Técnico: ¿existe y está disponible la tecnología necesaria?
• Legal: ¿los requisitos cumplen las normas legales, contratos, etc.?
• Operativo: ¿puede implantarse de manera efectiva, teniendo en cuenta la filosofía de la organización y la cultura del personal?

La planeación y gestión de un proyecto de software es muy importante, tomando en cuenta el aspecto económico, se puede decir que los costes de un proyecto de software pueden ser:

• Del personal técnico implicado (desde el análisis hasta la instalación)
• De consultoría
• De software adicional (sistemas operativo, SGBD, herramientas CASE, etc.)
• Del hardware
• De la infraestructura (mobiliario, obras, locales, etc.)
• Debidos al usuario (formación, manuales, etc.)

Al igual, los beneficios pueden ser:

• Nuevas funcionalidades
• Eliminación de errores
• Reducción de errores
• Aumento de velocidad
• Aumento de la fiabilidad.

IEEE es una de las asociaciones de profesionales más grandes a nivel internacional, con más de 320,000 miembros de cerca de 150 países. Organizada en 37 asociaciones técnicas, incluyendo la sociedad de computación. IEEE genera tres tipos de estándares: Estándares, Prácticas recomendadas y Guías, distinguidos por su grado de prescripción en sus requerimientos normativos. En particular, para la planeación de aseguramiento de calidad en proyectos de ingeniería de software se desarrolló el estándar IEEE-730 el cual describe los elementos sugeridos para un plan de aseguramiento de calidad de un proyecto.

Los estándares de “Proyecto” corresponden a un conjunto de guías que buscan establecer un modelo de diseño y ejecución de proyectos, predecible, escalable y que cuente con un esquema de gobierno de los proyectos.  Para esto existen diversos enfoques metodológicos, pero me atrevo a decir que los más difundidos a nivel mundial el estándar PMI y estándar Prince2.  Estos estándares proveen de guías para todo tipo de proyectos, sin importar su tamaño ni industria.  Ambos tienen una terminología y un ciclo de vida de los proyectos diferentes, les recomiendo que analicen ambos y adopten uno de ellos

Cada estándar define el formato y contenido de los planes de gestión de proyectos de software, algunos de ellos que tienen que ver con las calidad de productos software son:

• IEEE 610.12 – GLOSARIO ESTÁNDAR DE TÉRMINOS EN LA INGENIERÍA DE SOFTWARE: Su función es Identificar los términos que se utilizan actualmente en la ingeniería de software. Se establecen definiciones estándar para estos términos.
• IEEE 828-1998 – PLAN DE GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARE: Es definido el contenido mínimo requerido para el plan de gestión de la configuración de un producto de software, mediante la definición de ciertas actividades que se abordarán y los requisitos de las cuales se definen para cualquier parte del ciclo de vida del software. Establece los contenidos mínimos que deben aparecer en el Plan de Gestión de la Configuración Software. Dicho plan puede ser un documento aislado o formar
• IEEE 730-1998 – IEEE PLANES DE ASEGURAMIENTO DE LA CALIDAD DE SOFTWARE: Proporciona requisitos mínimos aceptables para la creación y contenido de planes de seguro. Este estándar se aplica al desarrollo y mantenimiento de software crítico. Un subconjunto de los requisitos de esta norma puede aplicarse a software no crítico o ya desarrollado. El contenido de un plan de aseguramiento de calidad para un producto software de acuerdo con este estándar debe contener los puntos mencionados en las siguientes subsecciones. Tiene como propósito delinear el propósito específico y el alcance del plan de SQA. Listar los nombres de los elementos software cubiertos por el plan de SQA y el propósito de su uso. Determinar la porción del ciclo de vida cubierta por el plan para cada elemento software.
• IEEE 982.1-1988 – IEEE MEDIDAS DE FIABILIDAD DEL SOFTWARE: El estándar proporciona un conjunto de medidas para indicar la confiabilidad del software que se puede aplicar a productos de software, así como a los procesos de desarrollo y soporte. Se necesitan medidas que se puedan aplicar al principio del proceso de desarrollo, y estas medidas se pueden utilizar como indicadores de la fiabilidad del producto entregado. Ante una gran cantidad de modelos, técnicas y medidas, los desarrolladores de software y los usuarios lo han demandado.
• IEEE 829-1998 – DOCUMENTACIÓN DE PRUEBA DE SOFTWARE: La Función de este estándar es describir un conjunto de documentos básicos de pruebas de software. Además de que se integra de un contenido de documentos de prueba, aunque es importante mencionar que no se especifica el conjunto de documentos necesarios para la prueba.
• IEEE 12207 – PROCESOS DEL CICLO DE VIDA DE SOFTWARE: Este estándar define una serie de procesos extensos, que cubren todo el ciclo de vida desde el inicio del sistema de software hasta el final.
• IEEE 1471-2000 – DESCRIPCIÓN DE LA ARQUITECTURA DE SOFTWARE DE SISTEMAS INTENSIVOS: Esta norma es recomendada porque dirige las actividades de la creación, análisis, y el mantenimiento de las descripciones arquitectónicas. Además de definir el contenido de la descripción de la arquitectura. El apéndice proporciona los principios de conceptos y términos clave, la relación con otros estándares y ejemplos de uso.
• IEEE 1462-1998 – Evaluación y Selección de las Normas CASE: Se trata de una adopción IEEE de la norma ISO / IEC 14102. Una vez que la norma ISO / IEC 14102 revisa, adopta la versión revisada (o tal vez emitir una corrección). En ese momento, se debe adoptar el número ISO (14102).
• IEEE 1465-1998 – REQUISITOS DE CALIDAD Y PRUEBAS: Se establecen los requisitos de calidad para los paquetes de software y las instrucciones sobre cómo probar un paquete de software en contra de estos requisitos. Estos requisitos se aplican a los paquetes de software proporcionados y entregados, y no se aplican al proceso de producción (incluidas las actividades y los productos intermedios, como las especificaciones)
• IEEE 1233-1998 – DESARROLLO Y ESPECIFICACIONES DE LOS REQUISITOS DEL SISTEMA: Proporciona pautas para formular conjuntos de requisitos y estandarizar los requisitos del sistema. El desarrollo incluye identificar, organizar, presentar y modificar requisitos. También se establecen las condiciones para incorporar conceptos operativos, restricciones de diseño y requisitos de configuración de diseño en la especificación. Esta guía también cubre las características y la calidad de cada requisito.
• IEEE 1228-1994 – PLAN DE SEGURIDAD DE SOFTWARE: Determina los requisitos mínimos aceptables para el contenido del plan de seguridad del software. Este estándar se aplica a los planes de seguridad de software utilizado para el desarrollo, adquisición, mantenimiento y eliminación de software de seguridad. La norma requiere que los planes se preparen en el contexto de los procedimientos de seguridad del sistema. Solo se incluyen los aspectos de seguridad del software. Este estándar no contiene requisitos especiales para el software utilizado en sistemas distribuidos o procesadores paralelos.
• IEEE 1074-1997 – PROCESOS DEL CICLO DE VIDA DE UN SOFTWARE: Proporciona procedimientos para crear procesos del ciclo de vida del software. Es útil para cualquier organización que se ocupe de la gestión e implementación de proyectos de software. Define las actividades que constituyen los procesos necesarios para el desarrollo y el mantenimiento de software, ya sea parte de un sistema mayor o autónomo (stand-alone).Tiene como características:

• Los procesos de gestión y soporte a lo largo de todo el ciclo de vida.
• Procesos divididos en actividades (obligatorias y opcionales):

• Información de entrada.
• Descripción.
• Información de salida.

• Antes de empezar un proyecto, revisar las actividades para ver si son aplicables, y establecer un orden.
• Conformidad con el estándar: realización de todas las actividades obligatorias.

• IEEE 1058.1-1987 – PLANES DE GESTIÓN DE PROYECTOS DE SOFTWARE: Este estándar especifica el formato y contenido de un plan de gestión de proyectos de software. No especifica las técnicas exactas utilizadas para desarrollar el plan del proyecto, ni proporciona ejemplos de planes de gestión del proyecto. Toda organización que utilice este estándar debe desarrollar un conjunto de prácticas y procedimientos para desarrollar pautas detalladas para preparar y actualizar planes basados ​​en el estándar. Estos procedimientos y prácticas detallados deben tener en cuenta los factores ambientales, organizativos y políticos que afectan la aplicación de la norma.
• IEEE 1061-1998 – METODOLOGÍA DE MÉTRICAS DE CALIDAD DE SOFTWARE: Un método para establecer requisitos de calidad e identificar, implementar, analizar y verificar el software del producto y los procesos de medición de la calidad. La metodología cubre todo el ciclo de vida del software.
• IEEE 1063-2001 – DOCUMENTACIÓN DE USUARIO: Existen dos factores que han contribuido al desarrollo de esta norma: la baja calidad de documentación del usuario, así como la necesidad de los requisitos expresados ​​por los productores de la documentación.
• IEEE 1044 -1993 – CLASIFICACIÓN DE ANOMALÍAS DEL SOFTWARE: El estándar clasificará las anomalías encontradas en el software y proporcionará su documentación. Describe los métodos de manejo de las excepciones que se encuentran en cualquier etapa del ciclo de vida del software y proporciona un registro completo de las excepciones del software y los elementos de datos relacionados que se pueden utilizar para identificarlos y rastrearlos. Esta norma no pretende definir los requisitos de procedimiento o de formato para el uso de sistemas de clasificación. Sino que hace esto para identificar algunas medidas de clasificación, por lo que no intenta definir todos los datos que respaldan el análisis de las anomalías.
• IEEE 1540-2001 – GESTIÓN DE RIESGOS DEL PROCESO DE CICLO DE VIDA DEL SOFTWARE: Este es el proceso de gestión de riesgos durante el ciclo de vida del software. Se puede agregar al conjunto de procesos de ciclo de vida del software existente definido por la serie de estándares IEEE / EIA 12207, o se puede usar de forma independiente.
• IEEE 1062-1998 – IEEE ADQUISICIÓN DE SOFTWARE: Aquí es descrito un conjunto de prácticas de calidad útiles que se pueden seleccionar y aplicar en uno o más pasos en el proceso de adquisición del software. Esta práctica es recomendada, dado que se puede aplicar al software que se ejecuta en cualquier sistema informático, independientemente de su tamaño, complejidad o criticidad del software, sine embargo, es importante mencionar que ésta es más mucho adecuada para software estándar modificado al igual que para el software completamente desarrollado.
• IEEE 1045-1992 – IEEE PRODUCTIVIDAD Y MÉTRICAS DE SOFTWARE: El estándar es el encargado de medir los factores que intervienen en la productividad del software. Las métricas de productividad del software se proporcionan para garantizar la comprensión de los datos de medición para el código fuente y los documentos de producción. Aunque este estándar especifica métricas para caracterizar los procesos de software, no recomienda mediciones de productividad como método para evaluar proyectos de software o desarrolladores de software. Este estándar no mide la calidad del software. El estándar no está destinado a aumentar la productividad, sólo para medirlo. El propósito de este estándar es comprender mejor el proceso del software para que pueda proporcionar información para mejorarlo.
• IEEE 1012a-1998 – PLANES PARA LA VERIFICACIÓN Y VALIDACIÓN DE SOFTWARE: Explica la relación entre los dos conjuntos de requisitos del plan de verificación y validación de software que se encuentran en los estándares IEEE 1012-1998 e IEEE / EIA 12207.1-1997 para que los usuarios puedan generar documentos que cumplan con los estándares.
• IEEE 1028-1997 – REVISIONES DE SOFTWARE: Esta norma define cinco tipos de revisiones de software, así como los procedimientos necesarios para la ejecución de cada tipo de examen. Esta regla se refiere solo a la crítica. No define los procedimientos para determinar la necesidad de revisión, ni especifica cómo manejar los resultados de la revisión. Los tipos de revisiones incluyen revisiones de la dirección, revisiones técnicas, inspecciones y auditorías.
• parte de otro documento (por ejemplo: el plan del proyecto o el plan SQA).
• IEEE 1008-1987(R1993) (App Dec 11 '86, Reaff Dec 2 '93) – ANSI/IEEE PRUEBAS UNITARIAS DE SOFTWARE: El propósito principal del estándar es especificar un método estándar para las pruebas unitarias de software que puede ser utilizado como base para la práctica de la ingeniería de software de sonido.
• IEEE 1012-1998 – VERIFICACIÓN Y VALIDACIÓN DE PROCESOS SOFTWARE: Con este estándar se determina si el producto desarrollado en una actividad en particular cumple con los requisitos de esa actividad y si el software satisface las necesidades de los usuarios y usuarios esperados. Esta determinación puede incluir análisis, revisión, inspección, evaluación y prueba de productos y procesos de software. El proceso de V&V evalúa el software en el contexto del sistema, incluido el entorno operativo, el hardware, el software de interfaz, los operadores y los usuarios.
• IEEE 1016-1998 – IEEE PRÁCTICA RECOMENDADA PARA LAS DESCRIPCIONES DE SOFTWARE DE DISEÑO: Información y recomendaciones necesarias para la especificación de diseño de software. SDD es una representación de un sistema de software, que se utiliza como medio para comunicar información de diseño de software. Este enfoque es adecuado para documentos en papel, bases de datos automáticas, descripciones de diseño, idioma u otros métodos de descripción.
• IEEE 830-1998 – ESPECIFICACIÓN DE REQUISITOS DE SOFTWARE: En este estándar se especifican los requisitos del software que se desarrollará, pero también puede ayudar a seleccionar productos de software comerciales.

Las normas IEEE mencionadas anteriormente son aplicadas durante el ciclo de vida de un proyecto de software, por lo que es realmente importante que sean ejecutadas, sin embargo, existen dos de ellas que son más importantes o, mejor dicho, existe una mayor atención hacia ellas, la primera es:

La norma IEEE 1471, que es un estándar IEEE reemplazado para describir la arquitectura de un "sistema intensivo en software", también conocido como arquitectura de softwar, formalmente conocido como ANSI / IEEE 1471-2000.

...