Guilherme Siqueira Simões

Guía de Práctica Ágil

Ivett Sanchez — Wed, 25 Oct 2017 21:18:19 +0000

Guía de Práctica Ágil

Evento

SG Virtual #13

Ivett Sanchez Wed, 10/25/2017 - 16:18

Conferencista(s)

Guilherme Siqueira Simões

El objetivo de la ponencia es presentar la Guía de Práctica Ágil, creado por una asociación entre PMI y Agile Alliance. La guía proporciona herramientas, guías de situación y una comprensión de los diversos enfoques ágiles disponibles para permitir mejores resultados.

Se presentará de manera breve los principales puntos tratados por la Guía de Práctica Ágil:

Introducción a la agilidad.
Selección del ciclo de vida adecuado para un proyecto. -
Creación de un entorno ágil
Entrega de valor continua
Consideraciones organizacionales.

La guía es especialmente útil para los administradores de proyectos acostumbrados a un entorno más tradicional al adaptarse a un enfoque más ágil.

Acerca del conferencista

Guilherme Siquiera Simões es socio director de FATTO Consultoría y Sistemas, especializado en las áreas de medición, estimación y requerimientos de proyectos de software.

La ingeniería de requerimiento en el proceso ágil

guilherme.simoes — Fri, 12 May 2017 18:59:31 +0000

La ingeniería de requerimiento en el proceso ágil

Evento

SG Virtual #12

guilherme.simoes Fri, 05/12/2017 - 13:59

Conferencista(s)

Guilherme Siqueira Simões

La ingeniería de requerimiento en el proceso ágil de Software Guru

Un error muy común de varias personas es creer que en un proceso ágil de desarrollo de software la Ingeniería de Requerimientos es innecesaria. Aunque se cambie: la ejecución de la disciplina, las técnicas aplicadas, el momento de ejecución del trabajo y el perfil de los responsables; la disciplina de requerimientos sigue siendo fundamental para el éxito en los proyectos.

El objetivo de esta ponencia es demostrar como La Ingeniería de Requerimientos es aplicada en el contexto ágil, utilizando el proceso Scrum a manera de ilustración.

Acerca del conferencista

Guilherme Siquiera Simões es socio y director de FATTO Consultoría y Sistemas,
donde actúa como consultor e instructor en servicios de consultoría y capacitación de medición, estimación y requerimientos de proyectos de software. Autor de los libros "Análise de Pontos de Função: Medição, Estimativas e Gerenciamento de Projetos de Software" y "Engenharia de Requisitos: Software Orientado ao Negocio", ambos publicados en Brasil.

Tiene más de 20 años de experiencia en el desarrollo de sistemas. Graduado en Ciencias de la Computación, Pos-graduado en Gestión Empresarial, certificado como experto en Puntos de Función por el IFPUG y el COSMIC, como director de Proyectos por el PMI y Ingeniero de Requerimientos (CPRE-FL) por el IREB.

La Importancia de la Ingeniería de Requerimientos

ana2lp — Wed, 03 May 2017 06:17:27 +0000

La Importancia de la Ingeniería de Requerimientos

ana2lp Wed, 05/03/2017 - 01:17

Publicado en

SG #54

Requerimientos

Autor

Guilherme Siqueira Simões

La ingeniería de requerimientos es una de las disciplinas fundamentales de la ingeniería de software y proporciona información para la mayoría de las demás disciplinas. Este artículo presenta resultados de investigaciones que fundamentan de manera cuantitativa esta cuestión. El propósito es demostrar las consecuencias del descuido de la disciplina de requerimientos: retrasos en el cronograma y costo adicional, nivel alto de defectos en el software y principalmente la entrega de un software que no satisface las necesidades del cliente.

Fallos famosos

Para ilustrar, a continuación se muestran casos famosos de fallos en proyectos de software relacionados con algún tipo de discapacidad en el ejercicio de la ingeniería de requerimientos.

La sonda espacial Mars Climate Orbiter (MCO)

La MCO fue una sonda espacial cuyo objetivo principal era estudiar el clima de Marte. Fue lanzada en diciembre de 1998, alcanzando Marte nueve meses y medio después. Al entrar en la órbita de Marte, la sonda fue destruida en la atmósfera debido a un error de cálculo en la maniobra. El error fue causado porque el software responsable del cálculo de ruta de entrada esperaba datos usando el sistema de medidas imperial (libras fuerza) y recibió datos en sistema métrico universal (newtons). No se sabe si la NASA proporcionó la especificación equivocada al proveedor que desarrolló el software o si hubo una falla del proveedor en el levantamiento de requerimientos.

Misil antibalístico Patriot

Durante la Guerra del Golfo, los Estados Unidos usaron un sistema de defensa con misiles antibalísticos llamado Patriot. El 25 de febrero de 1991 este sistema falló y no interceptó el misil Scud lanzado por Irak que mató a 28 militares y lesionó otros 98.

La raíz de la falla fue que el software original del sistema utilizaba datos de las señales del radar para calcular la ruta del Patriot y trabajaba con una precisión de fracciones por segundo. Para hacer frente a misiles de más alta velocidad, se creó una subrutina para manejar el tiempo con mejor precisión (más decimales). Sin embargo, esta subrutina no fue aplicada a todas las partes necesarias del software lo que 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 impacto del cambio.

Cohete Ariane 501

El 1996, el cohete Ariane 501 fue lanzado y unos 37 segundos después del despegue, se desvió del curso esperado para después explotar. Fue el primer lanzamiento de la serie Ariane 5. La pérdida del cohete y su carga ascendieron a una pérdida de más de 370 millones de dólares. La comisión de investigación señaló que la falla había estado en el sistema de referencia inercial, el cual había sido reutilizado de la serie Ariane 4. El problema fue que el Ariane 5 estaba diseñado para transportar más carga, lo que implica otros estándares de trayectoria y velocidad diferentes, y esto no se tomó en cuenta al realizar el diseño y pruebas pertinentes.

Archivo Virtual FBI

