Repblica Bolivariana de Venezuela

Ministerio del Poder Popular para la Educacin Universitaria

Universidad Politcnica Territorial del Oeste de Sucre Clodosbaldo Russin
Cuman Estado Sucre
Programa Nacional de Formacin en Informtica

Unidad Curricular Gestin de Proyectos Informticos

Unidad I.- Proceso de Administracin del Proyecto

Facilitador:
Ing Leonardo J. Malav Q. MSc.

Cuman, Agosto - Septiembre de 2014

Contenido de la Unidad I

1. Administracin de proyectos.
Plan de desarrollo de software.
Plan de fase.
Plan de iteracin.
2. Administracin del riesgo:
Identificacin de riesgos: Lista de riesgo.
Evaluacin del riesgo.
Plan de Administracin de riesgo.
Seguimiento.
3. Administracin y configuracin del cambio.
4. Configuracin del entorno de desarrollo.

Unidad I
1.- Administracin de proyectos.

a.- Proyecto:

Conjunto de actividades, planificadas, ejecutadas y supervisadas que,

con recursos finitos, tienen como objetivo crear un producto o servicio
nico (Morillo, 2002)

Conjunto de actividades planificadas, ejecutadas y supervisadas con el

fin de alcanzar un fin comn con recursos finitos (Maigua, 2012)

Unidad I
Conjunto de actividades concretas, interrelacionadas y coordinadas
entre s, que se realizan con el fin de producir determinados bienes y
servicios capaces de satisfacer necesidades o resolver problemas.
(Ander-Egg, 2007).

Conjunto de elementos o partes interrelacionadas en una estructura

diseada para lograr objetivos especficos. En algunos casos puede
referirse a un conjunto de recursos y etapas diseadas para resolver
problemas mediante procesos que se consideran adecuados. (Cerda,
2001).

Unidad I

Situacin Actual

Situacin Deseada

(Necesidades y
Demandas Actuales)

(Necesidades y
Demandas Satisfechas)

Proyecto
(Tecnologa de Informacin
y Comunicacin)

b.- Caractersticas:
Persecucin de uno o varios objetivos

Actividades planificadas, ejecutadas y supervisadas

Disponibilidad limitada de recursos

Limitacin temporal

Resultados nicos

c.- Importancia del Desarrollo del Proyecto :

1. Permite proporcionar espacios de encuentros y aprendizajes

2. Facilitar como usar las herramientas que le permitan el acceso a la

informacin, como mecanismo de apropiacin social del conocimiento,
con apoyo en las tecnologas de comunicacin e informacin.

3. Permite reconocer los principios y valores de orientacin tecnolgica,

social, organizacional; identificacin de los elementos constitucionales,
filosficos y legales, que conllevan a la transformacin y ser capaces de
proporcionar soluciones acertadas a un determinado problema o
temtica.

d.- Etapas de un Proyecto :

DIAGNSTICO
Implica conocer los problemas de nuestra realidad con incorporacin
activa de todos los sujetos.

FORMULACIN y PLANIFICACIN
Preparar las acciones para atender o abordar los problemas.
EJECUCIN
Realizar las acciones planificadas.
EVALUACIN
Valorar las acciones que hemos realizado.
SISTEMATIZACIN
Reconstruir las experiencias de todo el proceso de trabajo y presentarlas.

e.- Preguntas que debe responder un Proyecto

Dnde?
Localizacin
Para quienes?
Beneficiarios
Quines?
Equipo responsable

Por qu y para qu?

Justificacin
Cmo?
Actividades y
Procedimientos
Cundo?
Cronograma

Qu?
Denominacin y
Objetivos

Con qu?
Presupuesto

f.- Tipos de Proyectos:

Tcnicos y no
tcnicos

Uni y multi

Mono y multi

Mono o multi

disciplinares

contrato.

personales

Tangibles o
Intangibles

Rentabilidad
Econmica o
Rentabilidad
Social

Proyectos
Espaciales

Proactivos y
Reactivos

Internos o
Externos

Mayor o
Menor
envergadura

Inversin
Propia o
Externa
(Privada o
Pblica) o
Mixta

Investigacin
y Desarrollo

h.- Tipos de Proyectos Informticos:

Software (o Metodologas, Ingeniera del software, etc; Software empotrado.)
Hardware (Velocidad de Proceso, S.O., Servicios, etc.; )
Comunicaciones y Redes (Protocolos, Buses, Cableado, etc.)
Instalaciones de Hardware (Peso de los equipos, Instalacin de aire acondicionado,
Suelo flotante, Extincin de incendios, Conectividad externa, etc.; CPDs, Sites de
Internet, etc.)
Sistemas de Misin Crtica (o Industrial, Mdica, Nuclear, Militar, Aeronutica, etc.; o
Tiempo real, Esquemas productivos, etc.)
Auditoras (o Sistemas, Seguridad, Calidad, Legislacin )
Peritajes (o Civiles, Penales, Laborales)
Consultora y Asesora (o Sobre cualquier actividad.)
Seguridad Informtica (ISO 17799) (o Seguridad de la Informacin.)
Reingeniera de Proyectos

i.- Proyecto Informtico:

Un Proyecto Informtico es un sistema de cursos de acciones

simultneas y/o secuenciales que incluye personas, equipamientos de
hardware, software y comunicaciones, enfocadas en obtener uno o ms
resultados deseables sobre un sistema de informacin. (Maigua, 2002)

j.- Gestin de Proyectos

Es un proceso continuo. Este proceso requiere de una estrategia global,
apoyada por herramientas de trabajo que incrementen la productividad.
El propsito de planificar y controlar es proveer una propuesta uniforme
para el desarrollo y la administracin de los proyectos. Los planes deben
apoyar los niveles estratgicos, tcticos y operacionales de las
organizaciones con el fin de alcanzar las metas corporativas de largo,
mediano y corto plazo.
A travs del ciclo de vida de un proyecto, se conforman dos categoras
de actividades a realizar y que se encuentran directamente
relacionadas: las actividades de gestin y las actividades de desarrollo
del sistema.

Actividades de Gestin

Relacionadas con la Administracin

Personas, organizaciones, sistemas

procedimientos
Planificacin y construccin del sistema

Trabaja en conjunto con las actividades de

desarrollo (estimadas, programadas y
ejecutadas)

Actividades de Desarrollo

Centradas en el desarrollo del mismo

Agrupadas en distintas fases

2
3

Agrupadas en reas funcionales de estudio,

diseo y construccin

Basada en una estructura

particin del trabajo

de

j.- Pasos en la Gestin de Proyectos

Incluye las 4 P (Personal, Producto, Proceso y Proyectos)
El personal debe organizarse para realizar el trabajo de software de
manera efectiva. La comunicacin con el cliente y con otros
participantes debe ocurrir de modo que el mbito del producto y los
requerimientos sean comprensibles. Debe seleccionarse un proceso que
sea adecuado para el personal y el producto. El proyecto debe
planificarse, estimndose el esfuerzo y el cronograma necesarios para
concluir

las

tareas:

definicin

de

los

productos

operativos,

establecimiento de los puntos de verificacin de calidad, identificacin

de mecanismos para monitorear y control del trabajo definido por el
plan.

Personal

El People-CMM define las siguientes reas prcticas claves para el

personal de software: plantilla, comunicacin y coordinacin, ambiente
de trabajo, desempeo administrativo, capacitacin, compensacin,
anlisis y desarrollo de competencias, desarrollo profesional, desarrollo
de grupo de trabajo y desarrollo de equipo/cultura, entre otros. Las
organizaciones que conforme a este modelo logran altos niveles de
madurez de capacidades de personal tienen una probabilidad muy
elevada de alcanzar la implementacin de prcticas administrativas
efectivas en los proyectos de software.

Producto
Antes de poder planear un proyecto, deben establecerse los objetivos y
el mbito del producto, considerarse soluciones alternativas e identificar
las restricciones tcnicas y administrativas. Sin esta informacin, es
imposible definir estimaciones razonables (y precisas) del costo, una
valoracin efectiva del riesgo, una descomposicin realista de las tareas
del proyecto y un calendario de proyecto manejable que proporcione en
cada momento un indicio significativo del progreso.
Como desarrolladores de software, todos los participantes deben
reunirse para definir los objetivos y el mbito del producto. En muchos
casos, esta actividad comienza como parte de la ingeniera del sistema o
de la ingeniera del proceso empresarial y contina como el primer paso

en la ingeniera de requerimientos del software. Los objetivos

identifican las metas globales para el producto (desde el punto de vista
de los participantes) sin considerar cmo se lograrn estas metas. El
mbito identifica los datos, funciones y comportamientos principales
que caracterizan al producto y, ms importante, intenta ligar dichas
caractersticas en forma cuantitativa.
Una vez comprendidos los objetivos y el mbito del producto, se
consideran soluciones alternativas. Aunque se analizan muy pocos
detalles, las alternativas permiten a los gerentes y profesionales
seleccionar un mejor enfoque, dadas las restricciones impuestas por
fechas de entrega, restricciones presupuestales, disponibilidad de
personal, interfaces tcnicas y muchos otros factores.

Proceso

Un proceso de software proporciona el marco conceptual desde el cual

puede establecerse un plan completo para el desarrollo de software. Un
pequeo nmero de actividades de marco conceptual se aplica a todos
los proyectos de software, sin importar su tamao o complejidad.
Algunos conjuntos de diferentes tareas (tareas, hitos, productos
operativos y puntos de aseguramiento de calidad) permiten que las
actividades del marco conceptual se adapten a las caractersticas del
proyecto de software y a los requerimientos del equipo del proyecto.

Proceso

Finalmente, las actividades sombrilla (como el aseguramiento de la

calidad del software, la administracin de configuracin del software y
las mediciones) recubren el modelo de proceso. Las actividades
sombrilla son independientes de cualquier actividad del marco
conceptual y ocurren a lo largo del proceso.

