Procesos de software

Partes: 1, 2

Justificación

El concepto de Proceso de software es uno de los conceptos más abstractos en la historia de la Ingeniería de software. Muchas veces confundido como un proyecto informático o como un abstracto que pretende ser la base de una potencial gestión de conocimiento de los procesos de desarrollo informático. Desde que Watts Humprey define más formalmente el proceso de software, se ha logrado concebir una cosmovisión del proceso de software más formal, siendo fijada como un proceso de continuo aprendizaje mediante el cual una organización mejora y se mejora a través de procesos adquiridos y/o sus propios procesos. Así se llega al proceso llamado CMM o Capability Maturity Model con sus modelos asociados a personas y adquisiciones. La versión actualizada del CMM, lCMMI o CMM Integrated, es actualmente un instrumento de la gestión de la ingeniería de software tradicional y formal.

No obstante, esta formalización ha hecho que su validez se pierda como "un proceso más a ejecutar" y no en su sentido organizador del trabajo informático sobre todos los artefactos informáticos que una organización utiliza hoy en día. Aún más, los adelantos en ingeniería organizacional y su pervivencia en las empresas hoy en día, hacen de que un enfoque de Proceso de software no se limite ni constriña a un conjunto de prácticas y al cumplimiento de un modelo, sino a un estado o proceder organizacional tendiente a gestionar el conjunto de proyectos, procesos y tareas asociadas al procesamiento de datos, de información y de conocimiento de una organización cualquiera.

En este sentido la asignatura presenta el proceso de software bajo una óptica de enclave organizacional que precisa una gestión completa, cabal e integral. Con relación a la Ingeniería de software como disciplina y al Ingeniero de software como profesional, el enfoque dado al concepto de Proceso de software resulta integrador con otros campos relacionados como la calidad y la gestión de riesgos, la gestión de proyectos y, la administración de sistemas tecnologizados al introducir conceptos de ventas versus diseño, selección de componentes o simplemente la constitución de una Oficina de Proyectos Informáticos.

En este sentido se introduce como término provocador el de Proceso de Negocio de Software, para encaminar al lector hacia esta nueva idea del alcance de un proceso de software, ya no como un conjunto de "cosas por hacer" para producir software, sino un conjunto de procesos claves y estrategicos que regulan todo el negocio adscrito a una producción de software lo cual no limita lo procesos a la producción tradicional, sino que incluye toda la cadena de valor que aporta valor a un software o desarrollo tecnológico cualquiera, lo cual incluye marketing, gerencia, investigación, etc.

Descripción de la asignatura

La asignatura revisa diversos conceptos asociados a la Ingeniería de software y a Proceso de software desde una óptica de unidad organizacional estratégica. Se pretende revisar una serie de instrumentos de gestión organización y administración empresarial en la esfera de la Ingeniería de software entendida como un negocio o unidad estratégica dentro de una empresa o en sí misma como una empresa.

La asignatura revisa diversos elementos vinculados tradicionalmente al proceso de software unido a otros propios de gestión y gerencia de proyectos para distinguir los procesos que serían clave al momento de sentar las bases de la idea de proceso de negocio de software y que en esencia define una empresa de software.

Objetivos

Objetivos generales

Presentar el concepto y noción de Proceso de software entendido como una herramienta organizacional y un signo de madurez organizacional de unidades informáticas con el fin de interpretar el proceso de software como una unidad de negocios empresarial.
Vincular el proceso de software a los tradicionales paradigmas de software ampliamente utilizados en la planificación de proyectos informáticos e igualmente se presenta asociado a conceptos de proyectos de software.
Relacionar el proceso de software con la estructura de una oficina de proyectos como una instancia de gestión organizacional del conocimiento asociado a las actividades de software en una organización.

Objetivos específicos

– Conocer los fundamentos de la calidad y de la organización de la calidad en una organización (ISO 9000, 1400 y 1800) y en una unidad de calidad integral (SQA, SCM, SEPG) y situarlos en una óptica de estrategia organizacional.