A principios del 2000, el FBI comenzó el desarrollo de un software llamado Virtual Case File (VCF) que permitiría el intercambio de información de casos entre los agentes. Originalmente se estimó que el desarrollo tomaría 3 años. Después de la tragedia del 11 de septiembre de 2001 el FBI recibió fuertes críticas por no anticipar el ataque; las evidencias estaban expuestas, el error fue no enlazarlas entre sí. Ante esto, se decidió aumentar la prioridad del VCF y extender su alcance. Cinco años y 170 millones de dólares después, el sistema no había podido ser terminado y se canceló su desarrollo. La investigación a cargo determinó que las principales causas de fracaso fueron:

Cambios frecuentes en los requerimientos. El proveedor alegó que el FBI adoptó la filosofía de trabajo de: "Yo sé lo que quiero después de ver el producto."
Alta rotación de gestión (también contribuyó a los cambios frecuentes).
Aumento descontrolado del alcance, con requerimientos agregados incluso cuando el proyecto ya estaba retrasado.

El principal motivo de fracaso

De acuerdo con cifras del Project Management Institute (PMI) [1], el 47% del fracaso de los proyectos es causado por una deficiencia en el ejercicio de la ingeniería de requerimientos. Algunos casos comunes:

El producto se entrega sin cumplir con los requerimientos necesarios, sin identificar varios de ellos.
La entrega final es un producto que no satisface al cliente, aunque a tiempo y dentro del presupuesto.
El proyecto incorpora requerimientos que no deben estar en el alcance.
La estimación de costo/esfuerzo se hace en base a un alcance equivocado ya que no considera algunas áreas funcionales y procesos de negocio.
Fallas de comunicación sobre requisitos, lo que resulta en la entrega de un producto defectuoso.
Cambios innecesarios debido a la falta de atención por comprender correctamente las necesidades del cliente al principio.

Una de las principales causas de defectos

Los defectos pueden surgir en cualquier etapa del ciclo de vida del proyecto, siendo el más común aquellos insertados durante la construcción, donde el producto construido tiene un comportamiento diferente al especificado.

Asimismo, un número significativo de defectos se origina a partir de los requerimientos. Pero, ¿La calidad no es cumplir con los requerimientos? ¿Cómo sería posible ello? Simple, basta que la especificación no represente correctamente las necesidades del usuario.

Según, Capers Jones [2], 1 de cada 5 posibles defectos se origina en los requerimientos, y estos pueden ser hasta el 60% del total de errores en el proyecto según explica Pohl [4]. La problemática es que estos sólo se detectan en etapas avanzadas del proyecto, a menudo cuando se aprueba el producto. Por otro lado, Leffingwell [5] acota que en proyectos complejos la fuente más común de errores son los requerimientos. Esto último se refleja en los resultados mostrados por Jones y Bonsignour [3] que se capturan en la tabla 1 donde se muestra la tasa potencial de defectos por punto de función segregados por la fuente del defecto y estratificado de acuerdo al tamaño del sistema.

Origen del Defecto	Tamaño del sistema (en puntos de función)
	100	1,000	10,000
	Defectos potenciales (bugs/PF)
Requerimiento	0.75	1.00	1.25
Arquitectura	0.10	0.25	0.50
Diseño	1.00	1.25	1.50
Código fuente	1.70	1.75	2.00
Material de pruebas	1.50	1.85	2.00
Documentación	0.65	0.70	0.75
Base de datos	2.00	2.75	3.00
Website	1.50	1.75	2.00
Total	9.20	11.30	13.00

Tabla 1. Defectos en potencial por tamaño de sistema y origen.

Los defectos originados en requerimientos son más difíciles de eliminar por métodos tradicionales: pruebas y análisis estático. Esto se debe a que cuando se aprueba la especificación con un requerimiento defectuoso, los casos de prueba son elaborados a partir del comportamiento equivocado.

Adicionalmente, los cambios en requerimientos tienden a una densidad de defectos mayor, debido a que típicamente son tratados a toda prisa. Y son más difíciles de eliminar porque “saltan” el control de calidad del proyecto. Por ejemplo, un crecimiento del 10% en el alcance del proyecto implica un aumento del 12% en el número de defectos.

El costo de reparación de los defectos

La industria del software tiene un gran potencial para explotar las ganancias de eficiencia. Según Boehm [6] del 40 al 50% del esfuerzo en los proyectos de software se gasta en la corrección de defectos. Uno de los factores que contribuyen para esta ineficiencia es que al corregir un defecto existe un 20-50% de posibilidades de introducir otro error al software [7].

Pohl [4] sostiene que la mayoría de los errores originados en los requerimientos se detecta en las etapas avanzadas del proyecto. Él afirma que una parte significativa de estos errores se identifica durante la validación por el cliente. El esfuerzo de encontrar y corregir un defecto después de la entrega, suele costar a menudo 100 veces más que corregirlo cuando todavía se está desarrollando los requerimientos. Como se observó en los casos citados, los errores detectados con el software en operación pueden causar daños en varios órdenes de magnitud mayor al costo de corrección del defecto.

El objetivo es desarrollar el producto correcto en el primer intento. De esta manera, se reducen los errores en las primeras etapas del proyecto en donde se puede mitigar con mayor intensidad la reanudación. El método de ensayo y error, además de ser más caro y demorado, crea insatisfacción en el cliente. Por lo que se busca es evolucionar en la calidad del trabajo con requerimientos para lograr un impacto positivo en el costo, el tiempo y la satisfacción del proyecto.

Referencias

PMI - Project Management Institute. PMI’s Pulse of the Profession: Requirements Management - A Core Competency for Project and Program Success, 2014.
C. Jones. Software Defects Origins and Removal Methods, 2012.
C. Jones, O. Bonsignour. The Economics of Software Quality. Addison-Wesley, 2012.
K. Pohl, C. Rupp. Requirements Engineering Fundamentals. Rocky Nook Computing, 2011.
D. Leffingwell. “Calculating the Return on Investment from More Effective Requirements Management”. American Programmer 10(4); 13-16; 1997.
B. Boehm & V. Basili, V. “Software Defect Reduction Top 10 List”. Computer 34(1). IEEE, 2001.
F. Brooks. The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley, 1995.

