0 Capas de la ingenieria de software

martes, 19 de octubre de 2010
Capa de calidad

• Base de cualquier proceso de ingeniería.
• La IS se basa en calidad.
Mejores técnicas de construcción de software

Capa de proceso

• Capa que unen calidad y métodos todos
Desarrollo racional de la IS.

• Conjunto de actividades y resultados asociados que sirven para construir un producto software.

Capa de métodos

• Un método incluye:
Análisis de requisitos
Diseño
Construcción de programas
Prueba
Mantenimiento
• Suelen estar bastante ligados al proceso

Capa de herramientas

• Soporte automático o semiautomático para el proceso y los
 Métodos
• Herramientas CASE


0 Orientadas a la Calidad y Organizaciones Pequeñas.

Métricas para la Calidad del Sw:

Corrección
Grado en que el swdesempeña la función para la que fue creado.
Se mide en Defectos por KLOC
Facilidad de mantenimiento
Sencillez con que un programa puede corregirsesi se encuentra un error, adaptarsesi su entorno cambia,omejorarsi el cliente cambia los requisitos.
Se mide en forma indirectaen TMC (tiempo medio de cambio).
Integridad
Habilidad de un sistema para resistir ataques.
Requiere la definición de Amenazay Seguridad
Integridad = 1 –(amenaza x (1 -seguridad))
Facilidad de Uso
Intento por cuantificar la sencillez de una aplicación al utilizarla.
Eficacia en la eliminación de defectos (EED)
Medida de la habilidad de filtrar las actividades de la garantía de calidad y de control conforme se aplica a través de todas las actividades del marco de trabajo del proceso.EED = E/(E+D)E: número de errores encontrados antes de entregar el swal usuario finalD: número de defectos encontrados despuésde la entrega
También se aplica para valorar la habilidad de encontrar errores antes de pasar a la siguiente actividad del marco de trabajo.EEDi= Ei/(Ei+Ei+1)Ei: número de errores encontrados durante la actividad iEi+1: número de errores encontrados durante la actividad .

Métricas para organizaciones pequeñas:
Sugerencia: centrarse en los resultados, no en las mediciones
Ejemplo: “Reducir el tiempo para evaluar e implementar los cambios solicitados”
Medidas que se pueden recopilar fácilmente:
Tiempo que transcurre desde que se hace una solicitud hasta que la evaluación esté completa
Esfuerzo necesario para hacer la evaluación
Tiempo que transcurre desde que se completa la evaluación hasta que se asigna el pedido de cambio al personal
Esfuerzo requerido para hacer el cambio
Tiempo requerido para hacer el cambio
Errores descubiertos mientras se hacía el cambio
Defectos descubiertos después de que el cambio es liberado a los clientes
Métricas para organizaciones pequeñas:
Una vez recopiladas las medidas de varios cambios solicitados es posible calcular promedios y porcentajes que permitan mejorar el proceso para reducir los tiempos.
También podremos calcular la EED así:EED = Ecambio/ (Ecambio+ Dcambio)Ecambio: Errores descubiertos mientras se hacía el cambioDcambio: Defectos descubiertos después de que el cambio es liberado a los clientes


0 Conceptos del Espectro de Gestion



0 Metrica Orientada a la Funcion

lunes, 18 de octubre de 2010


Métricas orientadas a la función


Son medidas indirectas del software y del proceso. Se centran en la funcionalidad o utilidad del programa. “Emplean como un valor de normalización una medida de la funcionalidad que entrega la aplicación. La métrica orientada a la función utilizada con mayor amplitud es el punto de función (PF)


Procedimiento para calcular el Punto de Función:


1. Llenar la columna de CUENTA de la siguiente tabla de valores, donde se determinan 5 características del ámbito de la información.


Tabla 1
Tabla de valores del dominio de la información:




     Entradas de Usuario (Entradas): cualquier entrada (pantalla, formulario, cuadro de diálogo, control o mensaje) a través de la cual el usuario u otro programa puede añadir, borrar o cambiar datos. 
     Salidas de Usuario (Salidas): cualquier salida (pantalla, informe, gráfico, mensaje) que tenga un formato diferente o requiera un procesamiento diferente a otros tipos de salida, generada para el usuario u otro programa. 
     Peticiones de Usuario (Consultas): combinaciones de entrada/salida en las que cada entrada genera una salida simple e inmediata. 
     Archivos Lógicos Internos (Archivos): principales grupos lógicos de datos de usuarios o de control que están controlados por el programa (una tabla de un SGBDR). 
     Archivos de Interfaz Externos (Interfaces): cada uno de los grupos de datos lógicos o información de control que entra o sale del programa.


