Este documento presenta los conceptos clave de organización empresarial y gestión de proyectos. Explica los objetivos de una empresa, diferentes tipos de estructuras organizativas como la jerárquica, funcional o territorial, y las funciones empresariales como dirección, recursos humanos, financiera, marketing y producción. Además, describe varios modelos de ciclo de vida de proyectos como el en cascada, orientado a hitos, orientado a prototipos y de programación extrema.

1. Apuntes de la Asignatura de
Empresa y Gestión de
Proyectos

2. Organización y Funciones
Empresariales
Anthony Lopez
Ci: 19.683.715

3. Indice
• Concepto de empresa
• Organización de la empresa
• Funciones empresariales

4. Objetivo
• ¿Cuál es el objetivo de una empresa?
– Supervivencia y crecimiento del negocio
– Obtención de utilidades/generación de
servicios
– Imagen y prestigio
– Aceptación social
– Satisfacción de necesidades colectivas

5. Concepto de empresa
• Se entiende por empresa al organismo
social integrado por elementos humanos,
técnicos y materiales cuyo objetivo natural
y principal es la obtención de utilidades, o
bien, la prestación de servicios a la
comunidad, coordinados por un
administrador que toma decisiones en
forma oportuna para la consecución de los
objetivos para los que fueron creadas.

6. Organización de la empresa
• La organización de una empresa puede
definirse como el conjunto de todas las formas
en que se divide el trabajodivide el trabajo en tareas distintas,
considerando luego la coordinación de las
mismas.
• Distintos tipos de estructuras organizativas:
– Organización jerárquica pura
– Organización funcional
– Organización territorial
– Organización por productos o servicios
– Organización por clientes
– Organizacion mixta
– Organización de línea y staff

7. Organización jerárquica pura
• También se llama “lineal” o “por
números”
• Cada persona recibe ordenes de
un solo jefe, prevaleciendo el
principio de jerarquía y de
subordinación absoluta a su
inmediato superior.
• Inconvenientes:
– Sobrecarga a personas con deberes
y responsabilidad
– Excesiva rigidez que no permite que
se implanten las ventajas de la
especialización
B
C D
E F
A
G H

8. Organización funcional (I)
• Definida por Taylor, que divide las actividades de
una empresa según las funciones asignadas. a
cada una de ellas
Dirección
Producción Marketing Financiero Recursos
humanos

9. Organización funcional (II)
• Ventajas:
– Es una organización muy probada y con éxito
– Procura e incide en la especialización del
trabajo facilitando el aprovechamiento de los
recursos, la formación y el control
• Inconvenientes:
– La responsabilidad de los resultados globales
se concentra en la cúspide de la organización
– No hay unidad de mando, lo que dificulta la
organización, puede originar posibles conflictos
de competencias, retrasos en las decisiones,
etc.

10. Organización territorial (I)
• En empresas de gran tamaño, se divide la
organización en distintas áreas según la
zona territorial a la que se atienda
Dirección
España PortugalFrancia

11. Organización territorial (II)
• Ventajas:
– Intensifica la responsabilidad por los resultados
– Aproxima las decisiones a las características
de cada territorio
• Inconvenientes
– Dificulta el control
– Pueden perderse economías de escala
– Requiere mayor número de directivos

12. Organización 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
Dirección
Producto A Producto CProducto B

13. Organización 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
Dirección
Productos de
caballeros
Productos de
señoras
Productos
infantiles

14. Organización mixta
• En casi todos los casos reales se mezclan
los anteriores sistemas de organización
• Ventajas:
– Adecuación de la organización a las
necesidades de la empresa
• Inconvenientes:
– Al mezclar criterios a veces se origina
descoordinación

15. Organización de línea y staff
• Se basa en la idea de Hery Fayol quien
sugirió la incorporación de comités
compuestos de asesores especialistas,
preservando la unidad de mando.
• No se proporciona autoridad a los
especialistas para dar ordenes, sólo se les
consulta para que ayuden en las tomas de
decisión al resto de personal.

16. Las funciones empresariales
• Se dividen principalmente en 5:
– Dirección
– Recursos humanos
– Financiera
– Marketing
– Producción
• Algunos autores consideran sólo como
básicas las funciones Financiera, de
Marketing y de Producción

17. La función de dirección
• La dirección 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

18. La función de recursos humanos
• Se encarga de:
– Selección de empleados
– Organización de personal
– Gestión de contratos y nóminas
– Análisis de puestos
– Formación
– Relaciones laborales
– Servicios sociales

19. La función financiera
• La función financiera incluye los
siguientes aspectos:
– Facturación: facturas, albaranes...
– Contabilidad
– Tributación: hacienda, seguridad social,
impuestos locales, etc
– Financiación: obtención de recursos; cuentas
de crédito, descuentos de papel, etc.

20. La función de marketing
• Regla de las cuatro P’s
– Producto: definición, estudios de mercado,
atención al cliente, soporte postventa, etc.
– Promoción: imagen corporativa, publicidad,
comerciales, etc.
– Precio: análisis de costes, fijación del precio,
descuentos, etc.
– Distribución (Placement): almacenes, red de
distribución, etc.

21. Función de producción (I)
• Empleo de factores humanos y materiales
para la producción de bienes y servicios
• Proceso en el cual una serie de entradas
(factores o inputs) se transforman en
salidas (productos o outputs)
INPUTS OUTPUTS
Transformación

22. Función de producción (II)
• Tipos de transformaciones:
– Físicas, como en las operaciones de
fabricación.
– De lugar, como en el transporte o en las
operaciones de almacenamiento.
– De intercambio, como en las operaciones con
los minoristas.
– Fisiológicas, como en el caso de la sanidad.
– Psicológicas, como en el caso de los servicios
de entretenimiento.
– Informacionales, como en el caso de las
comunicaciones