Bio

Guilherme Siqueira Simões es socio de FATTO Consultoría y Sistemas, donde actúa en consultoría y entrenamiento en medición, estimación y requisitos de software. Es graduado en Ciencias de la Computación por la UFES, posgraduado en Gestión Empresarial por el IEL/UFES, certificado como experto en Puntos de Función por IFPUG y COSMIC, Director de Proyectos (PMP) por PMI e Ingeniero de Requisitos por IREB. guilherme.simoes@fattocs.com

¿Gestión de Riesgos: cómo manejar las incertidumbres del proyecto?

guilherme.simoes — Mon, 26 Sep 2016 13:46:51 +0000

¿Gestión de Riesgos: cómo manejar las incertidumbres del proyecto?

Evento

SG Virtual #11

guilherme.simoes Mon, 09/26/2016 - 08:46

Conferencista(s)

Guilherme Siqueira Simões

¿Gestión de Riesgos: cómo manejar las incertidumbres del proyecto? de Software Guru

MOTIVACIÓN
La gestión de proyectos está siempre relacionada a muchas incertidumbres. Durante todo su desarrollo el proyecto está sujeto a eventos inciertos que pueden impactarlos. Estos representan riesgos y su gestión está directamente relacionada a alcanzar los objetivos del proyecto, buscando eliminar o minimizar la probabilidad de ocurrencia de eventos negativos y aumentar la probabilidad de eventos positivos, o sus impactos en el proyecto.
OBJETIVO
El objetivo de esta ponencia es abordar:
• ¿Por qué gestionar riesgos?
• ¿Qué es el riesgo?
• Objetivos de la gestión de riesgos
• Principales conceptos
• Ciclo de la gestión de riesgos

Acerca del conferencista

Guilherme Siqueira Simões es socio de la FATTO Consultoría y Sistemas, donde actúa en consultoría y entrenamiento en medición, estimación y requisitos de software.

Los Niveles de Granularidad del Requerimiento Funcional

sg — Fri, 08 Jul 2016 17:27:01 +0000

Los Niveles de Granularidad del Requerimiento Funcional

sg Fri, 07/08/2016 - 12:27

Publicado en

SG #51

Requerimientos

Autor

Como la mayoría de los lectores de SG saben, todo software posee dos dimensiones de requerimientos: funcional y no funcional. Los requerimientos funcionales (RF) describen el comportamiento del software para proporcionar tareas y servicios a sus usuarios; estos tipos de requerimientos están relacionados a lo que el software debe hacer. Los requerimientos no funcionales (RNF) están relacionados al cómo las funcionalidades del software serán entregadas a sus usuarios y pueden incluir aspectos de calidad, técnicos, ambientales y organizacionales.

Teniendo en cuenta un sistema de cajero automático de un banco se podría suponer los siguientes ejemplos para los dos tipos de requerimientos:

RF: Consultar saldo de la cuenta corriente (el qué).
RNF: Toda transacción debe ser completada en un máximo de 30 segundos (el cómo).

Aunque no sea una regla, el RF se acostumbra manifestar de manera explícita en el software, es un comportamiento que se puede determinar claramente en qué parte del software está. El RNF, por lo contrario, se acostumbra manifestar de manera general, se aplica a todo o casi todo el software.

Para la Ingeniería de Requerimientos los dos tipos son igualmente relevantes: ambos deben ser identificados, analizados, especificados, modelados y gestionados. Sin embargo, hay algunas diferencias entre estos dos tipos de requerimientos que valen la pena comentar por separado. Este artículo se enfocará en los RF, con el objetivo de presentar sus niveles de granularidad y su importancia en el trabajo de la Ingeniería de Requerimientos.

Los niveles de granularidad

Continuando con el ejemplo del sistema de cajero automático, las siguientes descripciones podrían estar presentes en su especificación de requerimientos:

Realizar transacciones con la cuenta corriente.
Transferir una cifra de una cuenta corriente para otra cuenta corriente.
Validar la tarjeta y la contraseña del cliente.
Garantizar que la suma de todas las transacciones del cliente en el día no puede ser superior a $5,000.

Aunque estos cuatro ejemplos sean casos válidos de RF, es posible percibir que el nivel de detalle (o granularidad) entre ellos es distinto. Lo más frecuente es que una especificación presente los requerimientos en distintos niveles de granularidad.

El nivel de granularidad es la mayor o menor amplitud de la descripción del comportamiento esperado para el software en una especificación funcional. Esto está relacionado al tipo de objetivo asociado al requerimiento. La Figura 1 ilustra la relación entre estos objetivos y el nivel de granularidad, utilizando una clasificación de tres niveles (agregado, usuario, subfunción) propuesta por Cockburn (2000) para casos de uso y generalizada por los autores para requerimientos funcionales. Esta clasificación no significa que el proceso de la ingeniería de requerimientos deba utilizar una estrategia de desarrollo por descomposición funcional.

Figura 1. Niveles de granularidad.

Nivel de usuario

El requerimiento a nivel de objetivo de usuario es aquel que:

Abarca una única tarea bajo la responsabilidad de un único individuo;
Es realizado en el momento en que el usuario posee todo lo que es necesario para que la tarea sea completada hasta el límite de su responsabilidad en el flujo operativo donde está contenida.

Al final de la tarea el usuario alcanza su propósito, está satisfecho y no hay nada más que necesite hacer. Una vez que el requerimiento fue completado, todo lo que debería de realizarse para tratar un evento externo fue realizado. Esta tarea es casi siempre parte de un proceso de negocio que puede tener un flujo operativo más amplio y por esto puede aún no estar completa. Sin embargo, la perspectiva relevante en este caso no es del proceso de negocio, es de la tarea.

En general, si un trabajo involucra más de un individuo es porque hay más de una tarea presente en el contexto. Hay excepciones como un retiro en la cuenta corriente en la sucursal del banco donde dos individuos participan: la caja del banco que solicita e informa datos para el retiro y el cliente que informa la contraseña.