– Comprender el rol organizacional de los modelos de mejora (CMM, SPICE, etc.), los conceptos de modelización, el rol de herramientas CASE centrado en el proceso, y dominar y generar métricas en ingeniería del software.

– Conocer las herramientas de decisión al momento de comprar o producir un software.

– Comprender los mecanismos que definen y regulan la relación entre clientes, consumidores, operadores y desarrolladores de software (outsorcing, deslocalización, etc.)

– Conocer sobre gestión de proveedores y la subcontratación, análisis de valor y pliego de condiciones.

– Comprender y conocer los procesos y herramientas de la evaluación de proyectos y la valorización de empresas.

– Interpretar la función del proceso de software como una unidad de negocio empresarial.

Organización del contenido y estructura del documento

Estos objetivos se desarrollan en los capítulos de la asignatura tal como se describe a continuación.

CAPÍTULO	OBJETIVO(S)	RESUMEN DEL CAPÍTULO	APORTACIÓN Y RESULTADO OBTENIDO
Capítulo 1	Conocer los conceptos y características esenciales de un proceso de software.	Revisión del concepto de proceso, ligado a la noción de calidad y riesgo como ejes del proceso de software incluyendo herramientas como SCM y SEPG, CASE, entornos de trabajo, Modelos de procesos de software y de mejora de la calidad (CMM, CMMI, SPICE, Trillium, etc.).	Se identifica la noción de proceso de software y sus rasgos distintivos.
Capítulo 2	Conocer los paradigmas y su relación con los procesos de software.	Revisión de los paradigmas de software y su relación con la Ingeniería de software, asimismo el cambio en los paradigmas bajo la dirección de un proceso de software.	Se relacionan los diversos paradigmas de desarrollo de software con los procesos de software lo cual relaciona la visión operacional con la estratégica.
Capítulo 3	Conocer el enfoque de proyectos y su relación con los procesos de software.	Revisión del proceso de software y su relación con la Gestión de Proyectos, y el cambio que se produce en el desarrollo de software desde la gestión de proyectos.	Se relaciona el enfoque de proyectos tradicional (diseño, gestión y dirección) con los procesos de software lo cual relaciona la visión de proceso organizacional con la visión de proceso asociada al software.
Capítulo 4	Reflexionar sobre la oficina de proyectos y los procesos de software.	Reflexión sobre una oficina de proyectos (y sus herramientas) como unidad estratégica organizacional y como base de una oficina de proyectos de software como motor del cambio organizacional.	Se discute y plantea una unidad organizacional estratégica y gerencial para gestionar y administrar proyectos de software desde la óptica de los procesos de software.

Capítulo 1 .- Conceptos y características esenciales de un proceso de software

O B J E T I V O

– Conocer los conceptos y características esenciales de un proceso de software.

1.1. Concepto de proceso

A continuación se presentan diversas definiciones de Proceso:1

– La norma internacional ISO-9001 define un proceso como "una actividad que utiliza recursos, y que se gestiona con el fin de permitir que los elementos de entrada se transformen en resultados". 2

– Oscar Barros hace una importante distinción, al introducir el concepto de valor agregado en la definición de proceso, señalando que "un proceso es un conjunto de tareas lógicamente relacionadas que existen para conseguir un resultado bien definido dentro de un negocio; por lo tanto, toman una entrada y le agregan valor para producir una salida. Los procesos tienen entonces clientes que pueden ser internos o externos, los cuales reciben a la salida, lo que puede ser un producto físico o un servicio. Estos establecen las condiciones de satisfacción o declaran que el producto o servicio es aceptable o no" (Barros, 1994; pp.56).

