Empresa y La Gestion de Proyectos

Apuntes de la Asignatura de
Empresa y Gestin de
Proyectos
Alberto Alonso Ruibal
alberto@alonsoruibal.com
http://www.alonsoruibal.com
Organizacin y Funciones
Empresariales

Indice
Concepto de empresa
Organizacin de la empresa
Funciones empresariales
Objetivo
Cul es el objetivo de una empresa?
Supervivencia y crecimiento del negocio
Obtencin de utilidades/generacin de
servicios
Imagen y prestigio
Aceptacin social
Satisfaccin de necesidades colectivas
Concepto de empresa
Se entiende por empresa al organismo
social integrado por elementos humanos,
tcnicos y materiales cuyo objetivo natural
y principal es la obtencin de utilidades, o
bien, la prestacin de servicios a la
comunidad, coordinados por un
administrador que toma decisiones en
forma oportuna para la consecucin de los
objetivos para los que fueron creadas.
Organizacin de la empresa
La organizacin de una empresa puede
definirse como el conjunto de todas las formas
en que se divide el trabajo en tareas distintas,
considerando luego la coordinacin de las
mismas.
Distintos tipos de estructuras organizativas:
Organizacin jerrquica pura
Organizacin funcional
Organizacin territorial
Organizacin por productos o servicios
Organizacin por clientes
Organizacion mixta
Organizacin de lnea y staff
Organizacin jerrquica pura
Tambin se llama lineal o por

nmeros
Cada persona recibe ordenes de
un solo jefe, prevaleciendo el
principio de jerarqua y de
subordinacin absoluta a su
inmediato superior.
Inconvenientes:
A
B
Sobrecarga a personas con deberes

y responsabilidad
Excesiva rigidez que no permite que
se implanten las ventajas de la
especializacin
Organizacin funcional (I)

Direccin
Produccin
Marketing
Financiero
Recursos
humanos
Definida por Taylor, que divide las actividades de

una empresa segn las funciones asignadas. a
cada una de ellas
Organizacin funcional (II)

Ventajas:
Es una organizacin muy probada y con xito
Procura e incide en la especializacin del
trabajo facilitando el aprovechamiento de los
recursos, la formacin y el control
Inconvenientes:
La responsabilidad de los resultados globales
se concentra en la cspide de la organizacin
No hay unidad de mando, lo que dificulta la
organizacin, puede originar posibles conflictos
de competencias, retrasos en las decisiones,
etc.
Organizacin territorial (I)

En empresas de gran tamao, se divide la
organizacin en distintas reas segn la
zona territorial a la que se atienda
Direccin
Espaa
Francia
Portugal
Organizacin territorial (II)

Ventajas:
Intensifica la responsabilidad por los resultados
Aproxima las decisiones a las caractersticas
de cada territorio
Inconvenientes
Dificulta el control
Pueden perderse economas de escala
Requiere mayor nmero de directivos
Organizacin por productos o servicios

Cada unidad de la empresa tiene asignada
la totalidad de las actividades asociadas a
un producto o familia de productos
La empresa gira en torno a sus productos
Direccin
Producto A
Producto B
Producto C
Organizacin por clientes

Se basa en dividir a los clientes en grupos
y crear un rea de la empresa para cada
uno de esos grupos
Es adecuado cuando los clientes requieren
tratamientos muy distintos
Direccin
Productos de
caballeros
Productos de
seoras
Productos
infantiles
Organizacin mixta
En casi todos los casos reales se mezclan
los anteriores sistemas de organizacin
Ventajas:
Adecuacin de la organizacin a las
necesidades de la empresa
Inconvenientes:
Al mezclar criterios a veces se origina
descoordinacin
Organizacin de lnea y staff

Se basa en la idea de Hery Fayol quien
sugiri la incorporacin de comits
compuestos de asesores especialistas,
preservando la unidad de mando.
No se proporciona autoridad a los
especialistas para dar ordenes, slo se les
consulta para que ayuden en las tomas de
decisin al resto de personal.
Las funciones empresariales

Se dividen principalmente en 5:
Direccin
Recursos humanos
Financiera
Marketing
Produccin
Algunos autores consideran slo como

bsicas las funciones Financiera, de
Marketing y de Produccin
La funcin de direccin
La direccin de una empresa debe:
Definir los objetivos de la empresa
Planificar el crecimiento
Controlar los resultados sobre los objetivos
planteados
Liderar y coordinar los distintos
departamentos
La funcin de recursos humanos

Se encarga de:
Seleccin de empleados
Organizacin de personal
Gestin de contratos y nminas
Anlisis de puestos
Formacin
Relaciones laborales
Servicios sociales
La funcin financiera
La funcin financiera incluye los
siguientes aspectos:
Facturacin: facturas, albaranes...
Contabilidad
Tributacin: hacienda, seguridad social,
impuestos locales, etc
Financiacin: obtencin de recursos; cuentas
de crdito, descuentos de papel, etc.
La funcin de marketing
Regla de las cuatro Ps
Producto: definicin, estudios de mercado,
atencin al cliente, soporte postventa, etc.
Promocin: imagen corporativa, publicidad,
comerciales, etc.
Precio: anlisis de costes, fijacin del precio,
descuentos, etc.
Distribucin (Placement): almacenes, red de
distribucin, etc.
Funcin de produccin (I)

Empleo de factores humanos y materiales
para la produccin de bienes y servicios
Proceso en el cual una serie de entradas
(factores o inputs) se transforman en
salidas (productos o outputs)
INPUTS
Transformacin
OUTPUTS
Funcin de produccin (II)

Tipos de transformaciones:
Fsicas, como en las operaciones de
fabricacin.
De lugar, como en el transporte o en las
operaciones de almacenamiento.
De intercambio, como en las operaciones con
los minoristas.
Fisiolgicas, como en el caso de la sanidad.
Psicolgicas, como en el caso de los servicios
de entretenimiento.
Informacionales, como en el caso de las
comunicaciones
Bibliografa
Gua para crear tu empresa. lvaro Lpez
Amo, Ed. Espasa.
http://www.monografias.com
Plan de empresa

Indice
Qu es un plan de empresa?
Para qu sirve?
Quin ha de elaborarlo?
Cmo se estructura?
Cmo presentarlo?
Qu es un plan de Empresa?
El Plan de Empresa es una herramienta de
trabajo para aquellas personas o colectivos
que quieran poner en marcha una iniciativa
empresarial.
Es un documento escrito por los promotores

del proyecto y en l estn recogidos los
diferentes factores y los objetivos de cada
una de las reas que intervienen en la
puesta en marcha de la empresa.
No debe confundirse con una simulacin de

cuentas de documentos financieros
provisionales.
Para qu sirve?
La utilidad del Plan de Empresa es doble:
Internamente obliga a los promotores del

proyecto a iniciar su aventura empresarial, con
unos mnimos de coherencia, eficacia, rigor y
posibilidades de xito, estudiando todos los
aspectos de viabilidad del mismo. Adems
sirve de base para cohesionar el equipo
promotor del proyecto, permitiendo definir
claramente los cargos y las responsabilidades,
y verificar que estn de acuerdo acerca de los
objetivos y la estrategia a seguir.
Externamente es una esplndida carta de
presentacin del proyecto a terceros, que
puede servir para solicitar soporte financiero,
buscar socios, contactar con proveedores,
Administraciones, etc. Adems, servir de
referencia para la accin futura de la empresa
y como instrumento de medida de los
rendimientos alcanzados.
Quin ha de elaborarlo?
Es muy importante que en la elaboracin
del Plan de empresa participen todos los
socios o promotores del proyecto.
Esto garantiza la plena implicacin de

todos en los objetivos de la empresa y en
la manera de alcanzarlos.
Cmo se estructura?
Una posible estructura de Plan de Empresa