Esta es la granularidad del ejemplo 2 (“Transferir una cifra de una cuenta corriente para otra cuenta corriente.”). Es una única tarea (seguramente compuesta por varios pasos y reglas), bajo la responsabilidad de un único individuo que al final de todos los pasos está satisfecho con el objetivo alcanzado: una cifra fue transferida a otra cuenta corriente.

Nivel agregado

El requerimiento en este nivel agrega varios requerimientos a nivel de objetivo de usuario en una única especificación de más alto nivel. Tanto más alto sea su nivel, más generales son sus objetivos y para que un objetivo de nivel más alto sea alcanzado, otros objetivos de nivel más bajo deben ser alcanzados primero.

Este tipo de requerimiento está relacionado a objetivos más generales y su amplitud está asociada a objetivos colaborativos o asociados a procesos de negocio de alto nivel. No es relativo a una única tarea, por lo contrario, agrega un conjunto de tareas de uno o más usuarios. Esta es la granularidad del ejemplo 1 (“Realizar transacciones con la cuenta corriente.”).

¿Cuáles son las tareas asociadas a este tipo de requerimiento? Tal vez sean obvias para los lectores de la especificación (los interesados) o tal vez aún no sean conocidas. Sin embargo, es sabido que hay actividades a realizar para levantar (refinar) este requerimiento. Lo que importa es que ya está claro que este requerimiento está dentro del alcance del software a ser desarrollado.

Sin embargo, algunos RF de este tipo poseen patrones que eliminan la necesidad de proporcionar más detalles. Un ejemplo clásico son los formularios CRUD (Create, Read, Update, Delete) para que el usuario pueda mantener datos por medio del software. Es muy común que esto sea expresado como: “El sistema debe mantener productos.”. Hay un conocimiento tácito entre los interesados que el verbo “mantener” agrega las tareas del CRUD. Por lo tanto queda claro a todos los lectores que el software debe permitir al usuario realizar las siguientes tareas: agregar, modificar, eliminar y consultar datos de producto.

Nivel de subfunción

Estos requerimientos son pedazos de requerimientos con objetivo de usuario; están relacionados a un conjunto de pasos o a reglas de una o más tareas de los usuarios.

El requerimiento en nivel de subfunción que representa un conjunto de pasos describe el cambio de datos en los dos sentidos entre el usuario y el software; y entre el software y los requerimientos de almacenamiento. Este es el caso del ejemplo 3 (“Validar la tarjeta y la contraseña del cliente.”). Cada tipo de transacción que utiliza la cuenta corriente (ej.: retiro, transferencia, pago, etc.) exige el mismo conjunto de pasos descrito por el ejemplo 3, que se podría suponer como:

Verificar si la tarjeta es válida.
Verificar si la transacción elegida es compatible con el tipo de tarjeta.
Verificar si la contraseña informada es correcta.
Incrementar el control de errores de contraseña en caso que la contraseña informada sea incorrecta.
Cambiar a cero el control de errores de contraseña en caso que la contraseña informada sea correcta.

Validar la tarjeta y contraseña del cliente no es el objetivo del cliente al utilizar el sistema de cajero automático, sin embargo son pasos necesarios y intermediarios para alcanzar su objetivo: por ejemplo, hacer un retiro.

El requerimiento en el nivel de subfunción que está relacionado a reglas, en general se vincula a las leyes que gobiernan el negocio y describen de manera que complementan los procesos de negocio. También llamadas muchas veces como reglas de negocio. La regla puede describir políticas corporativas, reglamentos gubernamentales o estándares de la industria por los cuales el software debe estar subordinado.

Este es el caso del ejemplo 4 (“Garantizar que la suma de todas las transacciones del cliente en el día no puede ser superior a $5,000.”). Las reglas de negocio muchas veces son compartidas entre varios RF, hasta entre distintos productos de software en la empresa.

Importancia de la granularidad

En una visión simplificada se puede decir que hay dos momentos clave donde una especificación de requerimientos es necesaria:

A. Proporcionar una visión amplia del software (y tal vez aún no profunda).

B. Proporcionar una visión profunda del software (de una parte o del todo).

El caso A es muy común en etapas tempranas de proyectos. El objetivo en este momento es primero obtener una visión amplia del alcance, por ejemplo: para planificar el proyecto, estimar un orden de magnitud de costo o plazo, o hacer un análisis de factibilidad. Un documento de visión es un ejemplo de documento que cumple este propósito. Especificar los RF en el nivel agregado es suficiente y más adecuado a este caso. El costo para obtener información y especificar en un nivel de granularidad más bajo puede significar desperdicio de esfuerzo para detallar lo que no es necesario.

Entonces el documento de requerimientos para el propósito A, tendrá la mayoría de los RF especificados en el nivel agregado. Es posible también que haya especificaciones en el nivel de usuario o subfunción, esto no es un error. A veces puede ser interesante especificar los RF más críticos (no todos o la mayoría) en un nivel más detallado, ya sea para facilitar la comprensión del alcance por el interesado o permitir una estimación con menos incertidumbre.

El principal propósito para especificar requerimientos en niveles agregados es establecer áreas de proceso objeto de informatización y/o automatización para que las necesidades de negocio queden resueltas.

Si el objetivo de la especificación es proporcionar una visión profunda de parte o de todo el software, por ejemplo para iniciar su desarrollo, la existencia de RF en el nivel agregado puede significar que varias decisiones sobre el alcance todavía siguen pendientes. Es decir, hay trabajo de levantamiento que debe ser hecho.

Para el propósito B, el nivel de granularidad más adecuado es del objetivo del usuario pues es el único que proporciona una definición de alcance del software de manera inequívoca; no hay dudas sobre lo que es abarcado. Esto es también el único nivel de descripción de procesos que puede ser estandarizado y consecuentemente es el nivel utilizado por todos los métodos de medición de tamaño funcional adherentes a la norma ISO/IEC 14143.

Consecuentemente, para el propósito B, lo más común es que un documento de requerimientos tenga los RF especificados en su mayoría con el objetivo de usuario. RF en el nivel agregado puede estar presente sólo cuando es el caso de que esté claro a todos los interesados que tareas son abarcadas por este RF.