– Thomas Davenport, uno de los pioneros de la reingeniería, señala que un proceso, simplemente, es "un conjunto estructurado, medible de actividades diseñadas para producir un producto especificado, para un cliente o mercado específico. Implica un fuerte énfasis en cómo se ejecuta el trabajo dentro de la organización, en contraste con el énfasis en el qué, característico de la focalización en el producto" (Davenport, 1993; pp. 5).

– Hammer (1996) por su parte, establece la diferencia sustancial entre un proceso y una tarea, señalando que una tarea corresponde a una actividad conducida por una persona o un grupo de personas, mientras que un proceso de negocio corresponde a un conjunto de actividades que, como un todo, crean valor para el cliente externo. Al hacer esta comparación, Hammer hace la analogía con la diferencia que existe entre las partes y el todo.

– Por su parte, Ould (1995) lista una serie de características que deben cumplir los procesos de negocio y que refuerzan la posición de Hammer; según este autor, un proceso de negocio contiene actividades con propósito, es ejecutado colaborativamente por un grupo de trabajadores de distintas especialidades, con frecuencia cruza las fronteras de un área funcional, e invariablemente es detonado por agentes externos o clientes de dicho proceso.

1 BARROS, Oscar. (1994). – Reingeniería de Procesos de negocio. Editorial Dolmen. Chile. 2 ISO. (2000). Norma Internacional ISO 9001 – Sistemas de gestión de la calidad – Requisitos- Impreso en la Secretaría Central de ISO en Ginebra, Suiza.

1.1.1. Proceso de negocios

Un proceso de negocio es un conjunto de tareas relacionadas lógicamente llevadas a cabo para lograr un resultado de negocio definido. Cada proceso de negocio tiene sus entradas, funciones y salidas. Las entradas son requisitos que deben tenerse antes de que una función pueda ser aplicada. Cuando una función es aplicada a las entradas de un método, tendremos ciertas salidas resultantes.

Es una colección de actividades estructurales relacionadas que producen un valor para la organización, sus inversores o sus clientes. Es, por ejemplo, el proceso a través del que una organización ofrece sus servicios a sus clientes.

Un proceso de negocio puede ser parte de un proceso mayor que lo abarque o bien puede incluir otros procesos de negocio que deban ser incluidos en su función. En este contexto un proceso de negocio puede ser visto a varios niveles de granularidad. El enlace entre procesos de negocio y generación de valor lleva a algunos practicantes a ver los procesos de negocio como los flujos de trabajo que efectúan las tareas de una organización.

Un subproceso es parte de un proceso de mayor nivel que tiene su propia meta, propietario, entradas y salidas. Las actividades son partes de los procesos de negocio que no incluyen ninguna toma de decisión ni vale la pena descomponer (aunque ello sea posible). Por ejemplo, "Responde al teléfono", "Haz una factura".

Un proceso de negocio es usualmente el resultado de una Reingeniería de Procesos. El modelado de procesos es usado para capturar, documentar y rediseñar procesos de negocio. Para aplicar los procesos se deben tener claras las tareas, una estructura jerárquica y una tendencia a la interacción y comunicación vertical.

1.1.1.1. Características de un proceso de negocio

Los procesos poseen las siguientes características:1

– Pueden ser medidos y están orientados al rendimiento.

– Tienen resultados específicos.

– Entregan resultados a clientes o "stakeholders".2

– Responden a alguna acción o evento específico.

– Las actividades deben agregar valor a las entradas del proceso.

Los procesos de negocio pueden ser vistos como un recetario para hacer funcionar un negocio y alcanzar las metas definidas en la estrategia de negocio de la empresa. Las dos formas principales de visualizar una organización, son la vista funcional y la vista de procesos.

1 DAVENPORT, Thomas. (1993). Process Innovation. Harvard Business School Press. USA. 2 Stakeholders. Todo grupo o persona que puede afectar o se ve afectado por una organización o sus actividades. También, toda persona o grupo que puede ayudar a definir las proposiciones de valor de una organización.

1.1.1.2. Objetivos centrales de un proceso de negocio

Los objetivos centrales de un proceso de negocio son:

– Mejorar el entendimiento de una situación y comunicarla entre los diversos stakeholders.

– Utilizarlos como una herramienta para alcanzar las metas de un proyecto de proceso de desarrollo. No obstante, para que los procesos de negocio puedan cumplir con su objetivo, constantemente son sometidos a cambios debido a programas de mejora continua en las organizaciones.

1.1.1.3. Tipos de procesos de negocio

Existen tres tipos de procesos de negocio:1

– Procesos estratégicos – Estos procesos dan orientación al negocio. Por ejemplo, "Planificar estrategia", "Establecer objetivos y metas".

– Procesos centrales – Estos procesos dan el valor al cliente, son la parte principal del negocio. Por ejemplo, "Repartir mercancías".

– Procesos de soporte – Estos procesos dan soporte a los procesos centrales. Por ejemplo, "contabilidad", "Servicio técnico".

1 IBM. (1981).Business Systems Planning-Information Systems Planning Guide, GE20-0527-3. USA

1.1.1.4. Vista funcional vs vista de proceso

La vista funcional descansa en el organigrama de la empresa como modelo fundamental del negocio; las actividades que debe ejecutar la organización, para cumplir con su misión, se estructuran en conjuntos de funciones relativamente homogéneas (por ejemplo, todas las actividades que tienen que ver con las finanzas de la organización, se unen bajo un mismo "techo"). Y así, los recursos pertenecen a los departamentos y la especialización funcional y el expertizaje, son las principales consideraciones a la hora de formar los departamentos, los cuales se relacionan a través de una jerarquía de estructuras de autoridad. Los programas de mejoramiento se focalizan en aumentar la eficiencia y efectividad de las funciones y unidades organizacionales específicas, muchas veces suboptimizando a la organización como un todo holístico y descuidando aquello que debiera ser la primera prioridad de cualquier organización: satisfacer y en lo posible anticiparse a los requerimientos de los clientes.

En contraste, la vista de procesos se orienta al trabajo mismo que se debe desarrollar en la organización, para que el negocio funcione y entregue un producto o servicio, por el cual un cliente externo está dispuesto a pagar. La vista de procesos es una manera tan poderosa de visualizar y analizar un negocio, porque provee de la lógica con la cual los clientes lo miran; los clientes interactúan con la empresa, a través de los procesos del negocio, contratando un servicio, recibiendo dicho servicio, pagándolo y recibiendo atención de post venta. Cuando se entiende el negocio desde esta perspectiva, es posible evaluar el "valor agregado" del trabajo que aporta cada cual.

1.1.2. Proceso de software

Un proceso de desarrollo de software tiene como propósito la producción eficaz y eficiente de un producto software que reúna los requisitos del cliente. Dicho proceso, en términos globales se puede ver en la figura 1.1.

Este proceso es intensamente intelectual, afectado por la creatividad y juicio de las personas involucradas. Aunque un proyecto de desarrollo de software es equiparable en muchos aspectos a cualquier otro proyecto de ingeniería, en el desarrollo de software hay una serie de desafíos adicionales, relativos esencialmente a la naturaleza del producto obtenido. A continuación se explican algunas particularidades asociadas al desarrollo de software y que influyen en su proceso de construcción.

Un producto software en sí es complejo, es prácticamente inviable conseguir un 100% de confiabilidad de un programa por pequeño que sea. Existe una inmensa combinación de factores que impiden una verificación exhaustiva de las todas posibles situaciones de ejecución que se puedan presentar (entradas, valores de variables, datos almacenados, software del sistema, otras aplicaciones que intervienen, el hardware sobre el cual se ejecuta.).

Un producto software es intangible y por lo general muy abstracto, esto dificulta la definición del producto y sus requisitos, sobre todo cuando no se tiene precedentes en productos software similares. Esto hace que los requisitos sean difíciles de consolidar tempranamente. Así, los cambios en los requisitos son inevitables, no sólo después de entregado en producto sino también durante el proceso de desarrollo.