23. Bibliografía
• Guía para crear tu empresa. Álvaro López
Amo, Ed. Espasa.
• http://www.monografias.com

24. Plan de empresa

25. Indice

¿Qué es un plan de empresa?

¿Para qué sirve?

¿Quién ha de elaborarlo?

¿Cómo se estructura?

¿Cómo presentarlo?

26. 
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 están
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 simulación
de cuentas de documentos financieros
provisionales.
¿Qué es un plan de Empresa?

27. ¿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 mínimos de coherencia, eficacia,
rigor y posibilidades de éxito, estudiando
todos los aspectos de viabilidad del mismo.
Además sirve de base para cohesionar el
equipo promotor del proyecto, permitiendo
definir claramente los cargos y las
responsabilidades, y verificar que están de
acuerdo acerca de los objetivos y la estrategia
a seguir.
− Externamente es una espléndida carta de
presentación del proyecto a terceros, que
puede servir para solicitar soporte financiero,
buscar socios, contactar con proveedores,
Administraciones, etc. Además, servirá de
referencia para la acción futura de la empresa
y como instrumento de medida de los
rendimientos alcanzados.

28. ¿Quién ha de elaborarlo?

Es muy importante que en la elaboración
del Plan de empresa participen todos los
socios o promotores del proyecto.

Esto garantiza la plena implicación de
todos en los objetivos de la empresa y en
la manera de alcanzarlos.

29. ¿Cómo se estructura?

Una posible estructura de Plan de
Empresa puede ser la siguiente:
− INTRODUCCIÓN
− PLAN DE MARKETING
− PLAN DE OPERACIONES
− PLAN DE RECURSOS HUMANOS
− PLAN DE INVERSIONES Y UBICACIÓN
− PLAN ECONÓMICO FINANCIERO
− ESTRUCTURA LEGAL DE LA EMPRESA
− CALENDARIO DE EJECUCIÓN
− RESUMEN Y VALORACIÓN
− ANEXOS

30. ¿Cómo 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 páginas como
máximo.

Todos los elementos detallados formarán
parte de anexos.

31. ¿Cómo presentarlo? (II)

La mayoría de los profesionales
recomiendan respetar un cierto número de
reglas:
− Un dossier principal breve y anexos: breve
resumen sobre las conclusiones del estudio
de mercado, comentarios acerca de los
documentos financieros, presentación
comprensible de los datos técnicos, etc.
− Un resumen obligatorio, de una o dos
páginas. Se trata, en cierto modo, de un
“folleto” o página de publicidad con la cual el
empresario trata de “vender” su empresa.
− Se aconseja realizar una presentación
estructurada, clara y concisa, cuidando los
aspectos formales y escrito a máquina o
impresora.

32. Proyectos TI, Metodologías y Ciclos
de Vida

33. Indice

¿Por qué es necesaria la gestión de
proyectos?

Definición de proyecto

Ciclo de vida de un proyecto
− En cascada
− Orientado a hitos
− Orientado a prototipos
− Programación extrema
− Métrica v3

34. La caseta de mi perro

Sólo hace falta
una persona

No requiere un
análisis previo,
presupuestos,
documentación,
etc.

35. Un edificio

Son necesarios
varios equipos de
trabajo

Es necesario una
especificación re
requisitos, un
análisis, una
planificación...
esto es un
proyecto

36. Definición de proyecto

Un proyecto es una acción 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
límites de costes y tiempo, se intenta
conseguir un cambio beneficioso
dirigido por unos objetivos
cualitativos y cuantitativos.

37. Proyectos de TI
La gestión de proyectos TI es más
compleja por:
− Complejidad intrínseca al desarrollo de
software
− Imprecisión en la planificación del proyecto y
estimación 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 Ingeniería de Software que
intenta resolver estos problemas

38. Ciclo de vida de un proyecto

Es la forma en la que se divide un
proyecto en etapas y cómo se avanza
entre estas etapas

Según la metodología hay varios modelos,
pero analizaremos los siguientes:
− En cascada
− Orientado a hitos
− Orientado a prototipos
− Programación extrema
− Métrica v3

39. Modelo en cascada (I)

Es el modelo clásico

Las fases se deben
ejecutar de forma
secuencial, pero se puede
volver a la fase anterior

Cada etapa genera una
documentación o un
producto que recibe de
entrada la siguiente fase
Especificación
de requisitos
Análisis
Diseño
Codificación
Pruebas
Mantenimiento
Implantación

40. Modelo en cascada (II)

Objetivo de cada una de las etapas:
− Especificación de requisitos: Documento con
la especificación de requisitos (ERQ)
− Análisis: Documento de análisis funcional
− Diseño: Documento de diseño técnico
− Codificación: Código fuente de la aplicación y
manuales de usuario
− Pruebas: Documentación de pruebas
− Implantación: Documento de operación

41. Modelo en cascada (III)

Ventajas
− Minimiza la repetición de tareas de desarrollo
− La planificación es sencilla
− Facilita el control, permitiéndonos 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 sólo ve los resultados al final

42. Modelo orientado a hitos (I)

Consiste en introducir
hitos entregables al
cliente durante el
desarrollo del proyecto
Especificación
de requisitos
Análisis
Diseño de arquitectura
Codificación y pruebas A
Codificación y pruebas B
Entrega B
Codificación y pruebas C
Entrega A
Entrega C

43. Modelo orientado a hitos (II)

Ventajas
− El cliente va viendo los resultados
− Permite reducir mucho el riesgo en proyectos
grandes si se gestionan sus módulos de
menor prioridad con esta técnica

Inconvenientes
− Se analiza todo el sistema al principio, y se
puede perder mucho tiempo en la
especificación y diseño de funcionalidades
que al final no nos da tiempo a implementar

44. Modelo orientado a prototipos (I)
Se desarrolla un primer
prototipo relativamente
completo, frecuentemente
destinado a ser ya utilizado
por cliente.

