Nuestro Blog 

 

 Mantén informado y actualizado en medición,

estimación y requisitos de software.

Constantemente publicamos noticias y artículos

de gran interés.

 

Archivo Virtual del FBI

 

A principios del 2000 el FBI (Policía Federal Estadounidense) comenzó el desarrollo de un software llamado Virtual Case File (VCF), un tipo de archivo virtual con procedimientos de investigación llevados a cabo por el FBI que iba permitir el intercambio de información de diferentes casos entre los agentes. El plan inicial tenía previsto una duración de tres años. 

 

Después de los ataques terroristas del 11 de septiembre de 2011, el FBI recibió fuertes críticas por no haberlo anticipado. La falla fue no haber conseguido establecer la relación entre las diferentes evidencias disponibles. El VCF, quien ayudaría en parte a este objetivo pasó a ser una de las prioridades del FBI: sus requerimientos aumentaron, así como sus plazos y costo.

 

Después de cinco años de desarrollo con costos incurridos de $ 170 millones, el proyecto fue abortado con el sistema en desarrollo. La investigación adicional encontró varias causas para el fracaso del proyecto, entre ellos:

  • Cambios frecuentes en los requerimientos. El proveedor contratado para el desarrollo alegó que el FBI adoptó la táctica de ensayo y error en diversas decisiones y la filosofía en el trabajo era "Yo sé lo que quiero después de ver el producto."
  • Alta rotación de gestión (también contribuyó a los cambios frecuentes en los requerimientos).
  • Aumento descontrolado del alcance, con requerimientos agregados incluso cuando el proyecto ya está retrasado.

 

Crisis en la gestión de crisis

Crisis y problema son cosas distintas. La crisis demanda soluciones más complejas e conocimiento multidisciplinar.

 

Paralización general de los servicios de seguridad pública, enfermedades endémicas fatales, desastres ambientales, guerras, refugiados, fundamentalismos e extremismos de toda orden, recesión en la economía, conflictos políticos, entre otros.

 

El mundo está en crisis y la verdad es que no estamos preparados para lidiar con ella. Prevención, evaluación de riesgos, estructuras y procedimientos centrados en la gestión de crisis e instrumentos de gobierno corporativo son aún tratados como “novedades”, buena parte de las empresas nacionales y, principalmente, en las instituciones públicas.

 

Estamos habituados a lidiar con problemas, sin embargo, crisis y problema son cosas distintas. Las crisis demandan soluciones más complejas, conocimiento y tratamiento multidisciplinar y multisectorial, involucran actores externos a la organización, generan disrupción de las operaciones regulares e impactos negativos a la imagen a largo plazo.

 

La gestión de una crisis demanda métodos, estructuras, estrategias, personas y procedimientos centrados en la reducción de perjuicios en los momentos que esto ocurre. Las áreas críticas exigen instrumentos preventivos tales como gabinetes de crisis, equipo preparado y planos de gestión y comunicación.

 

De manera distinta a lo que sucedió con el personaje bíblico Noé, quien consiguió salvar a los animales del diluvio recibiendo “informaciones privilegiadas” de Dios; los gestores de crisis, en general, son “cogidos por sorpresa”, y, comúnmente, tienen pocas informaciones sobre los hechos y sus repercusiones.

 

Muchas organizaciones están acostumbradas a lidiar riesgos inherentes a estas operaciones, pero no saben lidiar con los riesgos residuales y los “eventos de terceros”, subestiman riesgos y amenazas, lo que finalmente resulta en un agravamiento de los impactos y con ello dañando la imagen.

 

En casos de crisis, el gobierno o la empresa debe transmitir los siguientes mensajes: estar preparados para afrontar, controlar la situación y sobretodo, estar decididos a buscar un resultado rápido para la comunidad afectada.

Por ello, es esencial realizar una prevención con evaluación periódica y observar los niveles de riesgos, procesos adecuados de abastecimiento y principalmente, de comunicación.

 

En nuestro escenario actual, la crisis deja de ser algo excepcional y, de esta manera, la sorpresa y falta de preparación no es más justificable.  

 

Texto extraido de la revista Gazeta. Pueden encontrar el original aqui: https://goo.gl/7V2plv

 

 

Curso Online en vivo Estimaciones de Software

 