puede ser la siguiente:
INTRODUCCIN
PLAN DE MARKETING
PLAN DE OPERACIONES
PLAN DE RECURSOS HUMANOS
PLAN DE INVERSIONES Y UBICACIN
PLAN ECONMICO FINANCIERO
ESTRUCTURA LEGAL DE LA EMPRESA
CALENDARIO DE EJECUCIN
RESUMEN Y VALORACIN
ANEXOS
Cmo presentarlo? (I)

Las personas que tienen que leer un Plan
de Empresa (entidades financieras,
posibles socios, proveedores, etc.)
normalmente disponen de poco tiempo
para hacerlo, por ello, la parte principal del
documento debe ser relativamente breve,
del orden de 20 a 40 pginas como
mximo.
Todos los elementos detallados formarn

parte de anexos.
Cmo presentarlo? (II)
La mayora de los profesionales

recomiendan respetar un cierto nmero de
reglas:
Un dossier principal breve y anexos: breve

resumen sobre las conclusiones del estudio de
mercado, comentarios acerca de los
documentos financieros, presentacin
comprensible de los datos tcnicos, etc.
Un resumen obligatorio, de una o dos pginas.
Se trata, en cierto modo, de un folleto o pgina
de publicidad con la cual el empresario trata de
vender su empresa.
Se aconseja realizar una presentacin
estructurada, clara y concisa, cuidando los
aspectos formales y escrito a mquina o
impresora.
Proyectos TI, Metodologas y

Ciclos de Vida

Indice
Por qu es necesaria la gestin de

proyectos?
Definicin de proyecto
Ciclo de vida de un proyecto
En cascada
Orientado a hitos
Orientado a prototipos
Programacin extrema
Mtrica v3
La caseta de mi perro
Slo hace falta

una persona
No requiere un
anlisis previo,
presupuestos,
documentacin,
etc.
Un edificio
Son necesarios
varios equipos de
trabajo
Es necesario una
especificacin re
requisitos, un
anlisis, una
planificacin...
esto es un
proyecto
Definicin de proyecto
Un proyecto es una accin en la que

recursos humanos, financieros y
materiales se organizan de una nueva
forma para acometer un trabajo nico.
En este trabajo, dadas unas
especificaciones y dentro de unos
lmites de costes y tiempo, se intenta
conseguir un cambio beneficioso
dirigido por unos objetivos cualitativos
y cuantitativos.
Proyectos de TI
La gestin de proyectos TI es ms
compleja por:
Complejidad intrnseca al desarrollo de

software
Imprecisin en la planificacin del proyecto y

estimacin de los costos.
Baja calidad de las aplicaciones.
Dificultad de mantenimiento de las

aplicaciones.
Esto hace surgir una rama de la ciencia

que se llama Ingeniera de Software que
intenta resolver estos problemas
Ciclo de vida de un proyecto
Es la forma en la que se divide un proyecto

en etapas y cmo se avanza entre estas
etapas
Segn la metodologa hay varios modelos,
pero analizaremos los siguientes:
En cascada
Orientado a hitos
Orientado a prototipos
Programacin extrema
Mtrica v3
Modelo en cascada (I)

Especificacin
de requisitos
Anlisis
Diseo
Codificacin
Pruebas
Implantacin
Mantenimiento
Es el modelo clsico
Las fases se deben
ejecutar de forma
secuencial, pero se puede
volver a la fase anterior
Cada etapa genera una
documentacin o un
producto que recibe de
entrada la siguiente fase
Modelo en cascada (II)
Objetivo de cada una de las etapas:
Especificacin de requisitos: Documento con

la especificacin de requisitos (ERQ)
Anlisis: Documento de anlisis funcional
Diseo: Documento de diseo tcnico
Codificacin: Cdigo fuente de la aplicacin y
manuales de usuario
Pruebas: Documentacin de pruebas
Implantacin: Documento de operacin
Modelo en cascada (III)
Ventajas
Minimiza la repeticin de tareas de desarrollo
La planificacin es sencilla
Facilita el control, permitindonos afrontar

proyectos grandes
Inconvenientes
Solo es adecuado cuando hay requerimientos

muy bien definidos y que no van a cambiar
Retroceder para corregir fases previas o

introducir cambios es muy costoso
El cliente slo ve los resultados al final
Modelo orientado a hitos (I)

Especificacin
de requisitos
Anlisis
Diseo de arquitectura
Consiste en introducir
hitos entregables al
cliente durante el
desarrollo del proyecto
Codificacin y pruebas A
Entrega A
Codificacin y pruebas B
Entrega B
Codificacin y pruebas C
Entrega C
Modelo orientado a hitos (II)
Ventajas
El cliente va viendo los resultados
Permite reducir mucho el riesgo en proyectos

grandes si se gestionan sus mdulos de
menor prioridad con esta tcnica
Inconvenientes
Se analiza todo el sistema al principio, y se

puede perder mucho tiempo en la
especificacin y diseo de funcionalidades que
al final no nos da tiempo a implementar
Modelo orientado a prototipos (I)
Prototipo 1
Prototipo 2
Prototipo 3
Se desarrolla un primer
prototipo relativamente
completo, frecuentemente
destinado a ser ya utilizado
por cliente.
El cliente aporta
realimentacin y con ella se
desarrolla el siguiente
prototipo
Se van repitiendo los ciclos
de iteracin hasta alcanzar
una versin final.
Modelo orientado a prototipos (II)
Ventajas
Es muy frecuente que los requisitos sean

cambiantes, con lo cual se van adaptando los
prototipos
El cliente ya puede ir trabajando con los

prototipos, viendo el resultado y aportando
feedback
Inconvenientes
En proyectos grandes es imposible saber

cuando se terminar
Los desarrolladores tienen a saltarse las fases

de anlisis y diseo
Programacin extrema (I)
Consiste en llevar la lmite el modelo de

prototipos, haciendo entregas continuas
con pequeos cambios en la funcionalidad
Programacin extrema (II)
Sus principios fundamentales son:
Desarrollo iterativo e incremental
Pruebas unitarias continuas
Programacin en parejas
Frecuente interaccin con el usuario
Correccin de todos los errores antes de

aadir nueva funcionalidad
Hacer entregas frecuentes
Refactorizacin del cdigo
Propiedad del cdigo compartida
Simplicidad en el cdigo
Programacin extrema (III)
Ventajas
Es muy realista con respecto a la relacin con

el cliente
Le da importancia el diseo simple y las

pruebas, un punto normalmente descuidado
Aporta muy buenas ideas
Inconvenientes
Solo vale para proyectos relativamente

pequeos (entre 2 y 12 desarrolladores)
Sus principios no pueden ser aplicados a

rajatabla, es necesario saber decidir cuando
aplicar ciertas cosas y cundo no
Modelo mtrica v.3 (I)
Metodologa de Planificacin, Desarrollo y

Mantenimiento de Sistemas de informacin
promovida por el MAP
Interfaces orientados a la gestin de los
procesos:
Gestin de proyectos (GP).
Seguridad (SEG).
Aseguramiento de la Calidad (CAL).
Gestin de la Configuracin (GC).
Modelo mtrica v.3 (II)
Procesos:
Planificacin de Sistemas de Informacin (Proceso

PSI)
Desarrollo del Sistema de Informacin (Proceso DSI)

Estudio de Viabilidad del Sistema (Proceso EVS)
Anlisis del Sistema de Informacin (Proceso ASI)
Diseo del Sistema de Informacin (Proceso DSI)
Construccin del Sistema de Informacin (Proceso

CSI)
Implantacin y Aceptacin del Sistema (Proceso

IAS)
Mantenimiento del Sistema de Informacin (Proceso
MSI)
Bibliografa
Gestin de Proyectos IT con xito:

http://www.aqs.es
Programacin extrema:
http://www.extremeprogramming.com
Mtrica v3:
http://www.csi.map.es/csi/metrica3/
Gestin de proyectos: ERQs y

presupuestos