El cliente aporta
realimentación y con ella se
desarrolla el siguiente
prototipo

Se van repitiendo los ciclos
de iteración hasta alcanzar
una versión final.
Prototipo 1
Prototipo 2
Prototipo 3

45. 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 análisis y diseño

46. Programación extrema (I)

Consiste en llevar la límite el modelo de
prototipos, haciendo entregas continuas
con pequeños cambios en la funcionalidad

47. Programación extrema (II)

Sus principios fundamentales son:
− Desarrollo iterativo e incremental
− Pruebas unitarias continuas
− Programación en parejas
− Frecuente interacción con el usuario
− Corrección de todos los errores antes de
añadir nueva funcionalidad
− Hacer entregas frecuentes
− Refactorización del código
− Propiedad del código compartida
− Simplicidad en el código

48. Programación extrema (III)
Ventajas
− Es muy realista con respecto a la relación con
el cliente
− Le da importancia el diseño simple y las
pruebas, un punto normalmente descuidado
− Aporta muy buenas ideas

Inconvenientes
− Solo vale para proyectos relativamente
pequeños (entre 2 y 12 desarrolladores)
− Sus principios no pueden ser aplicados a
rajatabla, es necesario saber decidir cuando
aplicar ciertas cosas y cuándo no

49. Modelo métrica v.3 (I)

Metodología de Planificación, Desarrollo y
Mantenimiento de Sistemas de
información promovida por el MAP

Interfaces orientados a la gestión de los
procesos:
− Gestión de proyectos (GP).
− Seguridad (SEG).
− Aseguramiento de la Calidad (CAL).
− Gestión de la Configuración (GC).

50. Modelo métrica v.3 (II)
Procesos:
− Planificación de Sistemas de Información (Proceso
PSI)
− Desarrollo del Sistema de Información (Proceso DSI)

Estudio de Viabilidad del Sistema (Proceso EVS)

Análisis del Sistema de Información (Proceso ASI)

Diseño del Sistema de Información (Proceso DSI)

Construcción del Sistema de Información (Proceso
CSI)

Implantación y Aceptación del Sistema (Proceso
IAS)
− Mantenimiento del Sistema de Información (Proceso
MSI)

51. Bibliografía

Gestión de Proyectos IT con éxito:
http://www.aqs.es

Programación extrema:
http://www.extremeprogramming.com

Métrica v3:
http://www.csi.map.es/csi/metrica3/

52. Gestión de proyectos: ERQs y
presupuestos

53. Indice

Gestión del proyecto

Importancia de la documentación

Reuniones con el cliente

Especificación de requisitos

Presupuestación

54. Gestión del proyecto

La gestión del proyecto es la aplicación del
conocimiento, habilidades, herramientas y
técnicas a las actividades del proyecto
para conseguir cumplir los requisitos del
proyecto

Tareas críticas:
− Reuniones con el cliente
− Estimación de duración, coste y esfuerzo
(esto es, presupuestación)
− Planificación de tareas y asignación de
recursos
− Seguimiento y control

55. Importancia de la documentación

En los proyectos de software la
documentación es de vital importancia:
− El software es algo abstracto, la
documentación aporta algo tangible al
proyecto.
− Documentar ayuda a compartir información
entre usuarios y desarrolladores.
− Permite acotar el proyecto.
− Evita tomar decisiones precipitadas que
pueden llevar a resultados catastróficos.
− Facita la formación tanto de los usuarios
como los desarrolladores

56. Reuniones con el cliente

Motivación 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 técnicas: para discutir el diseño
técnico o el análisis funcional
− Reuniones de control: sobre un Gantt analizar
el punto en el que se encuentra el proyecto y
las posibles variaciones sobre la planificación

57. Errores frecuentes en las reuniones (I)

Acompañarse 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 más, desvelando excesiva
información sobre nuestra empresa u otros
proyectos

58. Errores frecuentes en las reuniones (II)

Cuidar la vestimenta, las formas y el
lenguaje corporal

No ignorar a los técnicos

Tomar notas (puede estar bien grabarlas
en audio o incluso levantar un “acta” de la
reunión y enviarla por email)

¡Cuidado con las conversaciones
informales!

59. Especificación 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 diseño

60. Especificación de Requisitos (II)

Como deben ser los requisitos:
− Completos
− Implementación independiente
− Consistentes y no ambiguos
− Precisos
− Verificables
− Que puedan ser leídos
− Modificables

Muy importante: que nos permitan hacer
un presupuesto

61. Especificación de Requisitos (III)

La toma de requisitos:
− Introspección: ponerse en lugar del cliente e
imaginar como desea que funcione el sistema
− Reuniones con el cliente

Escuchar la problemática del cliente

Entender la solución que espera

Ser capaz de orientar y aconsejar al cliente
durante la entrevista para orientarlo hacia nuestros
productos o tecnologías

Hay modelos estándard para la toma de
requisitos, de los cuales se cubre lo que
necesitemos

62. Presupuestación

¿Cuanto dinero va a costar realizar el
proyecto?

Lo más difícil 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
implementación se suelen cobrar por hora,
pero hay más cosas que contemplar en los
presupuestos...

63. Qué presupuestar (I)

Análisis: el análisis del problema posterior
al presupuesto previo a la elaboración del
documento de análisis funcional y del
diseño técnico

Consultoría: cuando el objetivo del
proyecto es la recomendación de medidas
apropiadas y prestación de asistencia en
la aplicación de dichas recomendaciones.

Preparación del entorno: instalación de
servidores, aplicaciones (CVS, IDEs, etc),
etc.

64. Qué presupuestar (II)

Implementación: las tareas de
programación en sí

Dirección de proyecto: las horas que
dedica el director de proyecto a la
coordinación de los programadores (se
suele poner un 25% del tiempo de
implementación)