La definición de un requerimiento en el nivel de subfunción es adecuada cuando el comportamiento especificado es común y compartido por varias otras tareas que el software entrega a los usuarios. Esto hace con que la especificación de requerimientos sea más fácil de modificar en respuesta a cambios, pues disminuye la redundancia de información al evitar describir el mismo conjunto de pasos o reglas más de una vez. También ayuda a alcanzar una especificación más consistente.

Conclusión

Aunque el concepto de los niveles de granularidad del requerimiento funcional sea sencillo, en términos prácticos se percibe que muchos ingenieros de requerimientos no están atentos a esto cuando elaboran las especificaciones. Tener en cuenta los niveles de granularidad ayuda a definir el esfuerzo adecuado para ser dedicado a la elaboración de la especificación y también a alcanzar una especificación de requerimientos de mejor calidad.

El estándar 830 de la IEEE presenta los siguientes criterios para evaluar la calidad de una especificación de requerimientos: correcta, completa, clara (no ambigua), consistente, modificable, priorizada, verificable, trazable.

Siendo el propósito de la especificación proporcionar una visión profunda del alcance, estar atento al nivel de granularidad del RF permite que:

• Se descubra que la especificación puede no estar completa cuando hay RF agregados.

• Se proporcione la comprensión del alcance sin ninguna ambigüedad con respeto a las tareas que el software entregará cuando se enfoca el RF con objetivo de usuario.

• Se genere un documento de requerimientos más fácil de mantener y consecuentemente más consistente al especificar los RF adecuados con objetivo de subfunción.

Referencias

A. Cockburn. Writing Effective Use Cases. Addison-Wesley, 2000.
COSMIC Measurement Manual: 4.0.1. Common Software Measurement International Consortium, 2015.
IEEE Std. 830–1998: IEEE Recommended Practice for Software Requirements Specifications. IEEE Computer Society, 1998.
Function Point Counting Practices Manual. Release 4.3.1. IFPUG, 2010.
C. Vazquez, G. Simões & R. Albert. Análise de Pontos de Função, Medição, Estimativas e Gerenciamento de Projetos de Software. Saraiva, 2013.
C. Vazquez, G. Simões. Engenharia de Requisitos: Software Orientado ao Negócio. Brasport, 2016.

Prototipos: Un Juguete muy Valioso

guilherme.simoes — Mon, 03 Aug 2015 18:49:07 +0000

Prototipos: Un Juguete muy Valioso

Evento

SG Virtual #9

guilherme.simoes Mon, 08/03/2015 - 13:49

Conferencista(s)

Guilherme Siqueira Simões

NOTA: Por cuestiones tecnicas de la herramienta, lamentablemente no se muestra la presentacion en la grabacion. Te ofrecemos una disculpa por las molestias que pueda ocasionar.

Prototipos:Un juguete muy valioso from Software Guru

La presentación comenta sobre prototipos en el desarrollo de software, enfocando: - Definición de prototipado - Beneficios de los prototipos - Planeación del prototipo - Enfoques posibles de los prototipos: -- Alta y baja fidelidad -- Desechable y evolutivo - La sesión de prototipado - Cuidados al prototipar

Contratación de Software Basada en Resultados

sg — Mon, 25 May 2015 05:19:38 +0000

Contratación de Software Basada en Resultados

sg Mon, 05/25/2015 - 00:19

Publicado en

SG #47

Outsourcing

Autor

Guilherme Siqueira Simões

El sector de Tecnologías de la Información se ha visto muy afectado por el movimiento de externalización de las empresas. Gran parte del desarrollo y mantenimiento de los sistemas ya no se hace más internamente.

Sin embargo, esta medida trajo efectos secundarios inesperados (y no deseados) para muchas organizaciones que han adoptado esta iniciativa. Uno de los problemas se refiere a las prácticas de contratación de estos servicios de terceros. En las secciones siguientes se comentan las formas más comunes de la contratación de servicios de desarrollo de software.

La contratación por hora-hombre

En esta forma de contratación, también conocida como body shopping, el cliente contrata a profesionales para la asignación en el desarrollo de software, generalmente en conjunto con su propio equipo, algunas veces con varios proveedores de mano de obra, y utiliza su infraestructura logística interna. La remuneración del proveedor se calcula basándose en el nivel de cualificación y experiencia de los profesionales que trabajan, en las horas trabajadas y otros gastos posibles.

En este tipo de contrato, la remuneración del proveedor está orientada a los procesos "internos" a la producción de software. El precio final de un proyecto se determina a partir de consideraciones tales como: la cantidad de trabajo que requiere, el perfil y la cantidad de profesionales movilizados para su aplicación, y la complejidad de la gestión. El control de precios está en manos del proveedor, que en teoría, tiene más experiencia en estos aspectos técnicos del proyecto que el cliente, cuya actividad económica tiende a ser diferente al desarrollo o mantenimiento de software.

Este modelo es fácil de administrar y proporciona una gran flexibilidad tanto para el cliente y como para el proveedor. Una vez que se hayan establecido las relaciones comerciales, el cliente es capaz de ser más ágil en el cumplimiento de los picos de demanda del servicio. En el caso de que exista cambio de las necesidades, no es necesario renegociar el contrato con el proveedor. Sin embargo, aumentar el alcance provoca un incremento del trabajo (horas), así como del costo del proyecto. Es justo que haya remuneración al proveedor por este esfuerzo adicional, ya que la gestión del alcance es responsabilidad directa del cliente.

El aspecto más crítico de este tipo de contratación, es que el cliente es responsable por la gestión del equipo de servicio, incluyendo la productividad del proveedor. Esto requiere un nivel de competencia que puede no estar disponible internamente. Además, la remuneración del proveedor no está vinculada a los resultados producidos, sólo al número de horas realizado. No hay incentivo para que el proveedor mantenga o aumente los niveles de productividad y calidad, lo que debería ser parte de su responsabilidad. El incentivo es negativo: en cuanto más esfuerzo se demande por parte del proveedor, mayor será la remuneración. ¡Y esta es la antítesis de la productividad!