Indice
Gestin del proyecto
Importancia de la documentacin
Reuniones con el cliente
Especificacin de requisitos
Presupuestacin
Gestin del proyecto
La gestin del proyecto es la aplicacin del

conocimiento, habilidades, herramientas y
tcnicas a las actividades del proyecto para
conseguir cumplir los requisitos del
proyecto
Tareas crticas:

Estimacin de duracin, coste y esfuerzo (esto
es, presupuestacin)
Planificacin de tareas y asignacin de
recursos
Seguimiento y control
En los proyectos de software la

documentacin es de vital importancia:
El software es algo abstracto, la

documentacin aporta algo tangible al
proyecto.
Documentar ayuda a compartir informacin
entre usuarios y desarrolladores.
Permite acotar el proyecto.
Evita tomar decisiones precipitadas que
pueden llevar a resultados catastrficos.
Facita la formacin tanto de los usuarios
como los desarrolladores
Motivacin de las reuniones:
Reuniones comerciales: el objetivo es vender

un producto o dar a conocer la empresa
Reuniones de toma de requisitos: para poder
elaborar un documento de requisitos o que el
cliente nos explique su documento de
requisitos
Reuniones tcnicas: para discutir el diseo
tcnico o el anlisis funcional
Reuniones de control: sobre un Gantt analizar
el punto en el que se encuentra el proyecto y
las posibles variaciones sobre la planificacin
Errores frecuentes en las reuniones (I)
Acompaarse de gente con experiencia en

reuniones
Nunca decir precios en reuniones de toma
de requisitos (esperar al presupuesto)
No dar a entender que el proyecto es
sencillo, puede dar una idea equivocada
sobre el precio que le vamos a dar al cliente
No hablar de ms, desvelando excesiva
informacin sobre nuestra empresa u otros
proyectos
Errores frecuentes en las reuniones (II)
Cuidar la vestimenta, las formas y el

lenguaje corporal
No ignorar a los tcnicos
Tomar notas (puede estar bien grabarlas
en audio o incluso levantar un acta de la
reunin y enviarla por email)
Cuidado con las conversaciones
informales!
Especificacin de Requisitos (I)
La captura de requisitos es parte esencial:

evita cambios posteriores en el sistema y
facilita el entendimiento con el cliente
Deben especificar lo siguiente:
Funcionalidad
Interfaz externa
Rendimiento
Atributos
Restricciones de diseo
Especificacin de Requisitos (II)
Como deben ser los requisitos:
Completos
Implementacin independiente
Consistentes y no ambiguos
Precisos
Verificables
Que puedan ser ledos
Modificables
Muy importante: que nos permitan hacer un

presupuesto
Especificacin de Requisitos (III)
La toma de requisitos:
Introspeccin: ponerse en lugar del cliente e

imaginar como desea que funcione el sistema
Escuchar la problemtica del cliente
Entender la solucin que espera
Ser capaz de orientar y aconsejar al cliente durante

la entrevista para orientarlo hacia nuestros
productos o tecnologas
Hay modelos estndard para la toma de

requisitos, de los cuales se cubre lo que
necesitemos
Presupuestacin
Cuanto dinero va a costar realizar el

proyecto?
Lo ms difcil a la hora de hacer un
presupuesto de un proyecto TI:
Diferenciar las tareas a presupuestar

Estimar el tiempo de cada tarea
Acotarlo de forma que el cliente no nos pueda
colar tareas no estimadas inicialmente
A la hora de poner un precio, las tareas de

implementacin se suelen cobrar por hora,
pero hay ms cosas que contemplar en los
presupuestos...
Qu presupuestar (I)
Anlisis: el anlisis del problema posterior al

presupuesto previo a la elaboracin del
documento de anlisis funcional y del
diseo tcnico
Consultora: cuando el objetivo del proyecto
es la recomendacin de medidas
apropiadas y prestacin de asistencia en la
aplicacin de dichas recomendaciones.
Preparacin del entorno: instalacin de
servidores, aplicaciones (CVS, IDEs, etc),
etc.
Qu presupuestar (II)
Implementacin: las tareas de

programacin en s
Direccin de proyecto: las horas que dedica
el director de proyecto a la coordinacin de
los programadores (se suele poner un 25%
del tiempo de implementacin)
Implantacin: instalacin de la aplicacin en
los entornos del cliente. Cuidado con las
subidas de los hitos entregables a los
entornos del cliente
Qu presupuestar (II)
Formacin: suele estar hasta bien visto por

el cliente dar un par de charlas de
formacin a los usuarios sobre la aplicacin
Documentacin: anlisis funcional, diseo
tcnico, manuales, documentos de puesta
en produccin, etc.
Desplazamientos: cuando el cliente se
encuentre a una distancia considerable, se
incluyen dietas.
Material: sobre todo hardware que se va a
instalar en el cliente...
Los mrgenes
Margen de riesgo
Margen comercial
Se aade para cubrir las tareas comerciales y

para poder negociar bajando el precio al bajar
este margen
Margen de calidad
Se aade a las tareas para cubrir errores en las

estimaciones
Se deja para el control de calidad del cdigo
Margen al tiempo de entrega
Se aade para cubrirse frente a que los

recursos se tenga que dedicar a otras tareas
El flujo de caja
Determina los plazos en los que el cliente

va a pagar el proyecto
Se suele intentar marcar hitos en el
proyecto e ir cobrando un porcentaje a la
entrega de esos hitos
Muy importante no cobrar slo al final del
proyecto, sobre todo en proyectos largos,
porque nos puede traer problemas
financieros
Tener cuidado con empresas que pagan
con pagars a 30, 60 o incluso 90 das
Clausulas de penalizacin
En algunos casos los clientes pueden

pedir que se incluyan clausulas que
penalicen el retraso del proyecto
Limitarlas a un porcentaje del costo total
del proyecto (un 20% como mucho)
Cubrirse las espaldas en la estimacin de
tiempos, sobre todo aplicando margen al
tiempo de entrega
El clculo de la rentabilidad
Es muy importante tener un modelo de

presupuesto que luego nos permita hacer
un clculo de la rentabilidad sobre los
tiempos estimados
Para ello durante la fase de implementacin
mediremos los tiempos que lleva cada
tarea y los compararemos con el estimado
(control de tareas)
Esto nos ser de mucha ayuda en futuros
presupuestos
Otras formas de presupuestar
Muchas veces lo que se presupuestan no

son slo proyectos, pueden ser:
Productos de software ya terminados: lo que

se vende es la licencia y en muchos casos la
implantacin.
Mantenimientos mensuales: con una cuota fija
al mes para realizar tareas de mantenimiento
de una aplicacin.
Packs de horas: se le cobran al cliente X
horas que ste ir consumiendo segn se
vayan realizando desarrollos solicitados.
Licencias
Una vez que tenemos un proyecto de

software desarrollado podemos establacer
licencias para venderlo a varios clientes.
Estas licencias pueden ser:
Por empresa
Por usuario de la empresa
Por cliente de la empresa que utilice la
aplicacin
Por CPU de servidor
etc.
Planificacin: PERTs y Gantts

Indice
Planificacin
Diagramas PERT
Actividades y sucesos
Representacin
Tecnicas PERT
Camino crtico
Diagramas Gantt
Representacin
Dependencias de tareas
Estimacin y asignacin de recursos
Grfico de ocupacin de recursos
Planificacin
La planificacin de un proyecto es la
previsin en fechas de la realizacin del
conjunto de actividades que lo componen,
teniendo en cuenta que se deben emplear
para ello unos recursos que implican unos
costes.
Para realizar una buena planificacin se
deben utilizar diversas tcnicas, algunas
de las cuales se exponen a continuacin.
Diagramas PERT (I)
PERT (Program Evaluation and Review

Technique)
Desarrollado por la Special Projects Office
de la Armada de EE.UU. a finales de los
50s para el programa de I+D que condujo a
la construccin de los misiles balsticos
Polaris.
Est orientada a los sucesos o eventos, y
se ha utilizado tpicamente en proyectos de
I+D en los que el tiempo de duracin de las
actividades es una incertidumbre.
Actividades y sucesos
Actividad: la ejecucin de una tarea, que