Implantación: instalación de la aplicación
en los entornos del cliente. Cuidado con
las subidas de los hitos entregables a los
entornos del cliente

65. Qué presupuestar (II)

Formación: suele estar hasta bien visto por
el cliente dar un par de charlas de
formación a los usuarios sobre la
aplicación

Documentación: análisis funcional, diseño
técnico, manuales, documentos de puesta
en producción, 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...

66. Los márgenes

Margen de riesgo
− Se añade a las tareas para cubrir errores en
las estimaciones

Margen comercial
− Se añade 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 código

Margen al tiempo de entrega
− Se añade para cubrirse frente a que los
recursos se tenga que dedicar a otras tareas

67. 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 sólo al final del
proyecto, sobre todo en proyectos largos,
porque nos puede traer problemas
financieros

Tener cuidado con empresas que pagan
con pagarés a 30, 60 o incluso 90 días

68. Clausulas de penalización

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 estimación de
tiempos, sobre todo aplicando margen al
tiempo de entrega

69. El cálculo de la rentabilidad

Es muy importante tener un modelo de
presupuesto que luego nos permita hacer
un cálculo de la rentabilidad sobre los
tiempos estimados

Para ello durante la fase de
implementación 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

70. Otras formas de presupuestar

Muchas veces lo que se presupuestan no
son sólo proyectos, pueden ser:
− Productos de software ya terminados: lo que
se vende es la licencia y en muchos casos la
implantación.
− Mantenimientos mensuales: con una cuota fija
al mes para realizar tareas de mantenimiento
de una aplicación.
− Packs de horas: se le cobran al cliente X
horas que éste irá consumiendo según se
vayan realizando desarrollos solicitados.

71. 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
aplicación
− Por CPU de servidor
− etc.

72. Planificación: PERTs y Gantts

73. Indice
Planificación

Diagramas PERT
− Actividades y sucesos
− Representación
− Tecnicas PERT

Camino crítico

Diagramas Gantt
− Representación
− Dependencias de tareas
− Estimación y asignación de recursos
− Gráfico de ocupación de recursos

74. Planificación

La planificación de un proyecto es la
previsión en fechas de la realización 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 planificación se
deben utilizar diversas técnicas, algunas
de las cuales se exponen a continuación.

75. 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 construcción de los misiles balísticos
Polaris.

Está orientada a los sucesos o eventos, y
se ha utilizado típicamente en proyectos
de I+D en los que el tiempo de duración de
las actividades es una incertidumbre.

76. Actividades y sucesos

Actividad: la ejecución de una tarea, que
exige para su realización la utilización 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, sólo
indica el principio o el fin de una actividad
o de un conjunto de actividades.

77. Representación de Diagramas PERT

Círculos: Sucesos

Flechas: Actividades

78. Diagramas PERT (II)

Con un diagrama PERT se obtiene un
conocimiento preciso de la secuencia
necesaria, o planificada para la ejecución
de cada actividad.

Muy orientado al plazo de ejecución, con
poca consideración hacia al coste.

Se suponen tres duraciones para cada
suceso, la optimista a, la pesimista b y la
normal m; suponiendo una distribución
beta, la duración más probable es: t = (a +
4m + b) / 6 .

79. Técnicas PERT

Conjunto de modelos para la
programación y análisis de proyectos de
ingeniería que sirven para:
− Determinar las actividades necesarias y
cuando lo son.
− Buscar las ligaduras temporales entre
actividades del proyecto.
− Buscar el camino crítico.
− Detectar y cuantificar las holguras de las
actividades no críticas
− Si se está fuera de tiempo durante la
ejecución del proyecto, señala las actividades
que hay que forzar.

80. Camino crítico

El camino crítico en un proyecto es la
sucesión de actividades que dan lugar al
máximo tiempo acumulativo.

Determina el tiempo más corto que
podemos tardar en hacer el proyecto si se
dispone de todos los recursos necesarios.

Para calcularlo es necesario conocer la
duración de las actividades que están en
el camino crítico y sumar sus tiempos:
− Método del tiempo estimado (CPM): se utiliza
el cálculo del tiempo medio: Te = m
− Método del tiempo esperado (PERT): Te = (a
+ 4m + b) / 6

81. Diagramas Gantt

Inventado por Charles Gantt en 1917

El diagrama de Gantt o cronograma tiene
como objetivo la representación del plan
de trabajo, mostrando las tareas a realizar,
el momento de su comienzo y su
terminación y la forma en que las distintas
tareas están encadenadas entre sí.

Es la forma habitual de presentar el plan
de ejecución de un proyecto.

82. Representación de diagramas Gantt (I)

Se representan de la siguiente forma:
− En las filas la relación de actividades a
realizar
− En las columnas la escala de tiempos que se
está manejando
− La duración y situación en el tiempo de cada
actividad se indica mediante un rectángulo
dibujado en el lugar correspondiente.
− Los hitos se marcan con rombos
− El porcentaje de realización de la tarea se
indica con una línea dentro del rectángulo de
la tarea
− Las fases se marcan con lineas sobre los
rectángulos de las tareas

83. Representación de diagramas Gantt (II)

84. Dependencias de tareas

Al igual que en el PERT, en el Gantt
también 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.

85. Estimación de recursos

La estimación de recursos consiste en
indicar cuántos recursos (personas) serán
necesarias para llevar a cabo el proyecto

El mayor factor condicionante en el
número de recursos será el tiempo de
entrega

Hay un límite, muy asociado con el camino
crítico (y con el asignar una tareas a más
de una persona), por encima del cual
asignando más recursos no
conseguiremos una reducción del tiempo

86. Asignación de recursos (I)

La asignación de recursos es una tarea
fundamental en la planificación, ya que
hay que considerar aspectos técnicos de
cada recurso como su disponibilidad,
capacidad de trabajo,impedimentos
horarios, etc.

Cuantificar necesidades y fechas de
incorporación de recursos.