Otro obstáculo está relacionado con las garantías de servicio. Si la asignación implica más de una empresa, es muy difícil aislar las responsabilidades de cada empresa y exigir la garantía. El cliente paga por un servicio y también por cualquier mantenimiento posterior correctivo asociado a éste.

Contratar a un precio fijo

Este tipo de contratación, también conocido como fixed price, favorece el enfoque de proyecto con un comienzo y un final bien definidos (y por supuesto, del alcance). Además, este modelo requiere un mayor nivel de organización del cliente y del proveedor. Si los requisitos están mejor definidos hay menos posibilidades de fricción entre las partes.

Sin embargo, es probable que el proveedor no tenga mucha información, no domine el problema o no dedique tiempo para un análisis detallado de los requisitos para la preparación de su propuesta de negocio. Como resultado, habrá un subdimensionamiento o sobredimensionamiento del presupuesto presentado. Cuando la competencia es intensa, es probable que el primer caso se produzca.

Ambos casos son indeseables. En el primero, el proveedor tendrá dificultades para atender al cliente. Si los requisitos no están bien definidos, es probable que se cree un callejón sin salida y una nueva negociación comercial tendrá que ser considerada. Aunque los requisitos hayan sido bien definidos, el presupuesto por el proveedor puede haber sido insuficiente y la calidad del producto se vea seriamente afectada o incluso el proyecto no pueda ser completado.

En este modelo hay una transferencia del riesgo del cliente al proveedor, y surgen los cuestionamientos con respecto al riesgo del alcance (¿los cambios serán alojados sin coste adicional?) y de la productividad (¿cuál es el nivel de control sobre los vectores que afectan el trabajo?). El precio propuesto por los proveedores debe tener en cuenta estos riesgos.

El uso de este enfoque se complica cuando se asume que los requisitos no cambiarán (o habrá poco cambio) después del inicio del proyecto. El entorno de una organización se es dinámico, los requisitos también lo son. En cuanto más larga sea la duración del proyecto, es más probable que hayan cambios en los requisitos. Aparte es difícil de estimar cómo estos cambios afectan el presupuesto original del proveedor. De acuerdo con [7] más de 2% de los requisitos cambian mensualmente después de la fase de requisitos. En este caso, es probable que sea necesaria una renegociación. Si esto ocurre, el cliente no tendrá la misma condición original, ya que dependiendo de qué fase el proyecto esté, no hay competencia, ni una unidad para comparar el precio originalmente acordado con los precios cobrados de acuerdo a las nuevas características solicitadas.

En este modelo de contratación, el control sobre la cantidad a pagar lo tiene el proveedor. Es muy común que la formación de precios se efectúe en términos de la estructura de descomposición del proyecto de trabajo, la cantidad de las horas y el perfil de profesionales asignados a esa actividad. Esto también ocurre con la contratación por hora-hombre, el control está bajo quienes poseen los conocimientos técnicos de ingeniería de software y la aplicación de sus disciplinas.

Un modelo alternativo de contratación

Con el tiempo, algunas organizaciones comenzaron a experimentar con formas alternativas de contratación de servicios de software que promovían una mejor distribución de los riesgos y resultados. En el modelo hora-hombre, la productividad del trabajo es un problema de gestión del cliente, cuando debería ser preocupación del proveedor. La administración del alcance también es responsabilidad del cliente, ya que el proveedor no tiene control sobre los requisitos. En el modelo de precio fijo, la productividad es responsabilidad del proveedor, lo que es justo, ya que este es responsable del proceso de trabajo. Sin embargo, cualquier cambio o incertidumbre de los requisitos, que es responsabilidad del cliente, impacta este modelo de contrato.

Por lo tanto, un modelo de contratación óptimo sería la remuneración de acuerdo con las unidades de resultado del servicio realizado. Esto promueve el balance de riesgos y responsabilidades entre cliente y proveedor. En este caso, la productividad es responsabilidad del proveedor, ya que existe un riesgo de lesiones si hay retraso en las unidades de producción. Además, en el caso de que exista un aumento en el alcance, se debe construir más unidades para el servicio y el proveedor es remunerado por ello.

El gran desafío de este enfoque es encontrar una unidad que sea reconocida de manera inequívoca, uniforme y consistente tanto para el cliente como para el proveedor. Ejemplos de unidades podrían ser: pantallas, informes, tablas, casos de uso, líneas de código, stored procedures, webservices, puntos de función, entre otros. Pero no todas estas unidades cumplen con los criterios para ser reconocidos por el cliente y el proveedor de forma consistente.

Al analizar las unidades de carácter más técnico, no se tiene en cuenta la visibilidad de estas por parte del cliente. La relación (si existe) entre las líneas de código, por ejemplo, y algo de valor tangible al cliente es muy débil. El cliente no siempre tiene toda la experiencia para atribuir valor a un servicio que involucró a escribir un cierto número de líneas de código. A menudo, una de las razones para la externalización es precisamente la búsqueda de un proveedor con más conocimientos especializados en un tema, que no es de interés para el cliente y no le generará interés de tener dominio.

Al analizar algunas unidades menos técnicas, tales como pantallas, tablas, informes, casos de uso o los puntos de función, estos tienen unidades que son fácilmente reconocidas y comprendidas por ambas partes. La cuestión ahora es encontrar una definición consistente para esta unidad. En el caso de las pantallas, tablas, informes y casos de uso, no hay definición normalizada. A pesar de que hay buenas prácticas, y hacen uso del sentido común para definir lo que debería ser o no un caso de uso o una pantalla, estas unidades no son suficientes para ser utilizadas como una unidad de medida de contratos. En un extremo el cliente puede manejar el servicio de todo el sistema si se especializa en solo un caso de uso para minimizar el costo; en caso contrario, el proveedor puede dividir la especificación del sistema en casos de uso para aumentar su remuneración.

El tamaño funcional puede ser considerado una unidad viable de medida en los contratos, precisamente porque son una medida de carácter no técnico, con una definición estándar, y consistente.