Los invitamos a participar del curso Estimaciones de Software: Fundamentos y técnicas en versión Online - En vivo

 

Será un momento para interactuar con nuestro tutor y aprender en tiempo real, aclarar dudas e intercambiar temas. Además las clases serán grabadas y serán compartidas dentro del grupo registrado.

 

- Inicio: 11 de Septiembre

- Duración: 2 semanas

- Horario: 19 hrs - 21 hrs  México, Colombia, Péru.

- Tutor: Carlos Eduardo Vasquez 

 

Promoción USD $119

Precio válido hasta 31 de Julio.

 


¡Aproveche esta oportunidad! 

 

 

Objetivos

 

Objetivo

 

El objetivo de este es dotar al participante de conocimiento a fin de que este sea capaz de: 

 

a) Establecer la diferencia entre los actos de estimar, asumir un compromiso y establecer una meta y con eso, adoptar una postura de quien ofrece una estimación en contraste con la postura de quien sólo intenta negociar más tiempo o recursos. El participante debe ser capaz de presentar las opciones y escenarios para que los responsables puedan establecer las metas o asumir compromisos con base en fundamentos sólidos y en instrumentos de gerencia del conocimiento.

 

b) Diferenciar una estimación directa y un modelo de estimación paramétrica. Específicamente sobre ésos últimos, discutimos las particularidades entre aquellas basadas en modelos determinísticos y aquellas basadas en modelos estocásticos.

 

c) Transformar los rangos de esfuerzo y plazo optimistas, más probables y pesimistas ofrecidas por modelos de estimación estocásticas o por la estimación directa en una determinada cantidad de horas o de meses acompañados de la respectiva probabilidad.

 

d) Diferenciar entre los tres modelos que componen el COCOMOII: Application Composition, Early Design, Post-Architecture y seleccionar aquellos más adecuados conforme al nivel de información disponible durante la elaboración de la estimación.

 

e) Utilizar el punto de función como parámetro de costo primario del modelo y realizar la evaluación de los demás parámetros de costo secundarios relativos al producto, al proceso, al personal.

 

f)  Interpretar los resultados del modelo en términos de cuáles actividades y en qué fases del ciclo de vida de desarrollo están siendo incluidas en las estimaciones generadas; cuáles categorías de trabajo son consideradas en los resultado y en qué puntos el modelo debe ser leído como una referencia de mercado e cuales puntos deben ser necesariamente calibrados a las condiciones locales de donde será aplicado.

 

El curso no se limita a la operación del modelo de estimación, también aborda asuntos sobre su administración, como:

  • Calibrar los porcentajes de esfuerzo y de plazo conforme la fase de acompañamiento gerencial.
  • Escoger la mejor métrica de calidad para evaluar el modelo considerando sus particularidades y cuales métricas son más adecuadas a la política de la organización donde el modelo será utilizado.
  • Calibrar el modelo.
  • Desarrollar una política local con la interpretación de los aspectos subjetivos de las directrices para la evaluación cualitativa de los factores secundarios de los gastos de personal, plataforma de producto y proceso.

 

 

 

Contenido

 