exige para su realizacin la utilizacin de
recursos tales como: mano de obra,
maquinaria, materiales,...
Suceso: es un acontecimiento, un punto
en el tiempo, una fecha en el calendario.
El suceso no consume recursos, slo
indica el principio o el fin de una actividad
o de un conjunto de actividades.
Representacin de Diagramas PERT
Crculos: Sucesos
Flechas: Actividades
Diagramas PERT (II)
Con un diagrama PERT se obtiene un

conocimiento preciso de la secuencia
necesaria, o planificada para la ejecucin
de cada actividad.
Muy orientado al plazo de ejecucin, con
poca consideracin hacia al coste.
Se suponen tres duraciones para cada
suceso, la optimista a, la pesimista b y la
normal m; suponiendo una distribucin beta,
la duracin ms probable es: t = (a + 4m +
b) / 6 .
Tcnicas PERT
Conjunto de modelos para la programacin

y anlisis de proyectos de ingeniera que
sirven para:
Determinar las actividades necesarias y

cuando lo son.
Buscar las ligaduras temporales entre
actividades del proyecto.
Buscar el camino crtico.
Detectar y cuantificar las holguras de las
actividades no crticas
Si se est fuera de tiempo durante la ejecucin
del proyecto, seala las actividades que hay
que forzar.
Camino crtico
El camino crtico en un proyecto es la

sucesin de actividades que dan lugar al
mximo tiempo acumulativo.
Determina el tiempo ms corto que
podemos tardar en hacer el proyecto si se
dispone de todos los recursos necesarios.
Para calcularlo es necesario conocer la
duracin de las actividades que estn en el
camino crtico y sumar sus tiempos:
Mtodo del tiempo estimado (CPM): se utiliza

el clculo del tiempo medio: Te = m
Mtodo del tiempo esperado (PERT): Te = (a +
4m + b) / 6
Diagramas Gantt
Inventado por Charles Gantt en 1917

El diagrama de Gantt o cronograma tiene
como objetivo la representacin del plan
de trabajo, mostrando las tareas a realizar,
el momento de su comienzo y su
terminacin y la forma en que las distintas
tareas estn encadenadas entre s.
Es la forma habitual de presentar el plan
de ejecucin de un proyecto.
Representacin de diagramas Gantt (I)
Se representan de la siguiente forma:
En las filas la relacin de actividades a realizar

En las columnas la escala de tiempos que se
est manejando
La duracin y situacin en el tiempo de cada
actividad se indica mediante un rectngulo
dibujado en el lugar correspondiente.
Los hitos se marcan con rombos
El porcentaje de realizacin de la tarea se
indica con una lnea dentro del rectngulo de
la tarea
Las fases se marcan con lineas sobre los
rectngulos de las tareas
Representacin de diagramas Gantt (II)
Dependencias de tareas
Al igual que en el PERT, en el Gantt

tambin se representan las dependencias
entre tareas con flechas
Cada tarea se retrasa hasta el punto en el
que las tareas de las que depende
terminan.
Estimacin de recursos
La estimacin de recursos consiste en

indicar cuntos recursos (personas) sern
necesarias para llevar a cabo el proyecto
El mayor factor condicionante en el
nmero de recursos ser el tiempo de
entrega
Hay un lmite, muy asociado con el camino
crtico (y con el asignar una tareas a ms
de una persona), por encima del cual
asignando ms recursos no
conseguiremos una reduccin del tiempo
Asignacin de recursos (I)
La asignacin de recursos es una tarea

fundamental en la planificacin, ya que hay
que considerar aspectos tcnicos de cada
recurso como su disponibilidad, capacidad
de trabajo,impedimentos horarios, etc.
Cuantificar necesidades y fechas de
incorporacin de recursos.
Considerar la capacidad, los conocimientos
y la experiencia de cada recurso.
Considerar la complejidad, el tamao y los
requerimientos tcnicos de cada tarea.
Asignacin de recursos (II)
Asignar tareas sencillas a recursos con

poca experiencia.
Asignar tareas complejas a recursos con
mucha experiencia.
Construir el grfico de ocupacin de
recursos, para poder ver la coherencia de
las asignaciones.
Tratar de asignar una tarea a un nico
recurso, descomponiendo cuanto sea
necesario.
Vigilar que no haya vacos en el grfico de
recursos.
Grfico de ocupacin de recursos
Es un grfico que muestra, en cada

periodo de tiempo el porcentaje de
ocupacin de cada uno de los recursos.
Intentar mantener la ocupacin de
recursos al 100%
... pero no sobrepasar el 100%
Aplicaciones informticas
Microsoft Project: sistema completo de gestin de

proyectos, slo para windows
http://www.microsoft.com/Project
Microsoft Visio: aplicacicin para el diseo de
diagramas http://office.microsoft.com/visio
GanttProject: aplicacin Java orientada a la
creacin de Gantts http://www.ganttproject.biz
Imendio Planner: aplicacin de planificacin para
Linux
http://developer.imendio.com/projects/planner
Yed: editor de diagramas para Java:
http://www.yworks.com/products/yed
Dia: aplicacin para dibujar diagramas en Linux
http://www.gnome.org/projects/dia
Anlisis Funcional y Casos de

Uso

Indice
Anlisis funcional
Casos de uso
Especificacin
Diagramas
Pruebas
Qu ms incluir en el documento
En los proyectos de software la

documentacin es de vital importancia:
El software es algo abstracto, la documentacin

aporta algo tangible al proyecto.
Documentar ayuda a compartir informacin
entre usuarios y desarrolladores.
Permite acotar el proyecto.
Evita tomar decisiones precipitadas que
pueden llevar a resultados catastrficos.
Facita la formacin tanto de los usuarios como
los desarrolladores
Anlisis funcional
En informtica, el anlisis funcional es aqul
que describe que se va a desarrollar, sin
entrar en como se desea hacerlo, que es el
objetivo del anlisis orgnico (o tcnico).
Se utilizan varias tcnicas, pero la ms

frecuente es la especifiacin mendiante los
casos de uso.
En el documento de anlisis funcional

tambin se suele hacer una introduccin a
la aplicacin.
Casos de uso (I)

Un caso de uso es una secuencia de
acciones realizadas por el sistema, que
producen un resultado observable y
valioso para un usuario en particular, es
decir, representa el comportamiento del
sistema con el fin de dar respuestas a los
usuarios.
Se pueden descomponer en subcasos de

uso (otros casos menores que lo
componen)
Casos de uso (II)
Los objetivos de los casos de uso son los

siguientes:
Capturar los requisitos funcionales del sistema

y expresarlos desde el punto de vista del
usuario.
Guiar todo el proceso de desarrollo del sistema
de informacin.
Los casos de uso proporcionan un modo de

comunicacin cliente/desarrollador.
Para el cliente proporcionan una visin de caja

negra del sistema.
Para los desarrolladores, es el punto de partida
y el eje sobre el que se apoya el desarrollo del
sistema.
Casos de uso: Especificacin (I)
Se especifica en un texto de la siguiente

forma:
Descripcin: del caso de uso. En el se pueden

indicar uno o varios requisitos funcionales del
sistema que son satisfechos por este caso de
uso.
Actores: se describirn los actores que
intervienen en el caso de uso.
Precondiciones: qu condiciones deben
cumplirse para que se realice un caso de uso.
Postcondiciones (o garantas de xito):
cules son aquellas condiciones que se
cumplen posteriormente al caso de uso.
Casos de uso: Especificacin (II)
Escenarios (o secuencias): son los distintos

