Apuntes de la Asignatura

de Empresa y Gestin de
Proyectos
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
empresade una empresa puede
La organizacin
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 staf
 Organizacin jerrquica
pura Tambin se llama lineal o
por nmeros
A Cada persona recibe ordenes
de un solo jefe, prevaleciendo
B el principio de jerarqua y de
subordinacin absoluta a su
inmediato superior.
C D Inconvenientes:
Sobrecarga a personas con
deberes y responsabilidad
E F G H
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 Productos de Productos

caballeros seoras 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
staf
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 OUTPUTS
Transformacin
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

Es el modelo clsico
Anlisis

Las fases se deben
Diseo
ejecutar de forma
secuencial, pero se puede
Codificacin
volver a la fase anterior

Cada etapa genera una
Pruebas documentacin o un
producto que recibe de
Implantacin entrada la siguiente fase

Mantenimiento
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

Consiste en introducir
Anlisis hitos entregables al
cliente durante el
Diseo de arquitectura 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) Se desarrolla un primer

prototipo relativamente
Prototipo 1
completo, frecuentemente
destinado a ser ya
utilizado por cliente.

El cliente aporta
Prototipo 2
realimentacin y con ella
se desarrolla el siguiente
prototipo
Prototipo 3
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:
Reuniones con el cliente
Estimacin de duracin, coste y esfuerzo
(esto es, presupuestacin)
Planificacin de tareas y asignacin de
recursos
Seguimiento y control
Importancia de la
documentacin

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
Reuniones con el cliente

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
Reuniones con el cliente

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
Se aade a las tareas para cubrir errores en
las estimaciones

Margen comercial
Se aade para cubrir las tareas comerciales
y para poder negociar bajando el precio al
bajar este margen

Margen de calidad
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

Importancia de la documentacin

Anlisis funcional

Casos de uso
Especificacin
Diagramas
Pruebas

Qu ms incluir en el documento
Importancia de la
documentacin

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
Usa: cuando se quiere
discontinuas, y
pueden serunde dos tipos:

reflejar
comportamiento comn
en varios casos de uso.
Extiende: cuando se

quiere reflejar un
comportamiento opcional
de un caso de uso
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 estados
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
Diagramas de estados

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-trac
ker/
)
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
Indice

Calidad
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:
Administrador
Usuario

Otras veces se separan as

Manual de uso rpido
Manual avanzado

A continuacin mostramos una

estructura tpica de un manual de una
aplicacin informtica:
Apartados

Introduccin
del manual (I)

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