3. ¿Por qué es necesaria la gestión o
administració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
4. La caseta de mi perro
Sólo hace falta
una persona
Muchas veces No
requiere un
análisis previo,
presupuestos,
documentación,
etc.
5. 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
6. 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.
7. Proyectos de TI
La gestión o administracion de proyectos TI es
más compleja por:
Complejidad intrínseca al desarrollo de
software y hardware
Imprecisión en la planificación del proyecto y
estimación de los costos.
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
8. 1. Método completo para la GPT
2. Origen de los proyectos
tecnológicos
3. Ventajas competitivas y
procesos del negocio
4. Claves de la administración
integral del proyecto
8
9. Aplicar Método (o calidad)
• Trabajar con un método
– Completo, coherente, consistente, flexible
• Sistema de productividad
– Incorporación del usuario, Normalización,
– Técnicas, Herramientas, Hardware,
– Habilidad del desarrollador.
• Responsabilidad social
• Análisis de riesgos
9
10. Etapas del Proyecto
– Concepción: necesidad o problema
– Factibilidad: soluciones y plan de proyecto
– Análisis: modelo integral de la solución (la mesa)
– Diseño: ingeniería de detalle del modelo
– Implementación: realizar en carácter piloto
– Despliegue: llevar a todos los puntos de uso
– Operación: acciones de mejora continua durante la
vida útil
10
C F A D I D O
Estudio Desarrollo MC
C F A D I D O
Estudio Desarrollo MC
11. ¿Cuáles Proyectos
Tecnológicos?
• Solucionar problemas de información
• Apoyar los procesos del negocio
• Apoyar las adquisiciones
• Implementar un ERP
• Administrar documentos
• De comunicación
• Otros
11
12. Insertar la GPT en la
estrategia de la organización
• Por si sola no aporta valor, está al
servicio del propósito de la
organización
• Mayor proporción si se acerca al corazón del
negocio
• Comunicación con los socios
tecnológicos
• La TI pasa a través de integrantes de
la organización quienes deben
querer usarla y estar capacitados
para ello 12
13. Las seis mejores prácticas
del desarrollo de software
Método RUP (Rational Unified Process), de Rational Corp.
• Desarrollo Iterativo
• Manejo de los requerimientos
• Uso de una arquitectura de componentes
• Modelamiento visual del software
• Verificación de la calidad
• Control de cambios
13
14. El plan del proyecto
• Completo, flexible, revisado en cada
etapa
• Preparación de licitaciones por etapa
• La misma formalidad en caso de
desarrollo interno
• Mantener un Kill Time
• Orientación del desarrollo:
cascada o espiral
14
15. Técnica de desarrollo en
espiral
• Alcanza en cada iteración mayor porción de
requerimientos y avanza en eficacia y
eficiencia
• Cada vuelta es un ciclo completo de
desarrollo
• Exige amplio esfuerzo de gestión y
operación
• Se resuelven primero los
requerimientos más críticos
15
16. Dos equipos de trabajo
• Uno de gestión del proyecto
• Análisis de riesgos, RS, Gestión del
cambio, seguimiento y otros
• Aseguramiento de calidad (QA), método,
diseño de pruebas, confirmación de
requerimientos con los usuarios, etc...
• Al menos una “UTP” (Unidad Técnica de
Proyectos) o PMO (Project Management
Office)
• Otro de desarrollo operativo del
proyecto
16
17. En el modelamiento…
• Coordinar a todos los actores
• Considerar la protección de la
información
• Conocer características de un buen
diseño
• Aplicar el modo de procesamiento
correcto
• Optimizar la operación del sistema
• Facilitar la auditoría computacional
17
19. Origen de los proyectos
tecnológicos
• Acercamiento a las TI
• ¿Cómo se conciben los proyectos
tecnológicos?
• Liderazgo Tecnológico
• Rol del commodity
• Revisión de soluciones tecnológicas típicas
19
20. Acercamiento a las TI
• Aportes de la tecnología a la luz del propósito
de la organización para obtener ventajas
competitivas
• En la organización no existen problemas
tecnológicos sino solamente problemas del
negocio.
• Alto nivel de fallas en proyectos TI
• Necesidad de método, sistematización,
calidad...
20
21. ¿Cómo se conciben los
proyectos tecnológicos?
• Aumentar la proporción hacia la estrategia en
lugar de la reacción
• Más allá del hardware, incluye métodos,
técnicas, herramientas y muchos otros
factores
• Rol preponderante de las personas
• Tecnología de información básica
generalizada
• Alta tecnología focalizada y al servicio del
propósito
21
22. Liderazgo tecnológico
• Base en un modelo de negocios
• Las fortalezas de los procesos
• Concentrarse en las habilidades
centrales
• El contexto de un método completo
22
23. Rol del commodity
• Especialmente en los procesos que no
agregan valor y que deben existir (¿?)
• Tecnología de información de uso
generalizado
• Existen soluciones genéricas para
casi todo tipo de negocio
• Es preferible no reinventar a nivel del
commodity, solamente usarlo
23
24. Revisión de soluciones
tecnológicas típicas
• Productos ERP (World Class)
• SCM, CRM, BI y otras
• Comunicación interna y externa
• Desarrollo interno de software
• Externalización del desarrollo
• Aplicaciones B2B, B2C...
• Otras tecnologías:
groupware, Workflow, EDI, ...
» En cada caso ¿cuando usar?
24
26. Ventajas competitivas y
procesos del negocio
• Algunos mensajes
• Desde el Plan de Negocios
• La cadena de valor de M. Porter
26
27. Algunos mensajes
• La estrategia guía el trabajo en la
gestión de procesos del negocio
• Es un proceso complejo
• Secuencia clave: fortalezas, factores
de diferenciación y ventajas
competitivas
• Retroalimentación entre ventajas
competitivas y procesos del negocio
• Invertir en una buena
implementación
27
FDFO VC
28. Desde el Plan de Negocios
• Propósito
– Visión, misión y valores
• Objetivos
– Pocos, con hitos y mediciones
• Programa de Acción
– Acciones o proyectos específicos,
responsables, costos, plazos y calidad,
seguimiento
28
29. Infraestructura de la firma
Manejo de Recursos Humanos
Desarrollo de Tecnología
Adquisiciones
Logística
de
entrada
Operaciones Logística
de salida
Marketing
y ventas
Servicio
Actividades Primarias
Activi-
dades
de
apoyo
Margen
Margen
Cadena de valor de M. Porter
29
31. Claves de la administración
integral del proyecto
• Claves de la GPT
• Componentes intrínsecos de la
GPT
• Ver el todo
31
32. Claves de la GPT
• Pensar en soluciones integrales, desde
la estrategia
• Trabajar con calidad para tener activos
tecnológicos
• Comunicar y hacer participar a todos los
involucrados
• Plan de proyecto completo y por cada
etapa
32
33. Componentes intrínsecos de la
GPT
• Contenido, seguimiento,
presentación,
implementación, retroalimentación,
riesgos y responsabilidad social
• En pocas palabras: aplicar método
33
34. Ver el todo...
• Hablamos de proyectos de
cambio integral, también
llamados:
• De modernización institucional
• De Reingeniería de negocios
• Todo comienza por... los
procesos
34
35. 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
36. 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
37. 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
38. 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
39. 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
40. 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
41. 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
42. 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
43. Programación extrema (I)
Consiste en llevar la límite el modelo de prototipos,
haciendo entregas continuas con pequeños cambios en
la funcionalidad
44. 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
45. 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
Sus principios no pueden ser aplicados a rajatabla,
es necesario saber decidir cuando aplicar ciertas
cosas y cuándo no
46. 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).
47. 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)
49. Gestión del proyecto
Importancia de la documentación
Reuniones con el cliente
Especificación de requisitos
Presupuestación
50. Gestión del Proyecto
La gestión o administracion 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
51. Importancia de la documentación
Ejemplo : 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
52. 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
53. 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
54. Errores frecuentes en las reuniones (II)
Cuidar la vestimenta, las formas y el
lenguaje corporal
No ignorar a los technical
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!
55. 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
56. 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
57. 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
58. 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...
59. 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 etc.
60. 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.
61. 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...
62. 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
63. 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
64. 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
tempos, sobre todo applicant margen al
tiempo de entrega
65. 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
tempos estimados
Para ello durante la fase de
implementación mediremos los tempos
que lleva cada tarea y los compararemos
con el estimado (control de tareas)
Esto nos será de mucha ayuda
66. 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.
67. 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.
69. 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
70. 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.
71. 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
para el submarino 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.
72. 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.
74. 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 .
75. 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.
76. 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 tempos:
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
77. 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.
78. 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 tempos 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
80. 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.
81. 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
82. Asignación de recursos (I)
La asignación de recursos es una tarea
fundamental en la planificación, ya que hay
que considerar aspectos technical 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 technical de cada tarea.
83. 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.
84. 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.
85. 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:
“Usa”: cuando se quiere
reflejar un
comportamiento común
en varios casos de uso.
“Extiende”: cuando se
quiere reflejar un
comportamiento opcional
de un caso de uso
88. 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
89. 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.
90. ¿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
91. ¿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
92. 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
93. 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.
94. Diagramas de despliegue (II)
En los diagramas de despligue se
representan los distintos componentes con
los siguientes símbolos:
95. 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
96. 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
97. 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.
98. 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)
99. Diagramas de componentes (I)
Muestra los distintos componentes del
software que va a ser desarrollado y su
interrelación
100. 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
101. 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.
103. Diagramas de secuencia (I)
Representan la interacción temporal entre
los distintos actores y componentes del
sistema para un caso de uso.
104. 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
105. 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.
107. Sistemas de control de versiones
CVS
Terminología
Operaciones
Tags
Subversion
Clearcase
Control de tempos
Control del estado del proyecto
Incidencias
108. Introducción
La programación de grandes proyectos de
software necesita de varias herramientas,
como los sistemas de control de versiones
de código,
Durante la fase de desarrollo, el gestor del
proyecto debe de encargarse del
seguimiento del proyecto, con el control de
tempos y de estado, gestionando la
comunicación con el cliente.
109. 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
110. 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
111. 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.
112. 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
113. 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
114. Control de tempos
Durante la programación es encesario
saber cuánto tiempo invierte cada
programador en cada una de las tarea
Estos tempos nos permiten saber cuánto
nos hemos equivocado en la estimación
Hay aplicaciones que nos permiten llevar
este control
115. 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
116. 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 tempos 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...
117. 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
119. 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
120. 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.
121. 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
122. 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
123. 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
124. ¿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?)
125. ¿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?)
126. ¿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?
127. 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
128. Entornos de prueba
En todo desarrollo de software nos
deberíamos encontrar con estos
escenarios:
Desarrollo
Integración
Producción
129. 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
130. 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.
131. 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
132. 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)
133. 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
134. 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
135. 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.
136. 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
138. 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
139. Implantación
La implantación es el proceso de veridical e
instalar Nuevo equip, 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.
140. 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
141. 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
142. 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
143. 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
144. 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
145. Documento de operación
Cada aplicación debe tener un documento
destinado al equip 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
146. 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
147. 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
148. 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
149. 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
150. 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)
151. 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
152. 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.
153. 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 tempos
que se ahorran los usuarios
Dificultad para imputar mejoras de
rendimiento en el beneficio
Hay cosas intangibles como la satisfacción de
los usuarios