Administración de

Proyectos

de TI

DR. CARLOS WONG LAU

Administración de Proyectos de TI ,

Metodologías y Ciclos de Vida

¿Por qué es necesaria la gestión o administración de proyectos?

Definición de proyecto

Ciclo de vida de un proyecto

En cascada

Orientado a hitos

Orientado a prototipos

Programación extrema

Métrica v3

La caseta de mi perro

Sólo hace falta una persona

Muchas veces 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 planificación... esto es un

Proyecto

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.

Proyectos de TI

La gestión o administracion de proyectos TI es más compleja por:

Complejidad intrínseca al desarrollo de software y hardware

Imprecisión en la planificación del proyecto y estimación de los costos.

Calidad de las aplicaciones.

Dificultad de mantenimiento de las aplicaciones.

Esto hace surgir una rama de la ciencia que se llama Ingeniería de Software que intenta resolver estos problemas

1. Método completo para la GPT 2. Origen de los proyectos

tecnológicos 3. Ventajas competitivas y

procesos del negocio 4. Claves de la administración

integral del proyecto

8

Aplicar Método (o calidad)

• Trabajar con un método

– Completo, coherente, consistente, flexible

• Sistema de productividad

– Incorporación del usuario, Normalización,

– Técnicas, Herramientas, Hardware,

– Habilidad del desarrollador.

• Responsabilidad social

• Análisis de riesgos

9

Etapas del Proyecto

– Concepción: necesidad o problema

– Factibilidad: soluciones y plan de proyecto

– Análisis: modelo integral de la solución (la mesa)

– Diseño: ingeniería de detalle del modelo

– Implementación: realizar en carácter piloto

– Despliegue: llevar a todos los puntos de uso

– Operación: acciones de mejora continua durante la vida útil

10

C F A D I D O

Estudio Desarrollo MC

C F A D I D O

Estudio Desarrollo MC

¿Cuáles Proyectos Tecnológicos?

• Solucionar problemas de información • Apoyar los procesos del negocio • Apoyar las adquisiciones • Implementar un ERP • Administrar documentos • De comunicación • Otros

11

Insertar la GPT en la estrategia de la organización

• Por si sola no aporta valor, está al servicio del propósito de la organización

• Mayor proporción si se acerca al corazón del negocio

• Comunicación con los socios tecnológicos

• La TI pasa a través de integrantes de la organización quienes deben querer usarla y estar capacitados para ello 12

Las seis mejores prácticas del desarrollo de software

Método RUP (Rational Unified Process), de Rational Corp.

• Desarrollo Iterativo • Manejo de los requerimientos • Uso de una arquitectura de componentes • Modelamiento visual del software • Verificación de la calidad • Control de cambios

13

El plan del proyecto

• Completo, flexible, revisado en cada etapa

• Preparación de licitaciones por etapa • La misma formalidad en caso de

desarrollo interno • Mantener un Kill Time • Orientación del desarrollo:

cascada o espiral

14

Técnica de desarrollo en espiral

• Alcanza en cada iteración mayor porción de requerimientos y avanza en eficacia y eficiencia

• Cada vuelta es un ciclo completo de desarrollo

• Exige amplio esfuerzo de gestión y operación

• Se resuelven primero los requerimientos más críticos

15

Dos equipos de trabajo

• Uno de gestión del proyecto • Análisis de riesgos, RS, Gestión del

cambio, seguimiento y otros

• Aseguramiento de calidad (QA), método, diseño de pruebas, confirmación de requerimientos con los usuarios, etc...

• Al menos una “UTP” (Unidad Técnica de Proyectos) o PMO (Project Management Office)

• Otro de desarrollo operativo del proyecto

16

En el modelamiento…

• Coordinar a todos los actores • Considerar la protección de la

información • Conocer características de un buen

diseño • Aplicar el modo de procesamiento

correcto • Optimizar la operación del sistema • Facilitar la auditoría computacional

17

Origen de los Proyectos Tecnológicos

18

Origen de los proyectos tecnológicos

• Acercamiento a las TI • ¿Cómo se conciben los proyectos

tecnológicos? • Liderazgo Tecnológico • Rol del commodity • Revisión de soluciones tecnológicas típicas

19

Acercamiento a las TI

• Aportes de la tecnología a la luz del propósito de la organización para obtener ventajas competitivas

• En la organización no existen problemas tecnológicos sino solamente problemas del negocio.

• Alto nivel de fallas en proyectos TI • Necesidad de método, sistematización,

calidad...

20

¿Cómo se conciben los proyectos tecnológicos?

• Aumentar la proporción hacia la estrategia en lugar de la reacción

• Más allá del hardware, incluye métodos, técnicas, herramientas y muchos otros factores

• Rol preponderante de las personas • Tecnología de información básica

generalizada • Alta tecnología focalizada y al servicio del

propósito

21

Liderazgo tecnológico

• Base en un modelo de negocios • Las fortalezas de los procesos • Concentrarse en las habilidades

centrales • El contexto de un método completo

