martes, 19 de octubre de 2010 | By: Wynnie Calero

Caso de Estudio #2

Programa de Métricas

1.    Objetivo/s del Negocio
Realizar una mercadotecnia defensiva de sus servicios de viaje

2.    Nuevos saberes/aprendizaje
Conocimiento de los servicios que ofrece la compañía
ü  Contactos
·         Hoteles
·         Aerolíneas
·         Rentacar
ü  Paquetes turísticos
ü  Promociones de boletos de avión
ü  informes
·         Encuestas
·         Sugerencias


3.    Sub-objetivos
Pagina Web
 
4.    Entidades y Atributos de los sub-objetivos



 
5.    Objetivo/s de medición
Medimos para tener una idea del tiempo que se necesita invertir en el desarrollo del software, los recursos humanos y monetarios a utilizar.

6.    Preguntas cuantitativas e indicadores relacionales
Preguntas
Indicadores
¿Cuál es el esfuerzo necesario para desarrollar el software?
Esfuerzo(E)

¿Cuántas personas van a ser necesarias para conformar el equipo de trabajo?
Personas(P)
¿Cuánto tiempo va a ser invertido para el desarrollo e implementación del software?
Tiempo de desarrollo(TD)
¿Cuál es el coste de inversión para el software?
Costo(CT)

7.    Recolección de datos y calculo de indicadores

P=3.00*(0.367)1.12
P=0.975 = 1

TD=2.5*(0.976)0.35
TD=2.47 = 2 ½ meses

CT= (0.976/2.47)*275
CT=108.66 = 109
E=0.976*16.12
E=15.73 = 16

8.    Medidas a usar(Definición operativa de los resultados)

·         En el cálculo de las personas se llego a la conclusión de que no se necesita de un grupo de trabajo porque una persona es suficiente para realizar todo el trabajo que requiere.
·         En el cálculo del tiempo de desarrollo de software concluimos que la duración del desarrollo del proyecto será de dos meses y medio.
·         En el cálculo del costo concluimos que la ganancia del proyecto después de finalizar todos los pagos(viáticos, salarios, licencia, alquiler y servicios generales) es de $109(ciento nueve dólares).
·         En el cálculo del esfuerzo nos dimos cuenta de que la persona que desarrollara el software realizara en dos meses y medio lo que hubieran realizado 16 personas manualmente.

9.    Acciones de mejora
No hay acciones de mejora porque los cálculos son equitativos a la realidad y por tanto pasamos a la implementación.

 
 Plan de implementación(Diagrama de proyect)



  
Interfaces






Tabla de Gestión de Riesgo

lunes, 18 de octubre de 2010 | By: Wynnie Calero

Conceptos de Aspectos de Gestión


La gestión eficaz de un proyecto de software se centra en las cuatro P’s: personal, producto, proceso y proyecto. El orden no es arbitrario. El gestor que se olvida de que el trabajo de ingeniería del software es un esfuerzo humano intenso nunca tendrá éxito en la gestión de proyectos. Un gestor que no fomenta una minuciosa comunicación con el cliente al principio de la evolución del proyecto se arriesga a construir una elegante solución para un problema equivocado. El administrador que presta poca atención al proceso corre el riesgo de arrojar métodos técnicos y herramientas eficaces al vacío. El gestor que emprende un proyecto sin un plan sólido arriesga el éxito del producto.

Personal

La necesidad de contar con personal para el desarrollo del software altamente preparado y motivado se viene discutiendo desde los años 60 (por ejemplo, COUSO, WíT94, DEM981). De hecho, el «factor humano» es tan importante que el Instituto de Ingeniería del Software ha desarrollado un Modelo de madurez de la capacidad de gestión de personal (MMCGP) «para aumentar la preparación de organizaciones del software para llevar a cabo las cada vez más complicadas aplicaciones ayudando a atraer, aumentar, motivar, desplegar y retener el talento necesario para mejorar su capacidad de desarrollo de software» [CUR94].

