Unidad I gestion de proyecto

Repblica Bolivariana de VenezuelaMinisterio del Poder Popular para la Educacin Universitaria

Universidad Politcnica Territorial del Oeste de Sucre Clodosbaldo RussinCuman Estado Sucre

Programa Nacional de Formacin en Informtica

Unidad Curricular Gestin de Proyectos InformticosUnidad 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. 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,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(Necesidades y

Demandas Actuales)

Situacin Deseada(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 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.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 :

DIAGNSTICOImplica conocer los problemas de nuestra realidad con incorporacin

activa de todos los sujetos.

FORMULACIN y PLANIFICACINPreparar las acciones para atender o abordar los problemas.

EJECUCINRealizar las acciones planificadas.

EVALUACINValorar las acciones que hemos realizado.

SISTEMATIZACINReconstruir las experiencias de todo el proceso de trabajo y presentarlas.

e.- Preguntas que debe responder un Proyecto

Dnde?

Localizacin

Para quienes?

Beneficiarios

Por qu y para qu?

Cmo?

Actividades y Procedimientos

Justificacin

Quines?

Equipo responsable

Qu?

Denominacin y Objetivos

Beneficiarios Procedimientos

Cundo?

Cronograma

Con qu?

Presupuesto

f.- Tipos de Proyectos:

Tcnicos y no tcnicos

Uni y multi

personales

Mono y multi

disciplinares

Mono o multi

contrato.

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 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.

1 Relacionadas con la Administracin

2

Personas, organizaciones, sistemas yprocedimientos

Planificacin y construccin del sistema

Actividades de Gestin

2 Planificacin y construccin del sistema

3

Trabaja en conjunto con las actividades dedesarrollo (estimadas, programadas yejecutadas)

1 Centradas en el desarrollo del mismo

2

Agrupadas en distintas fases Agrupadas en reas funcionales de estudio,

diseo y construccin

Actividades de Desarrollo

2 diseo y construccin

3 Basada en una estructura de

particin del trabajo

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.

EjemplosEjemplos

2.- Administracin del riesgo

Identificacin de riesgos: Lista de riesgo.

Evaluacin del riesgo.

Plan de Administracin de riesgo.

Seguimiento. 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.Riesgo: Probabilidad de que una circunstancia adversa ocurra.

Exposicin al Riesgo:

estimada asoc Prdidax riesgo ocurrencia Prob


Influencia Riesgo:

ductoranCostoAccio

ERER despuesantes

Re

)( ductoranCostoAccio Re

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:

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 gradoEl 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)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)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:


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


8. Manuales de operacin y de instalacin

9. Programas ejecutables

10. Manual de usuario

11. Documentos de mantenimiento

a. Informes de problemas del softwarea. 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


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 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.


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


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.: editor-

compilador-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


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


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.

Documents

Unidad I gestion de proyecto