Producto
Los proyectos de software se planean y controlan debido a una razn
principal: es la nica forma conocida para manejar la complejidad. E
incluso as, los equipos de software todava batallan. En un estudio de
250 grandes proyectos de software desarrollados entre 1998 y 2004,
Capers Jones [Jon04] encontr que alrededor de 25 se consideraron
exitosos por haber logrado sus objetivos de calendario, costo y calidad.
Aproximadamente 50 tuvieron demoras o excesos por abajo de 35 por
ciento, mientras que ms o menos 175 experimentaron grandes
demoras y excesos, o se dieron por concluidos sin completarse. Aunque
actualmente la tasa de xito para los proyectos de software puede
haber mejorado un poco, la tasa de falla de proyecto sigue siendo

Producto

mucho ms alta de lo que debiera. Para evitar el fracaso del proyecto,

un gerente de proyecto de software y los ingenieros de software que
construyan el producto deben evitar un conjunto de seales de
advertencia comunes, entender los factores de xito cruciales que
conducen a una buena administracin del proyecto y desarrollar un
enfoque de sentido comn para planificar, monitorear y controlar el
proyecto.

k.- Planes
Plan de desarrollo de software.
Plan de fase.
Plan de iteracin.
Ejemplos

2.- Administracin del riesgo

Identificacin de riesgos: Lista de riesgo.
Evaluacin del riesgo.
Plan de Administracin de riesgo.
Seguimiento.

a.- Objetivos de la Gestin de Riesgos

Identificar, analizar y cuantificar posibles riesgos que puedan
aparecer durante el desarrollo de un proyecto software.

Desarrollar respuestas adecuadas para los posibles riesgos.

Monitorizar el transcurso de un proyecto para evaluar el estado de

los riesgos y actuar en consecuencia.

b.- Identificacin de Riesgos

Riesgo:

Evento o circunstancia cuya probabilidad de ocurrencia es

incierta, pero que, en caso de aparecer, tiene un efecto (positivo o

negativo) sobre los objetivos de un proyecto.

Riesgo: Probabilidad de que una circunstancia adversa ocurra.

Exposicin al Riesgo:

Prob ocurrencia riesgo x Prdida asoc estimada

b.- Identificacin de Riesgos

Influencia Riesgo:

( ERantes ERdespues )
CostoAccion Re ductora

b.- Identificacin de Riesgos

Plan de Gestin de Riesgos:

Descripcin de responsabilidades y

actividades relacionadas con la Gestin de Riesgos.

Organigrama para la gestin de riesgos.

Proceso de identificacin y anlisis de riesgos.
Herramientas y tcnicas a utilizar.
Taxonomas de riesgos a utilizar.
Plantillas estandarizadas para la identificacin y gestin de riesgos
(Registro Riesgos).
Actividades de control de riesgos y periocidad de las mismas.

c.- Tcnicas de Identificacin de Riesgos:

Revisin de la documentacin existente

Revisin planificacin y estimaciones.
Tormenta de ideas.
Juicio Experto: Tcnica Delphi.
Taxonomas de riesgos.
Anlisis FODA
Diagrama de Ishikawa

Taxonoma de Riesgos:

Registro de Riesgos:

Registro de Riesgos:

Anlisis Cualitativo de Riesgos:

Tcnicas de Anlisis Cualitativo de Riesgos:

Juicio experto.

Tablas de impacto.

Matrices de probabilidad e impacto.

Agrupacin por causas.

Agrupacin por prioridad temporal.

Tabla de Impacto

Matriz de Probabilidad de Impacto

Anlisis Cuantitativo de Riesgos

Tcnicas de Anlisis Cuantitativo de Riesgos:

Obtencin de datos estadsticos descriptivos.
Distribuciones de Probabilidad

Juicio experto.

Anlisis de Sensibilidad (Diagramas de Tornado)

Anlisis de Valor Esperado + rboles de Decisin

Modelo y Simulacin (Montecarlo)

Diagrama de Tornado

rboles de Decisin

Plan de Respuesta al Riesgo

Tcnicas de Respuestas al Riesgo

Evitar el riesgo (ej. personal reemplazable).
Transferir el riesgo (ej. contratar seguro devaluacin moneda).

Atenuar el riesgo (ej. comprar un mejor servidor web).

Aceptacin pasiva, no se hace nada.

Aceptacin activa, se hace reserva de contingencia (ej. Cancelacin

vuelos).

Control de Riesgos

Objetivos del Control de Riesgo

Actualizar el registro de riesgos conforme avanza el proyecto,
identificando, analizando nuevos riesgos que pudiesen emerger,
elaborando nuevas respuestas para tales riesgos.

Comprobar si han materializado alguno de los riesgos identificados; y si

fuese as, ejecutar los correspondientes planes de respuesta.

Realizar el seguimiento de los planes de respuesta en ejecucin.

Administrar el fondo de reserva para contingencias.

3.- Administracin y configuracin del cambio

La Gestin del Cambio es una disciplina que apoya directamente el
desarrollo y mantenimiento del software, mediante la conservacin de
la integridad del producto antes y despus de su puesta en produccin.

El cambio es inevitable cuando se construye software, aumenta el grado

de confusin entre los ingenieros de software que trabajan en un
proyecto. La confusin surge cuando los cambios:

(a) No se analizan antes de realizarlos (b) No se registran antes de implementarlos

(c) No se reportan a quienes deben saberlo (d) No se controlan de forma que mejore la
calidad y reduzca el error.

