UTILERIAS: PROCESSDASH Y ENTERPRISE ARCHITEC

UTILERIAS: PROCESSDASH Y ENTERPRISE ARCHITEC

PROCESS DASHBOARD

es una iniciativa de código abierto para crear una herramienta de soporte PSP. PSP y el TSP son tecnologías notables que pueden cambiar la cara de la industria del software, y compartimos el entusiasmo de SEI para promover su uso generalizado.

Fue desarrollado originalmente en 1998 por la Fuerza Aérea de los Estados Unidos, y ha continuado evolucionando bajo el modelo de código abierto. Está disponible gratuitamente para descargar bajo las condiciones de la Licencia Pública GNU. 

Process dashboard soporta:

• Recopilación de datos - Tiempo, defectos, tamaño; plan vs. datos reales
• Planificación : scripts, plantillas, formularios y resúmenes integrados, PROBE, valor ganado
• Seguimiento - Potente soporte de valor ganado
• Análisis de datos : los gráficos e informes ayudan en el análisis de las tendencias de datos históricos.
• Exportación de datos - Exportar datos a Excel, o exportar datos a formato de texto para su uso con herramientas externas.

Las principales fortalezas del Process dashboard son:

• Facilidad de uso
  • Optimiza la facilidad de recopilación de las métricas más frecuentes (tiempo y defectos)
  • Otras ayudas de proceso (scripts, formularios, plantillas y resúmenes) están a solo un clic del mouse
  • Su pequeña huella en pantalla permite que la herramienta coexista con entornos de desarrollo integrados
  • Las tareas se organizan jerárquica mente, reflejando la estructura de desglose del trabajo del proyecto.
• Flexibilidad / extensibilidad
• Se pueden agregar nuevos procesos y nuevos tipos de datos sin programación
• Los scripts, plantillas, formularios y resúmenes de procesos son HTML y, por lo tanto, se pueden crear con cualquier editor HTML.

ENTERPRISE ARCHITECT

es una herramienta de diseño y modelado visual basada en OMG UML . La plataforma soporta: el diseño y construcción de sistemas de software; modelado de procesos de negocio; y modelado de dominios basados ​​en la industria. Es utilizado por empresas y organizaciones no solo para modelar la arquitectura de sus sistemas, sino también para procesar la implementación de estos modelos en todo el ciclo de vida del desarrollo de la aplicación.

características principales:

Gestión de requisitos

Las características comunes de la gestión de requisitos soportada por Enterprise Architect incluyen la personalización de cómo se documentan los requisitos, vincular los requisitos a los detalles de diseño e implementación, y proporcionar la Trazabilidad de los requisitos a través de las fases de diseño y construcción. Estos requisitos pueden estar sujetos a gestión de cambios, procesamiento del flujo de trabajo, comparación de referencia y auditoria.

Modelado y análisis de negocios

Enterprise Architect admite varios métodos de modelado de procesos de negocios utilizando UML como el lenguaje de modelado de base. Los lenguajes principales para el modelado y análisis de negocios incluyen BPMN y BPEL 

Simulación

La simulación de modelo es compatible con:

• Diagramas de comportamiento:
• Máquinas de estado
• Interacción (diagramas de secuencia)
• Ocupaciones

Desarrollo del sistema

De acuerdo con los principios de diseño de Model Driven , Enterprise Architect admite transformaciones MDA de estructuras de clase PIM a estructuras de clase PSM , ingeniería de ida y vuelta de código para 10 lenguajes de software y varios lenguajes de sistemas HDL incrustados ( Ada , VHDL y Verilog ). También es compatible con la generación de código de modelos de comportamiento.

Idiomas soportados:

• ActionScript
• do
• C # (para .NET 1.1 y .NET 2.0)
• C ++ (estándar, más las extensiones de C ++ administradas por .NET)
• Delphi
• Java (incluyendo Java 1.5, Aspectos y Genéricos)
• PHP
• Pitón
• Visual Basic
• Visual Basic .NET

Métricas de diseño de componentes.

Métricas de diseño de componentes.

Trabajo: sensor anti-steal Prime

Integrantes:

      José de Jesús Cortezano Arellano.

      Velasco Amaya Vicente Ananías.

      López Mesa Alejandro Daniel.

      Palafox Méndez Vicente.

      Martinez Dominguez Edzon Carlos.

Programa

Las métricas de diseño de software tienen como finalidad entregar un producto con mejorar la calidad, de forma que se puedan pulir ciertos aspectos, que, de primeras, un usuario común no tomaría en cuenta. Pues tomando estas métricas podrás lograr pulir aspectos que de primeras no parecerían muy importantes, pero que, sin embargo, a la hora de la practica si tienen un gran peso, de forma que el producto que entregues, tenga mayor fiabilidad y confianza.

4.1.6 FURPS

(Funcionality, Usability, Reliability, Performance, Supportability)

Hewlett-Packard ha desarrollado un conjunto de factores de calidad de software al

que se le ha dado el acrónimo de FURPS:

•          Funcionalidad. Se aprecia evaluando el conjunto de características y

capacidades del programa

•          Usabilidad (facilidad de empleo o uso) Se valora considerando factores

humanos, la estética, consistencia y documentación general.

•          Fiabilidad. Se evalúa midiendo la frecuencia y gravedad de los fallos, la

exactitud de las salidas (resultados)