2. Multiplicar el valor de CUENTA por el Factor de Ponderación indicado, dependiendo de su complejidad para obtener Subtotal. Se asocia un valor de complejidad a cada medida, tomando en cuenta la heurística de la siguiente tabla.

TABLA 2
TABLA DE COMPLEJIDADES




A cada atributo se le asignará un valor dependiendo del grado de influencia de éstos.


Sin Influencia (0). El sistema no contempla este atributo.

Influencia Mínima (1). La influencia de este atributo es muy poco significativa.

Influencia Moderada (2). El sistema contempla este atributo y su influencia, aunque pequeña, ha de ser considerada.

Influencia Apreciable (3). La importancia de este atributo debe ser tenida en cuenta, aunque no es fundamental.

Influencia Significativa (4). Este atributo tiene una gran importancia para el Sistema.
Influencia Muy Fuerte (5). Este atributo es esencial para el sistema y se lo debe tomar en cuenta a la hora del diseño.

5. Sumar los puntos asignados a cada factor y obtener un TOTAL GI que indica un valor de ajuste de complejidad.
6. Calcular Punto de Función, utilizando la siguiente fórmula:

PUNTO FUNCIÓN = CUENTA_TOTAL * (0,65+ 0,01*TOTAL GI) 

Los valores constantes de la ecuación anterior y los factores de peso aplicados en las encuestas de los ámbitos de información han sido determinados empíricamente.

Una vez calculado el punto de función se usan de forma analógica a las LDC como medida de la productividad, calidad y otros productos del software.

Productividad = PF / Eficiencia
Calidad = Errores / PF
Costo = Dólares / PF
Documentación = Págs. Doc. / PF

0 Marco del trabajo comun.

Dentro del proceso del software, se establece un MARCO COMÚN DEL PROCESO. En este se definen un conjunto de tareas aplicables a los proyectos, buscando como finalidad la calidad del software, mediante la aplicación de procesos (madurez).


Niveles de madurez

Nivel 1 (inicial)
Se definen pocos procesos, esfuerzo individual.

Nivel 2 (repetible)
Gestión de proyectos, se da seguimiento a la planificación en proyectos similares.

Nivel 3 (Definido)
Los procesos se documentan y se estandarizan, aplicándolos en los proyectos.

Nivel 4 (Gestionado)
Se busca la calidad del producto mediante auditorias, en este punto el desarrollador pretende normalizar su producto, mediante estándares definidos: ISO 9001. a través del nivel 3.

Nivel 5 (Optimización)
Procesos de innovación que permiten hacer mejoras en los productos, en este nivel se emplean métricas de medición para alcanzar el nivel 4 y 5.

0 Garantia de calidad.

Garantía de calidad del software (SQA) consiste en los medios de la supervisión tecnología de dotación lógica los procesos y los métodos aseguraban calidad. Hace esto por medio de intervenciones de sistema de gerencia de la calidad debajo de cuál se crea el sistema de software. Estas intervenciones son movidas hacia atrás por unos o más estándares, generalmente ISO 9000.

Es distinto de control de calidad del software cuál incluye el repaso requisitos documentos, y prueba del software. La SQA abarca el entero desarrollo del software proceso, tales como el cual incluye procesos diseño del software, codificación, control del código de fuente, revisiones de código, cambie a gerencia, gerencia de la configuración, y lance a gerencia. Mientras que el control de calidad del software es un control de productos, la garantía de calidad del software es un control de procesos.

La garantía de calidad del software se relaciona con la práctica de garantía de calidad en producto fabricación. Hay, sin embargo, algunas diferencias notables entre el software y un producto manufacturado. Estas diferencias provienen el hecho de que el producto manufacturado es físico y puede ser visto mientras que el producto de software no es visible. Por lo tanto su función, ventaja y costes no están según lo medido fácilmente. Cuál es más, cuando un producto manufacturado cae la planta de fabricación, es esencialmente un completo, producto final, mientras que el software nunca se acaba. El software vive, crece, se desarrolla, y transforma, desemejante de sus contrapartes tangibles. Por lo tanto, los procesos y los métodos para manejar, para supervisar, y para medir su calidad en curso son tan líquido y a veces evasivos como son los defectos que se significan para mantener cheque.