Considerar la capacidad, los
conocimientos y la experiencia de cada
recurso.

Considerar la complejidad, el tamaño y los
requerimientos técnicos de cada tarea.

87. Asignación de recursos (II)

Asignar tareas sencillas a recursos con
poca experiencia.

Asignar tareas complejas a recursos con
mucha experiencia.

Construir el gráfico de ocupación 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 vacíos en el gráfico de
recursos.

88. Gráfico de ocupación de recursos

Es un gráfico que muestra, en cada
periodo de tiempo el porcentaje de
ocupación de cada uno de los recursos.

Intentar mantener la ocupación de
recursos al 100%

... pero no sobrepasar el 100%

89. Aplicaciones informáticas

Microsoft Project: sistema completo de gestión
de proyectos, sólo para windows
http://www.microsoft.com/Project

Microsoft Visio: aplicacición para el diseño de
diagramas http://office.microsoft.com/visio

GanttProject: aplicación Java orientada a la
creación de Gantts http://www.ganttproject.biz

Imendio Planner: aplicación de planificación para
Linux
http://developer.imendio.com/projects/planner

Yed: editor de diagramas para Java:
http://www.yworks.com/products/yed

Dia: aplicación para dibujar diagramas en Linux
http://www.gnome.org/projects/dia

90. Análisis Funcional y Casos de Uso

91. Indice

Importancia de la documentación

Análisis funcional

Casos de uso
− Especificación
− Diagramas
− Pruebas

Qué más incluir en el documento

92. Importancia de la documentación

En los proyectos de software la
documentación es de vital importancia:
− El software es algo abstracto, la
documentación aporta algo tangible al
proyecto.
− Documentar ayuda a compartir información
entre usuarios y desarrolladores.
− Permite acotar el proyecto.
− Evita tomar decisiones precipitadas que
pueden llevar a resultados catastróficos.
− Facita la formación tanto de los usuarios
como los desarrolladores

93. Análisis funcional

En informática, el análisis funcional es
aquél que describe que se va a desarrollar,
sin entrar en como se desea hacerlo, que
es el objetivo del análisis orgánico (o
técnico).

Se utilizan varias técnicas, pero la más
frecuente es la especifiación mendiante los
casos de uso.

En el documento de análisis funcional
también se suele hacer una introducción a
la aplicación.

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

95. 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 información.

Los casos de uso proporcionan un modo
de comunicación cliente/desarrollador.
− Para el cliente proporcionan una visión 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.

96. Casos de uso: Especificación (I)

Se especifica en un texto de la siguiente
forma:
− Descripción: 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 describirán los actores que
intervienen en el caso de uso.
− Precondiciones: qué condiciones deben
cumplirse para que se realice un caso de
uso.
− Postcondiciones (o garantías de éxito):
cuáles son aquellas condiciones que se
cumplen posteriormente al caso de uso.