caminos por los que puede evolucionar un caso
de uso, dependiendo de las condiciones que se
van dando en su realizacin.
Secuencia normal
Secuencia alternativa
Excepciones
Extensiones: casos de uso que extienden del

actual
Inclusiones: casos de uso que se incluyen en
el actual
Requisitos especiales: que debe cumplir este
caso de uso
Casos de uso: Diagramas (I)
Se componen principalmente de:
Actores: los actores sern tanto los

usuarios del sistema como los sistemas
externos.
Casos de uso: representa el
comportamiento que ofrece el sistema de
informacin desde el punto de vista del
usuario. Tpicamente ser un conjunto de
transacciones ejecutadas entre el sistema y
los actores.
Paquetes: son agrupaciones de casos de
uso.
Relaciones: pueden tener lugar entre
actores y casos de uso o entre casos de
uso.
Casos de uso: Diagramas (II)

Las relaciones cuando son entre un actor y
un caso de uso se representan por una
lnea recta
Cuando son entre casos de uso se

representan con lneas discontinuas, y
Usa:
cuando
se
pueden
ser de
dos tipos:
quiere reflejar un
comportamiento
comn en varios casos
de uso.
Extiende: cuando se
quiere reflejar un
comportamiento
opcional de un caso
Casos de uso: Diagramas (III)
Casos de uso: Pruebas

Los casos de uso son muy tiles si los
utilizamos para que definan nuestras
puebas funcionales.
Es preciso conocer los tipos de pruebas:
Unitarias: prueban una sla parte del cdigo,

generalmente una clase. Las herramientas que
se utilizan son jUnit, phpUnit, etc.
Funcionales: Prueban el sistema desde el punto
de vista del usuario introduciendo unos datos
por el interfaz de la aplicacin y esperando
recibir otros. Por ejemplo en el caso de una
aplicacin web se prueba automatizando la
navegacin por las pginas. Las herramientas
que se usan son Canoo Webtest, BadBoy,
Apache JMeter, etc.
Que ms incluir en el documento (I)
En primer lugar, el documento debe tener

una introduccin al igual que en el
documento de ERQ, en la que se incluya:
Objetivo
Alcance
Definiciones, acrnimos y abreviaturas
Referencias (a otros documentos, ERQs, etc.)
Visin general (Explicacin del documento)
Que ms incluir en el documento (II)
Una seccin de descripcin del producto,

que contenga lo siguiente:
Enfoque del Producto

Caractersticas del Producto
Tipos de Usuarios
Modelo de Casos de Uso
Entorno Operativo
Restricciones de Diseo y Despliegue
Documentacin de Usuario
Hiptesis y dependencias
En la seccin de modelos del curso se

muestra un ejemplo de esto
El Diseo Tcnico

Indice
Diseo Tcnico
Que debe incluir?
Herramientas
Diagramas de despliegue
Modelo entidad-relacin
Diagramas de clases
Diagramas de componentes
Diagramas de paquetes
Diagramas de secuencia
Diagramas de estados
Diseo tcnico
En el documento de diseo tcnico se
especificar el cmo a a ser
implementado el proyecto.
En muchos casos a este documento se le

llama el manual del programador
Es sobre todo para uso interno de los

programadores, de ayuda para comenzar
la programacin y para incorporar nuevos
programadores al proyecto.
Que debe incluir? (I)
Arquitectura de la aplicacin
Elementos de hardware
Comunicaciones: distintas conexiones de red
que hace la aplicacin
Software de base a emplear
Arquitectura actual: slo si haba una aplicacio
anterior
Arquitectura propuesta: la que se va a
implementar
Modelo de datos
Estructura de la base de datos
Que debe incluir? (II)

Organizacin del cdigo
Bibliotecas utilizadas
Diseo de los distintos componentes
Estructura de clases
Divisin de la aplicacin en paquetes
Explicaciones del funcionamiento del cdigo
Herramientas de desarrollo a utilizar: cmo

compilar, etc
Herramientas
En el documento de diseo tcnico nos

podremos valer de varias herramientas para
apoyar las explicaciones que debemos dar
sobre el proyecto:
Diagramas de despliegue
Modelo entidad-relacin
Diagramas de clases
Diagramas de componentes
Diagramas de paquetes
Diagramas de secuencia
Diagramas de despliegue (I)
Para representar la arquitectura se suele

utilizar un diagrama de despliegue, en el
que se suelen mostrar las mquinas y los
servicios/aplicaciones que corrern en
cada una de las mquinas.
Diagramas de despliegue (II)
En los diagramas de despligue se

representan los distintos componentes con
los siguientes smbolos:
Modelo entidad-relacin (I)
Nos sirve para definir el modelo de datos,

expicando los campos de cada una de las
tablas y las relaciones entre ellas
Modelo entidad-relacin (I)
Representa:
Entidades: se corresponden a las tablas en

la base de datos
Se indican los campos de cada una de las
entidades
Se puede especificar el tipo de cada campo
Relaciones: se corresponden a las foreign

keys de la DDBB, y pueden ser de varios
tipos:
1a1
1aN
NaN
Diagramas de clases (I)
El diagrama de clases recoge las clases

de objetos y sus asociaciones. En este
diagrama se representa la estructura y el
comportamiento de cada uno de los
objetos del sistema y sus relaciones con
los dems objetos, pero no muestra
informacin temporal.
Diagramas de clases (II)
Es muy difcil tener clara la estructura de

clases durante el diseo tcnico
Las clases se componen de:
Atributos
Mtodos
Se pueden representar:
Clases abstractas
Tipos de clases (Entidades, Interfaces,
Objetos de control)
Asociaciones entre clases
Paquetes (ver diagrama de paquetes)
Diagramas de componentes (I)
Muestra los distintos componentes del

software que va a ser desarrollado y su
interrelacin
Diagramas de componentes (II)
Se representan los
siguientes elementos:
Componentes: las clases en s

Interfaces: clases que
exponen mtodos a otro
paquete u otro grupo de
clases
Paquetes: agrupaciones de
clases
Relaciones entre ellos: en este
diagrama no hay tipos de
relaciones
Diagramas de paquetes (I)

Muestra la descomposicin del cdigo en
distintos paquetes y las relaciones entre
los distintos paquetes.
En este diagrama no hay tipos de

relaciones.
En Java tiene aplicacin directa, ya que

este lenguaje nos permite organizar el
cdigo en paquetes.
Diagramas de paquetes (II)
Diagramas de secuencia (I)
Representan la interaccin temporal entre

los distintos actores y componentes del
sistema para un caso de uso.
Diagramas de secuencia (II)

Se pueden entender como un cronograma,
pero en el que la lna temporal est en el
eje Y
Las dependencias y mensajes se

representan con flechas
Las tareas que realiza cada componente

se muestran con rectngulos sobre la lnea
temporal de cada uno de los componentes
Representa los estados que puede tomar

un componente o un sistema y muestra los
eventos que implican el cambio de un
estado a otro.
Fase de Programacin de los

proyectos

Indice
Sistemas de control de versiones

CVS
Terminologa
Operaciones
Tags
Subversion
Clearcase
Control de tiempos
Control del estado del proyecto
Incidencias
Introduccin
La programacin de grandes proectos de

software necesita de varias herramientas,
como los sistemas de control de versiones
de cdigo, que comentaremos en las
siguientes transparencias
Durante la fase de desarrollo, el gestor del
proyecto debe de encargarse del
seguimiento del proyecto, con el control de
tiempos y de estado, gestionando la
comunicacin con el cliente.
Sistemas de control de versiones
Nos permiten coordinar el desarrollo entre

varios programadores
Permiten que varias personas puedan
modificar un mismo fichero
simultneamente
Guardan el historial del desarrollo,
pudiendo contemplar el estado del proyecto
en cualquier instante temporal pasado
Permiten controlar la actividad de los
distintos desarrolladores
Los principales son el CVS y el Subversion
CVS
Concurrent Version System: es el ms

