Documentos de Académico
Documentos de Profesional
Documentos de Cultura
CONTROL DE PROYECTOS
Y
GESTIÓN EMPRESARIAL
1
1.- Organización y funciones empresariales.
2.- Plan de empresa.
3.- Proyectos TI, Metodologías y ciclos de vida.
4.- Gestión de proyectos : ERQ’s y presupuesto.
5.- Planificación : PERT’s y Gantts.
6.- Análisis funcional y casos de uso.
7.- El diseño técnico.
8.- Fase de programación de los proyectos.
9.- Calidad y pruebas de software.
10.- Implatación de software.
11.- Manuales de las aplicaciones. 2
Organización y Funciones
Empresariales
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 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
A números”
Cada persona recibe ordenes de un
B
solo jefe, prevaleciendo el principio
de jerarquía y de subordinación
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
especialización 8
Organización funcional (I)
Dirección
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
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
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
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
¿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 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.
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)
Especificación
de requisitos
Es el modelo clásico
Análisis
Las fases se deben ejecutar de
forma secuencial, pero se puede
Diseño
volver a la fase anterior
Codificación
Cada etapa genera una
documentación o un producto
que recibe de entrada la siguiente
Pruebas
fase
Implantación
Mantenimiento
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)
Especificación
de requisitos Consiste en introducir hitos
entregables al cliente durante el
Análisis
desarrollo del proyecto
Diseño de arquitectura
Codificación y pruebas A
Entrega A
Codificación y pruebas B
Entrega B
Codificación y pruebas C
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,
Prototipo 1 frecuentemente destinado a ser ya
utilizado por cliente.
El cliente aporta realimentación y
Prototipo 2
con ella se desarrolla el siguiente
prototipo
Se van repitiendo los ciclos de
iteración hasta alcanzar una versión
Prototipo 3 final.
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 (II)
Las relaciones cuando son entre un actor y un caso de
uso se representan por una línea recta
Cuando son entre casos de uso se representan con líneas
discontinuas, y pueden ser de dos tipos:
quiere reflejar un
comportamiento opcional
de un caso de uso
100
Casos de uso: Diagramas (III)
101
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.
102
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)
103
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
104
El Diseño Técnico
105
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
106
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.
107
¿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
108
¿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
109
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
110
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.
111
Diagramas de despliegue (II)
En los diagramas de despligue se representan los
distintos componentes con los siguientes símbolos:
112
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
113
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:
1a1
1aN
NaN
114
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.
115
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)
116
Diagramas de componentes (I)
Muestra los distintos componentes del software que va
a ser desarrollado y su interrelación
117
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
118
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.
119
Diagramas de paquetes (II)
120
Diagramas de secuencia (I)
Representan la interacción temporal entre los distintos
actores y componentes del sistema para un caso de uso.
121
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
122
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.
123
Fase de Programación de los
proyectos
124
Indice
Sistemas de control de versiones
CVS
Terminología
Operaciones
Tags
Subversion
Clearcase
Control de tiempos
Control del estado del proyecto
Incidencias
125
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.
126
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
127
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
128
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.
129
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
130
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
131
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
132
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
133
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/)
134
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/)
135
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
136
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...
137
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
138
Calidad y Pruebas del Software
139
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
140
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.
141
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
142
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
143
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
144
¿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?)
145
¿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?)
146
¿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?
147
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
148
Entornos de prueba
En todo desarrollo de software nos deberíamos
encontrar con estos escenarios:
Desarrollo
Integración
Producción
149
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.)
150
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.
151
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
152
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)
153
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
154
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
155
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.
156
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
157
Implantación de software
158
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 159
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.
160
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
161
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
162
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
163
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
164
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
165
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
166
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
167
Copia de seguridad y
plan de contingencia.
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 plan de contingencia (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
168
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
169
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
170
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)
171
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
172
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.
173
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
174
Manuales de las aplicaciones
175
Indice
Introducción
Tipos de manuales
Apartados del manual
Formatos de manuales
Acceso a los manuales
176
Introducción
Los manuales es un entregable imprescindible en los
proyectos
Deben ser presupuestados correctamente, ya que el
escribir documentación suele llevar siempre más
tiempo de lo previso
Facilitan la comprensión de la aplicación y la
resolución rápida de dudas
Reducen el nivel de consultas sobre el departamento
técnico
177
Tipos de manuales
Los manuales se suelen realizar en función del perfil de
usuario que los vaya a leer:
Administrador
Usuario
Otras veces se separan así
Manual de uso rápido
Manual avanzado
A continuación mostramos una estructura típica de un
manual de una aplicación informática:
178
Apartados del manual (I)
Introducción
Presentación del sistema
Requisitos de Configuración de Hardware
Distribución del Sistema y Autorización de Uso
Atención al Usuario
Esquema de Estados
Perfiles o Niveles de acceso al sistema
Primeros Pasos
Cómo acceder al sistema
Menú principal Nivel Usuario
Cambio de claves de acceso
Cómo salir del sistema
Cómo actuar ante una incidencia
179
Apartados del manual (II)
Uso avanzado: en esta sección se encuadran todas las
funcionalidades avanzadas de las que disponga la
aplicación:
Función 1
Función 2
...
Troubleshooting, o resolución de problemas frecuentes
Glosario: los términos y abreviaturas a comprender en
el resto del documento
180
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. También se puede empotrar
en web de forma sencilla
HTML: facilita la integración con las aplicaciones web,
pero dificulta el mantener una copia impresa con el
mismo contenido
Archivo de Ayuda de Windows CHM: no es
multiplataforma, sólo tiene sentido en aplicaciones
locales
Wiki: este método aporta facilidad de actualización y
posibilidad de participación de los usuarios de la
aplicación
181
Acceso a los manuales
Es aconsejable que una copia del manual esté siempre
accesible desde la aplicación
En caso de la web, se puede disponer en la portada de
la aplicación
En caso de aplicaciones locales, se pueden utilizar
sistemas de ayuda CHM, pero también se puede poner
un enlace a la web de documentación
182
FIN
183