Por otra parte, la contratación de los servicios basado en los resultados entregados, permite al cliente tener más control sobre los costos.

La medición funcional del software

La medición funcional mide el software mediante la cuantificación de sus tareas y servicios, es decir, las características que el software proporciona al usuario. En resumen, mide los requisitos funcionales del software.

La idea es que la medición funcional sea:

Lo suficientemente simple para reducir al mínimo el costo adicional del proceso de medición.
Una medida consistente entre los diversos proyectos y organizaciones.

El resultado de la medición es llamado tamaño funcional y a menudo expresado en una unidad llamada punto de función (PF).

Hay cinco métodos de medición funcional estándares: IFPUG (ISO/IEC 20926), NESMA (ISO / IEC 24570), Mark II (ISO / IEC 20968), COSMIC (ISO/IEC 19761) y FISMA (ISO/ IEC 29881).

Modelo de costos

Un modelo para la prestación de servicios de software basado en el tamaño funcional puede ser representado por las fórmulas siguientes, que en la práctica son similares.

Esfuerzo = Tamaño x Tasa de entrega (1)

En esta primera fórmula, el esfuerzo del proyecto que se ejecutará es estimado (en horas) teniendo en cuenta el tamaño (en puntos de función) y una tasa de entrega pre-definida (horas por puntos de función). Esta tasa es definida, de acuerdo con el proveedor y un estudio de productividad del cliente basado en una muestra histórica de proyectos ya implementados. El costo del proyecto se deriva simplemente de la multiplicación del esfuerzo calculado por un valor de horas acordado entre el cliente y el proveedor.

Costo = Tamaño x Precio por Unidad (2)

En esta segunda fórmula el costo del proyecto se calcula directamente con el tamaño funcional multiplicado por el precio unitario de este. Para establecer el precio que se ofrece, los proveedores deben tener en cuenta todo el proceso de trabajo definido por el cliente en el Request for Proposal.

Ambas fórmulas son equivalentes, ya que el esfuerzo se puede convertir en costos, como en el precio unitario es definido (o debería ser definido) según la productividad esperada para el contrato.

Al igual que las características de los servicios que se exigen en el contrato, el modelo puede ser refinado (y por lo general esto se hace) con el uso de diferentes indicadores de la tasa de entrega (H/PF) o el precio de la unidad ($/PF), calibrado para especificidades de cada tipo de servicio.

Para organizaciones grandes los procesos de contratación son a menudo largos y costosos. Por lo tanto, el modelo descrito anteriormente se aplica generalmente no en un proyecto individual, sino a un volumen de puntos de función predefinidos para ser utilizados en varios proyectos durante un período por lo general de doce o más meses. Este volumen se determina normalmente basado en los proyectos previstos por el área de sistemas en la planificación estratégica.

A medida que el tamaño funcional se realice con base a la vista externa del usuario, en contraste con una vista interna de la ingeniería de software, el cliente ejerce el control efectivo y la gestión de contratación. El perfil de los profesionales movilizados o la cantidad de horas trabajadas dejan de ser factores definitivos para el análisis. Se trata de un modelo en el que el tamaño funcional no cumple el papel de la estimación de esfuerzo o costo, sino de prescribir la cantidad que se pagará independientemente de su costo o esfuerzo real.

Al igual que los contratos de precio fijo, este modelo tiene riesgos. Sin embargo, con una mejor distribución. Las consideraciones acerca de la complejidad del trabajo en sus diversas dimensiones (excepto alcance de las funciones solicitadas y entregadas al usuario), y el perfil y la cantidad de profesionales asignados serán consideradas cuando se defina el precio por unidad ($/PF) o la tasa de entrega (H/PF).

El precio unitario, junto al tamaño funcional, prescribe la forma en la que el proveedor será recompensado por cada servicio prestado.

En un análisis específico de cada proyecto entregado, la recompensa (o esfuerzo) aumenta o disminuye en comparación con lo realmente realizado. Este modelo utiliza como base el precio medio (o promedio de productividad) para la derivación del costo. Dado que hay una buena definición de los parámetros de precios, estas variaciones entre los proyectos tienden a anularse entre sí cuando se considera el conjunto de proyectos llevados a cabo en un horizonte de tiempo más largo (por ejemplo, un año).

Beneficios del modelo propuesto

Una de las razones para usar el modelo propuesto es que el vocabulario de la medición funcional utiliza la terminología y define elementos de análisis que son independientes de la tecnología utilizada para desarrollar el software. El proceso de medición sólo tiene en cuenta la perspectiva de negocio como se entiende y es válida para el cliente. La eliminación de estos tecnicismos facilita la comprensión entre las partes y es un motor importante para la comunicación entre cliente y proveedor.

Otra de las ventajas de este método, especialmente para el sector público, es que contratos remunerados por el tamaño funcional permiten auditoría externa de todos los pagos hechos. Algo que no puede ser hecho en un contrato por hora-hombre. Verificar horas trabajadas después del pago es muy difícil.

Para los contratos basados en los puntos de función, el fraude es fácilmente detectado por la auditoría. A medida que la medición funcional refleje funcionalidades entregadas por los proyectos, no hay manera de que sean falsificados.

Service Level Agreements (SLAs)

En este modelo hay interés directo de los proveedores para maximizar el flujo de las demandas entregadas, ya que implica un aumento de los ingresos. Para el cliente esto también es beneficioso, ya que proporciona más capacidad de respuesta a las necesidades de software de la organización.

Como también hay interés por parte del proveedor para entregar un servicio de calidad, ya que las correcciones implican repetición del trabajo, sin los ingresos asociados, el costo impacta a la rentabilidad del contrato.

Pronto podremos ver una convergencia de intereses en ambos lados para una rápida entrega y una mejor calidad del servicio entregado. Sin embargo, no se puede prescindir de los Acuerdos de Nivel de Servicio (Service Level Agreements), específicamente en plazo y calidad.

