Monografias.com > Computación > Software
Descargar Imprimir Comentar Ver trabajos relacionados

Procesos de software



Partes: 1, 2

  1. Presentación
    de la asignatura
  2. Objetivos
  3. Conceptos y
    características esenciales de un proceso de
    software
  4. Proceso de negocio
    de software versus proceso de software de
    negocio
  5. La calidad y el
    riesgo como ejes del proceso
  6. Los procesos de
    apoyo organizacional: SCM y SEPG
  7. Herramientas CASE y
    entornos de trabajo
  8. Modelos de procesos
    de software y de mejorar de calidad

Presentación de la
asignatura

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.

Monografias.com

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:

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.

Monografias.com

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.

Monografias.com

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.

Monografias.com

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.

– Trabaja con los gerentes de línea, cuyos
proyectos se ven afectados por cambios en las prácticas de
ingeniería de software, proporcionando una amplia
perspectiva de los esfuerzos de mejora y ayudarles a fijar las
expectativas.

– Mantiene relaciones de
colaboración de trabajo con los ingenieros de
software, especialmente para obtener, planificar, e
instalar nuevas prácticas y tecnologías.

– Los arreglos para cualquier
capacitación o educación continua relacionados con
mejoras en el proceso.

– Pistas, monitores, y los informes sobre
el estado de los esfuerzos de mejora en particular.

– Facilita la creación y
mantenimiento de las definiciones de procesos, en
colaboración con los directores y el personal de
ingeniería.

– Mantiene una base de datos de
proceso.

– Proporciona consultoría de
procesos para proyectos de desarrollo y de
gestión.

1 Software Engineering
Institute
. Carnegie Mellon. (2010). Software Engineering
Process Group
Guide. [en
línea].

Enlace web:
http://www.sei.cmu.edu/library/abstracts/reports/90tr024.cfm.
[Leído: 20 de enero 2010, 14.00 h
GMT+1].

1.4.2.2. Enfoques SEPG

Cada SEPG tiene un enfoque y misión
diferente. A continuación se describen algunos:

– "Trabajo" SEPG de que realmente
desarrollar e implementar el proceso como un tipo de equipo de
consultores internos.

– "Supervisión" SEPG que
supervisará el proceso de La arquitectura, gestión
de cambios, y dar prioridad a él (una especie de proceso
de CCB).

– "Qué Deliberante" SEPG es el
enfoque de proceso de debate y desarrollo de estrategia para un
proceso de arquitectura y el despliegue.

– "Virtual" SEPG de que se componen de
representantes de toda la organización que dedicar una
cierta cantidad de tiempo para el esfuerzo y son responsables de
la implementación y la formación de todos los
demás en la organización.

Partes: 1, 2

Página siguiente 

Nota al lector: es posible que esta página no contenga todos los componentes del trabajo original (pies de página, avanzadas formulas matemáticas, esquemas o tablas complejas, etc.). Recuerde que para ver el trabajo en su versión original completa, puede descargarlo desde el menú superior.

Todos los documentos disponibles en este sitio expresan los puntos de vista de sus respectivos autores y no de Monografias.com. El objetivo de Monografias.com es poner el conocimiento a disposición de toda su comunidad. Queda bajo la responsabilidad de cada lector el eventual uso que se le de a esta información. Asimismo, es obligatoria la cita del autor del contenido y de Monografias.com como fuentes de información.

Categorias
Newsletter