Apuntes de la Asignatura de
Empresa y Gestión de
Proyectos
Alberto Alonso Ruibal
alberto@alonsoruibal.com
http://www.alons...
Organización y Funciones
Empresariales
Alberto Alonso Ruibal
alberto@alonsoruibal.com
http://www.alonsoruibal.com
Indice
• Concepto de empresa
• Organización de la empresa
• Funciones empresariales
Objetivo
• ¿Cuál es el objetivo de una empresa?
– Supervivencia y crecimiento del negocio
– Obtención de utilidades/genera...
Concepto de empresa
• Se entiende por empresa al organismo
social integrado por elementos humanos,
técnicos y materiales c...
Organización de la empresa
• La organización de una empresa puede
definirse como el conjunto de todas las formas
en que se...
Organización jerárquica pura
• También se llama “lineal” o “por
números”
• Cada persona recibe ordenes de
un solo jefe, pr...
Organización funcional (I)
• Definida por Taylor, que divide las actividades
de una empresa según las funciones asignadas....
Organización funcional (II)
• Ventajas:
– Es una organización muy probada y con éxito
– Procura e incide en la especializa...
Organización territorial (I)
• En empresas de gran tamaño, se divide la
organización en distintas áreas según la
zona terr...
Organización territorial (II)
• Ventajas:
– Intensifica la responsabilidad por los resultados
– Aproxima las decisiones a ...
Organización por productos o servicios
• Cada unidad de la empresa tiene asignada
la totalidad de las actividades asociada...
Organización por clientes
• Se basa en dividir a los clientes en grupos
y crear un área de la empresa para cada
uno de eso...
Organización mixta
• En casi todos los casos reales se mezclan
los anteriores sistemas de organización
• Ventajas:
– Adecu...
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 a...
Las funciones empresariales
• Se dividen principalmente en 5:
– Dirección
– Recursos humanos
– Financiera
– Marketing
– Pr...
La función de dirección
• La dirección de una empresa debe:
– Definir los objetivos de la empresa
– Planificar el crecimie...
La función de recursos humanos
• Se encarga de:
– Selección de empleados
– Organización de personal
– Gestión de contratos...
La función financiera
• La función financiera incluye los
siguientes aspectos:
– Facturación: facturas, albaranes...
– Con...
La función de marketing
• Regla de las cuatro P’s
– Producto: definición, estudios de mercado,
atención al cliente, soport...
Función de producción (I)
• Empleo de factores humanos y materiales
para la producción de bienes y servicios
• Proceso en ...
Función de producción (II)
• Tipos de transformaciones:
– Físicas, como en las operaciones de
fabricación.
– De lugar, com...
Bibliografía
• Guía para crear tu empresa. Álvaro López
Amo, Ed. Espasa.
• http://www.monografias.com
Plan de empresa
Alberto Alonso Ruibal
alberto@alonsoruibal.com
http://www.alonsoruibal.com
Indice

¿Qué es un plan de empresa?

¿Para qué sirve?

¿Quién ha de elaborarlo?

¿Cómo se estructura?

¿Cómo presenta...

El Plan de Empresa es una herramienta de
trabajo para aquellas personas o
colectivos que quieran poner en marcha
una ini...
¿Para qué sirve?

La utilidad del Plan de Empresa es doble:
− Internamente obliga a los promotores del
proyecto a iniciar...
¿Quién ha de elaborarlo?

Es muy importante que en la elaboración
del Plan de empresa participen todos los
socios o promo...
¿Cómo se estructura?

Una posible estructura de Plan de
Empresa puede ser la siguiente:
− INTRODUCCIÓN
− PLAN DE MARKETIN...
¿Cómo presentarlo? (I)