La Gestin del Cambio es llamada usualmente Gestin de la

Configuracin del Software (GCS o GC). Se debe de tener muy claro lo
que es Soporte y Gestin de la Configuracin.

Soporte: Conjunto de actividades de ingeniera del software que

ocurren despus de que ste se ha entregado al cliente y ha sido puesto
en operacin.

Gestin de la configuracin del software: Conjunto de actividades de

seguimiento y control que se inician cuando empieza un proyecto de
ingeniera del software y terminan slo cuando ste se retira de
operacin.

La Gestin de la Configuracin del Software es un conjunto de

actividades desarrolladas para gestionar los cambios a lo largo del ciclo
de vida. La GCS es una actividad de garanta de calidad de software que
se aplica en todas las fases del proceso de ingeniera del software.
El resultado del proceso de ingeniera del software es una informacin
que se puede dividir en tres amplias categoras:
1.

Programas de computadora (tanto en forma de cdigo fuente como ejecutable)

2.

Documentos que describen los programas (manuales tanto tcnicos como de

usuario)

3.

Estructuras de datos (contenidas en el programa o externas a l).

Estos resultados son elementos que se denominan colectivamente

configuracin del software.

Origen de los Cambios

Nuevas condiciones en el negocio o mercado (cambios en los requisitos del producto

o reglas del negocio)

Nuevas necesidades del cliente (modificacin de los datos que producen los
sistemas, funcionalidad que entregan los productos o los servicios)

La reorganizacin o el crecimiento o reduccin del negocio (cambios en las

prioridades del proyecto o estructura del equipo de ingeniera del software)

Restricciones presupuestales o de calendarizacin (redefinicin del sistema o

producto)

Escenario Tpico de la GCS

Elementos de un Sistema de GCS

Componentes: conjunto de herramientas acopladas dentro de un sistema de gestin
de archivos (ej.: Base de datos), permiten el acceso y la gestin de cada elemento de
configuracin del software

Proceso: serie de procedimiento y tareas que definen un enfoque eficaz con el cual
gestionar el cambio

Construccin: conjunto de herramientas que automatizan la construccin del software

al asegurar que se ha ensamblado un conjunto adecuado de componentes validados

Humanos: la implementacin de una GCS eficaz requiere que el equipo de software

utilice un conjunto de herramientas y caractersticas de procesos

Lnea Base
Se definen como un punto del ciclo de vida del software en el cual se aplica el control
de configuraciones a un elemento especfico de la configuracin. Es un concepto de
gestin de la configuracin del software que nos ayuda a controlar los cambios sin
impedir seriamente los cambios justificados. El IEEE define una lnea base como: Una
especificacin o producto que se ha revisado formalmente y se est de acuerdo con
los resultados, y que a partir de ah sirve como la base para el desarrollo ulterior y que
puede cambiarse slo por medio de procedimientos formales de control de cambio.
Antes de que un elemento de configuracin del software se convierta en lnea base, es
posible realizar el cambio rpida e informalmente. Sin embargo, una vez establecida
una lnea base, metafricamente se pasa a travs de una puerta giratoria de una sola
direccin. Si los pasos sucesivos generan cambios en el documento despus de una
lnea base, se requerir una revisin formal y una justificacin de todas las
modificaciones del documento (control de cambios).

Lnea Base

Elementos de Configuracin de ECS

Un elemento de configuracin del software (ECS) es la informacin que se crea como
parte del proceso de ingeniera del software. Un ECS es un documento, un conjunto
completo de casos de prueba o un componente de un programa dado. Los ECS estn
organizados para formar objetos de configuracin susceptibles de catalogar en la base
de datos del proyecto con un solo nombre. Un objeto de configuracin tiene un
nombre, atributos y est conectado con otros objetos por medio de relaciones. Los
siguientes ECS son el objeto de las tcnicas de gestin de configuraciones y forman un
conjunto de lneas base:

Elementos de Configuracin de ECS

1. Especificacin del sistema
2. Plan del proyecto software
3.
a. Especificacin de requerimientos del software
b. Prototipo ejecutable o en papel
4. Manual de usuario preliminar
5. Especificacin de diseo:
a. Diseo preliminar
b. Diseo detallado
6. Listados del cdigo fuente
7.
a. Planificacin y procedimiento de prueba
b. Casos de prueba y resultados registrados

Elementos de Configuracin de ECS

8. Manuales de operacin y de instalacin

9. Programas ejecutables
10. Manual de usuario
11. Documentos de mantenimiento
a. Informes de problemas del software
b. Peticiones de mantenimiento
c. rdenes de cambios de ingeniera
12. Estndares y procedimientos de ingeniera del software

Depsito de ECS

Al inicio de la ingeniera del software los elementos de configuracin

eran documentos de papel que se almacenaban fsicamente, esto dio
muchos problemas: difcil de encontrar; no saber realmente cul
elemento fue cambiado, cundo y por quin; la construccin de nuevas
versiones consuma mucho tiempo y era proclive al error; etc. En la
actualidad, los ECS se conservan en una base de datos o depsito del
proyecto.

Depsito de ECS

Al inicio de la ingeniera del software los elementos de configuracin