Contenido

  • Contenido

     

     

    1. El problema para las estimaciones

     

     

    2. Fundamentos en estimaciones

     

    2.1. Tipos de estimación en relación al procedimiento

     

    2.1.1.Estimaciones directas

     

    2.1.2.Estimaciones paramétricas

     

    2.2. Tipos de estimación de acuerdo a los resultados

     

    2.2.1.Resultados estocásticos

     

    2.2.2.Resultados deterministas

     

    2.2.3.La diferencia entre una estimación y una profecía

     

    2.3. Estimación de tres puntos

     

    2.3.1.Qué es la estimación de tres puntos

     

    2.3.2.La estimación en el contexto de una distribución de probabilidades

     

    2.3.3.La técnica de Delphi para obtención de estimaciones de tres puntos

     

    2.4. Técnicas para asumir un compromiso o establecer una meta

     

    2.4.1. La estimación 50/50 a partir de los tres puntos con o PERT

     

    2.5. Evaluación más amplia de riesgos con la simulación de Monte Carlo

     

     

    3. Medición de Tamaño Funcional (Análisis de Puntos de Función)

     

    2.1.1.1. Estimaciones por analogía

     

    2.1.1.2. Estimaciones de abajo para arriba (botton-up)

     

    2.1.2.1. Basadas en simples relaciones lineales

     

    2.1.2.2. Más sofisticadas

     

    3.1. Qué es el APF

     

    3.2. Objetivos del APF

     

    3.3. Tipos de requisitos y el ISO/IEC 14.143

     

    3.4. APF midiendo los requisitos funcionales

     

    3.5. Lo qué es el usuario y la visión de usuario para la medición

     

    3.6. El proceso de medición IFPUG

     

    3.7. El proceso de medición COSMIC

     

    3.8. Estimaciones de esfuerzo con el Análisis de Puntos de Función (APF)

     

    3.9. Datos de benchmarking de ISBSG como un test de realidad

     

     

    4. COCOMOII para estimar mejor un esfuerzo y el plazo

     

    4.1. Que es el COCOMOII

     

    4.2. Objetivos del COCOMOII

     

    4.3. Entradas y salidas del COCOMOII

     

    4.4. El COCOMOII como herramienta para obtener una Estimación de Tres Puntos

     

    4.4.1.Una visión similar al COCOMOII de la NASA

     

    4.5. La variedad del proceso de las estimaciones

     

    4.5.1.El Punto de Función como fator de costo primario

     

    4.5.2.Variabilidad en sus orígenes

     

    4.5.3.Factores de costo proporcionales

     

    4.5.4.Factores de escala y sus causas

     

    4.5.5.La responsabilidad por identificar excepciones

     

    4.5.6.El modelo Early Design y Post-Architecture

     

    4.5.6.1. Factores de Costo de Producto

     

    4.5.6.2. Factores de Costo de Plataforma

     

    4.5.6.3. Factores de Costo de Proyecto

     

    4.5.6.4. Factores de Costo de Personas

     

    4.5.7.Los factores de escala en el COCOMOII

     

     

    5. Estimaciones de Esfuerzo

     

    5.1. La ecuación para el esfuerzo COCOMO II

     

    5.2. Evaluación de los factores de costo y de escala

     

    5.2.1.Impacto relativo y comparativo por factor de costo

     

    5.3. Distribución % del esfuerzo propuesto por el COCOMOII

     

    5.3.1.Una visión de Gartner

     

     

    6. Estimación de Plazo

     

    6.1. Plazo como una función de esfuerzo y de equipo

     

    6.2. La ley de Brooks

     

    6.3. La región imposible

     

    6.4. El modelado del COCOMO II para estimación del plazo

     

    6.5. Una ecuación de plazo del COCOMOII

     

     

    7. Datos históricos

     

    7.1. Qué es calibrar un modelo de estimaciones

     

    7.2. Porque calibrar el modelo de estimaciones

     

    7.3. Insumos para calibrar el modelo de estimaciones

     

     

    8. Estudio de casos

     

     

    9. Conclusión

     

     

     

    Carga Horaria

    20 horas. Incluye horas de contigencia

 

 

 

Público

 

A quién va dirigido

 

Profesionales involucrados en desarrollo, mantenimiento, gestión, garantía de calidad o contratación de software.

 

Pre-requisitos

 

Experiencia en proyectos de software 

 

 

 

Contacto

  

Envia un mensaje a contacto@fattocs.com para mayor información. Formas de pago y demás! 
 

  

 

Misil antibalístico Patriot

 

 

Durante la Guerra del Golfo en la década de 1990, las fuerzas de la coalición liderada por los Estados Unidos usaron un sistema de defensa con misiles antibalísticos llamado Patriot. El 25 de febrero de 1991 este sistema falló e interceptó un misil Scud lanzado por Irak. El mísil mató a 28 militares estadounidenses y lesionó otros 98. Una investigación descubrió que la raíz de la falla estaba en el software.

 

 

El software original que calculaba la ruta del Patriot utilizaba datos de las señales del radar y necesitaba trabajar con una precisión de fracciones de segundo. Para hacer frente a misiles más modernos de alta velocidad se creó una subrutina con mayor manejo de precisión (más decimales) en la información de reloj del sistema. Sin embargo, esta subrutina no utilizó todas las partes necesarias del software. Como consecuencia, se generó una acumulación de fallas de precisión, y después de cierto tiempo, el sistema se quedaba ineficaz. No fue sólo un fallo de programación, fue también un fallo de evaluación en el cambio de impacto.

 

.

 

.