22

Rol del commodity

• Especialmente en los procesos que no agregan valor y que deben existir (¿?)

• Tecnología de información de uso generalizado

• Existen soluciones genéricas para casi todo tipo de negocio

• Es preferible no reinventar a nivel del commodity, solamente usarlo

23

Revisión de soluciones tecnológicas típicas

• Productos ERP (World Class)

• SCM, CRM, BI y otras

• Comunicación interna y externa

• Desarrollo interno de software

• Externalización del desarrollo

• Aplicaciones B2B, B2C...

• Otras tecnologías: groupware, Workflow, EDI, ...

» En cada caso ¿cuando usar?

24

Ventajas competitivas y procesos del negocio

25

Ventajas competitivas y procesos del negocio

• Algunos mensajes • Desde el Plan de Negocios • La cadena de valor de M. Porter

26

Algunos mensajes

• La estrategia guía el trabajo en la gestión de procesos del negocio

• Es un proceso complejo

• Secuencia clave: fortalezas, factores de diferenciación y ventajas competitivas

• Retroalimentación entre ventajas competitivas y procesos del negocio

• Invertir en una buena implementación

27

FD FO VC

Desde el Plan de Negocios

• Propósito – Visión, misión y valores

• Objetivos – Pocos, con hitos y mediciones

• Programa de Acción – Acciones o proyectos específicos,

responsables, costos, plazos y calidad, seguimiento

28

Infraestructura de la firma

Manejo de Recursos Humanos

Desarrollo de Tecnología

Adquisiciones

Logística de

entrada

Operaciones Logística de salida

Marketing y ventas

Servicio

Actividades Primarias

Activi-dades

de apoyo

Margen

Margen

Cadena de valor de M. Porter

29

Claves de la administración integral

del proyecto

30

Claves de la administración integral del proyecto

• Claves de la GPT • Componentes intrínsecos de la

GPT • Ver el todo

31

Claves de la GPT

• Pensar en soluciones integrales, desde la estrategia

• Trabajar con calidad para tener activos tecnológicos

• Comunicar y hacer participar a todos los involucrados

• Plan de proyecto completo y por cada etapa

32

Componentes intrínsecos de la GPT

• Contenido, seguimiento, presentación, implementación, retroalimentación, riesgos y responsabilidad social

• En pocas palabras: aplicar método

33

Ver el todo...

• Hablamos de proyectos de cambio integral, también llamados:

• De modernización institucional

• De Reingeniería de negocios

• Todo comienza por... los procesos

34

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

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

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)

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

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 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

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

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)

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)

Gestión de proyectos: ERQs y presupuestos

Gestión del proyecto

Importancia de la documentación

Reuniones con el cliente

Especificación de requisitos

Presupuestación

Gestión del Proyecto

La gestión o administracion del proyecto es la aplicación del conocimiento, habilidades, herramientas y técnicas a las actividades del proyecto para conseguir cumplir los requisitos del proyecto

Tareas críticas:

Reuniones con el cliente

Estimación de duración, coste y esfuerzo (esto es, presupuestación)

Planificación de tareas y asignación de recursos

Seguimiento y control

Importancia de la documentación

Ejemplo : En los Proyectos de Software la documentación es de vital importancia:

El software es algo abstracto, la documentación aporta algo tangible al proyecto.

Documentar ayuda a compartir información entre usuarios y desarrolladores.

Permite acotar el proyecto.

Evita tomar decisiones precipitadas que pueden llevar a resultados catastróficos.

Facita la formación tanto de los usuarios como los desarrolladores

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

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

Errores frecuentes en las reuniones (II)

Cuidar la vestimenta, las formas y el lenguaje corporal

No ignorar a los technical

Tomar notas (puede estar bien grabarlas en audio o incluso levantar un “acta” de la reunión y enviarla por email)

¡Cuidado con las conversaciones informales!

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

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

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

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...

Qué presupuestar (I)

Análisis: el análisis del problema posterior al presupuesto previo a la elaboración del documento de análisis funcional y del diseño técnico

Consultoría: cuando el objetivo del proyecto es la recomendación de medidas apropiadas y prestación de asistencia en la aplicación de dichas recomendaciones.

Preparación del entorno: instalación de servidores, aplicaciones etc.

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.

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...

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

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

Clausulas de penalización

En algunos casos los clientes pueden pedir que se incluyan clausulas que penalicen el retraso del proyecto

Limitarlas a un porcentaje del costo total del proyecto (un 20% como mucho)

Cubrirse las espaldas en la estimación de tempos, sobre todo applicant margen al tiempo de entrega

El cálculo de la rentabilidad

Es muy importante tener un modelo de presupuesto que luego nos permita hacer un cálculo de la rentabilidad sobre los tempos estimados

Para ello durante la fase de implementación mediremos los tempos que lleva cada tarea y los compararemos con el estimado (control de tareas)

Esto nos será de mucha ayuda

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.

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.

Planificación: Pert’s y Gantt’s

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

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.