eran documentos de papel que se almacenaban fsicamente, esto dio
muchos problemas: difcil de encontrar; no saber realmente cul
elemento fue cambiado, cundo y por quin; la construccin de nuevas
versiones consuma mucho tiempo y era proclive al error; etc. En la
actualidad, los ECS se conservan en una base de datos o depsito del
proyecto. El depsito ECS es el conjunto de mecanismos y estructuras de
datos que permiten que el equipo de software maneje el cambio en una
manera eficaz.

Caractersticas de GCS

El apoyo a la GCS requiere que el almacn o depsito debe tener un

conjunto de herramientas que ofrezca soporte para las siguientes
caractersticas:

Versiones: Debe ser capaz de guardar todas las versiones para

permitir la gestin eficaz de las liberaciones de producto y permitir que
los desarrolladores regresen a versiones anteriores.

Gestin del seguimiento de la dependencia y del cambio: El depsito

gestiona las relaciones entre los objetos de configuracin que guarda. Es

Caractersticas de GCS

crucial la habilidad con que se da seguimiento a estas relaciones, para la

integridad de la informacin y la generacin de productos basados en
ella.
Seguimiento de requisitos: Habilidad de seguir todos los
componentes, entregables de diseo y construccin que resulten de una
determinacin especfica de requisitos; tambin debe identificar qu
requisitos generaron algn producto de trabajo dado.

Caractersticas de GCS

Gestin de la configuracin: Facilita la conservacin de una serie de

configuraciones que representan hitos del proyecto o liberaciones de
produccin.

Rutas de auditoria: Informacin adicional acerca de cundo, por qu y

por quin se hicieron los cambios.

Proceso de GCS

Identificar los elementos que colectivamente definen la configuracin

del software

Gestionar los cambios a uno o ms de dichos elementos

Facilitar la construccin de diferentes versiones de una aplicacin

Garantizar que la calidad del software se conserva conforme la

configuracin evoluciona a lo largo del tiempo

Tareas de la GCS
Identificacin de objetos en la configuracin del software
Esta tarea de identificacin establece estndares de documentacin y
un esquema de identificacin de documentos. El control y la gestin de
elementos de configuracin del software requieren:
1. Nombrar cada uno de los elementos por separado
2. Organizarlo mediante un enfoque orientado a objetos
Es posible identificar dos tipos de objetos:
1. Bsicos: Unidad de informacin creada durante: anlisis, diseo,
cdigo o pruebas.
2. Agregados: Es un mecanismo para representar una versin completa
de una configuracin de software.

Cada objeto o elemento tiene un conjunto de caractersticas distintivas

que lo identifican de manera exclusiva:

1. Identificador (nmero, letra, ambos. No ambiguo)

2. Nombre (descriptivo)
3. Tipo (documento, cdigo, producto de terceros, etc.)
4. Localizacin
5. Fecha
6. Versin (mayor, menor, revisin)
7. Estado (Ej. Para un documento En elaboracin, finalizado, revisado,
aceptado)
8. Proyecto/producto

Control de la Versin
Combina procedimientos y herramientas para gestionar diferentes
versiones de objetos de configuracin que se crean durante el proceso
del software. Un sistema de control de la versin implementa cuatro
grandes capacidades:
1. Base de datos del proyecto: guarda los objetos de configuracin
relevantes.
2. Capacidad de gestin de la versin: almacena todas las versiones de
un objeto de configuracin.
3. Facilidad de hechura que permita al ingeniero de software recopilar
todos los objetos de configuracin relevantes y construir una versin
especfica del software.

Control de la Versin

4. Seguimiento de conflictos: permiten al equipo registrar y hacer

seguimiento del estado de todos los conflictos destacados asociados
con cada objeto de configuracin.

Control del Cambio

Es la evaluacin y registro de todos los cambios que se hacen
durante la configuracin del software. El cambio debe ser aceptado por
la Autoridad de control del cambio (ACC), los mismos que van a
determinar el impacto y categora del cambio; es necesario clasificar el
cambio de acuerdo a la prioridad y categora para su correcto
procesamiento. Cuando un cambio ha sido aprobado se genera una
orden de cambio en la ingeniera (OCI). La OCI describe el cambio que se
debe realizar, las restricciones y los criterios de revisin y auditoria. La
ACC puede estar compuesta de una persona (el gestor del proyecto) o
varias personas (representantes de hardware, software, ingeniera de
bases de datos, soporte, mercadotecnia).

Auditora de la Configuracin
La

auditoria

garantiza

que

el

cambio

se

ha

implementado

correctamente. Cmo se puede garantizar que el cambio se ha

implementado con propiedad?
A travs de:
Revisiones tcnicas formales: correccin tcnica del objeto de
configuracin que se ha modificado; se la debe realizar en casi la
mayora de los cambios triviales.
Auditoria de la configuracin del software: complementa la revisin
tcnica formal.
Cuando la GCS es una actividad formal, la auditoria la lleva a cabo por
separado el grupo de aseguramiento de la calidad.