Además, de las dos anteriores, siempre puede señalarse la inmadurez de la ingeniería del software como disciplina, justificada por su corta vida comparada con otras disciplinas de la ingeniería. Sin embargo, esto no es más que un inútil consuelo.

1.1.2. Proceso de software

edu.red

Figura 1.1: Proceso de desarrollo de software.

El proceso de desarrollo de software no es único. No existe un proceso de software universal que sea efectivo para todos los contextos de proyectos de desarrollo. Debido a esta diversidad, es difícil automatizar todo un proceso de desarrollo de software.

A pesar de la variedad de propuestas de proceso de software, existe un conjunto de actividades fundamentales que se encuentran presentes en todos ellos:

1.1.2.1. Actividades fundamentales del proceso de software

A continuación se describen las actividades fundamentales del proceso de software:

– Especificación de software: Se debe definir la funcionalidad y restricciones operacionales que debe cumplir el software.

– Diseño e Implementación: Se diseña y construye el software de acuerdo a la especificación.

– Validación: El software debe validarse, para asegurar que cumpla con lo que quiere el cliente.

– Evolución: El software debe evolucionar, para adaptarse a las necesidades del cliente.

Además de estas actividades fundamentales, Pressman menciona un conjunto de "actividades protectoras", que se aplican a lo largo de todo el proceso del software. Ellas se señalan a continuación:

– Seguimiento y control de proyecto de software.

– Revisiones técnicas formales.

– Garantía de calidad del software.

– Gestión de configuración del software.

– Preparación y producción de documentos.

– Gestión de reutilización.

– Mediciones.

– Gestión de riesgos.

1.1.2.2. Elementos del proceso de software

Pressman caracteriza un proceso de desarrollo de software como se muestra en la figura 1.2. Los elementos involucrados se describen a continuación:

– Un marco común del proceso, definiendo un pequeño número de actividades del marco de trabajo que son aplicables a todos los proyectos de software, con independencia del tamaño o complejidad.

– Un conjunto de tareas, cada uno es una colección de tareas de ingeniería del software, hitos de proyectos, entregas y productos de trabajo del software, y puntos de garantía de calidad, que permiten que las actividades del marco de trabajo se adapten a las características del proyecto de software y los requisitos del equipo del proyecto.

– Las actividades de protección, tales como garantía de calidad del software, gestión de configuración del software y medición, abarcan el modelo del proceso. Las actividades de protección son independientes de cualquier actividad del marco de trabajo y aparecen durante todo el proceso.

edu.red

Figura 1.2: Elementos del proceso del software.

1.1.2.3. Relación entre los elementos del proceso de software

Otra perspectiva utilizada para determinar los elementos del proceso de desarrollo de software es establecer las relaciones entre elementos que permitan responder Quién debe hacer Qué, Cuándo y Cómo debe hacerlo.

edu.red

Figura 1.3: Relación entre elementos del proceso del software.

En la figura 1.3 se muestran los elementos de un proceso de desarrollo de software y sus relaciones. Así las interrogantes se responden de la siguiente forma:

– Quién: Las Personas participantes en el proyecto de desarrollo desempeñando uno o más Roles específicos.

– Qué: Un Artefacto1 es producido por un Rol en una de sus Actividades. Los Artefactos se especifican utilizando Notaciones específicas. Las Herramientas apoyan la elaboración de Artefactos soportando ciertas Notaciones.

– Cómo y Cuándo: Las Actividades son una serie de pasos que lleva a cabo un Rol durante el proceso de desarrollo. El avance del proyecto está controlado mediante hitos que establecen un determinado estado de terminación de ciertos Artefactos.

1 Un artefacto es una pieza de información que es producida, modificada o usada por el proceso, define un área de responsabilidad para un rol y está sujeta a control de versiones. Un artefacto puede ser un modelo, un elemento de modelo o un documento.