Ventajas de la SQA

Un plan de la SQA puede tomar un número de trayectorias, probando para diversas capacidades y la ejecución diferente analiza, dependiendo de las demandas del proyecto, los usuarios, y el software sí mismo. Pero cualquier plan riguroso de la SQA realizado escrupulosamente por los profesionales chevronn3es del QA conferirá ciertas ventajas:


Satisfacción de cliente mejorada significa relaciones más de largo, más provechosas del cliente, testimonial positivos del cliente, y las ondas del negocio de la remisión generadas de la palabra positiva de la boca.

Si descontentan a los clientes con un producto que han comprado de un vendedor particular del software, nunca son probables recomendar ese producto ni compra a ese vendedor del software otra vez. Los insectos y los defectos, además seriamente de obstaculizar la funcionalidad de un uso, miran descuidados y un profesional, y reflejan mal en la reputación de una compañía.

Cuál es más, sin la prueba apropiada, es virtualmente imposible saber los nuevos usuarios responderán a las funciones de un uso, a las opciones, y a las características de la utilidad. Los especialistas imparciales de la garantía de calidad del software vienen a un proyecto fresco, con una perspectiva clara, y así que servicio como la primera línea de defensa contra interfaces utilizador un intuitivo y funcionalidad quebrada del uso. Un uso de la calidad está garantizado para dar lugar a la satisfacción de cliente realzada.

Coste reducido de desarrollo Porque el proceso de la garantía de calidad del software se diseña para prevenir defectos e ineficacias del software, los proyectos que incorporan riguroso, prueba del objetivo encontrarán que los costes del desarrollo están reducidos puesto que todas las fases más posteriores del ciclo vital del desarrollo llegan a ser aerodinámicas y simplificados perceptiblemente. Con la SQA, toda la otra prueba y desarrollo incluyendo despliegues de la prueba y del cliente del usuario irán más suavemente, y por supuesto más rápidamente -- qué medio su proyecto del desarrollo del software constantemente alcanzará la terminación el tiempo y dentro del presupuesto, lance después de lanzamiento.

Coste de mantenimiento reducido los usos Insecto-infestados son molestos apoyar. El coste combinado de memorias, de vueltas, y de remiendos innecesarios puede ser espantoso. Y eso no dice nada de qué tendrá que ser pasada en ayuda de cliente en curso, sea por el teléfono, email, o en persona. Todos estos costes y pueden ser reducidos más dramáticamente lanzando solamente productos riguroso calidad-asegurados. Los vendedores del software que ahora invierten en calidad pueden evitar pérdidas grandes en el futuro.

Metodología de la SQA

La prueba del software es tanto un arte como una ciencia. En grande, los usos complejos, tales como sistemas operativos, es prácticamente imposible planchar hacia fuera cada solo insecto antes de lanzarlo ambos de un punto de vista de la dificultad y debido a los apremios del tiempo. Diversos usos del software requieren diversos acercamientos cuando viene a la prueba, pero algunas de las tareas mas comunes del QA del software incluyen:

Prueba de la validación

La prueba de la validación es el acto de los datos que entran que el probador sabe para ser erróneo en un uso. Por ejemplo, mecanografiando “hola” en una caja de corregir que está esperando recibir una entrada numérica.

Comparación de los datos

Comparando la salida de un uso con parámetros específicos a un sistema previamente creado de los datos con los mismos parámetros que se saben para ser exactos.

Prueba de la tensión

Una prueba de tensión es cuando el software se utiliza tan pesadamente como sea posible por un período de la hora de considerar si hace frente a los altos niveles de la carga. De uso frecuente para el software del servidor que tendrá múltiple los usuarios conectaron con él simultáneamente. También conocido como prueba de la destrucción.

Prueba de la utilidad

A veces consiguiendo a los usuarios que son desconocedores con el software intentarlo durante algún tiempo y ofrecer la regeneración a los reveladores sobre lo que encontraron difíciles de hacer es la mejor manera de llevar a cabo mejoras a un interfaz utilizador.

0 Modelos COCOMO,SLIM y Modelo de capacidad y de madurez.

Introducción

Es un modelo de estimación de costes.

Creado por Barry W. Boehm.

Incluye 3 submodelos con un nivel de detalle cada vez mayor.


Características principales:

Está basado en modelos de estimaciones matemáticas.

Está orientado al producto final, no a fases intermedias.

Se basa en la cantidad de líneas de codigo del proyecto.

