Apuntes de la Asignatura de Empresa y Gesti

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

• Alberto Alonso Ruibal
• alberto_at_alonsoruibal.com
• http//www.alonsoruibal.com

2
Organización y Funciones Empresariales

• Alberto Alonso Ruibal
• alberto_at_alonsoruibal.com
• http//www.alonsoruibal.com

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 números
• Cada persona recibe ordenes de un solo jefe,
  prevaleciendo el principio de jerarquía y de
  subordinación absoluta a su inmediato superior.
• Inconvenientes
• Sobrecarga a personas con deberes y
  responsabilidad
• Excesiva rigidez que no permite que se implanten
  las ventajas de la especialización

A
B
C
D
E
F
G
H
8
Organización funcional (I)
Dirección
Producción
Marketing
Financiero
Recursos humanos

• Definida por Taylor, que divide las actividades
  de una empresa según las funciones asignadas. a
  cada una de ellas

9
Organización funcional (II)

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

10
Organización territorial (I)

• En empresas de gran tamaño, se divide la
  organización en distintas áreas según la zona
  territorial a la que se atienda

Dirección
España
Portugal
Francia
11
Organización territorial (II)

• Ventajas
• Intensifica la responsabilidad por los resultados
• Aproxima las decisiones a las características de
  cada territorio
• Inconvenientes
• Dificulta el control
• Pueden perderse economías de escala
• Requiere mayor número de directivos

12
Organización por productos o servicios

• Cada unidad de la empresa tiene asignada la
  totalidad de las actividades asociadas a un
  producto o familia de productos
• La empresa gira en torno a sus productos

Dirección
Producto A
Producto C
Producto B
13
Organización por clientes

• Se basa en dividir a los clientes en grupos y
  crear un área de la empresa para cada uno de esos
  grupos
• Es adecuado cuando los clientes requieren
  tratamientos muy distintos

Dirección
Productos de caballeros
Productos de señoras
Productos infantiles
14
Organización mixta

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

15
Organización de línea y staff

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

16
Las funciones empresariales

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

17
La función de dirección

• La dirección de una empresa debe
• Definir los objetivos de la empresa
• Planificar el crecimiento
• Controlar los resultados sobre los objetivos
  planteados
• Liderar y coordinar los distintos departamentos

18
La función de recursos humanos

• Se encarga de
• Selección de empleados
• Organización de personal
• Gestión de contratos y nóminas
• Análisis de puestos
• Formación
• Relaciones laborales
• Servicios sociales

19
La función financiera

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

20
La función de marketing

• Regla de las cuatro Ps
• 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
Alberto Alonso Ruibal alberto_at_alonsoruibal.com htt
p//www.alonsoruibal.com
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
Alberto Alonso Ruibal alberto_at_alonsoruibal.com htt
p//www.alonsoruibal.com
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
• 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

Análisis
Diseño
Codificación
Pruebas
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 desarrollo del proyecto

Análisis
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, frecuentemente destinado a ser ya
  utilizado por cliente.
• El cliente aporta realimentación y con ella se
  desarrolla el siguiente prototipo
• Se van repitiendo los ciclos de iteración hasta
  alcanzar una versión final.

Prototipo 1
Prototipo 2
Prototipo 3
45
Modelo orientado a prototipos (II)

• Ventajas
• Es muy frecuente que los requisitos sean
  cambiantes, con lo cual se van adaptando los
  prototipos
• El cliente ya puede ir trabajando con los
  prototipos, viendo el resultado y aportando
  feedback
• Inconvenientes
• En proyectos grandes es imposible saber cuando se
  terminará
• Los desarrolladores tienen a saltarse las fases
  de análisis y diseño

46
Programación extrema (I)

• Consiste en llevar la límite el modelo de
  prototipos, haciendo entregas continuas con
  pequeños cambios en la funcionalidad

47
Programación extrema (II)

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

48
Programación extrema (III)

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

49
Modelo métrica v.3 (I)

• Metodología de Planificación, Desarrollo y
  Mantenimiento de Sistemas de información
  promovida por el MAP
• Interfaces orientados a la gestión de los
  procesos
• Gestión de proyectos (GP).
• Seguridad (SEG).
• Aseguramiento de la Calidad (CAL).
• Gestión de la Configuración (GC).

50
Modelo métrica v.3 (II)

• Procesos
• Planificación de Sistemas de Información (Proceso
  PSI)
• Desarrollo del Sistema de Información (Proceso
  DSI)
• Estudio de Viabilidad del Sistema (Proceso EVS)
• Análisis del Sistema de Información (Proceso ASI)
• Diseño del Sistema de Información (Proceso DSI)
• Construcción del Sistema de Información (Proceso
  CSI)
• Implantación y Aceptación del Sistema (Proceso
  IAS)
• Mantenimiento del Sistema de Información (Proceso
  MSI)

51
Bibliografía

• Gestión de Proyectos IT con éxito
  http//www.aqs.es
• Programación extrema http//www.extremeprogrammin
  g.com
• Métrica v3 http//www.csi.map.es/csi/metrica3/

52
Gestión de proyectos ERQs y presupuestos
Alberto Alonso Ruibal alberto_at_alonsoruibal.com htt
p//www.alonsoruibal.com
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
Alberto Alonso Ruibal alberto_at_alonsoruibal.com htt
p//www.alonsoruibal.com
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 ID 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 ID 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/planne
  r
• 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
Alberto Alonso Ruibal alberto_at_alonsoruibal.com htt
p//www.alonsoruibal.com
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

• 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

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
Alberto Alonso Ruibal alberto_at_alonsoruibal.com htt
p//www.alonsoruibal.com
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 aplicacino
  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
• 1 a 1
• 1 a N
• N a N

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
Alberto Alonso Ruibal alberto_at_alonsoruibal.com htt
p//www.alonsoruibal.com
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.formassem
  bly.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
Alberto Alonso Ruibal alberto_at_alonsoruibal.com htt
p//www.alonsoruibal.com
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 som