1.2. Proceso de negocio de software versus proceso de software de negocio

– Proceso de negocio de software es el proceso (organizacional) de un negocio cuyo eje de actividad es cualquier actividad del ciclo de vida del software: desde la concepción hasta la implantación llave en mano, pasando por comercialización, desarrollo, y/o estudio, etc. En otras palabras sería el proceso de negocio adscrito a la cadena de valor de un negocio de software, dejando claro que no necesariamente puede desarrollarse sólo al desarrollo de software, sino también a otras facetas a la actividad de negocio (por ejemplo, comercialización de software). Esto no excluye, que se incluyan actividades de negocio tradicional para soportar las actividades centrales del negocio (por ejemplo, contabilidad y finanzas del negocio). Por ejemplo: una empresa de benchmarking de software cuyo proceso de negocio de Software sería todas las fases de estudio, investigación, análisis y test de software y el proceso de negocio sería estas mismas fases más otras como las propias de gerencia y de administración general. Por ejemplo: una empresa que desarrolla software ERP, su proceso de negocio, sería la producción de software y -entre otras- las actividades de difusión y comercialización del ERP, y el proceso de negocio de Software serían los procesos claves de producción, como la customización al cliente de los ERP.

– Proceso de software de negocio es el proceso de software de un software de un negocio o en otras palabras el proceso de un desarrollo de software orientado a un negocio. Por ejemplo: el análisis, diseño, programación, implantación y puesta en marcha de un software en un empresa cualquiera.

1.3. La calidad y el riesgo como ejes del proceso

La identificación y gestión de los riesgos asociados a los requisitos del software, individuales y a grupos de ellos, desde la fase se ingeniería de requisitos puede permitir minimizarlos, evadirlos y controlarlos. El enfrentamiento proactivo de los riesgos que pueden afectar al desarrollo o a la calidad de los requisitos y las acciones para evitarlos, permitirían minimizar problemas que persisten en el desarrollo de software. Son de mayor importancia los riesgos asociados a las principales características de calidad de los requisitos.

La ingeniería de requisitos es un área de investigación que procura atacar un punto fundamental en el proceso, que es la definición de lo que se quiere producir. Jackson afirma que la ingeniería de requisitos se ubica en el punto de encuentro entre lo informal y lo formal del desarrollo de software (Jackson, 2001).1

Para lograr producir aquello que el cliente requiere, en el plazo solicitado y ajustados al presupuesto asignado, se necesita desarrollar un proceso que incluya desde la etapa más temprana la gestión de los riesgos asociados a los requisitos, de forma que se contribuya al mejoramiento gradual del proceso de desarrollo y la gestión de un proyecto de software que logre la satisfacción del cliente en estas organizaciones.

1 JACKSON, M. (2001). Software Requirements and Specifications. Addison-Wesley.

1.3.1. La gestión de riesgos en el ámbito del software

La gestión de riesgos en el ámbito del software procura formalizar conocimiento orientado a la minimización o evitación de riesgos en proyectos de desarrollo de software, mediante la generación de principios y buenas prácticas de aplicación realista (Roppponen, 2000).1 Hasta el momento se ha propuesto y utilizado diferentes enfoques de gestión del riesgo desde que Boehm (Boehm, 1988)2 atrajo a la comunidad de ingeniería del software hacia la gestión del riesgo. Sin embargo, es evidente que pocas organizaciones utilizan todavía de una forma explícita y sistemática métodos específicos para gestionar los riesgos en sus proyectos software.

En (Pressman, 2002)3 se presenta la definición de riesgo dada por Robert Charette en (Charette, 1989)4 donde plantea que en primer lugar, el riesgo afecta a los futuros acontecimientos. En segundo lugar, el riesgo implica cambios. En tercer lugar, el riesgo implica elección, y la incertidumbre que entraña esta. Cuando se considera el riesgo en el contexto de la ingeniería de software, los tres pilares de Charette se hacen continuamente evidentes. Es indiscutible que están presentes permanentemente las características de incertidumbre (acontecimiento que caracteriza al riesgo y que puede o no ocurrir) y de pérdida (si el riesgo se convierte en una realidad ocurrirán consecuencias no deseables o pérdidas).