utilizado por ser el que lleva ms aos
Es una estructura cliente-servidor, en la que
el cliente tiene una copia local del cdigo de
la aplicacin
El cliente puede trabajar en su copia local
sin influir a los dems usuarios, y va
subiendo al servidor CVS los cambios que
va realizando
No se debe subir al servidor CVS cdigo
que no compile, ya que dificultara el
desarrollo de los dems usuarios
CVS: Terminologa
Servidor CVS: Mquina que ejecuta CVS

y actua como almacn de ficheros.
Repositorio: Jerarqua de directorios
alojada en el servidor CVS que contiene
diferentes mdulos a disposicin de los
usuarios.
Mdulo: rbol de directorios que forma
parte del repositorio. Cada proyecto de
software se suele corresponder a un
mdulo.
CVS: Operaciones
Las operaciones que puede realizar un

cliente contra un servidor CVS son
principalmente:
import: subir un mdulo al repositorio

checkout: obtener una copia local de un
mdulo del repositorio
update: actualizar la copia local con los
cambios que haya en el servidor
commit: subir los cambios de la copia local del
cdigo al servidor
add: aadir un fichero al repositorio
del: borrar un fichero del repositorio
diff: ver diferencias entre ficheros
CVS: Tags
En CVS cada fichero tiene una versin

indicada por un nmero
Podemos crear TAGs o etiquetas que
marquen una versin determinada de
cada uno de los ficheros
Esto nos sirve para etiquetar las versiones
de cdigo estable en el repositorio y seguir
desarrollando
Hay un tag implcito que se llama HEAD y
que representa la ltima versin de cada
uno de los ficheros
Subversion
El CVS tiene una serie de limitaciones:
No permite mover o renombrar ficheros (al

renombrarlos se pierde su historial)
No funciona bien con ficheros binarios
No soporta versiones en los directorios
Sistema complicado de Branches
...
Subversion es un sistema de control de

versiones ms reciente que trata de corregir
estas limitaciones
Est substituyendo al CVS de forma
progresiva
Clearcase
Desarrollado por Rational, que ahora son

divisin de IBM
Software propietario (y caro!)
Difcil de administrar
Est probado en proyectos de tamao
ingente
Permite trabajar a distintos equipos sobre
un mismo cdigo
Herramientas de gestin de proyectos
Hay una serie de herramientas que nos