Inconvenientes del modelo:

Comentarios en líneas de código.

Estimaciones sobre un nº de líneas de código variable.

No se le da importancia a la productividad, referente a los hábitos de trabajo

Dificultad para contemplar costes de revisiones, reuniones…

Modelos de estimación:

*Modelo básico

*Modelo intermedio

*Modelo avanzado

Modos:

Orgánico.

Semiacoplado.

Empotrado.

Modo Básico:
El modelo básico se usa para obtener una aproximación rápida del esfuerzo.

Usa las variables a, b, c y d, que varían en función de los modos.

Conforme se aumenta la complejidad del modo, aumentan los valores de las variables (esfuerzo).

Modelo básico.

Personas necesarias para llevar a cabo el proyecto:
(MM) = a*(Klb)
Tiempo de desarrollo del proyecto:
(TDEV) = c*(MMd)
Personas necesarias para el proyecto:
(CosteH) = MM/TDEV
Coste total del proyecto:
(CosteM) = CosteH * Salario medio

Modelo Intermedio:

Añade al modelo básico 15 factores de ajuste o guías de coste.
Logramos mayor precisión en la estimación gracias a los nuevos factores.
La fórmula es la misma que la del modelo básico pero con el añadido del factor (multiplicando).

Atributos del modelo:
Software:
RELY: Indica las consecuencias para el usuario si falla el producto.
DATA: Relación Tamaño de la BD / Líneas de código.
CPLX: Complejidad del producto.

Hardware:
TIME: Limitaciones en el porcentaje del uso de la CPU.
STOR: Limitaciones en el porcentaje del uso de la memoria.
VIRT: Volatilidad de la máquina virtual.
TURN: Tiempo de respuesta.

Personal:
ACAP: calificación de los analistas.
AEXP: experiencia del personal.
PCAP: calificación de los programadores.
VEXP: experiencia del personal en la máquina virtual.
LEXP: experiencia en el lenguaje.

Proyecto:
MODP: uso de prácticas modernas de programación.
TOOL: uso de herramientas de desarrollo de software.
SCED: limitaciones en el cumplimiento de la planificación.

Modelo SLIM:

Propuesto por Putnam.
Diseñado para proyectos grandes, aunque se puede adaptar a pequeños.
Se basa en la curva de Rayleigh

Parámetros del Modelo SLIM:

C: factor de tecnología
K: esfuerzo total medido en años-persona
td: tiempo de finalización del proyecto medido en años.
Se ven las consecuencias de variar estos parámtros

Ecuaciones del Modelo SLIM:




Las potencias de las ecuaciones se calcularon a partir de datos experimentales de desarrollo de productos software.

Modelo CMM:

Propuesto por el SEI
Evalúa la forma de desarrollar software de una organización
El CMM cuantifica la calidad del desarollo en 5 niveles distintos
El modelo ha evolucionado actualmente hasta el CMMI

Niveles del CMM:

Nivel 1: Inicial
Nivel 2: Repetible
Nivel 3: Definido
Nivel 4: Gestionado
Nivel 5: Optimizado

0 Uso de Técnicas de cuarta Generación

Las técnicas de cuarta generación son un conjunto muy diverso de métodos y herramientas que tienen por objeto el de facilitar el desarrollo del software, facilitan al que desarrolla el software la propiedad de especificar algunas características del mismo a alto nivel, mas tarde, la herramienta genera automáticamente el código fuente a partir de esta especificación.

Los tipos más comunes de generadores de código curen uno o varios de los siguientes aspectos:

•Acceso a base de datos: utilizando lenguajes de consulta de alto nivel.

•Generadores de códigos: a partir de una especificación de los requisitos se genera automáticamente toda la aplicación.

•Generación de pantallas: permitiendo diseñar la pantalla dibujándola directamente, incluyendo además el control del cursor y la gestión de los errores de los datos de entrada.

•Gestión de entornos gráficos.

•Generación de informes.


Los pasos de los paradigmas son: Recolección de requerimientos, Estrategia de Diseño, Implementación usando T4G y Producto.