Debido a que este será un proyecto con la finalidad de que los usuarios que lo adquieran obtengan una mayor seguridad en cuestión de sus artículos personales., esta métrica nos podría ayudar ya que estudiaremos la forma en la que el dispositivo sea fácil de manejar, así como que tenga una respuesta rápida y efectiva y con las ayudas de este el articulo tenga la oportunidad de ser cada vez más efectivo es su tarea.

4.5 Métrica de pruebas.

Estas métricas tienen como objetivo, realizar un test complejo, de forma que el software quede aprobado en cualquier ámbito, para evitar la existencia de fallos no previstos.

La mayoría de las métricas propuestas se concentran en el proceso de pruebas, no en las características técnicas de las pruebas mismas, pueden usarse para predecir el esfuerzo global.

 Las métricas de diseño de alto nivel proporcionan información sobre facilidad o dificultad asociada con la prueba de integración y la necesidad de software especializado de prueba.

Explicación: Consiste en hacer una inversión, de forma que el programa pase por un conjunto de pruebas, de forma que la versión final, salga con la menor cantidad de errores posible.

De forma que utilizamos esta norma, para entregar una prueba al cliente de que nuestro producto realizara su tarea correctamente sin errores, pues esta fue sometida a una gran cantidad de pruebas, por lo que los errores no van a ser comunes, así tendrán la seguridad de que este trabaja correctamente.

4.4.- Métricas de código fuente.

Esta consiste en optimizar el código, de forma de que este sea rápido y eficiente, además de neutralizar todos los fallos.

Usaremos esto en nuestro proyecto, ya que arduino requiere la menor cantidad posible de código, además de que nuestro proyecto debe tener respuesta inmediata, debido a su temática principal, el robo. Por lo que pulir el código debe ser una prioridad dentro del proyecto.

Personal Software Process

Es un conjunto de prácticas disciplinadas para la gestión del tiempo y mejora de la productividad personal de los programadores o ingenieros de software, en tareas de desarrollo y mantenimiento de sistemas, mediante el seguimiento del desempeño predicho frente al desempeño real. Está alineado y diseñado para emplearse en organizaciones con modelos de procesos CMMI o ISO 15504.

ELEMENTOS DE PSP

Requisitos
Planeacion
Diseño de alto nivel
Revisión de alto nivel de diseño
Desarrollo cíclico
Post Mortem
Integración
Pruebas
Producto

NIVELES:

• PSP 0:
  • Proceso actual.
  • Registro de tiempos.
  • Registro de defectos.
• PSP 0.1 :
  • Estándares de código.
  • Medición de tamaño.
• PSP 1 - Inicial:
  • Estimación de tamaño.
  • Reporte de pruebas.
• PSP 1.1:
  • Calendario de planeación de tareas.
• PSP 2 - Repetible:
  • Revisión de diseño y código.
• PSP 2.1:
• Plantillas de Diseño.

MÉTRICA DE SOFTWARE

MÉTRICA DE SOFTWARE

APLICACIÓN DE AEROPUERTO

esta aplicación busca gestionar toda la información que se genere dentro de un aeropuerto como lo es la creación de nuevos vuelos, agregar nuevos pilotos así como asignarlos a los aviones y vuelos, del lado del cliente este podrá conocer los vuelos disponibles así como comprar sus boletos.

EJEMPLO POR LINEA DE CÓDIGO (GESTOR DE AEROPUERTO)

Proyecto	LDC	Esfuerzo	Costo	Doc.	Errores	Defectos	personal
Alfa	200	10	3000	0	15	6	2
beta	230	26	3450	0	7	2	2

EJEMPLO POR PUNTO DE FUNCIÓN (GESTOR DE AEROPUERTO)

Calculo cuenta total:

Valor dominio	Cuentas	Grado complejidad	resultado
Entrada de usuario	8	Promedio (4)	32
Salidas de usuario	3	Simple (3)	9
Peticiones de usuario	3	Simple (3)	9
Archivos	3	Simple (7)	21
Interfaces externas	1	Simple (5)	5
Factor de ajuste:	39	Total:	76

FACTOR DE AJUSTE

Comunicación de datos = 4

Procesamiento distribuido = 4

Perfomance = 1

Configuración del equipamiento = 1

Volumen de transacciones = 3

Entrada de datos on-line = 5

Interfase con el usuario = 3

Actualización on-line = 3

Procesamiento complejo = 2

Reusabilidad = 3

Facilidad de implementación = 2

Facilidad de operación = 3

Múltiples locales = 3

Facilidad de cambios = 2

Cuenta total

PF=76 x [.65 +.01 x 39] =79.04

PRESUPUESTO

Durante la segunda fase se pretende estimar el esfuerzo necesario para determinar las horas hombre y saber cuanto se le dedico al proyecto, para estimar el costo.
Por lo que siguiendo la siguiente formula : H/H = PFA *  horas promedio, donde pfa son las horas dedicadas para realizar el programa.

152 hh / 2 =76 hh por persona8 horas diarias entre 19 dias =2.375
84.36 x 2.375 = 199.5

Para desarrollar este programa se tomara en cuenta que la cantidad de programadores    es 2

Por lo que podemos intuir, que este programa tiene una complejidad media.
Debido a que no se ocupo un "presupuesto" para realizar este proyecto, tomamos el suelo base de un programador en puebla, el cual seria en $6000 mensual por trabajador, y ocupando un sueldo a otros gastos de $7000
Obtendríamos el siguiente resultado:

Costo = ( 3 * 1.97 * 12,000) + 7000 = 77,920 para el desarrollo.