Diagramas PERT (I)

PERT (Program Evaluation and Review Technique)

Desarrollado por la Special Projects Office de la Armada de EE.UU. a finales de los 50s para el programa de I+D que condujo a la construcción de los misiles balísticos para el submarino Polaris.

Está orientada a los sucesos o eventos, y se ha utilizado típicamente en Proyectos de I+D en los que el tiempo de duración de las actividades es una incertidumbre.

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.

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 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 .

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.

Camino crítico El camino crítico en un proyecto es la sucesión

de actividades que dan lugar al máximo tiempo acumulativo.

Determina el tiempo más corto que podemos tardar en hacer el proyecto si se dispone de todos los recursos necesarios.

Para calcularlo es necesario conocer la duración de las actividades que están en el camino crítico y sumar sus tempos:

Método del tiempo estimado (CPM): se utiliza el cálculo del tiempo medio: Te = m

Método del tiempo esperado (PERT): Te = (a + 4m + b) / 6

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.

Representación de diagramas Gantt (I)

Se representan de la siguiente forma:

En las filas la relación de actividades a realizar

En las columnas la escala de tempos que se está manejando

La duración y situación en el tiempo de cada actividad se indica mediante un rectángulo dibujado en el lugar correspondiente.

Los hitos se marcan con rombos

El porcentaje de realización de la tarea se indica con una línea dentro del rectángulo de la tarea

Las fases se marcan con lineas sobre los rectángulos de las tareas

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 flechas

Cada tarea se retrasa hasta el punto en el que las tareas de las que depende terminan.

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

Asignación de recursos (I) La asignación de recursos es una tarea

fundamental en la planificación, ya que hay que considerar aspectos technical de cada recurso como su disponibilidad, capacidad de trabajo,impedimentos horarios, etc.

Cuantificar necesidades y fechas de incorporación de recursos.

Considerar la capacidad, los conocimientos y la experiencia de cada recurso.

Considerar la complejidad, el tamaño y los requerimientos technical de cada tarea.

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.

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 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

Casos de uso: Diagramas (III)

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:

1 a 1 1 a N N a N

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

Sistemas de control de versiones

CVS

Terminología

Operaciones

Tags

Subversion

Clearcase

Control de tempos

Control del estado del proyecto

Incidencias

Introducción

La programación de grandes proyectos de software necesita de varias herramientas, como los sistemas de control de versiones de código,

Durante la fase de desarrollo, el gestor del proyecto debe de encargarse del seguimiento del proyecto, con el control de tempos y de estado, gestionando la comunicación con el cliente.

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

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

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.

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

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

Control de tempos

Durante la programación es encesario saber cuánto tiempo invierte cada programador en cada una de las tarea

Estos tempos nos permiten saber cuánto nos hemos equivocado en la estimación

Hay aplicaciones que nos permiten llevar este control

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

Incidencias (I) La fase de desarrollo no suele ser un

“camino de rosas”, ya que nos solemos encontrar con:

Cambios que pide el cliente: es necesario presupuestarlos, planificarlos y ver cómo afectan a los tempos de entrega, o bien dejarlos para cuando se termine el proyecto

Partes de la aplicación mal especificadas: que nos originan nuevas tareas que no teníamos previstas

Retrasos en la programación: por estimaciones demasiado optimistas. Suele ser necesario replanificar

Complicaciones técnicas: los problemas que nunca están previstos y siempre aparecen...

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

Calidad y Pruebas del Software

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

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.

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

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

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

¿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?)

¿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?)

¿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?

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

Entornos de prueba

En todo desarrollo de software nos deberíamos encontrar con estos escenarios:

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

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.

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

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

Implantación La implantación es el proceso de veridical e

instalar Nuevo equip, instalar la aplicación, construir todos los archivos de datos necesarios para utilizarla y entrenar a los usuarios.

Cada estrategia de implantación tiene sus méritos de acuerdo con la situación que se considere dentro de la empresa. Sin importar cuál sea la estrategia utilizada, los encargados de desarrollar el sistema procuran que el uso inicial del sistema se encuentre libre de problemas.

Los sistemas de información deben mantenerse siempre al día, la implantación es un proceso de constante evolución.

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

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

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

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

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

Documento de operación

Cada aplicación debe tener un documento destinado al equip de operación

En este documento debe figurar:

De qué ficheros consta la aplicación

Cómo se instala y se actualiza la aplicación

Cómo configurar la aplicación

Las operaciones de mantenimiento

Cómo se hacen las copias de seguridad y la recuperación de desastres

Cómo monitorizar la aplicación

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

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

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

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

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)

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

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.

El retorno de inversión (I)

Por qué es complicado medir los beneficios:

Lo que entiende cada uno como beneficios

La entrada en juego de factores como el cambio tecnológico

El desorden al controlar y medir finanzas

La dificultad a la hora de medir los tempos que se ahorran los usuarios

Dificultad para imputar mejoras de rendimiento en el beneficio

Hay cosas intangibles como la satisfacción de los usuarios