Professional Documents
Culture Documents
Empresa y Gestión de
Proyectos
• 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/generación de
servicios
– Imagen y prestigio
– Aceptación social
– Satisfacción de necesidades colectivas
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.
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
Organización jerárquica pura
• También se llama “lineal” o “por
números”
A • Cada persona recibe ordenes de
un solo jefe, prevaleciendo el
B principio de jerarquía y de
subordinación absoluta a su
inmediato superior.
C D
• Inconvenientes:
– Sobrecarga a personas con deberes
y responsabilidad
E F G H
– Excesiva rigidez que no permite que
se implanten las ventajas de la
especialización
Organización funcional (I)
Dirección
Dirección
Dirección
• 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
La función de dirección
INPUTS OUTPUTS
Transformación
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
Bibliografía
• Guía para crear tu empresa. Álvaro López
Amo, Ed. Espasa.
• http://www.monografias.com
Plan de empresa
Es el modelo clásico
Análisis
Las fases se deben
Diseño ejecutar de forma
secuencial, pero se puede
Codificación volver a la fase anterior
Pruebas
Cada etapa genera una
documentación o un
Implantación producto que recibe de
entrada la siguiente fase
Mantenimiento
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
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
Modelo orientado a hitos (I)
Especificación
de requisitos
Consiste en introducir
Análisis hitos entregables al
cliente durante el
Diseño de arquitectura desarrollo del proyecto
Codificación y pruebas A
Entrega A
Codificación y pruebas B
Entrega B
Codificación y pruebas C
Entrega C
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
Modelo orientado a prototipos (I)
Se desarrolla un primer
prototipo relativamente
Prototipo 1
completo, frecuentemente
destinado a ser ya utilizado
por cliente.
Prototipo 2 El cliente aporta
realimentación y con ella se
desarrolla el siguiente
Prototipo 3
prototipo
Se van repitiendo los ciclos
de iteración hasta alcanzar
una versión final.
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
Programación extrema (I)
Consiste en llevar la límite el modelo de
prototipos, haciendo entregas continuas
con pequeños cambios en la funcionalidad
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
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
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).
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)
CSI)
Implantación y Aceptación del Sistema (Proceso
IAS)
Mantenimiento del Sistema de Información (Proceso
MSI)
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/
Gestión de proyectos: ERQs y
presupuestos
Importancia de la documentación
Análisis funcional
Casos de uso
Especificación
Diagramas
Pruebas
Qué más incluir en el documento
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
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.
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)
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.
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.
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
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.
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
“Usa”:
sercuando
de dossetipos:
quiere
reflejar un
comportamiento común
en varios casos de uso.
“Extiende”: cuando se
quiere reflejar un
comportamiento opcional
de un caso de uso
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.
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.
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)
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
El Diseño Técnico
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
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.
¿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
¿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
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
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.
Diagramas de despliegue (II)
En los diagramas de despligue se
representan los distintos componentes con
los siguientes símbolos:
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
Modelo entidad-relación (I)
Representa:
Entidades: se “corresponden” a las tablas en
la base de datos
Se indican los campos de cada una de las
entidades
Se puede especificar el tipo de cada campo
Relaciones: se “corresponden” a las foreign
keys de la DDBB, y pueden ser de varios
tipos:
1a1
1aN
NaN
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.
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)
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: 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
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.
Diagramas de paquetes (II)
Diagramas de secuencia (I)
Representan la interacción temporal entre
los distintos actores y componentes del
sistema para un caso de uso.
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
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.
Fase de Programación de los
proyectos
Desarrollo
Integración
Producción
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.)
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.
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
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)
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
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
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.
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
Implantación de software
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 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
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:
Apartados
Introducción
del manual (I)
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
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
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
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