Como otros paradigmas, T4G comienza con el paso de recolección de requerimientos. Idealmente el cliente debe describir los requerimientos y estos debe traducirse directamente en un prototipo operacional pero este no funciona. El cliente puede no estar seguro de lo que necesita, puede ser ambiguo en la especificación de hechos que son conocidos y puede ser incapaz o no desear especificar la información en la forma que una herramienta T4G puede construirla además las herramientas actuales T4G no son lo suficientemente sofisticadas para acomodar realmente lenguaje natural y no lo serán por algún tiempo en este momento el dialogo cliente técnico descrito por los otros paradigmas permanecen como una pequeña parte esencial del enfoque T4G. Para aplicaciones pequeñas puede ser posible ir directamente desde el paso de establecimiento de requerimientos a la implementación, usando un lenguaje de cuarta generación no procedimental (L4G) sin embargo es necesario un mayor esfuerzo para desarrollar una estrategia del diseño para el sistema incluso si se utiliza un L4G. El uso de T4G sin diseño para el sistema incluso si se utiliza un L4G. El uso de T4G sin diseño para grandes proyectos causará las mismas dificultades (poca calidad, pobre mantenimiento, mala aceptación por el cliente) que se encuentran cuando se desarrolla software usando los métodos convencionales. La implementación usando L4G facilita el que desarrolla al software la descripción de los resultados deseados, los cuales se traducen automáticamente en código fuente para producir dichos resultados. Obviamente debe existir una estructura de datos con información relevante y debe estar rápidamente accesible al L4G. El último paso de la figura anterior contiene la palabra producto para transformar una implementación T4G en un producto, el que lo desarrollo debe dirigir una prueba completa, desarrollar una documentación con sentido y ejecutar todas las otras actividades de transición requeridas en los otros paradigmas de la ingeniería de software. Además del software desarrollado con T4g, debe ser construido de forma que facilite que el mantenimiento y pueda ser ejecutado de una forma expeditiva. Los defensores aducen reducciones dramáticas en el tiempo de desarrollo en el software y una mejora significativa en la productividad de la gente que construye el software. Los retractores de este paradigma aducen que los lenguajes de programación, que el código fuente producido por tales herramientas es ineficiente y que el mantenimiento de grandes sistema de software desarrollado usando T4g está abierto a discusión.

Entre las críticas más habituales están las siguientes:

•No son más fáciles de utilizar que que los lenguajes de tercera generación.

•El código fuente que produce es ineficiente, al estar generado automáticamente no pueden hacer uso de de los trucos habituales para aumentar el rendimiento, que se basan en el buen conocimiento de cada caso en particular.

•Sólo son aplicables al software de gestión, la mayoría de las herramientas de cuarta generación están orientadas a la generación a partir de grandes bases de datos, pero últimamente están surgiendo herramientas que generan esquemas de códigos para aplicaciones de ingeniería y de tiempo real.

Algunos lenguajes de cuarta generación:

Progress 4GL, o Progress Open Edge como se han llamado sus últimas versiones, es un lenguaje muy utilizado pues es portable y muy confiable. Es una plataforma diseñada para ayudar a los desarrolladores en la construcción de aplicaciones empresariales de forma rápida, esto ayuda a recuperar la inversión de manera más rápida. Tiene la facilidad de fácilmente conectarse e integrarse con clientes, con otras aplicaciones y con distintas bases de datos.


SQL (Structured Query Language): SQL (lenguaje de consultas estructurado) es un lenguaje de acceso a bases de datos relacionales con el cual se pueden crear y manipular las mismas.


WinDev: Permite el desarrollo de interfaz gráfica. Se pueden realizar muchos tipos de aplicaciones, entre ellas: Gestión, industriales, médicas. En WinDev la calidad de las aplicaciones dependen menos del equipo de desarrollo que con otras herramientas, esto debido a que trae un conjunto de funciones avanzadas sin la necesidad de que alguien las programe, por ejemplo, puede ser que el entorno detecte que mejoras para aumentar el rendimiento y la velocidad del sistema y este mismo las sugiere y las realiza automáticamente, además, posee una herramienta generadora de reportes automática.


PowerBuilder: Es un entorno gráfico de programación orientado a objetos para el desarrollo de aplicaciones cliente/servidor, distribuidas y web. Incluye herramientas para generar reportes, acceder bases de datos y para crear interfaz gráfica.


Mathematica: En Mathematica se contemplan muchos de los aspectos técnicos de la computación como el manejo numérico, la conversión de datos, la visualización y la creación de interfaces para el usuario. El avance intelectual que hizo posible el desarrollo de un paquete tan completo fue la invención de un lenguaje que fuera capaz de manipular la gran cantidad de objetos que alberga la computaron técnica. Por su completitud es un paquete que a pesar de inicialmente ser usado por técnicos ha pasado a ser un ambiente manejado por gran cantidad de personas que han aprendido desplegar todas las utilidades que el programa ofrece como por ejemplo los estudiantes a los que les permite aprender de manera interactiva.