Informe de Estado
El informe de estado de la configuracin (IEC), es tambin llamado
contabilidad de estado. El IEC es una tarea de GCS que responde las
siguientes interrogantes:
Qu ocurri?
Quin lo hizo?
Cundo ocurri?
Qu otra cosa ser afectada?
Al asignarse una identificacin nueva a un ECS se efecta una entrada
de IEC. Cada vez que la ACC aprueba un cambio (se expide una OCI) se
genera una entrada en el IEC. Al realizarse una auditoria los resultados
se reportan como parte de la tarea de IEC.

Informe de Estado

Razones de la Resistencia al Cambio

Razones de la Resistencia al Cambio

Este programa no haca lo que el anterior.

Este programa es ms difcil.
No puedo trabajar con este software le falta la direccin a la factura
no puedo seguir trabajando.
Simplemente no funciona.
Esto est lleno de problemas.
Esto no es lo que nos vendieron

4.- Configuracin del Entorno de Desarrollo

Entorno se refiere al contexto dentro del cual se desarrolla una
determinada actividad, o tambin a la combinacin de instrumentos
utilizados. El entorno de desarrollo software, SEE, cuenta con una serie
de tcnicas de automatizacin denominadas CASE.
Las primeras herramientas se referan a la fase de codificacin, as el
entorno de programacin clsico consiste en un compilador con editor,
montador de enlaces, etc. Posteriormente con el empleo del trmino
CASE se ha extendido la automatizacin a las fases de anlisis y diseo.
Para las pruebas de integracin se puede disponer de herramientas de
ensayo y para la fase de mantenimiento se dispone de soporte de
gestin de configuracin, que incluye la gestin de versiones y el control

4.- Configuracin del Entorno de Desarrollo

de cambios.
El futuro de las tcnicas CASE est en el soporte completo de todo el
ciclo de vida. Se ha denominado IPSE, ICASE e ISEE.
Formas de Organizacin:
En cadena, se combinan una serie de herramientas de manera que
la salida de cada una es la entrada de la siguiente. Ej.: editorcompilador-montador
Con

repositorio,

las

herramientas

integradas

guardan

su

informacin en este almacn comn. Una parte del repositorio es el

diccionario de datos
Como una nica herramienta global, capaz de realizar todas las

4.- Configuracin del Entorno de Desarrollo

operaciones necesarias.
Dar soporte a la programacin en un lenguaje concreto
Dar soporte a una metodologa de desarrollo
Ayudar al desarrollo de entornos de desarrollo (meta-entornos)
CLASIFICACIN, desde un punto de vista pragmtico:
ENTORNOS ASOCIADOS A UN LENGUAJE. Un primer paso lo
constituyen los intrpretes de los lenguajes de programacin
interactivos (BASIC, LISP, SmallTalk, ada).

ENTORNOS ASOCIADOS A ESTRUCTURA. En ellos se almacena la

informacin correspondiente al programa en forma estructurada y

4.- Configuracin del Entorno de Desarrollo

y no simplemente como texto. La edicin del programa se consigue
mediante un editor de estructura, que permite construir o modificar un
programa operando sobre los elementos de su estructura. El entorno se
basa en plantillas que describen las estructuras bsicas (PL/).
ENTORNOS BASADOS EN HERRAMIENTAS. Consisten en una
coleccin de herramientas (toolkit o toolbox) relativamente
independientes, aunque compatibles entre s, adems deben de
existir algn medio para hacerlas funcionar en forma combinada.
Suele presentar como ventaja el ser bastante abiertos, permitiendo
la incorporacin de nuevas herramientas. Su inconveniente es la
falta de una interfaz de usuario interactiva y uniforme.

ENTORNOS ASOCIADOS A UNA METODOLOGA. La integracin de

los distintos elementos del entorno se suele conseguir mediante el
empleo de un almacn nico o repositorio CASE para almacenar
todos los elementos de informacin contemplados en la
metodologa soportada. El repositorio contiene informacin de los
diagramas de flujo de datos, descripcin de cada dato y de cada
proceso.

ENTORNOS DE 4 GENERACIN. Se apoyan en un sistema de gestin

de base de datos dotado de un lenguaje de consulta con
herramientas complementarias.

Clasificacin de los Entornos por Niveles

Nivel de servicio. Corresponde a un producto que realiza una funcin u
operacin elemental, que una vez invocada no se interrumpe
(compilador).
Nivel de herramienta. Producto software que permite invocar
diferentes servicios u operaciones correspondientes a una misma
actividad individual. (editor de textos).
Nivel de banco de trabajo o equipo de herramientas. Corresponde a un
producto CASE que automatiza o soporta un perfil concreto de actividad
profesional dentro del proceso de desarrollo. Un banco de trabajo suele
englobar varias herramientas, integradas con una interfaz de usuario
uniforme. En la actividad de codificacin el banco de trabajo se.

Clasificacin de los Entornos por Niveles

denomina entorno de programacin.

Entorno de desarrollo. Producto CASE que soporta el proceso completo

de desarrollo de software (IPSE o ICASE).
Los dos primeros niveles se describen a veces como uno solo.

Herramientas de Software
Clsicas.
Editor de texto.
Compilador
Montador de enlaces. Construye ejecutables combinando varios
ficheros objeto.
Gestor de librera. Combina ficheros objeto en una librera.
Herramienta MAKE. Automatiza la actualizacin de los ficheros a
partir de otros.