1 ROPPPONEN, J.; LYYTINEN, K. (2000). Components of Software Development Risk: Hot to address Them? IEEE transactions on software engineering.2 BOEHM, B. (1988). A Spiral Model of Software Development and Enhancement. IEEE Computer. Vol. 21, # 5. 3 PRESSMAN, Roger S. (2002). Ingeniería de Software. Un enfoque práctico. Quinta edición. McGraw-Hill. 4 CHARETTE, R. N. (1989). Software Engineering Risk Analysis and Management. McGraw-Hill.

1.3.2. Categorías de riesgos

Están definidas las categorías de riesgos: los riesgos del proyecto, que amenazan el plan; los riesgos técnicos, que amenazan la calidad y la planificación temporal; y los riesgos del negocio, que amenazan la viabilidad del proyecto o del producto. Otra categorización a considerar a partir del conocimiento que se tenga de ellos: los riesgos conocidos (los que se descubren en las evaluaciones); los riesgos predecibles (se extrapolan de la experiencia) y los riesgos impredecibles (pueden ocurrir, pero es muy difícil identificarlos de antemano).

1.3.3. Estrategias frente al riesgo

También son claras las estrategias frente al riesgo. Por un lado están las reactivas, cuyo método es evaluar las consecuencias del riesgo cuando este ya se ha producido (ya no es un riesgo) y actuar en consecuencia. Este tipo de estrategias acarrea consecuencias negativas, al poner el proyecto en peligro. Y por el otro las preactivas, que aplican el método de evaluación previa y sistemática de los riesgos y sus posibles consecuencias, a la par que conforman planes de contingencias para de evitar y minimizar las consecuencias. Consecuentemente, este tipo de estrategias permite lograr un menor tiempo de reacción ante la aparición de riesgos impredecibles.

De acuerdo con (Pressman, 2002), la administración o gestión de riesgos es un proceso iterativo que se aplica durante todo el proyecto y se desarrolla en cuatro etapas. Los resultados de la administración de riesgos deben ser documentados en un plan de administración de riesgos. La figura 1.4 refleja el procedimiento.

edu.red

Figura 1.4: Procedimiento de gestión de riesgos.

1.4. Los procesos de apoyo organizacional: SCM y SEPG

A continuación se describen los siguientes procesos de apoyo organizacional: SCM Software Configuration Management y SEPG Software Engineering Process Group.

1.4.1. SCM – Software Configuration Management

SCM es la actividad que se aplica durante todo el proceso, desde el inicio del proyecto hasta que el mismo esté fuera de uso. Comprende básicamente la administración de cambios y control de versiones. Está orientada a identificar el cambio, controlar el cambio, garantizar su correcta implementación e Informar el mismo a los interesados.

1.4.1.1. Qué involucra SCM

A continuación se describen las actividades que involucra SCM:

a) Identificación de los artifacts.1

Esta actividad responde el siguiente interrogante ¿Qué componentes quiero administrar?

– Objetos básicos: es un sólo deliverable.

– Objetos compuestos: se incluyen varios deliverables.

– Interrelaciones entre objetos.

– Evolución del objeto.

b) Control de cambios.

Procedimientos humanos y automáticos para el control de cambio, a continuación se describen el ciclo de vida de un cambio:

– Solicitud de cambio,

– evaluación,

– ejecución,

– control; y,

– nueva versión.

Debe asegurarse:

– Control de accesos: quiénes pueden modificar los componentes

– Control de sincronización: que no se pierdan cambios porque más de un recurso hace modificaciones sobre un mismo componente.

c) Configuración del software.