El modelo de madurez de gestión de personal define las siguientes áreas clave prácticas para el personal que desarrolla software: reclutamiento, selección, gestión de rendimiento, entrenamiento, retribución, desarrollo de la carrera, diseño de la organización y del trabajo y desarrollo cultural y de espíritu de equipo. El MMCGP es compañero del modelo de madurez de la capacidad software, que guía a las organizaciones en la creación de un proceso de software maduro.

Cargos del Personal

  1. Operador de PC
  2. Técnico de Soporte y Mantenimiento
  3. Técnico de Reparación de PC, impresoras, monitores, celulares, etc.
  4. Técnico en Programación
  5. Técnico en Redes de PC, teléfonos y de comunicación
  6. Ingeniero en Computación
  7. Ingeniería en Sistemas de Información
  8. Ingeniería en Telecomunicaciones
  9. Administrados de Base de Datos
  10. Administrador de Redes
  11. Administrador de Servidores
  12. Administrador de Sistemas de Informáticos
  13. Analista Categorías: A, B, C.
  14. Diseñador de Web y de Interfaz
  15. Diseñador/a
  16. Auditor/a
  17. Evaluador/a
  18. Diseñador/a Informático/a
  19. Director/a de Centros
  20. Capacitadores  

Producto

Antes de poder planificar un proyecto, se deberían establecer los objetivos y el ámbito del producto, se deberían considerar soluciones alternativas e identificar las dificultades técnicas y de gestión. Sin esta información, es imposible definir unas estimaciones razonables (y exactas) del coste; una valoración efectiva del riesgo, una subdivisión realista de las tareas del proyecto o una planificación del proyecto asequible que proporcione una indicación fiable del progreso.


El desarrollador de software y el cliente deben reunirse para definir los objetivos del producto y su ámbito. En muchos casos, esta actividad empieza como parte del proceso de ingeniería del sistema o del negocio y continúa como el primer paso en el análisis de los requisitos del software.  Los objetivos identifican las metas generales del proyecto sin considerar cómo se conseguirán (desde el punto de vista del cliente).


El ámbito identifica los datos primarios, funciones y comportamientos que caracterizan al producto, y, más importante, intenta abordar estas características de una manera cuantitativa. Una vez que se han entendido los objetivos y el ámbito del producto, se consideran soluciones alternativas.


Proceso

Un proceso de software proporciona la estructura desde la que se puede establecer un detallado plan para el desarrollo del software. Un pequeño número de actividades estructurales se puede aplicar a todos los proyectos de software, sin tener en cuenta su tamaño o complejidad. Diferentes conjuntos de tareas, hitos, productos del trabajo y puntos de garantía de calidad permiten a las actividades estructurales adaptarse a las características del proyecto de software y a los requisitos del equipo del proyecto. Finalmente, las actividades protectoras tales como garantía de calidad del software, gestión de la configuración del software y medición cubren el modelo de proceso. Las actividades protectoras son independientes de las estructurales y tienen lugar a lo largo del proceso.

Proyecto

Dirigimos los proyectos de software planificados y controlados por una razón principal es la Única manera conocida de gestionar la complejidad. Y todavía
seguimos esforzándonos. En 1998, los datos de la industria del software indicaron que el 26% de proyectos de software fallaron completamente y que el 46% experimentaron un desbordamiento en la planificación y en el coste [REE99]. Aunque la proporción de éxito para los proyectos de software ha mejorado un poco, nuestra proporción de fracaso de proyecto permanece más alto del que debería ser. Para evitar el fracaso del proyecto, un gestor de proyectos de software y los ingenieros de software que construyeron el producto deben eludir un conjunto de señales de peligro comunes; comprender los factores del éxito críticos que conducen a la gestión correcta del proyecto y desarrollar un enfoque de sentido común para planificar, supervisar y controlar el proyecto.


Practicas Críticas

El Concilio Airlie ha desarrollado una lista de «prácticas críticas de software para la gestión basada en el rendimiento». Estas prácticas son «utilizadas de un modo consistente por, y consideradas críticas por, organizaciones y proyectos de software de mucho éxito cuyo rendimiento “final” es más consistente que los promedios de la industria» [AIR99]. En un esfuerzo por permitir a una organización de software determinar si un proyecto específico ha implementado prácticas críticas, el Concilio Airlie ha desarrollado un conjunto de preguntas de «Visión Rápida» [AIR99] para un proyecto:

Gestión formal del riesgo ¿Cuáles son los diez riesgos principales para este proyecto? Para cada uno de los riesgos ¿cuál es la oportunidad de que el riesgo se convierta en un problema y cuál es el impacto si lo hace?

Coste empírico y estimación de la planificación ¿Cuál es el tamaño actual estimado de la aplicación de software (sin incluir el software del sistema) que será entregada en la operación? ¿Cómo se obtuvo?

Gestión de proyectos basada en métricas ¿Dispone de un programa de métricas para dar una primera indicación de los problemas del desarrollo? Si es así, ¿cuál es la volatilidad de los requisitos actualmente?


Seguimiento del valor ganado ¿Informa mensualmente de las métricas del valor ganado? Si es así, ¿están calculadas estas métricas desde una red de actividades de tareas para el esfuerzo total a la próxima entrega?

Seguimiento de defectos frente a objetivos de calidad ¿Realiza el seguimiento e informa periódicamente del número de defectos encontrados en cada prueba de inspección [revisión técnica formal] y ejecución desde el principio del programa y del número de defectos que se corrigen y se producen en la actualidad?

Gestión del programa del personal ¿Cuál es la media de rotación de la plantilla en los tres Últimos meses por cada uno de los distribuidores/desarrolladores involucrados en el desarrollo del software para este sistema?

Si un equipo de proyectos de software no puede responder a estas preguntas, o las responde inadecuadamente, se debe realizar una revisión completa de las prácticas del proyecto.

Gestión de Configuración del Software


El resultado del proceso de ingeniería del software es una información que se puede dividir en tres amplias categorías:

1.      Programas de computadora (tanto en forma de código fuente como ejecutable)
2.      Documentos que describen los programas de computadora (tanto técnicos como de usuario)
3.      Datos (contenidos en el programa o externos a él).

Los elementos que componen Toda la información producida como parte del proceso de ingeniería del software se denomina colectivamente configuración del software. A medida que progresa el proceso del software, el número de elementos de configuración del software (ECSs) crece rápidamente. Una especificación del sistema produce un plan del proyecto del software y una especificación de requisitos del software (así como otros documentos relativos al hardware). A su vez, éstos producen otros documentos para crear una jerarquía de información.

Si simplemente cada ECS produjera otros ECSs, no habría prácticamente confusión. Desgraciadamente, en el proceso entra en juego otra variable el cambio. El cambio se puede producir en cualquier momento y por cualquier razón. De hecho, la Primera Ley de la Ingeniería de Sistemas [BERSO] establece: Sin importar en qué momento del ciclo de vida del sistema nos encontremos, el sistema cambiará y el deseo de cambiarlo persistirá a lo largo de todo el ciclo de vida.

¿Cuál es el origen de estos cambios? La respuesta a esta pregunta es tan variada como los cambios mismos. Sin embargo, hay cuatro fuentes fundamentales de cambios: nuevos negocios o condiciones comerciales que dictan los cambios en los requisitos del producto o en las normas comerciales;
Nuevas necesidades del cliente que demandan la modificación de los datos producidos por sistemas de información, funcionalidades entregadas por productos o servicios entregados por un sistema basado en computadora; Reorganización o crecimiento/reducción del negocio que provoca cambios en las prioridades del proyecto o en la estructura del equipo de ingeniería del software; restricciones presupuestarias o de planificación que provocan una redefinición del sistema o producto. La gestión de configuración del software (GCS) es un conjunto de actividades desarrolladas para gestionar los cambios a lo largo del ciclo de vida del software de computadora.
 

Líneas base

Una línea base es un concepto de gestión de configuración del software que nos ayuda a controlar los cambios sin impedir seriamente los cambios justificados. La IEEE (Estándar IEEE 610.12-1990) define una línea base como:
Una especificación o producto que se ha revisado formalmente y sobre los que se ha llegado a un acuerdo, y que de ahí en adelante sirve como base para un desarrollo posterior y que puede cambiarse solamente a través de procedimientos formales de control de cambios.