97. Casos de uso: Especificación (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 realización.

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

98. Casos de uso: Diagramas (I)

Se componen principalmente de:
− Actores: los actores serán tanto los
usuarios del sistema como los sistemas
externos.
− Casos de uso: representa el
comportamiento que ofrece el sistema de
información desde el punto de vista del
usuario. Típicamente 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.

99. Casos de uso: Diagramas (III)

100. 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 sóla parte del código,
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 aplicación y
esperando recibir otros. Por ejemplo en el
caso de una aplicación web se prueba
automatizando la navegación por las páginas.
Las herramientas que se usan son Canoo
Webtest, BadBoy, Apache JMeter, etc.

101. Que más incluir en el documento (I)

En primer lugar, el documento debe tener
una introducción al igual que en el
documento de ERQ, en la que se incluya:
− Objetivo
− Alcance
− Definiciones, acrónimos y abreviaturas
− Referencias (a otros documentos, ERQs, etc.)
− Visión general (Explicación del documento)

102. Que más incluir en el documento (II)

Una sección de descripción del producto,
que contenga lo siguiente:
− Enfoque del Producto
− Características del Producto
− Tipos de Usuarios
− Modelo de Casos de Uso
− Entorno Operativo
− Restricciones de Diseño y Despliegue
− Documentación de Usuario
− Hipótesis y dependencias

En la sección de modelos del curso se
muestra un ejemplo de esto

103. El Diseño Técnico

104. Indice

Diseño Técnico

¿Que debe incluir?

Herramientas
− Diagramas de despliegue
− Modelo entidad-relación
− Diagramas de clases
− Diagramas de componentes
− Diagramas de paquetes
− Diagramas de secuencia
− Diagramas de estados

105. Diseño técnico

En el documento de diseño técnico se
especificará el “cómo” 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 programación y para incorporar nuevos
programadores al proyecto.

106. ¿Que debe incluir? (I)

Arquitectura de la aplicación
− Elementos de hardware
− Comunicaciones: distintas conexiones de red
que hace la aplicación
− Software de base a emplear
− Arquitectura actual: sólo si había una
aplicacińo anterior
− Arquitectura propuesta: la que se va a
implementar

Modelo de datos
− Estructura de la base de datos

107. ¿Que debe incluir? (II)

Organización del código

Bibliotecas utilizadas

Diseño de los distintos componentes
− Estructura de clases
− División de la aplicación en paquetes
− Explicaciones del funcionamiento del código

Herramientas de desarrollo a utilizar: cómo
compilar, etc

108. Herramientas

En el documento de diseño técnico nos
podremos valer de varias herramientas
para apoyar las explicaciones que
debemos dar sobre el proyecto:
− Diagramas de despliegue
− Modelo entidad-relación
− Diagramas de clases
− Diagramas de componentes
− Diagramas de paquetes
− Diagramas de secuencia
− Diagramas de estados

109. Diagramas de despliegue (I)

Para representar la arquitectura se suele
utilizar un diagrama de despliegue, en el
que se suelen mostrar las máquinas y los
servicios/aplicaciones que correrán en
cada una de las máquinas.

110. Diagramas de despliegue (II)

En los diagramas de despligue se
representan los distintos componentes con
los siguientes símbolos:

111. Modelo entidad-relación (I)

Nos sirve para definir el modelo de datos,
expicando los campos de cada una de
las tablas y las relaciones entre ellas

112. Modelo entidad-relación (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:

1 a 1

1 a N

N a N

113. 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 demás objetos, pero no muestra
información temporal.

114. Diagramas de clases (II)

Es muy difícil tener clara la estructura de
clases durante el diseño técnico

Las clases se componen de:
− Atributos
− Métodos

Se pueden representar:
− Clases abstractas
− Tipos de clases (Entidades, Interfaces,
Objetos de control)
− Asociaciones entre clases
− Paquetes (ver diagrama de paquetes)

115. Diagramas de componentes (I)

Muestra los distintos componentes del
software que va a ser desarrollado y su
interrelación

116. Diagramas de componentes (II)

Se representan los
siguientes elementos:
− Componentes: las clases en sí
− Interfaces: clases que
exponen métodos a otro
paquete u otro grupo de
clases
− Paquetes: agrupaciones de
clases
− Relaciones entre ellos: en este
diagrama no hay tipos de
relaciones

117. Diagramas de paquetes (I)

Muestra la descomposición del código en
distintos paquetes y las relaciones entre
los distintos paquetes.

En este diagrama no hay tipos de
relaciones.

En Java tiene aplicación directa, ya que
este lenguaje nos permite organizar el
código en paquetes.

118. Diagramas de paquetes (II)

119. Diagramas de secuencia (I)

Representan la interacción temporal entre
los distintos actores y componentes del
sistema para un caso de uso.

120. Diagramas de secuencia (II)

Se pueden entender como un cronograma,
pero en el que la lína temporal está en el
eje Y

Las dependencias y mensajes se
representan con flechas

Las tareas que realiza cada componente
se muestran con rectángulos sobre la línea
temporal de cada uno de los componentes

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

122. Fase de Programación de los
proyectos

123. Indice

Sistemas de control de versiones

CVS
− Terminología
− Operaciones
− Tags

Subversion

Clearcase

Control de tiempos

Control del estado del proyecto

Incidencias

124. Introducción

La programación de grandes proectos de
software necesita de varias herramientas,
como los sistemas de control de versiones
de código, 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
comunicación con el cliente.

125. Sistemas de control de versiones

Nos permiten coordinar el desarrollo entre
varios programadores

Permiten que varias personas puedan
modificar un mismo fichero
simultáneamente

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

126. CVS

Concurrent Version System: es el más
utilizado por ser el que lleva más años

Es una estructura cliente-servidor, en la
que el cliente tiene una copia local del
código de la aplicación

El cliente puede trabajar en su copia local
sin influir a los demás usuarios, y va
subiendo al servidor CVS los cambios que
va realizando

No se debe subir al servidor CVS código
que no compile, ya que dificultaría el
desarrollo de los demás usuarios

127. CVS: Terminología

Servidor CVS: Máquina que ejecuta CVS
y actua como almacén de ficheros.

Repositorio: Jerarquía de directorios
alojada en el servidor CVS que contiene
diferentes módulos a disposición de los
usuarios.

Módulo: Árbol de directorios que forma
parte del repositorio. Cada proyecto de
software se suele corresponder a un
módulo.

128. CVS: Operaciones

Las operaciones que puede realizar un
cliente contra un servidor CVS son
principalmente:
− import: subir un módulo al repositorio
− checkout: obtener una copia local de un
módulo del repositorio
− update: actualizar la copia local con los
cambios que haya en el servidor
− commit: subir los cambios de la copia local
del código al servidor
− add: añadir un fichero al repositorio
− del: borrar un fichero del repositorio
− diff: ver diferencias entre ficheros

129. CVS: Tags

En CVS cada fichero tiene una versión
indicada por un número

Podemos crear TAGs o etiquetas que
“marquen” una versión determinada de
cada uno de los ficheros

Esto nos sirve para etiquetar las versiones
de código estable en el repositorio y seguir
desarrollando

Hay un tag implícito que se llama “HEAD”
y que representa la última versión de cada
uno de los ficheros

130. 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 más reciente que trata de
corregir estas limitaciones

Está substituyendo al CVS de forma
progresiva

131. Clearcase

Desarrollado por Rational, que ahora son
división de IBM

Software propietario (¡y caro!)

Difícil de administrar

Está probado en proyectos de tamaño
ingente

Permite trabajar a distintos equipos sobre
un mismo código

132. Herramientas de gestión de proyectos

Hay una serie de herramientas que nos
permiten gestionar de forma fácil 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/)

133. Control de tiempos

Durante la programación es encesario
saber cuánto tiempo invierte cada
programador en cada una de las tarea

Estos tiempos nos permiten saber cuánto
nos hemos equivocado en la estimación

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/
)

134. Control del estado del proyecto

En los proyectos grandes, al final de la
semana se suele enviar al cliente un
informe de situación 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 acompañar 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

135. 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 cómo
afectan a los tiempos de entrega, o bien
dejarlos para cuando se termine el proyecto
− Partes de la aplicación mal especificadas: que
nos originan nuevas tareas que no teníamos
previstas
− Retrasos en la programación: por
estimaciones demasiado optimistas. Suele ser
necesario replanificar
− Complicaciones técnicas: los problemas que
nunca están previstos y siempre aparecen...

136. Incidencias (II)

Hay varias formas de hacerles frente:
− Replanificar retrasando el proyecto
− Replanificar añadiendo más desarrolladores
− Trabajar 12 horas al día y fines de semana
para intentar recuperar los retrasos (intentar
evitar esta opción)

No obstante, los márgenes que dejamos
durante la fase de estimación deberían ser
siempre suficientes para absorber todas
las posibles incidencias que se puedan
producir