Las personas que tienen que leer un Plan
de Empresa (entidades financieras,
posibles socios, prov...
¿Cómo presentarlo? (II)

La mayoría de los profesionales
recomiendan respetar un cierto número de
reglas:
− Un dossier pr...
Proyectos TI, Metodologías y
Ciclos de Vida
Alberto Alonso Ruibal
alberto@alonsoruibal.com
http://www.alonsoruibal.com
Indice

¿Por qué es necesaria la gestión de
proyectos?

Definición de proyecto

Ciclo de vida de un proyecto
− En casca...
La caseta de mi perro

Sólo hace falta
una persona

No requiere un
análisis previo,
presupuestos,
documentación,
etc.
Un edificio

Son necesarios
varios equipos de
trabajo

Es necesario una
especificación re
requisitos, un
análisis, una
p...
Definición de proyecto

Un proyecto es una acción en la que
recursos humanos, financieros y
materiales se organizan de un...
Proyectos de TI
La gestión de proyectos TI es más
compleja por:
− Complejidad intrínseca al desarrollo de
software
− Impr...
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
...
Modelo en cascada (I)

Es el modelo clásico

Las fases se deben
ejecutar de forma
secuencial, pero se puede
volver a la ...
Modelo en cascada (II)

Objetivo de cada una de las etapas:
− Especificación de requisitos: Documento con
la especificaci...
Modelo en cascada (III)

Ventajas
− Minimiza la repetición de tareas de desarrollo
− La planificación es sencilla
− Facil...
Modelo orientado a hitos (I)

Consiste en introducir
hitos entregables al
cliente durante el
desarrollo del proyecto
Espe...
Modelo orientado a hitos (II)

Ventajas
− El cliente va viendo los resultados
− Permite reducir mucho el riesgo en proyec...
Modelo orientado a prototipos (I)
Se desarrolla un primer
prototipo relativamente
completo, frecuentemente
destinado a se...
Modelo orientado a prototipos (II)

Ventajas
− Es muy frecuente que los requisitos sean
cambiantes, con lo cual se van ad...
Programación extrema (I)

Consiste en llevar la límite el modelo de
prototipos, haciendo entregas continuas
con pequeños ...
Programación extrema (II)

Sus principios fundamentales son:
− Desarrollo iterativo e incremental
− Pruebas unitarias con...
Programación extrema (III)
Ventajas
− Es muy realista con respecto a la relación con
el cliente
− Le da importancia el di...
Modelo métrica v.3 (I)

Metodología de Planificación, Desarrollo y
Mantenimiento de Sistemas de
información promovida por...
Modelo métrica v.3 (II)
Procesos:
− Planificación de Sistemas de Información (Proceso
PSI)
− Desarrollo del Sistema de In...
Bibliografía

Gestión de Proyectos IT con éxito:
http://www.aqs.es

Programación extrema:
http://www.extremeprogramming....
Gestión de proyectos: ERQs y
presupuestos
Alberto Alonso Ruibal
alberto@alonsoruibal.com
http://www.alonsoruibal.com
Indice

Gestión del proyecto

Importancia de la documentación

Reuniones con el cliente

Especificación de requisitos
...
Gestión del proyecto

La gestión del proyecto es la aplicación del
conocimiento, habilidades, herramientas y
técnicas a l...
Importancia de la documentación

En los proyectos de software la
documentación es de vital importancia:
− El software es ...
Reuniones con el cliente

Motivación de las reuniones:
− Reuniones comerciales: el objetivo es vender
un producto o dar a...
Errores frecuentes en las reuniones (I)

Acompañarse de gente con experiencia en
reuniones

Nunca decir precios en reuni...
Errores frecuentes en las reuniones (II)

Cuidar la vestimenta, las formas y el
lenguaje corporal

No ignorar a los técn...
Especificación de Requisitos (I)

La captura de requisitos es parte esencial:
evita cambios posteriores en el sistema y
f...
Especificación de Requisitos (II)

Como deben ser los requisitos:
− Completos
− Implementación independiente
− Consistent...
Especificación de Requisitos (III)

La toma de requisitos:
− Introspección: ponerse en lugar del cliente e
imaginar como ...
Presupuestación

¿Cuanto dinero va a costar realizar el
proyecto?

Lo más difícil a la hora de hacer un
presupuesto de u...
Qué presupuestar (I)

Análisis: el análisis del problema posterior
al presupuesto previo a la elaboración del
documento d...
Qué presupuestar (II)

Implementación: las tareas de
programación en sí

Dirección de proyecto: las horas que
dedica el ...
Qué presupuestar (II)

Formación: suele estar hasta bien visto por
el cliente dar un par de charlas de
formación a los us...
Los márgenes

Margen de riesgo
− Se añade a las tareas para cubrir errores en
las estimaciones

Margen comercial
− Se añ...
El flujo de caja

Determina los plazos en los que el cliente
va a pagar el proyecto

Se suele intentar marcar hitos en e...
Clausulas de penalización

En algunos casos los clientes pueden
pedir que se incluyan clausulas que
penalicen el retraso ...
El cálculo de la rentabilidad

Es muy importante tener un modelo de
presupuesto que luego nos permita hacer
un cálculo de...
Otras formas de presupuestar

Muchas veces lo que se presupuestan no
son sólo proyectos, pueden ser:
− Productos de softw...
Licencias

Una vez que tenemos un proyecto de
software desarrollado podemos establacer
licencias para venderlo a varios c...
Planificación: PERTs y Gantts
Alberto Alonso Ruibal
alberto@alonsoruibal.com
http://www.alonsoruibal.com
Indice
Planificación

Diagramas PERT
− Actividades y sucesos
− Representación
− Tecnicas PERT

Camino crítico

Diagram...
Planificación

La planificación de un proyecto es la
previsión en fechas de la realización del
conjunto de actividades qu...
Diagramas PERT (I)

PERT (Program Evaluation and Review
Technique)

Desarrollado por la Special Projects Office
de la Ar...
Actividades y sucesos

Actividad: la ejecución de una tarea, que
exige para su realización la utilización de
recursos tal...
Representación de Diagramas PERT

Círculos: Sucesos

Flechas: Actividades
Diagramas PERT (II)

Con un diagrama PERT se obtiene un
conocimiento preciso de la secuencia
necesaria, o planificada par...
Técnicas PERT

Conjunto de modelos para la
programación y análisis de proyectos de
ingeniería que sirven para:
− Determin...
Camino crítico

El camino crítico en un proyecto es la
sucesión de actividades que dan lugar al
máximo tiempo acumulativo...
Diagramas Gantt

Inventado por Charles Gantt en 1917

El diagrama de Gantt o cronograma tiene
como objetivo la represent...
Representación de diagramas Gantt (I)

Se representan de la siguiente forma:
− En las filas la relación de actividades a
...
Representación de diagramas Gantt (II)
Dependencias de tareas

Al igual que en el PERT, en el Gantt
también se representan las dependencias
entre tareas con fle...
Estimación de recursos

La estimación de recursos consiste en
indicar cuántos recursos (personas) serán
necesarias para l...
Asignación de recursos (I)

La asignación de recursos es una tarea
fundamental en la planificación, ya que
hay que consid...
Asignación de recursos (II)

Asignar tareas sencillas a recursos con
poca experiencia.

Asignar tareas complejas a recur...
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...
Aplicaciones informáticas

Microsoft Project: sistema completo de gestión
de proyectos, sólo para windows
http://www.micr...
Análisis Funcional y Casos de
Uso
Alberto Alonso Ruibal
alberto@alonsoruibal.com
http://www.alonsoruibal.com
Indice

Importancia de la documentación

Análisis funcional

Casos de uso
− Especificación
− Diagramas
− Pruebas

Qué ...
Importancia de la documentación

En los proyectos de software la
documentación es de vital importancia:
− El software es ...
Análisis funcional

En informática, el análisis funcional es
aquél que describe que se va a
desarrollar, sin entrar en co...
Casos de uso (I)

Un caso de uso es una secuencia de
acciones realizadas por el sistema, que
producen un resultado observ...
Casos de uso (II)

Los objetivos de los casos de uso son los
siguientes:
− Capturar los requisitos funcionales del sistem...
Casos de uso: Especificación (I)

Se especifica en un texto de la siguiente
forma:
− Descripción: del caso de uso. En el ...
Casos de uso: Especificación (II)
− Escenarios (o secuencias): son los distintos
caminos por los que puede evolucionar un
...
Casos de uso: Diagramas (I)

Se componen principalmente de:
− Actores: los actores serán tanto los
usuarios del sistema c...
Casos de uso: Diagramas (II)

Las relaciones cuando son entre un actor y
un caso de uso se representan por una
línea rect...
Casos de uso: Diagramas (III)
Casos de uso: Pruebas

Los casos de uso son muy útiles si los
utilizamos para que definan nuestras
puebas funcionales.

...
Que más incluir en el documento (I)

En primer lugar, el documento debe tener
una introducción al igual que en el
documen...
Que más incluir en el documento (II)

Una sección de descripción del producto,
que contenga lo siguiente:
− Enfoque del P...
El Diseño Técnico
Alberto Alonso Ruibal
alberto@alonsoruibal.com
http://www.alonsoruibal.com
Indice

Diseño Técnico

¿Que debe incluir?

Herramientas
− Diagramas de despliegue
− Modelo entidad-relación
− Diagrama...
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...
¿Que debe incluir? (I)

Arquitectura de la aplicación
− Elementos de hardware
− Comunicaciones: distintas conexiones de r...
¿Que debe incluir? (II)

Organización del código

Bibliotecas utilizadas

Diseño de los distintos componentes
− Estruct...
Herramientas

En el documento de diseño técnico nos
podremos valer de varias herramientas
para apoyar las explicaciones q...
Diagramas de despliegue (I)

Para representar la arquitectura se suele
utilizar un diagrama de despliegue, en el
que se s...
Diagramas de despliegue (II)

En los diagramas de despligue se
representan los distintos componentes con
los siguientes s...
Modelo entidad-relación (I)

Nos sirve para definir el modelo de datos,
expicando los campos de cada una de las
tablas y ...
Modelo entidad-relación (I)

Representa:
− Entidades: se “corresponden” a las tablas en
la base de datos

Se indican los...
Diagramas de clases (I)

El diagrama de clases recoge las clases
de objetos y sus asociaciones. En este
diagrama se repre...
Diagramas de clases (II)

Es muy difícil tener clara la estructura de
clases durante el diseño técnico

Las clases se co...
Diagramas de componentes (I)

Muestra los distintos componentes del
software que va a ser desarrollado y su
interrelación
Diagramas de componentes (II)

Se representan los
siguientes elementos:
− Componentes: las clases en sí
− Interfaces: cla...
Diagramas de paquetes (I)

Muestra la descomposición del código en
distintos paquetes y las relaciones entre
los distinto...
Diagramas de paquetes (II)
Diagramas de secuencia (I)

Representan la interacción temporal entre
los distintos actores y componentes del
sistema par...
Diagramas de secuencia (II)

Se pueden entender como un cronograma,
pero en el que la lína temporal está en el
eje Y

La...
Diagramas de estados

Representa los estados que puede tomar
un componente o un sistema y muestra los
eventos que implica...
Fase de Programación de los
proyectos
Alberto Alonso Ruibal
alberto@alonsoruibal.com
http://www.alonsoruibal.com
Indice

Sistemas de control de versiones

CVS
− Terminología
− Operaciones
− Tags

Subversion

Clearcase

Control de ...
Introducción

La programación de grandes proectos de
software necesita de varias herramientas,
como los sistemas de contr...
Sistemas de control de versiones

Nos permiten coordinar el desarrollo entre
varios programadores

Permiten que varias p...
CVS

Concurrent Version System: es el más
utilizado por ser el que lleva más años

Es una estructura cliente-servidor, e...
CVS: Terminología

Servidor CVS: Máquina que ejecuta CVS
y actua como almacén de ficheros.

Repositorio: Jerarquía de di...
CVS: Operaciones

Las operaciones que puede realizar un
cliente contra un servidor CVS son
principalmente:
− import: subi...
CVS: Tags

En CVS cada fichero tiene una versión
indicada por un número

Podemos crear TAGs o etiquetas que
“marquen” un...
Subversion

El CVS tiene una serie de limitaciones:
− No permite mover o renombrar ficheros (al
renombrarlos se pierde su...
Clearcase

Desarrollado por Rational, que ahora son
división de IBM

Software propietario (¡y caro!)

Difícil de admini...
Herramientas de gestión de proyectos

Hay una serie de herramientas que nos
permiten gestionar de forma fácil los
distint...
Control de tiempos

Durante la programación es encesario
saber cuánto tiempo invierte cada
programador en cada una de las...
Control del estado del proyecto

En los proyectos grandes, al final de la
semana se suele enviar al cliente un
informe de...
Incidencias (I)

La fase de desarrollo no suele ser un
“camino de rosas”, ya que nos solemos
encontrar con:
− Cambios que...
Incidencias (II)

Hay varias formas de hacerles frente:
− Replanificar retrasando el proyecto
− Replanificar añadiendo má...
Calidad y Pruebas del Software
Alberto Alonso Ruibal
alberto@alonsoruibal.com
http://www.alonsoruibal.com
Indice
Calidad
− Gestión de la calidad
− Control de la calidad
− Determinación de la calidad

Pruebas
− Entornos de prue...
Calidad

“Concordancia con los requisitos
funcionales y de rendimiento
explícitamente establecidos con los
estándares de ...
Gestión de la calidad

Gestión de la calidad (ISO 9000): Conjunto
de actividades de la función general de la
dirección qu...
Control de la calidad

Son las técnicas y actividades de carácter
operativo, utilizadas para satisfacer los
requisitos re...
Determinación de la calidad

Los requisitos del software son la base de
las medidas de calidad. La falta de
concordancia ...
¿Qué determina la calidad? (I)

Operaciones del producto: características
operativas
− Corrección (¿Hace lo que se le pid...
¿Qué determina la calidad? (II)

Revisión del producto: capacidad para
soportar cambios
− Facilidad de mantenimiento (¿Pu...
¿Qué determina la calidad? (III)

Transición del producto: adaptabilidad a
nuevos entornos
− Portabilidad (¿Podré usarlo ...
Pruebas

Las pruebas de software es el conjunto
de técnicas que permiten determinar la
calidad de un producto software

...
Entornos de prueba

En todo desarrollo de software nos
deberíamos encontrar con estos
escenarios:
Desarrollo
Integración
...
Pruebas unitarias

Unidad: Este tipo de prueba solo aplica a
proyectos grandes. Se divide el proyecto a
unidades y cada u...
Pruebas funcionales

Prueban el sistema desde el punto de vista
del usuario introduciendo unos datos por el
interfaz de l...
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...
Pruebas de usabilidad (II)
− ¿Quiénes son los usuarios, cuáles sus
conocimientos, y cuánta preparación
necesitan?
− ¿Puede...
Pruebas de integración

Se prueba la aplicación en un entorno
similar al de producción asegurándose de:
− que funciona so...
Pruebas de carga

Las pruebas de carga o stress se utilizan
para comprobar cómo responde el sistema
frente a un determina...
Pruebas de regresión

Esta prueba incluye todas las pruebas
anteriores en caso de que se le haga
algún cambio a algún mod...
Pruebas de aceptación

Estas pruebas las realiza el cliente
para validar el desarrollo

Son básicamente pruebas
funciona...
Implantación de software
Alberto Alonso Ruibal
alberto@alonsoruibal.com
http://www.alonsoruibal.com
Indice
Implantación

Instalación de hardware

Instalación de software

Bases de datos

Configuración

Los equipos de...
Implantación

La implantación es el proceso de verificar
e instalar nuevo equipo, instalar la
aplicación, construir todos...
Instalación de hardware

En muchos proyectos también es
necesario instalar el hardware sobre el que
va a funcionar

Cuan...
Instalación de software

La instalación y actualización de software
debe automatizarse lo máximo posible:
− Instaladores
...
Bases de datos

Cuando pasamos a producción una
aplicación con BBDD nos podemos
encontrar con dos escenarios:
− Creación ...
Configuración

Es muy importante, ya normalmente el
correcto funcionamiento de la aplicación
depende de su correcta confi...
Los equipos de operación

Son equipos en las empresas que se
encargan del mantenmiento de los
sistemas, lo que se suele l...
Documento de operación

Cada aplicación debe tener un documento
destinado al equipo de operación

En este documento debe...
Documento de paso a producción

En aplicaciones complejas también es
necesario, para cada actualización de la
aplicación ...
Copia de seguridad y marcha atrás

Es necesario que todo paso a producción
sea reversible para volver atrás en caso de
qu...
Monitorización de aplicaciones

Una vez puesta en producción, es
necesario monitorizar los siguientes
parámetros de la ap...
La importancia del control del código

En una empresa los proveedores de TI
pueden ser varios y se puede cambiar
entre el...
La formación a los usuarios (I)

Es una parte básica de la implantación de
software, sobre todo cuando éste
interactúa co...
La formación a los usuarios (II)

En las jornadas de formación suelen
participar los responsables del proyecto,
tanto por...
El retorno de inversión (II)

El ROI (Return Of Investments) es el
beneficio que obtenemos por cada unidad
monetaria inve...
El retorno de inversión (I)

Por qué es complicado medir los
beneficios:
− Lo que entiende cada uno como beneficios
− La ...
Manuales de las aplicaciones
Alberto Alonso Ruibal
alberto@alonsoruibal.com
http://www.alonsoruibal.com
Indice

Introducción

Tipos de manuales

Apartados del manual

Formatos de manuales

Acceso a los manuales
Introducción

Los manuales es un entregable
imprescindible en los proyectos

Deben ser presupuestados correctamente,
ya ...
Tipos de manuales

Los manuales se suelen realizar en
función del perfil de usuario que los vaya a
leer:
− Administrador
...
Apartados del manual (I)
Introducción

Presentación del sistema
− Requisitos de Configuración de Hardware
− Distribución...
Apartados del manual (II)

Uso avanzado: en esta sección se
encuadran todas las funcionalidades
avanzadas de las que disp...
Formatos de manuales

Los manuales pueden ser presentados en
varios formatos:
− Papel: aporta tangibilidad al proyecto
− ...
Acceso a los manuales

Es aconsejable que una copia del manual
esté siempre accesible desde la aplicación

En caso de la...
Upcoming SlideShare
Loading in …5
×

Empresa y gestion_de_proyectos

783 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
783
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
12
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Empresa y gestion_de_proyectos

  1. 1. Apuntes de la Asignatura de Empresa y Gestión de Proyectos Alberto Alonso Ruibal alberto@alonsoruibal.com http://www.alonsoruibal.com
  2. 2. Organización y Funciones Empresariales Alberto Alonso Ruibal alberto@alonsoruibal.com http://www.alonsoruibal.com
  3. 3. Indice • Concepto de empresa • Organización de la empresa • Funciones empresariales
  4. 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. 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. 6. Organización de la empresa • La organización de una empresa puede definirse como el conjunto de todas las formas en que se divide el trabajodivide el trabajo en tareas distintas, considerando luego la coordinación de las mismas. • Distintos tipos de estructuras organizativas: – Organización jerárquica pura – Organización funcional – Organización territorial – Organización por productos o servicios – Organización por clientes – Organizacion mixta – Organización de línea y staff
  7. 7. Organización jerárquica pura • También se llama “lineal” o “por números” • Cada persona recibe ordenes de un solo jefe, prevaleciendo el principio de jerarquía y de subordinación absoluta a su inmediato superior. • Inconvenientes: – Sobrecarga a personas con deberes y responsabilidad – Excesiva rigidez que no permite que se implanten las ventajas de la especialización B C D E F A G H
  8. 8. Organización funcional (I) • Definida por Taylor, que divide las actividades de una empresa según las funciones asignadas. a cada una de ellas Dirección Producción Marketing Financiero Recursos humanos
  9. 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. 10. Organización territorial (I) • En empresas de gran tamaño, se divide la organización en distintas áreas según la zona territorial a la que se atienda Dirección España PortugalFrancia
  11. 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. 12. Organización por productos o servicios • Cada unidad de la empresa tiene asignada la totalidad de las actividades asociadas a un producto o familia de productos • La empresa gira en torno a sus productos Dirección Producto A Producto CProducto B
  13. 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. 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. 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. 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. 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. 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. 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. 20. La función de marketing • Regla de las cuatro P’s – Producto: definición, estudios de mercado, atención al cliente, soporte postventa, etc. – Promoción: imagen corporativa, publicidad, comerciales, etc. – Precio: análisis de costes, fijación del precio, descuentos, etc. – Distribución (Placement): almacenes, red de distribución, etc.
  21. 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. 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. 23. Bibliografía • Guía para crear tu empresa. Álvaro López Amo, Ed. Espasa. • http://www.monografias.com
  24. 24. Plan de empresa Alberto Alonso Ruibal alberto@alonsoruibal.com http://www.alonsoruibal.com
  25. 25. Indice  ¿Qué es un plan de empresa?  ¿Para qué sirve?  ¿Quién ha de elaborarlo?  ¿Cómo se estructura?  ¿Cómo presentarlo?
  26. 26.  El Plan de Empresa es una herramienta de trabajo para aquellas personas o colectivos que quieran poner en marcha una iniciativa empresarial.  Es un documento escrito por los promotores del proyecto y en él están recogidos los diferentes factores y los objetivos de cada una de las áreas que intervienen en la puesta en marcha de la empresa.  No debe confundirse con una simulación de cuentas de documentos financieros provisionales. ¿Qué es un plan de Empresa?
  27. 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. 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. 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. 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. 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. 32. Proyectos TI, Metodologías y Ciclos de Vida Alberto Alonso Ruibal alberto@alonsoruibal.com http://www.alonsoruibal.com
  33. 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. 34. La caseta de mi perro  Sólo hace falta una persona  No requiere un análisis previo, presupuestos, documentación, etc.
  35. 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. 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. 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. 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. 39. Modelo en cascada (I)  Es el modelo clásico  Las fases se deben ejecutar de forma secuencial, pero se puede volver a la fase anterior  Cada etapa genera una documentación o un producto que recibe de entrada la siguiente fase Especificación de requisitos Análisis Diseño Codificación Pruebas Mantenimiento Implantación
  40. 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. 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. 42. Modelo orientado a hitos (I)  Consiste en introducir hitos entregables al cliente durante el desarrollo del proyecto Especificación de requisitos Análisis Diseño de arquitectura Codificación y pruebas A Codificación y pruebas B Entrega B Codificación y pruebas C Entrega A Entrega C
  43. 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. 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. 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. 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. 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. 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. 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. 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. 51. Bibliografía  Gestión de Proyectos IT con éxito: http://www.aqs.es  Programación extrema: http://www.extremeprogramming.com  Métrica v3: http://www.csi.map.es/csi/metrica3/
  52. 52. Gestión de proyectos: ERQs y presupuestos Alberto Alonso Ruibal alberto@alonsoruibal.com http://www.alonsoruibal.com
  53. 53. Indice  Gestión del proyecto  Importancia de la documentación  Reuniones con el cliente  Especificación de requisitos  Presupuestación
  54. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 72. Planificación: PERTs y Gantts Alberto Alonso Ruibal alberto@alonsoruibal.com http://www.alonsoruibal.com
  73. 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. 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. 75. Diagramas PERT (I)  PERT (Program Evaluation and Review Technique)  Desarrollado por la Special Projects Office de la Armada de EE.UU. a finales de los 50s para el programa de I+D que condujo a la construcción de los misiles balísticos Polaris.  Está orientada a los sucesos o eventos, y se ha utilizado típicamente en proyectos de I+D en los que el tiempo de duración de las actividades es una incertidumbre.
  76. 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. 77. Representación de Diagramas PERT  Círculos: Sucesos  Flechas: Actividades
  78. 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. 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. 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. 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. 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. 83. Representación de diagramas Gantt (II)
  84. 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. 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. 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. 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. 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. 89. Aplicaciones informáticas  Microsoft Project: sistema completo de gestión de proyectos, sólo para windows http://www.microsoft.com/Project  Microsoft Visio: aplicacición para el diseño de diagramas http://office.microsoft.com/visio  GanttProject: aplicación Java orientada a la creación de Gantts http://www.ganttproject.biz  Imendio Planner: aplicación de planificación para Linux http://developer.imendio.com/projects/planner  Yed: editor de diagramas para Java: http://www.yworks.com/products/yed  Dia: aplicación para dibujar diagramas en Linux http://www.gnome.org/projects/dia
  90. 90. Análisis Funcional y Casos de Uso Alberto Alonso Ruibal alberto@alonsoruibal.com http://www.alonsoruibal.com
  91. 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. 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. 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. 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. 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. 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. 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. 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. 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. 100. Casos de uso: Diagramas (III)
  101. 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. 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. 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. 104. El Diseño Técnico Alberto Alonso Ruibal alberto@alonsoruibal.com http://www.alonsoruibal.com
  105. 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. 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. 107. ¿Que debe incluir? (I)  Arquitectura de la aplicación − Elementos de hardware − Comunicaciones: distintas conexiones de red que hace la aplicación − Software de base a emplear − Arquitectura actual: sólo si había una aplicacińo anterior − Arquitectura propuesta: la que se va a implementar  Modelo de datos − Estructura de la base de datos
  108. 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. 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. 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. 111. Diagramas de despliegue (II)  En los diagramas de despligue se representan los distintos componentes con los siguientes símbolos:
  112. 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. 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. 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. 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. 116. Diagramas de componentes (I)  Muestra los distintos componentes del software que va a ser desarrollado y su interrelación
  117. 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. 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. 119. Diagramas de paquetes (II)
  120. 120. Diagramas de secuencia (I)  Representan la interacción temporal entre los distintos actores y componentes del sistema para un caso de uso.
  121. 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. 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. 123. Fase de Programación de los proyectos Alberto Alonso Ruibal alberto@alonsoruibal.com http://www.alonsoruibal.com
  124. 124. Indice  Sistemas de control de versiones  CVS − Terminología − Operaciones − Tags  Subversion  Clearcase  Control de tiempos  Control del estado del proyecto  Incidencias
  125. 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. 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. 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. 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. 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. 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. 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. 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. 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. 134. Control de tiempos  Durante la programación es encesario saber cuánto tiempo invierte cada programador en cada una de las tarea  Estos tiempos nos permiten saber cuánto nos hemos equivocado en la estimación  Hay aplicaciones que nos permiten llevar este control: − KARM: ( http://pim.kde.org/components/karm.php) − Time tracker (Online) ( http://http://www.formassembly.com/time-tracker/ )
  135. 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. 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. 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. 138. Calidad y Pruebas del Software Alberto Alonso Ruibal alberto@alonsoruibal.com http://www.alonsoruibal.com
  139. 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. 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. 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. 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. 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. 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. 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. 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. 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. 148. Entornos de prueba  En todo desarrollo de software nos deberíamos encontrar con estos escenarios: Desarrollo Integración Producción
  149. 149. Pruebas unitarias  Unidad: Este tipo de prueba solo aplica a proyectos grandes. Se divide el proyecto a unidades y cada unidad es sometida a prueba individualmente  Para los lenguajes de programación orientado a objetos, estas unidades suelen ser las clases, por lo que se suele realizar una prueba por clase  Se utilizan frameworks de prueba como lso xUnit (jUnit, phpUnit, etc.)
  150. 150. Pruebas funcionales  Prueban el sistema desde el punto de vista del usuario introduciendo unos datos por el interfaz de la aplicación y esperando recibir otros.  Por ejemplo en el caso de una aplicación web se prueba automatizando la navegación por las páginas y comprobando que los resultados son los esperados.  Las herramientas que se untilizan son Canoo Webtest, BadBoy, Apache JMeter, etc.
  151. 151. Pruebas de usabilidad (I)  La usabilidad se refiere a la facilidad o nivel de uso, es decir, al grado en el que el diseño de un programa facilita o dificulta su manejo  Este tipo de prueba se refiere a asegurar de que la interfaz de usuario (o GUI) sea intuitiva, amigable y funcione correctamente.  Enumeraremos los factores que influyen principalmente en la usabilidad
  152. 152. Pruebas de usabilidad (II) − ¿Quiénes son los usuarios, cuáles sus conocimientos, y cuánta preparación necesitan? − ¿Pueden los usuarios realizar fácilmente sus tareas previstas? − ¿Qué documentación u otro material de apoyo están disponible para ayudar al usuario? ¿Puede éste hallar las respuestas que buscan en estos medios? − ¿Cuáles y cuántos errores cometen los usuarios cuando interactúan con el producto? − Se han tomado medidas para cubrir las necesidades especiales de los usuarios con discapacidades? (accesibilidad)
  153. 153. Pruebas de integración  Se prueba la aplicación en un entorno similar al de producción asegurándose de: − que funciona sobre el hardware/software que nos encontraremos en el entorno de producción − que no aparecen problemas al trabajar con los datos que hay en el entorno de producción (tanto en tipo como en volumen) − que se integra sin problema con el resto de aplicaciones con las que se comunica
  154. 154. Pruebas de carga  Las pruebas de carga o stress se utilizan para comprobar cómo responde el sistema frente a un determinado número de usuarios o transacciones  Permiten detectar cuellos de botella en el rendimiento de las aplicaciones  Deben realizarse sobre el entorno de integración, para que los resultados se parezcan lo más posible a los que nos vamos a encontrar en producción
  155. 155. Pruebas de regresión  Esta prueba incluye todas las pruebas anteriores en caso de que se le haga algún cambio a algún modulo después de haber sido puesto en producción  Se trata de evaluar si el cambio introduido afecta de forma errónea al funcionamiento de otros módulos  Es importante tener automatizadas las pruebas para, después de implementar el cambio, poder ejecutarlas sin perder mucho tiempo.
  156. 156. Pruebas de aceptación  Estas pruebas las realiza el cliente para validar el desarrollo  Son básicamente pruebas funcionales, sobre el sistema completo, y buscan una cobertura de la especificación de requisitos y del manual del usuario  Estas pruebas no se realizan durante el desarrollo, pues sería impresentable al cliente; sino que se realizan sobre el producto terminado e integrado o pudiera ser una versión del producto o una iteración funciona pactada previamente con el cliente
  157. 157. Implantación de software Alberto Alonso Ruibal alberto@alonsoruibal.com http://www.alonsoruibal.com
  158. 158. Indice Implantación  Instalación de hardware  Instalación de software  Bases de datos  Configuración  Los equipos de operación  Documento de operación  Documento de paso a producción  Copia de seguridad y marcha atrás  Monitorización de las aplicaciones  La importancia del control de código  La formación a los usuarios  El retorno de inversión
  159. 159. Implantación  La implantación es el proceso de verificar e instalar nuevo equipo, instalar la aplicación, construir todos los archivos de datos necesarios para utilizarla y entrenar a los usuarios.  Cada estrategia de implantación tiene sus méritos de acuerdo con la situación que se considere dentro de la empresa. Sin importar cuál sea la estrategia utilizada, los encargados de desarrollar el sistema procuran que el uso inicial del sistema se encuentre libre de problemas.  Los sistemas de información deben mantenerse siempre al día, la implantación es un proceso de constante evolución.
  160. 160. Instalación de hardware  En muchos proyectos también es necesario instalar el hardware sobre el que va a funcionar  Cuando se instala el entorno de producción es aconsejable instalar también el de integración, para que sean similares (replicación de entornos)  Redundancia: para aplicaciones críticas es mejor no tener una sóla sola máquina en producción: se utiliza redundancias para aumentar la disponibilidad  Cada vez se tiende más hacia la virtualización de las máquinas, lo que facilita la redundancia, las copias de seguridad y la replicación de entornos
  161. 161. Instalación de software  La instalación y actualización de software debe automatizarse lo máximo posible: − Instaladores − Scripts que copien la aplicación a todos los equipos  No sólo tenemos que instalar nuestra aplicación, también sistema operativo y aplicaciones auxiliares: BBDD, etc.  Hay lenguajes que tienen mecanismos para realizar estas actualizaciones de forma automática: − Java Web Start: la aplicación, al arrancar, consulta sus partes que se han modificado, se las descarga y se ctualiza automáticamente
  162. 162. Bases de datos  Cuando pasamos a producción una aplicación con BBDD nos podemos encontrar con dos escenarios: − Creación por primera vez de la BBDD: se proporciona un script con todas las sentencias de creación de la BBDD y la inserción en tablas de todos los datos necesarios − Actualización: es necesario tener scripts que incluyan los cambios entre la version anterior y la nueva:  Añadir/borrar columnas  Modificar datos  Insertar/borrar filas
  163. 163. Configuración  Es muy importante, ya normalmente el correcto funcionamiento de la aplicación depende de su correcta configuración  Abarca: − Conexiones a BBDD − Conexiones a otras máquinas: FTP, web services, etc − Parámetros dentro de la aplicación, etc.  Hay aplicaciones cuya adaptación a la empresa se hace completamente por configuración (CRMs, ERPs...) y es un proceso mutuo en el que se adapta la aplicación a la empresa y la empresa a la aplicación
  164. 164. Los equipos de operación  Son equipos en las empresas que se encargan del mantenmiento de los sistemas, lo que se suele llamar “operación de sistemas”  Entre sus tareas están las de: − Instalar/mantener el hardware − Instalar las nuevas aplicaciones − Actualizar las versiones de las aplicaciones existentes − Gestionar las copias de seguridad y las restauraciones en caso de desastres − Monitorizar el rendimiento de las aplicaciones − Gestionar la seguridad global de la empresa
  165. 165. Documento de operación  Cada aplicación debe tener un documento destinado al equipo de operación  En este documento debe figurar: − De qué ficheros consta la aplicación − Cómo se instala y se actualiza la aplicación − Cómo configurar la aplicación − Las operaciones de mantenimiento − Cómo se hacen las copias de seguridad y la recuperación de desastres − Cómo monitorizar la aplicación
  166. 166. Documento de paso a producción  En aplicaciones complejas también es necesario, para cada actualización de la aplicación elaborar un documento en el que se indiquen: − Los cambios que incluye la nueva versión de la aplicación − Cuándo se va a pasar y si requiere corte en el servicio o no − Los pasos que hay que realizar para actualizar la aplicación − Cómo comprobar que los cambios funcionan correctamente
  167. 167. 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
  168. 168. Monitorización de aplicaciones  Una vez puesta en producción, es necesario monitorizar los siguientes parámetros de la aplicación: − uso de CPU − memoria consumida − espacio en disco − uso de red  Para ello hay software específico que permite a las empresas controlar su infraestructura de aplicaciones: − Nagios − OSSIM  SNMP (Simple Network Management Protocol): protocolo para intercambiar información
  169. 169. La importancia del control del código  En una empresa los proveedores de TI pueden ser varios y se puede cambiar entre ellos  Si no se dispone del código fuente de las aplicaciones que llevan la lógica de negocio de nuestra empresa, estaremos atándonos a un solo proveedor  En empresas grandes es muy importante tener un sistema de control de versiones bajo el control de la empresa, donde los desarrolladores de las empresas proveedoras suban el código de las aplicaciones que realizan
  170. 170. La formación a los usuarios (I)  Es una parte básica de la implantación de software, sobre todo cuando éste interactúa con los usuarios  Lo peor que puede pasar es que los usuarios no acepten la aplicación o no sean capaces de usarla  Se suelen impartir jornadas de formación a los distintos grupos de usuarios en las que: − Se presenta la aplicación y se explican sus bondades (importante para su aceptación) − Se realizan casos prácticos de uso (importante para la comprensión)
  171. 171. La formación a los usuarios (II)  En las jornadas de formación suelen participar los responsables del proyecto, tanto por parte del cliente como del proveedor  Es bueno acompañar la formación con la entrega de manuales, que pueden ser distintos en función del grupo de usuarios
  172. 172. El retorno de inversión (II)  El ROI (Return Of Investments) es el beneficio que obtenemos por cada unidad monetaria invertida en tecnología durante un periodo de tiempo.  Esto es lo que busca cada cliente que implanta una aplicación  Suele utilizarse para analizar la viabilidad de un proyecto y medir su éxito.  ROI=(Beneficios/Costes)x100  El coste es sencillo de medir: siempre sabemos cuánto nos estamos gastando lo complicado es calcular el beneficio.
  173. 173. El retorno de inversión (I)  Por qué es complicado medir los beneficios: − Lo que entiende cada uno como beneficios − La entrada en juego de factores como el cambio tecnológico − El desorden al controlar y medir finanzas − La dificultad a la hora de medir los tiempos que se ahorran los usuarios − Dificultad para imputar mejoras de rendimiento en el beneficio − Hay cosas intangibles como la satisfacción de los usuarios
  174. 174. Manuales de las aplicaciones Alberto Alonso Ruibal alberto@alonsoruibal.com http://www.alonsoruibal.com
  175. 175. Indice  Introducción  Tipos de manuales  Apartados del manual  Formatos de manuales  Acceso a los manuales
  176. 176. Introducción  Los manuales es un entregable imprescindible en los proyectos  Deben ser presupuestados correctamente, ya que el escribir documentación suele llevar siempre más tiempo de lo previso  Facilitan la comprensión de la aplicación y la resolución rápida de dudas  Reducen el nivel de consultas sobre el departamento técnico
  177. 177. Tipos de manuales  Los manuales se suelen realizar en función del perfil de usuario que los vaya a leer: − Administrador − Usuario  Otras veces se separan así − Manual de uso rápido − Manual avanzado  A continuación mostramos una estructura típica de un manual de una aplicación informática:
  178. 178. Apartados del manual (I) Introducción  Presentación del sistema − Requisitos de Configuración de Hardware − Distribución del Sistema y Autorización de Uso − Atención al Usuario − Esquema de Estados − Perfiles o Niveles de acceso al sistema  Primeros Pasos − Cómo acceder al sistema − Menú principal Nivel Usuario − Cambio de claves de acceso − Cómo salir del sistema − Cómo actuar ante una incidencia
  179. 179. Apartados del manual (II)  Uso avanzado: en esta sección se encuadran todas las funcionalidades avanzadas de las que disponga la aplicación: − Función 1 − Función 2 − ...  Troubleshooting, o resolución de problemas frecuentes  Glosario: los términos y abreviaturas a comprender en el resto del documento
  180. 180. Formatos de manuales  Los manuales pueden ser presentados en varios formatos: − Papel: aporta tangibilidad al proyecto − Word: problemas a la hora de imprimirlo y empotrarlo en aplicaciones web − PDF: Útil para ser impreso. También se puede empotrar en web de forma sencilla − HTML: facilita la integración con las aplicaciones web, pero dificulta el mantener una copia impresa con el mismo contenido − Archivo de Ayuda de Windows CHM: no es multiplataforma, sólo tiene sentido en aplicaciones locales − Wiki: este método aporta facilidad de actualización y posibilidad de participación de los usuarios de la aplicación
  181. 181. Acceso a los manuales  Es aconsejable que una copia del manual esté siempre accesible desde la aplicación  En caso de la web, se puede disponer en la portada de la aplicación  En caso de aplicaciones locales, se pueden utilizar sistemas de ayuda CHM, pero también se puede poner un enlace a la web de documentación

×