Una forma de describir la línea base es mediante la siguiente Consideración: las puertas de la cocina en un gran restaurante. Para evitar colisiones, una puerta está marcada como SALIDA y la otra como ENTRADA. Las puertas tienen topes que hacen que sólo se puedan abrir en la dirección apropiada. Si un camarero recoge un pedido en la cocina, lo coloca en una bandeja luego se da cuenta de que ha cogido un plato equivocado, puede cambiar el plato correcto rápida e informalmente antes de salir de la cocina. Sin embargo, si abandona la cocina, le da el plato al cliente y luego se le informa de su error, debe seguir el siguiente procedimiento:

1.    Mirar en la orden de pedido si ha habido algún error
2.    Disculparse insistentemente
3.    Volver a la cocina por la puerta de ENTRADA
4.    Explicar el problema, etc.

Una línea base es análoga a la cocina de un restaurante. Antes de que un elemento de configuración de software se convierta en una línea base, el cambio se puede llevar a cabo rápida e informalmente. Sin embargo, una vez que se establece una línea base, pasamos, de forma figurada, por una puerta de un solo sentido. Se pueden llevar a cabo los cambios, pero se debe aplicar un procedimiento formal para evaluar y verificar cada cambio. En el contexto de la ingeniería del software, definimos una línea base como un punto de referencia en el desarrollo del software que queda marcado por el envío de uno o más elementos de configuración del software y la aprobación del ECS obtenido mediante una revisión técnica forma.

Por ejemplo, los elementos de una Especificación de Diseño se documentan y se revisan. Se encuentran errores y se corrigen. Cuando todas las partes de la especificación se han revisado, corregido y aprobado, la Especificación de Desafío se convierte en una línea base. Sólo se pueden realizar cambios futuros en la arquitectura del software (documentado en la Especificación de Desafío) tras haber sido evaluados y aprobados. Aunque se pueden definir las líneas base con cualquier nivel de detalle, las líneas base más comunes son las que se muestran en la Figura 9.1. La progresión de acontecimientos que conducen a una línea base está también ilustrada en la Figura 9.1.


Las tareas de la ingeniería del software producen uno o más ECSs. Una vez que un ECS se ha revisado y aprobado, se coloca en una base de datos del proyecto (también denominada biblioteca del proyecto o depósito de software). Cuando un miembro del equipo de ingeniería del software quiere hacer modificaciones en un ECS de línea base, se copia de la base de datos del proyecto a un área de trabajo privada del ingeniero. Sin embargo, este ECS extraído puede modificarse sólo si se siguen los controles GCS. Las flechas punteadas de la Figura 9.1 muestran el camino de modificación de una línea base ECS.

 
Elementos de configuración del software

Ya hemos definido un elemento de configuración del software como la información creada como parte del proceso de ingeniería del software. Llevado al extremo, se puede considerar un ECS como una sección individual de una gran especificación o cada caso de prueba de un gran conjunto de pruebas. De forma más realista, un ECS es un documento, un conjunto completo de casos de prueba o un componente de un programa dado (p. ej., una función de C++ o un paquete de ADA). 

 
En realidad, los ECSs se organizan como objetos de configuración que han de ser catalogados en la base de datos del proyecto con un nombre único. Un objeto de configuración tiene un nombre y unos atributos y está «conectado» a otros objetos mediante relaciones. De acuerdo con la Figura 9.2, los objetos de configuración, Especificación de Diseño, modelo de datos, componente N, código fuente y Especificación de Prueba, están definidos por separado. Sin embargo, cada objeto está relacionado con otros como muestran las flechas.

Una flecha curvada representa una relación de composición. Es decir, modelo de datos y componente N son parte del objeto Especificación de Diseño. Una flecha recta con dos puntas representa una interrelación. Si se lleva a cabo un cambio sobre el objeto código fuente, las interrelaciones permiten al ingeniero de software determinar qué otros objetos (y ECSs) pueden verse afectados'.