Cuando hay un retraso en la entrega del servicio, incluso si el cliente tiene la previsibilidad del saldo a pagar, este retraso puede resultar en pérdida de oportunidades para el negocio. Lo mismo se aplica a los defectos, aunque no hay costo adicional para las correcciones, esto puede afectar la fecha de entrega de una solución o incluso provocar un daño muy grande al negocio si la manifestación del defecto ocurre después del despliegue del software. Por lo tanto, es una buena práctica, el uso de SLA’s en los contratos basados en la medición funcional.

Dificultades comunes

Una dificultad para la adopción del modelo de contrato basado en el tamaño funcional es la poca madurez en proyectos en muchas organizaciones. Para aquellos que están en un modelo basado en hora-hombre, existe un gran impacto para promover este cambio. La contratación por el tamaño funcional consiste en trabajar enfocado en proyectos, lo que implica una buena planificación y evaluación del alcance. Sin embargo, la falta de planificación, documentación y visibilidad de los resultados producidos es común en contratos por hora-hombre.

Otro cuidado es no copiar modelos de costos de otras organizaciones, sin la calibración necesaria de sus parámetros con datos históricos propios. Cuando se utilizan parámetros de otras organizaciones (o precio unitario), los costos de la contratación pueden elevarse o los proveedores serán oprimidos hasta llegar al punto de rescindir el contrato.

Otra dificultad está relacionada con las mediciones, que deben centrar exclusivamente en las necesidades del negocio. Para aquellos que están involucrados en la implementación, a menudo hay una dificultad en la abstracción de la implementación y esto se refleja en una medición a menudo incorrecta (y por lo general, más grande).

Conclusión

El modelo de contratación de servicio de software por resultados ha sido madurado principalmente en Brasil y Corea del Sur durante los últimos quince años. En varios casos fueron percibidos mejora de productividad, mejora de la calidad de la documentación de requisitos y resultados entregados con nivel de satisfacción más alto.

Referencias

Vazquez, C. E.; Simões, G. S; Albert, R. M., “Análise de Pontos de Função: Medição, Estimativas e Gerenciamento de Projetos de Software”. 13ª ed., São Paulo-Brasil: Editora Érica, 2013.
International Function Point User Group. http://ifpug.org
United Kingdom Software Metrics Association. http://uksma.co.uk
Common Software Measurement International Consortium (COSMIC). http://cosmicon.com
NESMA. http://nesma.org
Finnish Software Measurement Association (FISMA) http://fisma.fi
C. Jones. “Conflict and Litigation Between Software Clients and Developers”, Software Productivity Research, Versión 10 . abr. 2001

Bio

Guilherme Siquiera Simões es socio y director de FATTO Consultoría y Sistemas, donde actúa como consultor e instructor en servicios de consultoría y capacitación de medición, estimación y requisitos de proyectos de software. Es autor del libro "Análise de Pontos de Função: Medição, Estimativas e Gerenciamento de Projetos de Software", el más vendido en Brasil sobre este tema.

Gestión de Requerimientos: El talón de Aquiles de los Proyectos

guilherme.simoes — Wed, 22 Apr 2015 21:03:43 +0000

Gestión de Requerimientos: El talón de Aquiles de los Proyectos

Evento

SG Conferencia y Expo 2015

guilherme.simoes Wed, 04/22/2015 - 16:03

Conferencista(s)

Guilherme Siqueira Simões

Gestión requerimientos from Software Guru

Un bajo desempeño en la Gestión de Requerimientos tiene un impacto desastroso sobre el éxito de un proyecto. Según el PMI, el 47% de los proyectos que fracasan tienen como causa fundamental una Gestión deficiente de sus Requerimientos. A pesar de toda su importancia, esta área de conocimiento es comúnmente descuidada en la formación de los profesionales.

El propósito de esta presentación es abordar:
- ¿Qué es la Gestión de Requerimientos?
- La relación de la Gestión de los Requerimientos con la Gestión de Proyectos
- ¿Cuál es la importancia de la Gestión de Requerimientos para los proyectos?
- Las dificultades comunes en la Gestión de Requerimientos
- Los principales procesos de Gestión de Requerimientos
- El nuevo programa de certificación del PMI: Professional in Business Analysis (PMIPBA)

Acerca del conferencista

Guilherme Siquiera Simões es socio y director de FATTO Consultoría y Sistemas,
donde actúa como consultor e instructor en servicios de consultoría y capacitación
de medición, estimación y requerimientos de proyectos de software. Autor del libro
"Análise de Pontos de Função: Medição, Estimativas e Gerenciamento de Projetos de
Software", el más vendido en Brasil sobre este tema.

Tiene más de 20 años de experiencia en el desarrollo de sistemas. Graduado en Ciencias de la Computación, Pos-graduado en Gestión Empresarial, certificado como experto en Puntos de Función por el IFPUG, como director de Proyectos por el PMI y Ingeniero de Requerimientos (CPRE-FL) por IREB.

Guilherme Siqueira Simões

Guía de Práctica Ágil

Evento

Conferencista(s)

La ingeniería de requerimiento en el proceso ágil

Evento

Conferencista(s)

La Importancia de la Ingeniería de Requerimientos

Publicado en

Autor

Fallos famosos

La sonda espacial Mars Climate Orbiter (MCO)

Misil antibalístico Patriot

Cohete Ariane 501

Archivo Virtual FBI

El principal motivo de fracaso

Una de las principales causas de defectos

El costo de reparación de los defectos

Tags

¿Gestión de Riesgos: cómo manejar las incertidumbres del proyecto?

Evento

Conferencista(s)

Los Niveles de Granularidad del Requerimiento Funcional

Publicado en

Autor

Los niveles de granularidad

Nivel de usuario

Nivel agregado

Nivel de subfunción

Importancia de la granularidad

Conclusión

Prototipos: Un Juguete muy Valioso

Evento

Conferencista(s)

Contratación de Software Basada en Resultados

Publicado en

Autor

La contratación por hora-hombre

Contratar a un precio fijo

Un modelo alternativo de contratación

La medición funcional del software

Modelo de costos

Beneficios del modelo propuesto

Service Level Agreements (SLAs)

Dificultades comunes

Conclusión

Gestión de Requerimientos: El talón de Aquiles de los Proyectos

Evento

Conferencista(s)