137. Calidad y Pruebas del Software

138. Indice
Calidad
− Gestión de la calidad
− Control de la calidad
− Determinación de la calidad

Pruebas
− Entornos de pruebas
− Pruebas unitarias
− Pruebas funcionales
− Pruebas de usabilidad
− Pruebas de integración
− Pruebas de carga
− Pruebas de regresión
− Pruebas de aceptación

139. Calidad

“Concordancia con los requisitos
funcionales y de rendimiento
explícitamente establecidos con los
estándares de desarrollo explícitamente
documentados y con las características
implícitas 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.

140. Gestión de la calidad

Gestión de la calidad (ISO 9000): Conjunto
de actividades de la función general de la
dirección que determina la calidad, los
objetivos y las responsabilidades y se
implanta por medios tales como la
planificación de la calidad, el control de la
calidad, el aseguramiento (garantía) de la
calidad y la mejora de la calidad, en el
marco del sistema de calidad.

Política de calidad (ISO 9000): Directrices
y objetivos generales de una organización,
relativos a la calidad, tal como se expresan
formalmente por la alta dirección

141. Control de la calidad

Son las técnicas y actividades de carácter
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

142. Determinación 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 implícitos o
expectativas que a menudo no se
mencionan, o se mencionan de forma
incompleta (por ejemplo el deseo de un
buen mantenimiento) que también pueden
implicar una falta de calidad.

A continuación mostramos un resumen de
los factores que pueden determinar la
calidad del software

143. ¿Qué determina la calidad? (I)

Operaciones del producto: características
operativas
− Corrección (¿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 fácil y cómodo de
manejar?)

144. ¿Qué determina la calidad? (II)

Revisión del producto: capacidad para
soportar cambios
− Facilidad de mantenimiento (¿Puedo localizar
los fallos?)
− Flexibilidad (¿Puedo añadir nuevas
opciones?)
− Facilidad de prueba (¿Puedo probar todas las
opciones?)

145. ¿Qué determina la calidad? (III)

Transición del producto: adaptabilidad a
nuevos entornos
− Portabilidad (¿Podré usarlo en otra máquina?)
− Reusabilidad (¿Podré utilizar alguna parte del
software en otra aplicación?)
− Interoperabilidad (¿Podrá comunicarse con
otras aplicaciones o sistemas informáticos?

146. Pruebas

Las pruebas de software es el conjunto
de técnicas 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
metódica

La cobertura de las pruebas es un
término que se refiere al porcentaje del
código de la aplicación que se cubre con
un determinado grupo de pruebas

147. Entornos de prueba

En todo desarrollo de software nos
deberíamos encontrar con estos
escenarios:
Desarrollo
Integración
Producción

148. 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 programación
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.)

149. Pruebas funcionales

Prueban el sistema desde el punto de vista
del usuario introduciendo unos datos por el
interfaz de la aplicación y esperando
recibir otros.

Por ejemplo en el caso de una aplicación
web se prueba automatizando la
navegación por las páginas y
comprobando que los resultados son los
esperados.

Las herramientas que se untilizan son
Canoo Webtest, BadBoy, Apache JMeter,
etc.

150. Pruebas de usabilidad (I)

La usabilidad se refiere a la facilidad o
nivel de uso, es decir, al grado en el que el
diseño 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

151. Pruebas de usabilidad (II)
− ¿Quiénes son los usuarios, cuáles sus
conocimientos, y cuánta preparación
necesitan?
− ¿Pueden los usuarios realizar fácilmente sus
tareas previstas?
− ¿Qué documentación u otro material de apoyo
están disponible para ayudar al usuario?
¿Puede éste hallar las respuestas que buscan
en estos medios?
− ¿Cuáles y cuántos errores cometen los
usuarios cuando interactúan con el producto?
− Se han tomado medidas para cubrir las
necesidades especiales de los usuarios con
discapacidades? (accesibilidad)

152. Pruebas de integración

Se prueba la aplicación en un entorno
similar al de producción asegurándose de:
− que funciona sobre el hardware/software que
nos encontraremos en el entorno de
producción
− que no aparecen problemas al trabajar con los
datos que hay en el entorno de producción
(tanto en tipo como en volumen)
− que se integra sin problema con el resto de
aplicaciones con las que se comunica

153. Pruebas de carga

Las pruebas de carga o stress se utilizan
para comprobar cómo responde el sistema
frente a un determinado número de
usuarios o transacciones

Permiten detectar cuellos de botella en el
rendimiento de las aplicaciones

Deben realizarse sobre el entorno de
integración, para que los resultados se
parezcan lo más posible a los que nos
vamos a encontrar en producción

154. Pruebas de regresión

Esta prueba incluye todas las pruebas
anteriores en caso de que se le haga
algún cambio a algún modulo después de
haber sido puesto en producción

Se trata de evaluar si el cambio introduido
afecta de forma errónea al funcionamiento
de otros módulos

Es importante tener automatizadas las
pruebas para, después de implementar el
cambio, poder ejecutarlas sin perder
mucho tiempo.

155. Pruebas de aceptación

Estas pruebas las realiza el cliente
para validar el desarrollo

Son básicamente pruebas
funcionales, sobre el sistema
completo, y buscan una cobertura de
la especificación de requisitos y del
manual del usuario

Estas pruebas no se realizan durante
el desarrollo, pues sería
impresentable al cliente; sino que se
realizan sobre el producto terminado
e integrado o pudiera ser una versión
del producto o una iteración funciona
pactada previamente con el cliente

156. Implantación de software

157. Indice
Implantación

Instalación de hardware

Instalación de software

Bases de datos

Configuración

Los equipos de operación

Documento de operación

Documento de paso a producción

Copia de seguridad y marcha atrás

Monitorización de las aplicaciones

La importancia del control de código