Es toda la información producida a lo largo del ciclo de vida. Pone énfasis en los cambios y presta especial atención a los cambios que se producen en un único deliverable.

d) Línea base.

Cualquier deliverable revisado y aprobado formalmente (está en la línea base) solo puede ser modificado bajo un procedimiento formal de "control de cambios".

e) Control de versiones.

Permite especificar configuraciones alternativas del SW mediante la selección de versiones adecuadas. Una nueva versión se define cuando se realizan cambios significativos en uno o más objetos. Existen herramientas de control de versiones que guardan la versión original más los cambios (deltas).

f) Auditoría de la configuración.

Debe asegurarse que el cambio ha sido implementado correctamente y debo saber en qué estado está cada componente.

g) Informes de estado.

Los informes de estado responden los siguientes interrogantes:

– ¿Cuándo se realizó el cambio?

– ¿Dónde se cambió un componente?

– ¿Quién es el autor del cambio?

– ¿Qué se cambió?

– ¿Cuál es el alcance del cambio?

h) Cambio – Cambiando el ciclo de vida.

A medida que se avanza a lo largo del ciclo de vida se debe poder restringir que tipo de cambios se puede realizar sobre el software. El ciclo de vida determina dos aspectos que influyen sobre el plan de SCM: cantidad de versiones que deberé administrar y etapas durante las cuales aceptaré sean efectuados cambios sobre el producto en sí.

La rigidez de los controles será directamente proporcional al avance del proyecto en la fase. A medida que se acerca al final de la fase, se debe estar acercando a tener algún entregable listo (versión). Esto hace que las restricciones para modificar el software sean incrementadas para asegurar que no existan desvíos, solo los cambios de urgencia o muy bien justificados tendrán lugar en esta etapa. De la misma manera, en ciclos de vida con un alto grado de prototipación, se hará énfasis en la auditoría en lugar de restringir que el equipo pueda modificar el producto.

1 Cualquier elemento de un producto de software que esté sujeto a cambios. Esto incluye código fuente, documentación, QA test plans, QA data, librerías, código objeto, etc. También es conocido en la terminología traducida que encontramos como "ítem de configuración".

1.4.1.2. Actividades esenciales de SCM

A continuación, se listan las actividades básicas de SCM:

– Identificar y almacenar artifacts en un repositorio seguro.

– Controlar y auditar cambios sobre los artifacts.

– Organizar artifacts en forma de componentes "versionados".

– Crear baselines para cada milestone (puntos de control) del proyecto.

– Registrar y hacer seguimiento a change requests.

– Organizar e integrar conjuntos consistentes de versiones a través de actividades.

– Mantener espacios de trabajo consistentes y estables.

– Soportar cambios concurrentes sobre artifacts.

– Integrar en forma temprana y frecuente.

– Asegurar que sea posible reproducir construcciones de software.

1.4.2. SEPG – Software Engineering Process Group

Es el punto focal de la organización de las actividades de mejora de procesos de software. Estas personas desarrollan principalmente las siguientes actividades: Realizan evaluaciones de la capacidad de organización, desarrollar planes para implementar las mejoras necesarias, coordinar la ejecución de esos planes, y medir la eficacia de estos esfuerzos. SEPGs exitosos requieren habilidades y conocimientos especializados de muchas áreas fuera de la ingeniería de software tradicional.1

1 FOWLER, Priscilla; RIFKIN, Stanley. (1990). Software Engineering Process Group Guide. CMU/SEI-90-TR-024. Carnegie Mellon University. Enlace web: http://www.sei.cmu.edu/library/abstracts/reports/90tr024.cfm. [Leído: 20 de enero 2010, 12.00 h GMT+1].

1.4.2.1. Actividades SEPG

Las siguientes son algunas de las actividades del grupo de procesos de Ingeniería de software:1

– Obtiene y mantiene el apoyo de todos los niveles de gestión.

– Facilita la evaluación de los procesos de software.

Partes: 1, 2

Página siguiente