Intrprete

interactivo.

Casi

Constituye

un

entorno

de

programacin completo (si lo es se debe clasificar a nivel de banco

de trabajo y no de herramienta). Engloba funciones equivalentes a

Herramientas de Software
compilacin, montaje y ejecucin.
Compilador/Intrprete. Procesador de un lenguaje interpretado
de forma no interactiva.Incluye un compilador a cdigo intermedio y
un intrprete de ejecucin de dicho cdigo intermedio con todas las
libreras de soporte. No incluye funciones de editor de programas.
Depurador absoluto. Ejecuta el programa de forma controlada.
Resulta incomodo de usar ya que hace referencia a posiciones de
memoria y a los registros del procesador.
Depurador simblico. Realiza una funcin anloga al anterior pero
con referencia al cdigo fuente por lo que es ms cmodo de usar.

Herramientas evolucionadas.
Editores orientados al lenguaje. Son editores de estructura.
Herramienta MAKE automtica. Se incorpora la funcin MAKE
al compilador.
Manejador de versiones. Almacena de forma organizada y
eficiente una serie de versiones del mismo elemento software. Se
suelen usar desde las utilidades MAKE al recompilar una aplicacin
en desarrollo.
Procesadores/Analizadores de cdigo fuente. Grupo en que se
pueden incluir diferentes herramientas que procesan el texto fuente
para obtener mediciones, generar tablas de referencias, encolumnar
etc. Estas funciones podran estar incorporadas en los compiladores

 Procesadores de documentos. No son especficos del desarrollo

pero son un soporte fundamental.
Herramientas de control de pruebas. Ayudan a la realizacin de
pruebas unitarias o de integracin.
Herramientas de control de cambios. Ayudan a la realizacin del
desarrollo y al mantenimiento de aplicaciones.
Procesadores de ficheros de texto.

Herramientas de 4 generacin.
Hojas de clculo. Procesadores de documentos
Gestores de bases de datos Lenguajes de 4 generacin.
Generadores de programas.

Entornos Integrados
Integracin de datos. Significa que la informacin almacenada en el
entorno es gestionada de manera uniforme, con independencia de las
transformaciones que se hagan con cada elemento de informacin.
Debe de conseguir:
Interoperatividad entre herramientas.
No redundancia de datos
Consistencia de datos.
Paso de datos de una herramienta a otra.
La integracin de datos puede conseguirse de diversas maneras:
Transferencia directa de datos de una herramienta a
otra. Eficiente pero poco flexible. Complicada para integrar muchas

herramientas diferentes.
Transferencia mediante ficheros. Es la ms sencilla. Existe un
formato normalizado (CDIF).
Transferencia basada en comunicacin. Alternativa a la anterior
y puede ser usada en sistemas distribuidos y en sistemas abiertos.
Repositorio comn. Se utiliza en los entornos modernos con un
grado de integracin elevado.

Integracin de control. Consiste en la combinacin flexible de funciones

para cumplir con las particularidades del proceso y actividades que hay
que informatizar. El mayor grado se consigue cuando desde una
herramienta se puede invocar funciones de otra herramienta. Exige

como paso previo la integracin de los datos.

Integracin de la presentacin. Trata de realizar la interaccin con el

usuario de manera uniforme, con cierta independencia dela funcin o
herramienta en uso. Para ello se deben conseguir los objetivos de un
sistema amigable:
Limitar el nmero de formas de interaccin diferentes.
Usar formas de interaccin y presentacin adecuadas al modelo
mental que el usuario tiene del entorno.
Satisfacer los tiempos de respuesta esperados y dar indicacin
del avance del proceso en caso de tratamiento de larga duracin.
Mantener informacin til a disposicin del usuario.

Integracin del proceso. Consiste en que las herramientas se combinan

de manera que apoyan o fuerzan el uso de una metodologa de
desarrollo definida. Este modo exige una buena integracin de control y
datos. El proceso de desarrollo puede definirse en base a los siguientes
elementos.
Un paso del desarrollo es una unidad de trabajo concreta que
produce un resultado (por ejemplo revisin del DDD).
Un suceso o evento es un condicin que ocurre durante la
ejecucin de un paso y que puede desencadenar la ejecucin de una
accin asociada (compilacin de un mdulo).
Una restriccin del desarrollo es una limitacin que debe
cumplirse.

Un buen grado de integracin del proceso exige que todo los pasos,
eventos y restricciones que definen de forma natural la metodologa de
desarrollo a utilizar, sean representables y tratables dentro del entorno.

Entornos Integrados: El Repositorio CASE

El repositorio CASE Es un almacn comn en el que se guarda toda la
informacin necesaria para la operacin de un grupo de herramientas o
de un entorno de desarrollo. El repositorio facilita las funciones de
almacenamiento y recuperacin de datos, normalmente en forma
concurrente multiusuario, y el mantenimiento de relaciones entre los
datos. Adems puede suministrar funciones de gestin de versiones, de
seguridad y de gestin de transacciones. Para proporcionar las

funciones de almacenamiento y recuperacin de datos se requiere:

Un servicio de metamodelo, que permita definir las estructuras de

datos que han de almacenarse en el repositorio.
Un servicio de consulta y actualizacin (query) que permita
acceder y manipular la informacin contenida en el repositorio.
Un servicio de vistas que permita definir subconjuntos de datos y
operaciones que constituyan el subentorno de trabajo de ciertas
actividades y entre los que haya que mantener relaciones concretas
de consistencia.
Un servicio de intercambio de datos, que facilite la importacin y
exportacin de informacin mediante ficheros externos.

Bancos o Equipos de Trabajo

Un banco de trabajo debe integrar las herramientas necesarias para dar
soporte a un determinado perfil profesional o actividad general de
desarrollo. Un banco de trabajo debe de conseguir:

Integracin de la presentacin
Integracin de control
Integracin de datos (preferentemente con repositorio comn).

Segn la actividad soportada, tendremos distintos bancos o equipos de

trabajo, entre ellos:

 Equipos de anlisis y diseo: Herramienta CASE o CASE

superior. Corresponde al entorno asociado a la metodologa. Muchos de
ellos cubren las dos fases (anlisis y diseo), mientras que otros slo
cubren una. El repositorio comn almacena todos los elementos
definidos en la metodologa soportada.
Entorno de programacin. Es el banco de trabajo para la
actividad de codificacin pudindose extender al diseo detallado y a
las pruebas de unidades.
Equipo de verificacin y validacin: Capaz de facilitar las
tareas de inspeccin y pruebas de mdulos y sistemas. Suelen estar
ligados al entorno de programacin. Pueden incluir funciones de:

 Anlisis esttico, con evaluacin de mtricas de calidad y

generacin de matrices o grafos de llamadas entre funciones y mdulos.
Generacin de tablas de referencias cruzadas.
Gestin de pruebas, automatizando la realizacin de ensayos.
Equipo de construccin de interfaz del usuario. Permite
definir cmodamente el esquema de dilogo con el usuario, as como
los elementos de interaccin.
Equipo de gestin de configuracin. Permite almacenar
diferentes versiones de los elementos del proyecto, definir distintas
configuraciones y controlar los cambios sucesivos.
Equipo de ingeniera inversa. Debe facilitar la extraccin de
informacin de diseo, los elementos abstractos a partir de un cdigo o

sistema software existente.

Equipo de gestin de proyectos. Facilita la confeccin de

planes de trabajo, con la asignacin de tiempos y recursos a diferentes
tareas, y el seguimiento de su realizacin.

Entornos Orientados a Objetos

Deben de ser capaces de soportar todas las actividades del ciclo de vida
de desarrollo siguiendo un modelo definido. Un entorno global de estas
caractersticas se designa como IPSE, ICASE o ISEE. La caracterstica
principal que distingue un entorno de esta clase de un banco de trabajo
amplio es el soporte explcito de un modelo global de desarrollo. El
entorno debe poseer las caractersticas de integracin del proceso,
adems de las de integracin de datos, control y presentacin.
Para conseguir este nivel de integracin es necesario contar con un
modelo formal del proceso de desarrollo. A diferencia de las
metodologas parciales de anlisis y diseo, este modelo suele
construirse a medida de cada empresa productora de software. Un ISEE

Entornos Orientados a Objetos

de uso general deber permitir:
Construir la definicin formal del modelo del proceso de
desarrollo.
Asegurar la aplicacin prctica del modelo definido.
Aunque no existen entornos ISEE disponibles si existen esquemas
generales de arquitectura de entornos orientados al proceso, que en
algunos casos han dado lugar a colecciones de herramientas que
facilitan las funciones deseadas. Algunas son:
PCTE (Portable Common Tool Environment). Es una
arquitectura de entorno integrado, basada en un repositorio comn. Su
elemento principal es la definicin de interfaz de acceso al repositorio.

Sobre l pueden operar herramientas que automaticen las actividades

previstas en el modelo del proceso. Existen implementaciones de
repositorio que cumplen con la especificacin PCTE, y tambin algunas
colecciones de herramientas como las del proyecto PACT.
ESF (Eureka Software Factory). Define otro modelo de
arquitectura, cuyo elemento central de integracin es el denominado
software bus, que es un interfaz normalizado para la interconexin de
herramientas. Se distinguen dos clases de herramientas: servidores y
herramientas de interaccin. Los servidores pueden realizar las
funciones de repositorio, tanto centralizado como distribuido, y
suministrar servicios o funciones automatizadas. Las herramientas de
interaccin permiten la comunicacin con los usuarios, que pueden

acceder a los repositorios y a los servicios a travs de ellas.

Modelo NIST/ECMA. Contempla

una

estructura

fija,

compuesta por elementos que proporcionan una integracin de datos,

basada en un repositorio comn, integracin de presentacin mediante
un soporte global de interfaz de usuario, e integracin del control,
basada en la gestin de procesos y mensajes. El entorno puede
particularizarse para un modelo de desarrollo determinado instalando
sobre estos elementos fijos una coleccin de herramientas.

Ante la ausencia de productos CASE listos para usar se debe de tomar el

enfoque de combinar productos para construir un entorno global.