La formación a los usuarios

El retorno de inversión

158. Implantación

La implantación es el proceso de verificar
e instalar nuevo equipo, instalar la
aplicación, construir todos los archivos de
datos necesarios para utilizarla y entrenar
a los usuarios.

Cada estrategia de implantación tiene sus
méritos de acuerdo con la situación que se
considere dentro de la empresa. Sin
importar cuál 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 información deben
mantenerse siempre al día, la implantación
es un proceso de constante evolución.

159. Instalación de hardware

En muchos proyectos también es
necesario instalar el hardware sobre el que
va a funcionar

Cuando se instala el entorno de
producción es aconsejable instalar
también el de integración, para que sean
similares (replicación de entornos)

Redundancia: para aplicaciones críticas es
mejor no tener una sóla sola máquina en
producción: se utiliza redundancias para
aumentar la disponibilidad

Cada vez se tiende más hacia la
virtualización de las máquinas, lo que
facilita la redundancia, las copias de
seguridad y la replicación de entornos

160. Instalación de software

La instalación y actualización de software
debe automatizarse lo máximo posible:
− Instaladores
− Scripts que copien la aplicación a todos los
equipos

No sólo tenemos que instalar nuestra
aplicación, también sistema operativo y
aplicaciones auxiliares: BBDD, etc.

Hay lenguajes que tienen mecanismos
para realizar estas actualizaciones de
forma automática:
− Java Web Start: la aplicación, al arrancar,
consulta sus partes que se han modificado, se
las descarga y se ctualiza automáticamente

161. Bases de datos

Cuando pasamos a producción una
aplicación con BBDD nos podemos
encontrar con dos escenarios:
− Creación por primera vez de la BBDD: se
proporciona un script con todas las sentencias
de creación de la BBDD y la inserción en
tablas de todos los datos necesarios
− Actualización: es necesario tener scripts que
incluyan los cambios entre la version anterior
y la nueva:

Añadir/borrar columnas

Modificar datos

Insertar/borrar filas

162. Configuración

Es muy importante, ya normalmente el
correcto funcionamiento de la aplicación
depende de su correcta configuración

Abarca:
− Conexiones a BBDD
− Conexiones a otras máquinas: FTP, web
services, etc
− Parámetros dentro de la aplicación, etc.

Hay aplicaciones cuya adaptación a la
empresa se hace completamente por
configuración (CRMs, ERPs...) y es un
proceso mutuo en el que se adapta la
aplicación a la empresa y la empresa a la
aplicación

163. Los equipos de operación

Son equipos en las empresas que se
encargan del mantenmiento de los
sistemas, lo que se suele llamar
“operación de sistemas”

Entre sus tareas están 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

164. Documento de operación

Cada aplicación debe tener un documento
destinado al equipo de operación

En este documento debe figurar:
− De qué ficheros consta la aplicación
− Cómo se instala y se actualiza la aplicación
− Cómo configurar la aplicación
− Las operaciones de mantenimiento
− Cómo se hacen las copias de seguridad y la
recuperación de desastres
− Cómo monitorizar la aplicación

165. Documento de paso a producción

En aplicaciones complejas también es
necesario, para cada actualización de la
aplicación elaborar un documento en el
que se indiquen:
− Los cambios que incluye la nueva versión de
la aplicación
− Cuándo se va a pasar y si requiere corte en el
servicio o no
− Los pasos que hay que realizar para
actualizar la aplicación
− Cómo comprobar que los cambios funcionan
correctamente

166. Copia de seguridad y marcha atrás

Es necesario que todo paso a producción
sea reversible para volver atrás en caso de
que se poduzca un error

Para ello, hay que proporcionar:
− un mecanismo de copia de seguridad
(backup)
− un mecanismo de marcha atrás (rollback)

Es preferible que este proceso esté
automatizado

Esta copia de seguridad tiene que
englobar al software modificado, los
ficheros de configuración y la base de
datos

167. Monitorización de aplicaciones

Una vez puesta en producción, es
necesario monitorizar los siguientes
parámetros de la aplicación:
− uso de CPU
− memoria consumida
− espacio en disco
− uso de red

Para ello hay software específico que
permite a las empresas controlar su
infraestructura de aplicaciones:
− Nagios
− OSSIM

SNMP (Simple Network Management Protocol):
protocolo para intercambiar información

168. La importancia del control del código

En una empresa los proveedores de TI
pueden ser varios y se puede cambiar
entre ellos

Si no se dispone del código fuente de las
aplicaciones que llevan la lógica de
negocio de nuestra empresa, estaremos
atándonos 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 código de las
aplicaciones que realizan

169. La formación a los usuarios (I)

Es una parte básica de la implantación de
software, sobre todo cuando éste
interactúa con los usuarios

Lo peor que puede pasar es que los
usuarios no acepten la aplicación o no
sean capaces de usarla

Se suelen impartir jornadas de formación a
los distintos grupos de usuarios en las
que:
− Se presenta la aplicación y se explican sus
bondades (importante para su aceptación)
− Se realizan casos prácticos de uso
(importante para la comprensión)

170. La formación a los usuarios (II)

En las jornadas de formación suelen
participar los responsables del proyecto,
tanto por parte del cliente como del
proveedor

Es bueno acompañar la formación con la
entrega de manuales, que pueden ser
distintos en función del grupo de usuarios

171. El retorno de inversión (II)

El ROI (Return Of Investments) es el
beneficio que obtenemos por cada unidad
monetaria invertida en tecnología durante
un periodo de tiempo.

Esto es lo que busca cada cliente que
implanta una aplicación

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 cuánto nos estamos gastando lo
complicado es calcular el beneficio.

172. El retorno de inversión (I)

Por qué es complicado medir los
beneficios:
− Lo que entiende cada uno como beneficios
− La entrada en juego de factores como el
cambio tecnológico
− 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 satisfacción de
los usuarios