Apuntes de la Asignatura de Empresa y Gestión de by mercy2beans111

VIEWS: 11 PAGES: 181

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


                      Alberto Alonso Ruibal
                  alberto@alonsoruibal.com
                http://www.alonsoruibal.com
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/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


Producción   Marketing      Financiero   Recursos
                                         humanos

• Definida por Taylor, que divide las actividades
  de una empresa según las funciones asignadas.
  a cada una de ellas
     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.
     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     Francia     Portugal
    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
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 B     Producto C
     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   Productos de   Productos
       caballeros      señoras      infantiles
          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
  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.
   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
      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
 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
        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.
     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.
      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
    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


                 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 presentarlo?
    ¿Qué es un plan de Empresa?
   El Plan de Empresa es una herramienta de
    trabajo para aquellas personas o colectivos
    que quieran poner en marcha una iniciativa
    empresarial.
   Es un documento escrito por los
    promotores del proyecto y en él están
    recogidos los diferentes factores y los
    objetivos de cada una de las áreas que
    intervienen en la puesta en marcha de la
    empresa.
   No debe confundirse con una simulación
    de cuentas de documentos financieros
    provisionales.
               ¿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.
      ¿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.
          ¿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
        ¿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.
          ¿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.
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 cascada
       Orientado a hitos
       Orientado a prototipos
       Programación extrema
       Métrica v3
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
          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 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
    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)
Especificación
 de requisitos

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


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


                       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
   Presupuestación
            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
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
         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 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!
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 (CVS, IDEs, etc),
    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. Cuidado con
    las subidas de los hitos entregables a 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
    tiempos, sobre todo aplicando 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
    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
    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: 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
   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
    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 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
             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 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
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 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.
      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.
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%
       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
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é 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
          “Usa”: de dos tipos:
    pueden sercuando 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)
          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


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


                       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 tiempos
   Control del estado del proyecto
   Incidencias
                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.
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
                   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
                 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
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/)
             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/)
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 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...
                 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


                        Alberto Alonso Ruibal
                   alberto@alonsoruibal.com
                  http://www.alonsoruibal.com
   Calidad            Indice
       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
   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


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

								
To top