permiten gestionar de forma fcil los
distintos proyectos de software, integrando
los sistemas de control de versiones con
gestores de incidencias, foros, wikis, etc.
Sourceforge (http://www.sf.net/)
Gforge (http://www.gforge.org/)
Savannah (http://savannah.gnu.org/)
Google Code (http://code.google.com/)
Trac (http://trac.edgewall.org/)
Control de tiempos
Durante la programacin es encesario

saber cunto tiempo invierte cada
programador en cada una de las tarea
Estos tiempos nos permiten saber cunto
nos hemos equivocado en la estimacin
Hay aplicaciones que nos permiten llevar
este control:
KARM: (
http://pim.kde.org/components/karm.php)
Time tracker (Online) (
http://http://www.formassembly.com/time-tracker
/
)
Control del estado del proyecto
En los proyectos grandes, al final de la

semana se suele enviar al cliente un
informe de situacin del proyecto
En l se suelen explicar las fases del
proyecto que se han realizado durante la
semana y el estado global del proyecto
Se puede acompaar con el digrama de
Gantt en el que se indica el porcentaje
completado de cada una de las tareas
Este control permite prevenir al cliente de
posibles atrasos
Incidencias (I)
La fase de desarrollo no suele ser un

camino de rosas, ya que nos solemos
encontrar con:
Cambios que pide el cliente: es necesario

presupuestarlos, planificarlos y ver cmo
afectan a los tiempos de entrega, o bien
dejarlos para cuando se termine el proyecto
Partes de la aplicacin mal especificadas: que
nos originan nuevas tareas que no tenamos
previstas
Retrasos en la programacin: por estimaciones
demasiado optimistas. Suele ser necesario
replanificar
Complicaciones tcnicas: los problemas que
nunca estn previstos y siempre aparecen...
Incidencias (II)
Hay varias formas de hacerles frente:
Replanificar retrasando el proyecto

Replanificar aadiendo ms desarrolladores
Trabajar 12 horas al da y fines de semana para
intentar recuperar los retrasos (intentar evitar
esta opcin)
No obstante, los mrgenes que dejamos

durante la fase de estimacin deberan ser
siempre suficientes para absorber todas las
posibles incidencias que se puedan producir
Calidad y Pruebas del Software

Calidad
Indice
Gestin de la calidad
Control de la calidad
Determinacin de la calidad
Pruebas
Entornos de pruebas
Pruebas unitarias
Pruebas funcionales
Pruebas de usabilidad
Pruebas de integracin
Pruebas de carga
Pruebas de regresin
Pruebas de aceptacin
Calidad
Concordancia con los requisitos

funcionales y de rendimiento
explcitamente establecidos con los
estndares de desarrollo explcitamente
documentados y con las caractersticas
implcitas que se espera de todo software
desarrollado profesionalmente R. S.
Pressman (1992).
La calidad de un sistema software es algo
en muchos casos subjetivo que depende
del contexto y del objeto que se pretenda
conseguir.
Gestin de la calidad
Gestin de la calidad (ISO 9000): Conjunto

de actividades de la funcin general de la
direccin que determina la calidad, los
objetivos y las responsabilidades y se
implanta por medios tales como la
planificacin de la calidad, el control de la
calidad, el aseguramiento (garanta) de la
calidad y la mejora de la calidad, en el
marco del sistema de calidad.
Poltica de calidad (ISO 9000): Directrices
y objetivos generales de una organizacin,
relativos a la calidad, tal como se expresan
formalmente por la alta direccin
Control de la calidad
Son las tcnicas y actividades de carcter

operativo, utilizadas para satisfacer los
requisitos relativos a la calidad, centradas
en dos objetivos fundamentales:
mantener bajo control un proceso

eliminar las causas de los defectos en las
diferentes fases del ciclo de vida
En general son las actividades para

evaluar la calidad de los productos
desarrollados
Determinacin de la calidad
Los requisitos del software son la base de

las medidas de calidad. La falta de
concordancia con los requisitos es una
falta de calidad
Existen algunos requisitos implcitos o
expectativas que a menudo no se
mencionan, o se mencionan de forma
incompleta (por ejemplo el deseo de un
buen mantenimiento) que tambin pueden
implicar una falta de calidad.
A continuacin mostramos un resumen de
los factores que pueden determinar la
calidad del software
Qu determina la calidad? (I)
Operaciones del producto: caractersticas

operativas
Correccin (Hace lo que se le pide?)

Fiabilidad (Lo hace de forma fiable todo el
tiempo?)
Eficiencia (Qu recursos hardware y
software necesito?)
Integridad (Puedo controlar su uso?)
Facilidad de uso (Es fcil y cmodo de
manejar?)
Qu determina la calidad? (II)
Revisin del producto: capacidad para

soportar cambios
Facilidad de mantenimiento (Puedo localizar

los fallos?)
Flexibilidad (Puedo aadir nuevas
opciones?)
Facilidad de prueba (Puedo probar todas las
opciones?)
Qu determina la calidad? (III)
Transicin del producto: adaptabilidad a

nuevos entornos
Portabilidad (Podr usarlo en otra mquina?)

Reusabilidad (Podr utilizar alguna parte del
software en otra aplicacin?)
Interoperabilidad (Podr comunicarse con
otras aplicaciones o sistemas informticos?
Pruebas
Las pruebas de software es el conjunto

de tcnicas que permiten determinar la
calidad de un producto software
Aunque hay muchos factores a probar que
son subjetivos, hay otros que pueden ser
probados y medidos de una forma
metdica
La cobertura de las pruebas es un
trmino que se refiere al porcentaje del
cdigo de la aplicacin que se cubre con
un determinado grupo de pruebas
Entornos de prueba
En todo desarrollo de software nos

deberamos encontrar con estos
escenarios:
Desarrollo
Integracin
Produccin
Pruebas unitarias
Unidad: Este tipo de prueba solo aplica a

proyectos grandes. Se divide el proyecto a
unidades y cada unidad es sometida a
prueba individualmente
Para los lenguajes de programacin
orientado a objetos, estas unidades suelen
ser las clases, por lo que se suele realizar
una prueba por clase
Se utilizan frameworks de prueba como lso
xUnit (jUnit, phpUnit, etc.)
Pruebas funcionales
Prueban el sistema desde el punto de vista
del usuario introduciendo unos datos por el
interfaz de la aplicacin y esperando
recibir otros.
Por ejemplo en el caso de una aplicacin

web se prueba automatizando la
navegacin por las pginas y
comprobando que los resultados son los
esperados.
Las herramientas que se untilizan son

Canoo Webtest, BadBoy, Apache JMeter,
etc.
Pruebas de usabilidad (I)
La usabilidad se refiere a la facilidad o

nivel de uso, es decir, al grado en el que el
diseo de un programa facilita o dificulta
su manejo
Este tipo de prueba se refiere a asegurar
de que la interfaz de usuario (o GUI) sea
intuitiva, amigable y funcione
correctamente.
Enumeraremos los factores que influyen
principalmente en la usabilidad
Pruebas de usabilidad (II)
Quines son los usuarios, cules sus

conocimientos, y cunta preparacin
necesitan?
Pueden los usuarios realizar fcilmente sus
tareas previstas?
Qu documentacin u otro material de apoyo
estn disponible para ayudar al usuario?
Puede ste hallar las respuestas que buscan
en estos medios?
Cules y cuntos errores cometen los
usuarios cuando interactan con el producto?
Se han tomado medidas para cubrir las
necesidades especiales de los usuarios con
discapacidades? (accesibilidad)
Pruebas de integracin
Se prueba la aplicacin en un entorno

similar al de produccin asegurndose de:
que funciona sobre el hardware/software que

nos encontraremos en el entorno de
produccin
que no aparecen problemas al trabajar con los
datos que hay en el entorno de produccin
(tanto en tipo como en volumen)
que se integra sin problema con el resto de
aplicaciones con las que se comunica
Pruebas de carga
Las pruebas de carga o stress se utilizan

para comprobar cmo responde el sistema
frente a un determinado nmero de
usuarios o transacciones
Permiten detectar cuellos de botella en el
rendimiento de las aplicaciones
Deben realizarse sobre el entorno de
integracin, para que los resultados se
parezcan lo ms posible a los que nos
vamos a encontrar en produccin
Pruebas de regresin
Esta prueba incluye todas las pruebas

anteriores en caso de que se le haga
algn cambio a algn modulo despus de
haber sido puesto en produccin
Se trata de evaluar si el cambio introduido
afecta de forma errnea al funcionamiento
de otros mdulos
Es importante tener automatizadas las
pruebas para, despus de implementar el
cambio, poder ejecutarlas sin perder
mucho tiempo.
Pruebas de aceptacin
Estas pruebas las realiza el cliente

para validar el desarrollo
Son bsicamente pruebas funcionales,
sobre el sistema completo, y buscan
una cobertura de la especificacin de
requisitos y del manual del usuario
Estas pruebas no se realizan durante
el desarrollo, pues sera impresentable
al cliente; sino que se realizan sobre
el producto terminado e integrado o
pudiera ser una versin del producto o
una iteracin funciona pactada
previamente con el cliente
Implantacin de software

Indice
Implantacin
Instalacin de hardware
Instalacin de software
Bases de datos
Configuracin
Los equipos de operacin
Documento de operacin
Documento de paso a produccin
Copia de seguridad y marcha atrs
Monitorizacin de las aplicaciones
La importancia del control de cdigo
La formacin a los usuarios
El retorno de inversin
Implantacin
La implantacin es el proceso de verificar e

instalar nuevo equipo, instalar la aplicacin,
construir todos los archivos de datos
necesarios para utilizarla y entrenar a los
usuarios.
Cada estrategia de implantacin tiene sus
mritos de acuerdo con la situacin que se
considere dentro de la empresa. Sin
importar cul sea la estrategia utilizada, los
encargados de desarrollar el sistema
procuran que el uso inicial del sistema se
encuentre libre de problemas.
Los sistemas de informacin deben
mantenerse siempre al da, la implantacin
es un proceso de constante evolucin.
Instalacin de hardware
En muchos proyectos tambin es
necesario instalar el hardware sobre el que
va a funcionar
Cuando se instala el entorno de

produccin es aconsejable instalar
tambin el de integracin, para que sean
similares (replicacin de entornos)
Redundancia: para aplicaciones crticas es

mejor no tener una sla sola mquina en
produccin: se utiliza redundancias para
aumentar la disponibilidad
Cada vez se tiende ms hacia la

virtualizacin de las mquinas, lo que
facilita la redundancia, las copias de
seguridad y la replicacin de entornos
Instalacin de software
La instalacin y actualizacin de software

debe automatizarse lo mximo posible:
Instaladores
Scripts que copien la aplicacin a todos los
equipos
No slo tenemos que instalar nuestra

aplicacin, tambin sistema operativo y
aplicaciones auxiliares: BBDD, etc.
Hay lenguajes que tienen mecanismos

para realizar estas actualizaciones de
forma automtica:
Java Web Start: la aplicacin, al arrancar,

consulta sus partes que se han modificado, se
las descarga y se ctualiza automticamente
Bases de datos
Cuando pasamos a produccin una

aplicacin con BBDD nos podemos
encontrar con dos escenarios:
Creacin por primera vez de la BBDD: se

proporciona un script con todas las sentencias
de creacin de la BBDD y la insercin en tablas
de todos los datos necesarios
Actualizacin: es necesario tener scripts que
incluyan los cambios entre la version anterior y
la nueva:
Aadir/borrar columnas
Modificar datos
Insertar/borrar filas
Configuracin
Es muy importante, ya normalmente el

correcto funcionamiento de la aplicacin
depende de su correcta configuracin
Abarca:
Conexiones a BBDD
Conexiones a otras mquinas: FTP, web
services, etc
Parmetros dentro de la aplicacin, etc.
Hay aplicaciones cuya adaptacin a la

empresa se hace completamente por
configuracin (CRMs, ERPs...) y es un
proceso mutuo en el que se adapta la
aplicacin a la empresa y la empresa a la
aplicacin
Los equipos de operacin
Son equipos en las empresas que se

encargan del mantenmiento de los
sistemas, lo que se suele llamar operacin
de sistemas
Entre sus tareas estn las de:
Instalar/mantener el hardware
Instalar las nuevas aplicaciones
Actualizar las versiones de las aplicaciones
existentes
Gestionar las copias de seguridad y las
restauraciones en caso de desastres
Monitorizar el rendimiento de las aplicaciones
Gestionar la seguridad global de la empresa
Documento de operacin
Cada aplicacin debe tener un documento
destinado al equipo de operacin
En este documento debe figurar:
De qu ficheros consta la aplicacin

Cmo se instala y se actualiza la aplicacin
Cmo configurar la aplicacin
Las operaciones de mantenimiento
Cmo se hacen las copias de seguridad y la
recuperacin de desastres
Cmo monitorizar la aplicacin
Documento de paso a produccin
En aplicaciones complejas tambin es

necesario, para cada actualizacin de la
aplicacin elaborar un documento en el que
se indiquen:
Los cambios que incluye la nueva versin de la

aplicacin
Cundo se va a pasar y si requiere corte en el
servicio o no
Los pasos que hay que realizar para actualizar
la aplicacin
Cmo comprobar que los cambios funcionan
correctamente
Copia de seguridad y marcha atrs

Es necesario que todo paso a produccin
sea reversible para volver atrs en caso de
que se poduzca un error
Para ello, hay que proporcionar:
un mecanismo de copia de seguridad (backup)

un mecanismo de marcha atrs (rollback)
Es preferible que este proceso est

automatizado
Esta copia de seguridad tiene que englobar

al software modificado, los ficheros de
configuracin y la base de datos
Monitorizacin de aplicaciones
Una vez puesta en produccin, es necesario

monitorizar los siguientes parmetros de la
aplicacin:
uso de CPU
memoria consumida
espacio en disco
uso de red
Para ello hay software especfico que

permite a las empresas controlar su
infraestructura de aplicaciones:
Nagios
OSSIM
SNMP (Simple Network Management Protocol):
protocolo para intercambiar informacin
La importancia del control del cdigo
En una empresa los proveedores de TI

pueden ser varios y se puede cambiar entre
ellos
Si no se dispone del cdigo fuente de las
aplicaciones que llevan la lgica de negocio
de nuestra empresa, estaremos atndonos
a un solo proveedor
En empresas grandes es muy importante
tener un sistema de control de versiones
bajo el control de la empresa, donde los
desarrolladores de las empresas
proveedoras suban el cdigo de las
aplicaciones que realizan
La formacin a los usuarios (I)

Es una parte bsica de la implantacin de
software, sobre todo cuando ste interacta
con los usuarios
Lo peor que puede pasar es que los

usuarios no acepten la aplicacin o no sean
capaces de usarla
Se suelen impartir jornadas de formacin a

los distintos grupos de usuarios en las que:
Se presenta la aplicacin y se explican sus

bondades (importante para su aceptacin)
Se realizan casos prcticos de uso (importante
para la comprensin)
La formacin a los usuarios (II)

En las jornadas de formacin suelen
participar los responsables del proyecto,
tanto por parte del cliente como del
proveedor
Es bueno acompaar la formacin con la

entrega de manuales, que pueden ser
distintos en funcin del grupo de usuarios
El retorno de inversin (II)
El ROI (Return Of Investments) es el

beneficio que obtenemos por cada unidad
monetaria invertida en tecnologa durante
un periodo de tiempo.
Esto es lo que busca cada cliente que
implanta una aplicacin
Suele utilizarse para analizar la viabilidad
de un proyecto y medir su xito.
ROI=(Beneficios/Costes)x100
El coste es sencillo de medir: siempre
sabemos cunto nos estamos gastando lo
complicado es calcular el beneficio.
El retorno de inversin (I)
Por qu es complicado medir los beneficios:
Lo que entiende cada uno como beneficios

La entrada en juego de factores como el cambio
tecnolgico
El desorden al controlar y medir finanzas
La dificultad a la hora de medir los tiempos que
se ahorran los usuarios
Dificultad para imputar mejoras de rendimiento
en el beneficio
Hay cosas intangibles como la satisfaccin de
los usuarios
Manuales de las aplicaciones

Indice
Introduccin
Tipos de manuales
Apartados del manual
Formatos de manuales
Acceso a los manuales
Introduccin
Los manuales es un entregable
imprescindible en los proyectos
Deben ser presupuestados correctamente,

ya que el escribir documentacin suele
llevar siempre ms tiempo de lo previso
Facilitan la comprensin de la aplicacin y

la resolucin rpida de dudas
Reducen el nivel de consultas sobre el

departamento tcnico
Tipos de manuales
Los manuales se suelen realizar en funcin

del perfil de usuario que los vaya a leer:
Otras veces se separan as
Administrador
Usuario
Manual de uso rpido
Manual avanzado
A continuacin mostramos una estructura

tpica de un manual de una aplicacin
informtica:
Apartados
del
manual
(I)
Introduccin
Presentacin del sistema
Requisitos de Configuracin de Hardware

Distribucin del Sistema y Autorizacin de Uso
Atencin al Usuario
Esquema de Estados
Perfiles o Niveles de acceso al sistema
Primeros Pasos
Cmo acceder al sistema

Men principal Nivel Usuario
Cambio de claves de acceso
Cmo salir del sistema
Cmo actuar ante una incidencia
Apartados del manual (II)
Uso avanzado: en esta seccin se

encuadran todas las funcionalidades
avanzadas de las que disponga la
aplicacin:
Funcin 1
Funcin 2
...
Troubleshooting, o resolucin de
problemas frecuentes
Glosario: los trminos y abreviaturas a

comprender en el resto del documento
Formatos de manuales
Los manuales pueden ser presentados en

varios formatos:
Papel: aporta tangibilidad al proyecto

Word: problemas a la hora de imprimirlo y
empotrarlo en aplicaciones web
PDF: til para ser impreso. Tambin se puede
empotrar en web de forma sencilla
HTML: facilita la integracin con las
aplicaciones web, pero dificulta el mantener una
copia impresa con el mismo contenido
Archivo de Ayuda de Windows CHM: no es
multiplataforma, slo tiene sentido en
aplicaciones locales
Wiki: este mtodo aporta facilidad de
actualizacin y posibilidad de participacin de
los usuarios de la aplicacin
Acceso a los manuales

Es aconsejable que una copia del manual
est siempre accesible desde la aplicacin
En caso de la web, se puede disponer en

la portada de la aplicacin
En caso de aplicaciones locales, se

pueden utilizar sistemas de ayuda CHM,
pero tambin se puede poner un enlace a
la web de documentacin

Empresa y La Gestion de Proyectos

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Empresa y La Gestion de Proyectos

Încărcat de

Drepturi de autor:

Formate disponibile

Apuntes de la Asignatura de

Alberto Alonso Ruibal

Organizacin jerrquica pura

Tambin se llama lineal o por

Sobrecarga a personas con deberes

Organizacin funcional (I)

Definida por Taylor, que divide las actividades de

Organizacin funcional (II)

Organizacin territorial (I)

Organizacin territorial (II)

Organizacin por productos o servicios

Organizacin por clientes

Organizacin de lnea y staff

Las funciones empresariales

Algunos autores consideran slo como

La funcin de recursos humanos

Funcin de produccin (I)

Funcin de produccin (II)

Alberto Alonso Ruibal

Es un documento escrito por los promotores

No debe confundirse con una simulacin de

La utilidad del Plan de Empresa es doble:

Internamente obliga a los promotores del

Esto garantiza la plena implicacin de

Una posible estructura de Plan de Empresa

Cmo presentarlo? (I)

Todos los elementos detallados formarn

Cmo presentarlo? (II)

La mayora de los profesionales

Un dossier principal breve y anexos: breve

Proyectos TI, Metodologas y

Alberto Alonso Ruibal

Por qu es necesaria la gestin de

Ciclo de vida de un proyecto

Slo hace falta

Un proyecto es una accin en la que

Complejidad intrnseca al desarrollo de

Imprecisin en la planificacin del proyecto y

Baja calidad de las aplicaciones.

Dificultad de mantenimiento de las

Esto hace surgir una rama de la ciencia

Ciclo de vida de un proyecto

Es la forma en la que se divide un proyecto

Modelo en cascada (I)

Modelo en cascada (II)

Objetivo de cada una de las etapas:

Especificacin de requisitos: Documento con

Implantacin: Documento de operacin

Modelo en cascada (III)

Minimiza la repeticin de tareas de desarrollo

Facilita el control, permitindonos afrontar

Solo es adecuado cuando hay requerimientos

Retroceder para corregir fases previas o

El cliente slo ve los resultados al final

Modelo orientado a hitos (I)

Modelo orientado a hitos (II)

El cliente va viendo los resultados

Permite reducir mucho el riesgo en proyectos

Se analiza todo el sistema al principio, y se

Modelo orientado a prototipos (I)

Modelo orientado a prototipos (II)

Es muy frecuente que los requisitos sean

El cliente ya puede ir trabajando con los

En proyectos grandes es imposible saber