Conclusión:

La evolución de los lenguajes tiende cada vez más a alejarnos de la maquina o hardware, creando una mayor abstracción de los problemas a resolver, esto es beneficioso pues genera un ahorro significativo de recursos como el tiempo que es tan valioso actualmente.

Los Lenguajes de Cuarta Generación tienden a ser muy compatibles entre sus mismas evoluciones lo que nos permite crear aplicaciones con la confianza de que el trabajo realizado no será desechado más adelante.

Paquetes tan poderosos como Mathematica hacen posible que las técnicas de computación mejoren constantemente pues brindan una mayor facilidad para el análisis y diseño de nuevas herramientas, mientas también ayudan a áreas tan importantes como la educación, todo esto empleando la misma herramienta.

Es importante resaltar que para utilizar un 4GL se debe tener claro que si se desea manipular para sacarle un mayor rendimiento, se debe de hacer cambiando la forma normal de hacer software. Para esto, los programadores deben de volverse analistas, deben dominar técnicas estructuradas, conceptos de diseño de interfaz grafica, conceptos de arquitectura, conceptos de orientación a objetos y de principios de diseño. Y todo esto para poder obtener una mayor productividad, una mayor facilidad al dar mantenimiento y además una mejor apariencia de la aplicación.

0 Gestion de configuracion de software

Es un conjunto de actividades aplicadas a la Línea Base para gestionar los cambios del software a lo largo del ciclo de vida e implica una revisión técnica formal (RTF) de los Elementos de Configuración del Software( ECS).

Los ECS son objetos que poseen sus nombres, atributos y relaciones entre ellos. Una manera fácil de obtenerlos, es respondiendo las preguntas orientadoras:

¿Cómo identifico y gestiono las diferentes versiones existentes de un mismo software (y su documentación)?

¿Cómo controlo los cambios, antes y después que he entregado software al cliente?

¿Quién tiene la responsabilidad de aprobar y asignar prioridades en los cambios (la organización o mi equipo de trabajo)?

¿Cómo garantizo que los cambios realizados han sido los adecuados?

¿Qué mecanismos se usan para avisar a otros, de los cambios realizados?


Los cambios se clasifican como completos y parciales:

CAMBIOS COMPLETOS: Implica una modificación general en las diversas líneas base. Y para ello se usa V 1.0, 1.1, 1.2, ….
CAMBIOS PARCIALES: Implica una modificación dirigida en alguna línea base. Y para ello se usa V 1.0, 1.0.1, 1.0.2, ….

En el caso de obtener otro software similar al existente. Se utiliza V 1.0, 2.0, 3.0

Para constatar la magnitud del cambio, se practica la
AUDITORÍA DE SISTEMAS.

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

1.     Plan de implementación(Diagrama de proyect)




Interfaces.
 





 Cuadro de Gestion de Riesgo





0 Caso de Estudio #1

Programa de Métricas


1. Objetivo/s del Negocio
Mejorar gestión de fondos asignados a los programas en Nicaragua.


2. Nuevos saberes/aprendizaje


Conocimiento de la agenda de eventos de la organización FES
*Lugar
*Fecha
*Refrigerio y alimentos
*Exponencias
•Temas
•Documentación
•Material de apoyo
*Participantes
• Invitaciones
• Confirmación
• Llenado de datos
*Informes
• Fotos
• Videos
*Publicaciones
• Comentarios(charlas)
• Encuestas
• Gráficos


3. Sub-objetivos
Agenda de eventos.


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.85)1.12
P=2.5=3


TD=2.5*(2.5)0.35
TD=3.44=3 1/2 meses



CT=(2.5/3.44) *275
CT= 199.85=200

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


• En el cálculo de las personas se llego a la concusión de q el grupo de trabajo va a estar conformado por no más de 3 integrantes.
• En el cálculo del tiempo de desarrollo de software se determino que la duración del proyecto sería de 3 meses y medio equivalente a 14 semanas.
• En el cálculo del costo concluimos que la ganancia del proyecto después de finalizar todos los pagos(viáticos, salarios, licencias, alquiler y servicios generales) es de $200(doscientos dólares).


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.


10. Plan de implementación(Diagrama de proyect)



Interfaces






  

Cuadro de Gestion de Riesgo