Ingeniería de Software de Élite

Existen dos frases, que he escuchado decir a muchos Líderes de equipo y Gerentes, quizás las has escuchado también:

- "Quiero un equipo con la camiseta bien puesta"

- "Todos los miembros del equipo deben ser más comprometidos"

Son una arenga, que busca motivar al equipo para que obtenga resultados extraordinarios o sea capaz de solucionar problemas activa y rápidamente. A veces, cuando existe la urgencia de liberar una función o un fix, la escucho en esta forma: "comprométete más con la empresa".

Sin embargo, solemos ver un efecto opuesto al que buscan estas frases: un equipo desmoralizado y resultados alejados de las expectativas de los líderes. Los miembros del equipo están comprometidos; dice Watts Humphrey: "todos los participantes quieren hacer un gran trabajo y dar lo mejor de sí, siempre", y es verdad; no conozco un solo desarrollador de software que se levante en las mañanas pensando "hoy haré el peor trabajo que pueda"; es solo que, en su estado actual, tiene poco margen para participar.

A lo largo de mi carrera profesional he escuchado lo siguiente en diferentes ámbitos:

“Es normal que el software tenga defectos” o su variante “El software siempre tendrá defectos”

No es normal.

Ustedes no andarían por un puente vehicular, del que saben que tiene defectos. No aceptarían un coche defectuoso o aceptarían una casa con múltiples defectos. Sin embargo, como decía mi profesor Carlos Montes de Oca “el software es tan necesario que le perdonamos que sea malo”.

Se vuelve el cuento de nunca acabar. En general, las organizaciones con este problema dedican entre 65% y 85% del tiempo solo a esta actividad en lugar de producir funciones nuevas, o dedican equipos completos solamente a esto. Algunas organizaciones, con algo de cinismo, la incluyen en los contratos como “fase de estabilización”, que solo es trasladarle el costo al cliente por la mala calidad del desarrollo.

A continuación te presento razones por las que se presenta este comportamiento en organizaciones de software.

No hay cultura de la calidad

Cuando pregunto “¿Quién es responsable de la calidad del software en la organizacion?” suelen responder:

El equipo de QA

La fase de Testing

Es decir, asumen que la calidad es “algo que sucede en un momento del tiempo” o es una actividad concreta, en lugar de ser un trabajo continuo.

Esto genera una forma de trabajo donde la responsabilidad se diluye. El equipo de desarrollo espera que QA sea quienes encuentren los defectos, y QA espera que desarrollo esté atento a los ciclos de pruebas para reparar cuanto antes. Además, genera conflicto y fricción, sobre todo si ambos grupos solo se involucran en su fase y no colaboran en el resto del ciclo.

Presiones para entregar a Testing rápido

Esto es consecuencia de la pobre cultura de la calidad. Project Managers, Gerentes y Líderes saben, por la experiencia anterior, que la fase con más costo será testing. Por lo tanto, concluyen que una forma de acortarla es iniciarla rápidamente. Presionan para entregar y empezar a probar, en lugar de promover que se aseguren de que lo que entregan aprobará las pruebas rápidamente. El resultado siempre es el opuesto al que esperan: mientras más defectos encuentran, más defectos hay por arreglar.

Watts Humphrey lo dice en su libro “A discipline for software engineering”: “Al llegar a testing, la calidad ya se encuentra dentro del producto”. William Lewis lo remata así: “No se puede agregar calidad a un producto ya terminado”

Imagen: pch.vector para Freepiki

La forma de trabajo es inadecuada

En el punto anterior menciono: mientras más defectos encuentran en testing, más defectos hay por arreglar. Si la forma de trabajo usada para arreglar los bugs es la misma que se usó para crear el código la primera vez, la consecuencia es que inserte más defectos. Puedes observar cosas como:

El equipo de desarrollo quiere regresar el código a QA lo más rápido posible (como la primera vez), y no verifica exhaustivamente que ya no hay defectos.

Los equipos no comparten información, que puede ayudar a prevenir defectos. Un caso común es que un equipo no comparte cuáles son las ideas de prueba que tiene, o qué cosas le gustaría probar.

Cualquier actividad de aseguramiento de calidad como peer review, inspecciones, walkthroughs, etc. es suprimida porque se ve como pérdida de tiempo y lo que urge es entregar a QA.

Deuda técnica

Productos y sistemas que están en desarrollo constante (mejoras y mantenimiento) suelen presentar el problema de la deuda técnica, la cual “se cobra” con el tiempo en forma de fallas y defectos. La deuda técnica es una implementación inadecuada, que se hizo apresuradamente para resolver algo en un momento, pero nunca se reemplazó por la solución correcta. Esto, a la larga, va manifestándose con problemas que son costosos para los equipos, en términos de tiempo.

Aunado a esto, los sistemas están pobre o nulamente documentados. Cuando un ingeniero quiere arreglar un problema, tardará mucho entendiendo qué hace ese código (sobre todo si nunca ha trabajado en esa sección, es nuevo en el equipo o hace mucho tiempo que no explora ese componente). La falta de documentación también nos lleva a otros problemas como duplicar funciones, romper la cohesión de componentes o hacer parches que aumentan la deuda técnica.

¿Qué hacer?

Apréndete y difunde estas dos frases:

La buena calidad no es opcional

La buena calidad es responsabilidad de todos en el equipo

Lo inicial es establecer una buena cultura de la calidad, que inicia con la responsabilidad compartida. Con base en eso, el equipo desarrollará acuerdos en su forma de trabajo, con los que asegurará la calidad de su software continuamente.

¡Con gusto te apoyo! Dime de qué manera podemos colaborar.

¡Nos vemos en la siguiente entrega!

Sígueme en mis redes:

Facebook: Software Engineering Coach

Twitter: EdgarTeamCoach

LinkedIn: https://linkedin.com/in/edgarfernandezr

En las cinco red flags de las organizaciones de software, que les detiene para lograr resultados de élite, tenemos el tiempo de desarrollo muy largo; esto es, la incapacidad del equipo para entregar software funcionando en intervalos cortos, regulares y frecuentes.

Algunas empresas se distinguen por su innovación, la cual notamos porque brindan funciones nuevas en sus productos constantemente. Hablamos de compañías como Amazon, Netflix o Facebook (ahora, Meta), quienes crearon una forma de trabajo capaz de hacer varios deploys al día, completamente funcionales. Amazon lo hace a una tasa de 30,000 al día; Netflix, 500 y Facebook 2 veces diariamente.

¿La tuya es capaz de hacer esto? Tal vez te encuentras en la circunstancia normal de muchas organizaciones: solo hacen una o dos entregas (deploys funcionales) AL AÑO. ¿Cuáles son las razones de esto? Te presento las más importantes.

Pasan muchos días entre el fin de un ciclo (sprint) y el inicio del siguiente

Los frameworks de la filosofía ágil, basados en ciclos, son muy populares. Estos recomiendan dividir el trabajo en ciclos cortos (sprints), en los que se produce un MVP listo para ser utilizado. La idea es que, después de cerrar uno, inmediatamente comenzar el siguiente, incorporando las nuevas User Stories y la retroalimentación del anterior.

Muchos equipos dejan pasar días, o semanas, entre el fin de un ciclo y el inicio del siguiente. Las causas suelen ser:

Realmente no entregaron un MVP sino un producto a testing; el equipo de QA ha regresado la entrega con muchos reportes de defectos para reparar.

No hay autonomía en el equipo para tomar decisiones. Si el responsable de autorizar o dar visto bueno a la planificación está ausente, el trabajo se detiene.

Proceso burocrático. Se requieren muchos pasos para lograr el visto bueno de inicio; por ejemplo, que los requerimientos sean definidos, priorizados y aprobados por varias personas.

Tiempos muertos entre silos funcionales

Si tu equipo está organizado en grupos especialistas (analistas, desarrolladores, testers, etc.), verás que las personas tienen picos de ocupación y desocupación. Esto es porque el trabajo está avanzando linealmente, pero necesita de que todo esté terminado para poder pasar al siguiente grupo; éste tiene que esperar, hacer su parte y enviarla al siguiente, que también está a la expectativa.

Mientras están desocupados, quizás están haciendo otras labores (capacitarse, arreglar defectos, entre otros), pero el progreso del sprint no está avanzando más rápidamente.

Burnout

Imagen: Macrovector para Freepik

Un equipo cansado es improductivo. Algunos señalan que una noche sin dormir (o poco sueño) reduce la efectividad de un Ingeniero en 20%; dos consecutivas la reducen 80%.

La creencia de que trabajar más horas hará que el resultado sea más rápido es contraproducente. Muchos Project Managers y Gerentes insistirán en prolongar las jornadas de trabajo para acelerar el desarrollo, pero con esto solamente lograrán que el equipo se queme. En esta circunstancia, por más horas que acumulen, no podrán producir un buen resultado y la cantidad de defectos y problemas crecerá exponencialmente. 

Pobres técnicas de ingeniería para validar la solución

A lo largo de mi carrera, he observado que una limitante para las entregas continuas es la carencia de técnicas ingenieriles:

Los desarrolladores no saben cómo probar un módulo si otro, u otros, no están terminados. Por esto, deciden usar un enfoque en Cascada para completar todas las partes y poder probar.

El equipo no sabe cómo automatizar las pruebas. Los procesos son manuales y replicar una prueba toma mucho tiempo, sobre todo si falla.

El proceso de instalación de cualquier cambio, actualización o ambiente es completamente manual. Literalmente, copian y pegan archivos de una computadora a otra en lugar de tener scripts o software que haga el deploy por ellos.

Estas limitaciones técnicas postergan una entrega por días, aunque la solución pueda ser escrita en código rápidamente, validarla manualmente alarga el ciclo.

¿Qué hacer?

El conseguir una forma de trabajo, que permita varios deploys al día, requiere de una disciplina constante en el equipo. Si te identificaste con algunas de las razones que describí, hay dos cosas que debes buscar desarrollar en tus equipos: autonomía y excelencia técnica.

Autonomía, para que el equipo pueda tomar todas las decisiones y autoorganizarse de la mejor manera.

Excelencia técnica, para aprovechar todas las ventajas de la tecnología en su propia forma de trabajo.

¡Con gusto te apoyo! Dime de qué manera podemos colaborar.

¡Nos vemos en la siguiente entrega!

Sígueme en redes

Facebook: @SoftwareEngineeringCoach

Twitter: @EdgarTeamCoach

LinkedIn: https://www.linkedin.com/in/edgarfernandezr/

Una organización de software es una persona o grupo, que tiene como fin crear y entregar soluciones basadas en software, las cuales deleitan a sus usuarios y dan valor financiero a los patrocinadores de su desarrollo. Estas organizaciones pueden ser vendedoras del servicio de software a clientes finales o estar dentro de otra empresa, creando el software que se usa en las operaciones diarias.

Mientras más rápido consigan la entrega, más rápido se obtienen también los beneficios e inician más oportunidades de desarrollo. Es lo que, hoy en día, se llama Agilidad y es un resultado que todas las organizaciones deben procurar.

Sin embargo, muchas de ellas descuidan factores importantes, que les impiden obtener los mejores resultados. Estas carencias se observan en sus prácticas de Ingeniería de Software. A continuación te presento cinco red flags en los grupos de desarrollo de software y las razones por las que detienen al equipo para lograr los resultados de elite:

El tiempo de desarrollo es muy largo

La mayor parte del tiempo se dedica a apagar fuegos y arreglar defectos

Moral de equipo baja

Pérdida de oportunidades para aprovechar tendencias tecnológicas y crear nuevos productos, servicios y negocios

No pueden crecer

Muchas veces ocurre que no comprendimos bien los requerimientos de un sistema y ponemos el producto incorrecto en las manos del cliente. Esto, si ya ha pasado mucho tiempo y se ha consumido mucho del presupuesto, puede causar daños irreparables para el cliente, hasta la quiebra de la compañía.

Entender mal los requerimientos es algo completamente normal y a todos nos va a pasar. Lo importante es que nos demos cuenta lo más pronto posible, cuando es fácil y barato corregir.

La validación de requerimientos es el medio que nos permite asegurar el entendimiento de lo que se va a hacer. Depende de lo que quieres validar es la técnica que puedes usar.

Soy Edgar Fernández, hablemos de la validación de requerimientos.

¿Qué es la validación de los requerimientos?

Validar los requerimientos es un paso crucial. Va más allá de leer los documentos, aprobar y recolectar firmas. Aunque esto es necesario a veces, no es lo más importante. 

Validar correctamente los requerimientos es lo que permitirá que el equipo se enfoque en producir y entregar valor frecuentemente. Es el paso en el que encontramos lo valioso y nos deshacemos de lo innecesario.

Hay varias formas de validar un requerimiento. Antes de conocerlas, primero veamos cuáles son las características de un requerimiento excelente.

Características de un requerimiento excelente 

Correcto: el requerimiento provee una función o capacidad que es acorde con una necesidad de los stakeholders. La función está descrita con claridad.

Factible: es posible implementar el requerimiento dentro de las capacidades y limitaciones del sistema y el proyecto. Por ejemplo, tenemos y conocemos el framework de desarrollo para hacerlo y contamos con el tiempo y el presupuesto necesarios.

Necesario: el requerimiento ofrece a los stakeholders el valor de negocio esperado, diferencia el producto de software de otros en el mercado, o es necesario para adecuarse a una regulación externa. En nuestra metodología DINO, estos son los requerimientos Obligatorios.

No ambiguo: primeramente, la definición del requerimiento debe ser comprensible; quien lo lee debe ser capaz de comprender lo que fue definido. Después, el requerimiento debe ser interpretado de la misma manera por dos o más personas.

Verificable: el requerimiento es verificable si podemos definir formas de probarlo. 

Consistente: los requerimientos deben ser atómicos y no entrar en conflicto con otros o contradecirse. Un ejemplo de contradicción es que el sistema de permisos autorice a usuarios a hacer cosas que no están en su tabla de acceso.

Completo: la especificación tiene el detalle suficiente para permitirle al equipo entender lo que se debe desarrollar. 

Ahora que conocemos las características de los requerimientos excelentes, veamos cómo se validan los requerimientos en sus diferentes niveles. 

Validación de requerimientos de negocio

Para validar los requerimientos de negocio, debemos asegurar que estamos alineados con los objetivos del negocio y que la solución propuesta nos conduce a ello.

Podemos validar estos requerimientos en dos momentos:

Al inicio del proyecto, con una prueba de concepto. Esta puede realizarse con un prototipo no funcional, que simula la aplicación final y la mostramos a los usuarios. Los prototipos no funcionales son hechos con tecnología y componentes que no serán parte del producto final, como un prototipo en papel, una presentación interactiva de diapositivas o un andamio rápido como los que hace Ruby on Rails.

Al comenzar el desarrollo, con un MVP. Esperamos que el equipo construya una primera versión del producto completo, con la que se validará la idea de negocio.

En la validación de requerimientos de negocio, aseguramos dos cosas más:

Los criterios de éxito están definidos en términos del negocio y sus objetivos, lo cual nos permitirá medir los parámetros que usaremos para nuestros prototipos.

Los perfiles de los stakeholders están completos. Así, podemos rastrear las diferentes fuentes de origen para corroborar información y obtener la que sea necesaria durante el proyecto.

Validación de requerimientos de usuario

Los requerimientos de usuario pueden ser especificados mediante lenguaje natural y documentos. Sin embargo, en la validación debemos optar por actividades más colaborativas:

Modelación colaborativa de la solución: el equipo, con los usuarios, colaboran frente a pizarras para definir el aspecto de la aplicación, las interacciones, los flujos de información y de pantallas y el comportamiento adecuado.

Mockups y prototipos en papel: el equipo diseña por su cuenta un prototipo, que presenta a los usuarios. Estos lo observan y dan su retroalimentación, la cual es anotada directamente sobre el prototipo con marcas y postits.

Validación de requerimientos no funcionales

En los requerimientos no funcionales, validamos que cada uno se encuentra especificado, con criterios objetivos y medibles.

Los requerimientos no funcionales no pueden ser validados sin la implementación. Sin embargo, esperar hasta que la mayoría del sistema esté construido para poder correr pruebas de sistema tomará mucho tiempo y recursos, y cualquier error será costoso de corregir. Por esa razón, valida los requerimientos no funcionales en etapas tempranas con una prueba de la arquitectura. Para esta prueba, el equipo construye un prototipo funcional, que integra todos los componentes e interfaces de hardware y software con unas pocas funciones y lo despliega en un ambiente similar a producción. Así, observa el comportamiento de la arquitectura en aspectos como carga, seguridad, interoperabilidad, etcétera.

Validar consistencia

Asegura varias de las características de los requerimientos con actividades de revisión e inspección.

Estas consisten en que las personas del equipo revisan minuciosamente las especificaciones con el fin de encontrar inconsistencias y errores. Del mismo modo, una inspección hecha por un panel de expertos, externos al proyecto, permiten validar que la solución es correcta para el negocio y están definidos de la forma adecuada.

Conclusiones

Todo el trabajo de los requerimientos converge en esta actividad. Es donde confirmamos que hemos entendido lo que se debe hacer, o corregimos los errores. La validación nos permite estar seguros que cumpliremos con los objetivos de negocio y los especificamos correctamente; solamente leerlos y firmarlos es insuficiente. 

Cualquier error en los requerimientos debe ser identificado y corregido temprano en el proyecto, cuando es más económico hacerlo. De acuerdo a estadísticas comparativas, corregir un defecto de requerimientos al inicio del proyecto toma 30 minutos en promedio, comparado con un promedio de 17 horas en pruebas del sistema y de aceptación. Hacer estas actividades es una garantía de calidad y satisfacción para el usuario, así que colabora con tu equipo para hacerlo e involúcrense todos.

Hablemos de la Especificación de Requerimientos

Es imposible que el equipo de desarrollo memorice toda la información del producto. A lo largo del proyecto, los miembros del equipo tendrán preguntas, habrá suposiciones y ocurrirán otras situaciones que causarán que haya un entendimiento diferente de lo que debe y no debe hacer el software. No resolver rápidamente las dudas o que haya esa comprensión dispar de los requerimientos nos conducirá a retrabajo, retrasos y descontento entre los stakeholders.

Además, para sistemas ya construidos, es importante que exista información que permita entender cómo y por qué se tomaron las decisiones y qué implica hacerle cambios.

Por eso debemos especificar los requerimientos. Esto significa documentar los acuerdos sobre lo que debe hacer el software y las restricciones existentes.

Ahora, una de las mayores dificultades que enfrentan los equipos de software es saber lo que sí se debe especificar. La información importante que siempre debes registrar en tus especificaciones es la que te permita responder las siguientes preguntas:

¿Qué se va a resolver y por qué es importante hacerlo?

¿En quiénes estamos teniendo impacto?

¿Qué es lo que quieren hacer los usuarios con el software?

¿Qué funciones tendrá el software?

¿Cuál es el ambiente en que estará operando el software?

¿Cómo se usarán las interfaces con otro software y hardware?

¿Hay alguna restricción con la tecnología?

¿Cómo evaluaremos el cumplimiento de los requerimientos no funcionales?

¿A cuáles estándares nos debemos apegar?

¿Qué se va a resolver y por qué es importante hacerlo?

Los requerimientos de negocio, que están en lo más alto de los niveles, marcan la dirección del proyecto, los objetivos que persigue el usuario u organización y una visión de cómo el producto ayudará a alcanzarlos.

Para que los involucrados siempre tengan presente por qué es importante hacer este proyecto, haz un resumen ejecutivo con lo siguiente:

El estado actual y la problemática que se enfrenta.

El estado deseado, expresado en objetivos SMART y criterios de éxito

El enunciado que describe la visión del software

Las funciones principales que ejecutará

Los riesgos del proyecto

Recuerda que esta especificación hablará en el lenguaje del negocio, por lo que debes evitar incluir muchos conceptos técnicos y ser muy concreto en la descripción de la visión.

Por ejemplo, tu especificación de la visión y sus funciones principales puede ser: "Un sistema distribuido en web y dispositivos móviles que permitirá registrar clientes, crear rutas de reparto, notificar los cambios de estado de los pedidos y administrar el almacén". La descripción detallada de cómo se hará cada función se hará, pero es parte de otras especificaciones.

¿En quiénes estamos teniendo impacto?

Todas las decisiones que se toman para el producto tienen un impacto en y reciben influencia de la comunidad de Stakeholders. Debemos establecer un acuerdo de quiénes son y cuál es su rol en la comunidad. En esta especificación, deberás definir:

Quiénes son los usuarios directos

Quiénes son los patrocinadores del proyecto

Quiénes son usuarios indirectos

Quiénes definen reglamentos, estándares y leyes

Los patrocinadores suelen tener el poder de aceptar o rechazar el proyecto, así que establecen los objetivos del mismo. Los usuarios directos utilizarán las funciones del software. Los usuarios indirectos reciben un beneficio aunque no usen el producto (por ejemplo, para una aplicación de GPS, los restaurantes se benefician de que los conductores puedan llegar a sus locales mediante el mapa y el gps). Los definidores de reglas establecen lineamientos a los que el software debe apegarse (como el Gobierno).

El Stakeholder especificado será el nombre del rol, no debes poner el nombre de cada persona. Como "Director", "Gerente", "Empleado", etc. Puedes agregar información adicional, como los intereses principales, actitudes y restricciones que tienen hacia el proyecto.

¿Qué es lo que quieren hacer los usuarios con el software?

Los usuarios quieren completar actividades usando el software. Estas actividades les permitirán lograr objetivos personales o propios de su rol. En la especificación de los requerimientos de usuario, documentamos los procesos y objetivos que quieren completar nuestros usuarios a través del software. Es importante que aquí entiendas que la especificación debe centrarse en Actividades completas del usuario, en vez de funciones individuales del software.

Por ejemplo, un usuario que llamaremos "publicista" quiere diseñar correos electrónicos para enviar promociones a sus clientes. El objetivo es enviar promociones y la actividad es diseñar el correo. El software debe permitirle completar la actividad y lograr el objetivo, que es enviar este correo a los clientes. Un ejemplo de lo que no debes especificar es "agregar imágenes mediante drag-and drop".

La especificación de requerimientos de usuario puede hacerse con la herramienta "User Stories". Si el equipo necesita mayor detalle sobre el proceso (pasos, orden y objetivos intermedios), la herramienta de Casos de Uso le será de utilidad.

¿Qué funciones tendrá el software?

El software debe ofrecer diferentes funciones para permitir que los usuarios completen sus actividades. La especificación de estas funciones nos permite entender qué hará la aplicación en sus diferentes elementos, pero no especifica el cómo lo hará (esta es una decisión de diseño). Retomemos el ejemplo del publicista y el envío de promociones por correo electrónico. Las funciones individuales pueden incluir: Escribir texto, elegir el tipo de fuente, cambiar el tamaño de la fuente, agregar imágenes y videos, alinear el texto, cambiar el color del fondo, guardar un borrador, seleccionar destinatarios, buscar destinatarios registrados, crear un nuevo destinatario, enviar el correo.

En la especificación también es importante describir el comportamiento de las funciones en escenarios de uso normal, error y excepción. Por ejemplo, si ocurre un error de comunicación, ¿el software debe presentar un mensaje o debe reiniciar?

Esta especificación puede hacerse sobre maquetas de pantallas, en las que agregas notas con los comentarios, en prototipos o en documentación detallada con la descripción de cada función.

¿Cuál es el ambiente en que estará operando el software?

El equipo debe ser capaz de comprender el ambiente en que operará el sistema. En el análisis hablamos del Contexto del sistema, y en la especificación describimos:

Las características de los dispositivos en que se ejecutará el software

Las características de las redes de comunicación entre los diferentes dispositivos

Dónde se localizan los usuarios

Cuántos son los usuarios estimados

Cuáles son los días y horarios donde se espera el mayor uso del sistema

El ecosistema de software con el que convive nuestro producto: programas, versiones, sistemas operativos, etcétera.

En este manual técnico, el equipo basará las decisiones de elección tecnológica y entenderá las limitaciones que enfrentará durante el desarrollo.

¿Cómo se usarán las interfaces con otro software y hardware?

Si tu sistema se comunicará con otras aplicaciones de software y hardware, debes especificar:

Cuáles son las aplicaciones

Las características de las interfaces que usarás para comunicarte con ellas (por ejemplo, APIs)

Cómo deben usarse en los diferentes procesos

Problemas conocidos con el uso de las interfaces

Mostrar algunos ejemplos de uso

Donde la especificación ya existe, debes nombrar la referencia y localización donde el equipo puede consultar esta información.

¿Hay alguna restricción con la tecnología?

La información en esta especificación permite que el equipo decida correctamente las herramientas y componentes adecuados para el desarrollo, y prevenga dificultades con la compatibilidad de la aplicación en diferentes dispositivos y programas. En muchas ocasiones, los proyectos inician en ambientes donde ya existe tecnología, la cual no es posible cambiar y es importante saberlo para usarla.

En esta información deberás especificar:

Dependencias con componentes y bibliotecas de terceros, en qué versión se encuentran 

Restricción de recursos, como cantidad de memoria, capacidad de procesamiento o ancho de banda

Resolución de pantallas en dispositivos

Equipos, sistemas operativos y aplicaciones que se usarán y que no pueden ser actualizados

Arquitecturas de hardware y sistemas operativos específicos, que no podemos cambiar.

Incluye también la referencia a manuales de operación, bibliotecas de ayuda, foros de apoyo y toda la información que permita entender y operar la tecnología con limitaciones.

¿Cómo evaluaremos el cumplimiento de los requerimientos no funcionales?

Los requerimientos más susceptibles a presentar ambigüedad son los atributos de calidad, o requerimientos no funcionales. ¿Cómo sabemos que hemos hecho un programa "seguro", "usable", "rápido", "libre de fallos" o "de alto desempeño"?

Especifica estos requerimientos con parámetros objetivos y medibles. Por ejemplo, "El sistema debe responder a 1000 peticiones cada segundo"

Idealmente, incluye escenarios de prueba. Colabora con los expertos en testing para esto.

¿A cuáles estándares nos debemos apegar?

Algunos elementos del sistema deben apegarse a estándares. Por ejemplo, cómo será la interfaz gráfica, cómo se escribirán los mensajes de usuario y su documentación de ayuda, cómo se producirán ciertos mensajes entre los diferentes sistemas, etcétera.

Estos estándares pueden ser externos o definidos internamente, debemos especificar lo suficiente de ellos para que el equipo lo use cuando es necesario.

¿Qué no sabemos todavía?

En varios momentos del tiempo existirá información incompleta respecto al sistema. Es importante hacer un apartado en nuestra especificación de los requerimientos para anotar

La información que obtienes durante el levantamiento de requerimientos es un conjunto de datos muy grande, que en su estado natural es poco útil. Debemos analizarla para entender cuatro cosas respecto a nuestro sistema:

— El contexto en el que se desempeña

— La información que pertenece al dominio del sistema

— Cómo y dónde se procesa la información

— El comportamiento que debe tener el sistema ante diferentes estímulos

¡Acompáñame para conocer en qué consiste el Análisis de los requerimientos!

Contexto

Las aplicaciones de software no realizan su trabajo de forma aislada. Estos interactúan con diferentes actores que se encuentran dentro de un sistema complejo, tales como otras aplicaciones, hardware y dispositivos, redes y ubicaciones remotas. A esto le llamamos El Contexto del sistema, y en él encontraremos información importante para definir nuestros requerimientos no funcionales.

Cosas que debes buscar para definir el contexto:

Otras aplicaciones y software que se está usando. Los usuarios pueden mencionar estos otros programas o descubrirlos en los manuales o documentos que te faciliten. Debes registrar cuantas instancias hay y si se encuentran en varias versiones.

Ubicaciones remotas. ¿Dónde se encuentran geográficamente los usuarios o los otros sistemas que interactúan? En esto, debes prestar atención para entender cómo se comunican, si existe una infraestructura de red de telecomunicación actualmente o será necesario desarrollar una. Debes comprender cómo es el acceso a cada lugar, geográficamente, para entender cómo será la comunicación con estos puntos remotos y no suponer ni asumir que la infraestructura de internet funcionará igual en todas partes.

Hardware y dispositivos. ¿Qué hardware especializado se usa e interactuará con nuestro software? ¿Qué dispositivos emplearán tus usuarios para acceder al sistema? ¿En qué versiones se encuentran? ¿Cuál es la variedad de dispositivos, sistemas operativos y capacidades que tienen? ¿Cuántos son y quiénes los usan? ¿Cuál es la posibilidad de cambiarlos por otros? Esta información te permitirá entender, más adelante, cuáles son las decisiones de tecnología que deberás tomar. Ten en cuenta que tu sistema deberá ser adecuado para el contexto y no obligar a los usuarios a que se adapten al sistema. 

Entender el contexto es muy importante y no se debe dar por hecho. Dale un tiempo a tus actividades de análisis para definirlo.

Dominio de la información

Los conceptos de información son entendidos de diferente forma en los distintos dominios. Piensa por ejemplo en un "Cliente"; en el contexto de los negocios, es alguien que consume productos y servicios, del cual nos interesa conocer su nombre, datos demográficos y otros atributos; pero en el dominio la informática, un "Cliente" es un dispositivo o programa que se comunica con un servidor para consultar información o ejecutar funciones de hardware; de este cliente, nos interesa conocer su origen, dirección, capacidad, permisos, entre otros atributos.

Así pues, debemos definir las entidades de información que se usarán en nuestro software y las relaciones entre ellas; debemos hacer esto de acuerdo al dominio en el que están nuestros usuarios.

El análisis del dominio es un diccionario de datos, que nos permite entender qué significa cada concepto o sustantivo que se usa en el dominio. No es un diccionario para una base de datos todavía, sino una descripción de alto nivel que nos permite entender qué significa, para un usuario, un concepto que él utiliza con frecuencia y cómo se relaciona con otros conceptos. Esto te permitirá encontrar los procesos en los que se origina y transforma cada parte de la información.

Por ejemplo, piensa nuevamente en el Cliente y en una Factura. Ambos estarán definidos por un conjunto de datos que les pertenecen y que esperaremos encontrar en el software. Ahora, ¿cómo se relacionan ambos conceptos? Una factura es creada cuando un cliente completa una compra, así que encontramos una relación entre ambos y un proceso en el que la información de ambos está involucrada. Haz lo mismo con los diferentes conceptos de información que aparecen en el dominio.

Procesamiento

La información en nuestro software se crea y se transforma a través de varios procesos. En el análisis de los requerimientos, debemos definir claramente cómo y dónde ocurren las actividades de procesamiento de la información. Deberás apoyarte en tu análisis del Contexto, pues una entidad de información podría estar en diferentes partes del sistema. Por ejemplo, piensa en un concepto como Usuario, cuya información utilizas para autorizar el acceso y conocer los permisos que tiene. Piensa que tu aplicación utiliza otro software para autenticar al usuario, como Facebook Login. Tanto tu aplicación como Facebook tendrán la información del Usuario, pero se usará o procesará en actividades diferentes en lugares diferentes. Facebook la usará para indicar si el usuario es válido o no, y tu aplicación recibirá esa información. Tu aplicación cambiará los permisos del usuario, y esa información no se intercambiará con Facebook, entre otros actividades que modelarás y definirás en esta parte de tu análisis.

Comportamiento

El comportamiento del sistema, en el análisis de requerimientos, no hace alusión a algo como la Usabilidad o la User Experience (UX), sino a la descripción de cómo se deberá comportar el sistema ante ciertos estímulos y en ciertos estados. En este análisis, nos interesa definir escenarios generales de funcionamiento correcto, errores y excepciones. Por ejemplo, si la información es completa y el usuario solicita guardarla, el sistema debe transitar a un estado de éxito; si la información es incompleta ante el mismo estímulo, el sistema debe permanecer en el mismo estado y no permitir que la información se guarde. También, debemos definir cuál debe ser el comportamiento ante eventos como alta demanda, alta carga o ancho de banda limitado. Como otro ejemplo, definir que si el servidor tarda más de 20 segundos en completar una petición, el cliente debe cancelar la transacción e iniciar una nueva.

En el análisis del comportamiento, también es importante revisar cómo es que los usuarios interactuarán con tu aplicación. Entiende como usuarios a las personas, al hardware y a otro software. Esto es, cuál es el tipo de acciones que hacen tus usuarios: peticiones mediante texto, peticiones mediante una interfaz gráfica, carga de archivos, descarga de archivos, uso de interfaces de hardware y software y procesos automáticos.

Conclusión

El análisis de requerimientos te permite entender el sistema en alto nivel. No debe ser una especificación detallada, sino un modelo concreto de los participantes, la información, los procesos existentes y el comportamiento esperado. Hay varios recursos y herramientas que se usan para hacer el análisis: Diagramas de flujo, diagramas de clases, diagramas de secuencias, diagramas de flujo de datos, diagramas de secuencia, entre otros. Usa los que le brinden información valiosa al equipo y desecha todo lo que no. Evita, en medida de lo posible, la sobredocumentación y el detalle exagerado. Mi recomendación es: un diagrama de contexto, un modelo de dominio con un diagrama de clases, diagramas de actividad para representar el procesamiento de información y diagramas de secuencia para el comportamiento.

Al hacer esta actividad, ahora sí podrás describir, brevemente de qué se va a tratar el sistema que se construirá:

Es una aplicación que interactúa con estos actores, procesa estas entidades de información, con actividades que ocurren aquí y allá y debe comportarse así ante estos estímulos.

¡Verás que no es necesario escribir una novela de García Márquez para describirlo!

Los ingenieros de software solemos cometer el error de esperar que los usuarios nos den sus requerimientos; ellos nunca lo podrán hacer, porque no están entrenados en desarrollo de software, pero insistimos en hacer preguntas como "¿Qué es lo que quieres?", "¿Usamos tal herramienta o tal otra?", "¿Será en plataforma móvil, web o de escritorio?", "¿Lo quieres responsivo?". 

Ya que estamos en eso, también debemos dejar de enojarnos cuando nos dicen cosas como "quiero que sea bonito y rápido".

La brecha que existe entre el vocabulario y entendimiento entre usuarios y desarrolladores debe achicarse, en vez de agrandarse. Los usuarios nos hablarán con su vocabulario habitual, en el contexto que conocen; nuestra labor es entender eso para transformarlo en los requerimientos que guiarán la construcción de un gran software. El primer paso es recolectar la información.

Identificar el problema

Descubrir las necesidades de los involucrados en el software es un reto. Es un proceso analítico y colaborativo con actividades para encontrar y definir las necesidades.

Los usuarios no pueden definir con precisión técnica cuál es el software que necesitan, por lo tanto, es labor de los ingenieros conseguir lo siguiente:

Tener un ambiente adecuado para facilitar la exploración y comunicación

Entender las actividades de los usuarios. 

¿Qué actividades quiere completar el usuario y cómo podemos ayudar?

¿Cuáles son las aspiraciones del usuario y cómo podemos ayudar a que las alcance?

¿Qué relación esperan que establezcamos con ellos?

¿Cuál es el valor que realmente esperan recibir?

Entender cómo toman decisiones

Entender lo que consideran innecesario, obsoleto o ineficiente.

Para esto, debemos trabajar primero en recolectar la información y resistir la tentación de diseñar el software hasta que has entendido el problema. En este proceso, seleccionamos de entre un conjunto de técnicas las que mejor se adapten a nuestro proyecto y a nuestros usuarios.

Técnicas para recolectar información

Antes de comenzar con cualquier intento de proponer una solución de software, debemos reunir la información suficiente para conocer, cuando menos, el contexto y las características principales de nuestros usuarios y su entorno. Este proceso puede durar unas pocas semanas, y en ellas recolectamos información.

Existen múltiples técnicas para descubrir las necesidades de usuarios de software

Colaborativas: Interacción con los usuarios

Independientes: Descubres información por tu cuenta

Algunas de las técnicas son:

Entrevistas

Talleres

Focus groups

Observación estructurada del entorno

Encuestas

Análisis de documentos

Evaluación heurística 

No uses solamente una, diferentes usuarios preferirán alternativas distintas

Detallemos cada una

Entrevistas

Las entrevistas son actividades colaborativas. El propósito es reunirte directamente con los usuarios, ya sea individualmente o en grupos pequeños, para preguntarles directamente y conocer su información.

Las entrevistas tienen un objetivo y propósito definidos, que se plasma en un cuestionario o una guía, y una duración, establecida en una agenda.

En el proceso de la entrevista debes presentarte, revisar la agenda con los asistentes, presentar los objetivos y resolver las preguntas iniciales. Tu objetivo es escuchar, así que hazlo activamente. Haz la pregunta y deja que los asistentes sean quienes hablen; solamente debes intervenir para aclarar algo o mantener el enfoque de la entrevista.

Esta técnica es útil cuando has identificado a los usuarios más representativos de un grupo y estos tienen poco tiempo para reunirse. Así que aprovecha todo el tiempo con ellos y prepara una buena lista de preguntas.

Talleres

Son reuniones formales y estructuradas, en las que un grupo de personas y expertos trabajan juntos. En esta colaboración, se usan diferentes herramientas para crear un modelo de la situación actual e identificar las necesidades a cubrir.

Un taller involucra a diferentes tipos de usuarios del sistema que se quiere hacer, para entender sus distintos puntos de vista. Los talleres son conducidos por un facilitador, usualmente el analista de requerimientos, y la información es registrada por una persona. 

Las actividades del taller son diversas, dependiendo del objetivo que tiene. Se debe cuidar el tiempo, para que las tareas y discusiones se mantengan dentro del enfoque y todos se mantengan involucrados. Se deben discutir ideas y no personas. Es importante que se programen descansos, pues los talleres suelen durar varias horas.

El facilitador debe leer el lenguaje corporal y otras pistas que hacen que algunos dejen de participar (Otros descalifican mis ideas, no las toman en serio) o no quieren interrumpir el trabajo.

Los talleres son una buena alternativa cuando los usuarios que nos pueden dar información tienen restricciones de calendario y solo los podrás consultar una sola vez.

Focus Group

Es una reunión con un conjunto seleccionado de los usuarios, que llamamos Champions. A diferencia del taller, el grupo de enfoque explora actitudes, preferencias y necesidades de los usuarios escuchándolos de viva voz. La información es subjetiva, más que cuantitativa.

Los focus group son muy efectivos para validar ideas que se parecen a soluciones ya existentes, por lo que se seleccionan usuarios que han usado productos similares y obtenemos de ellos las necesidades o cosas que no han podido ser cubiertas por las otras soluciones.

El facilitador de la reunión debe cuidar que se mantenga el enfoque, pero sin influir en las opiniones. No debe conducir las respuestas hacia una tendencia particular, sino mantenerse neutral.

Una característica importante del Focus Group es que la sesión debe ser grabada, por lo que debes obtener el consentimiento expreso de los asistentes para hacerlo.

Observación estructurada del entorno

Esta es un tipo de actividad independiente, pues no involucramos ni interactuamos con los usuarios. Algunos usuarios pueden tener dificultades para describir su trabajo o las actividades que hace, así que en vez de preguntarle directamente “cuál es el trabajo que hace”, lo observamos mientras lo realiza.

La necesidad de hacer observaciones suele identificarse en las entrevistas, cuando los usuarios no pueden describir detalladamente sus actividades. Estas son tan rutinarias que ya no piensan en ellas y las hacen automáticamente, así que no ponen atención al proceso. En casos así, acompañamos a los usuarios para observarlos mientras trabajan.

Para esto, se seleccionarán las actividades importantes para observar y a los usuarios. Es recomendado seleccionar a varios tipos de usuario. La observación se hace en el ambiente donde el usuario realiza su actividad normalmente; es importante no interrumpirle para obtener la mejor información acerca de qué hace y cómo lo hace; también, registra lo que ves: las herramientas que usa, la disposición del área, los objetos que están en ella y las personas con quienes interactúa. Esto permitirá entender mejor el contexto y el vocabulario del usuario. Limita la observación a un máximo de dos horas.

Encuestas

La encuesta consiste en una lista de preguntas para obtener información de un grupo grande de personas, principalmente cuando es difícil reunir a todos los usuarios o se encuentran dispersos en áreas geográficas específicas. Esta técnica es económica y suele ser usada como entrada para otras técnicas.

Las encuestas utilizan preguntas cerradas con opciones, comúnmente, y las respuestas son mutuamente excluyentes para poder diferenciar la opinión de las personas; en ocasiones, las respuestas incluyen la opción "otro", para recolectar más información y opiniones. No se recomienda hacerlo con todas las preguntas. Las opciones pueden usar escalas; en este caso, deben ser consistentes en toda la encuesta y no cambiarlas entre ellas (por ejemplo, escalas numéricas todas en el mismo rango, o las opciones de opinión "bueno, malo, excelente" iguales para todas las preguntas que la usen). 

Análisis de documentos

Es la Revisión sistemática de documentos existentes (lecciones aprendidas, manuales, procesos de negocio, bibliotecas de problemas)

La investigación reduce el tiempo de otras reuniones y Puede revelar información que la gente no te dice. Aunque Se corre el riesgo de que los documentos no están actualizados

Evaluación heurística

Esta técnica consiste en examinar un producto existente, similar al sistema que se quiere desarrollar. Este producto puede ser el sistema actual de los usuarios o un producto del mercado, que es parecido. El objetivo es evaluar qué tan bien funciona el producto y sus oportunidades de mejora; ambas cosas se documentan y presentan a los usuarios, con el fin de obtener su opinión y sugerencias. 

Para esta técnica, es necesaria experiencia y comprensión de las buenas prácticas de diseño y desarrollo de sistemas.

Conclusión

Los usuarios del software no podrán definir el producto que quieren. Nuestro trabajo, como ingenieros de software, es darles una solución, pero no podemos hacerlo si entender las necesidades reales de los usuarios:

¿Qué actividades quiere completar el usuario y cómo podemos ayudar?

¿Cuáles son las aspiraciones del usuario y cómo podemos ayudar a que las alcance?

¿Qué relación esperan que establezcamos con ellos?

¿Cuál es el valor que realmente esperan recibir?

Hay tres cosas que debes entender para tener buenas prácticas en tus requerimientos:

Qué son los Stakeholders

Los niveles de requerimientos

Los tipos de requerimientos

Comprender bien esto, te permitirá responder fácilmente a la pregunta: ¿Cuáles son las siguientes user stories a desarrollar? 

Identifica a tus Stakeholders

Un sistema de software impacta a diferentes personas y grupos. Entre esos individuos están tus usuarios, pero no son los únicos a los que debes considerar.

A toda la comunidad de interesados o impactados por el sistema le llamamos Stakeholders y representan la voz de las diferentes necesidades que se deben satisfacer con el software.

Entre tus stakeholders puedes encontrar:

Patrocinadores del proyecto: quienes aportan los recursos para realizar el proyecto, o apoyan con entusiasmo su realización; contribuyen en la gestión de recursos

Usuarios directos: individuos que utilizarán las funciones del software con frecuencia, para completar sus tareas habituales. En esta categoría encontramos también otros dispositivos o sistemas, que están empleando nuestro producto con frecuencia.

Usuarios indirectos: individuos, organizaciones y otros sistemas que reciben un beneficio con el uso de nuestro producto. Por ejemplo, para una aplicación de mapas y GPS, un usuario indirecto es un negocio, que recibe el beneficio de que la aplicación lleve a personas a su local. En esta categoría también encontramos a quienes se benefician con al información producida por nuestro producto, ya sea que la puedan consultar periódicamente o que acceden a ella de alguna forma.

Definidores de reglas de negocio: Individuos y entidades que establecen reglas, a los cuales el sistema se debe ajustar. Estos stakeholders podrían no utilizar el sistema, pero influyen en su comportamiento. Incluso, pueden ser externos, como instituciones de gobierno, reguladores u otras organizaciones.

Photo by Kaboompics .com from Pexels

Todos los usuarios y stakeholders consideran que sus necesidades y requerimientos son prioritarios e importantes, que todos deben ser incluidos en la solución final. Sin embargo, no es así: hay formas de encontrar los requerimientos que son importantes y prioritarios.

Para ello, te enseñaré el método DI NO

Tipos de requerimientos

DINO son las siglas de los tipos de requerimientos. Cada vez que encontramos uno debemos clasificarlo según lo siguiente:

Deseables: Requerimientos estéticos, agregan alguna conveniencia en la usabilidad o en el ahorro de pasos. También los conocemos como “nice to have” y son los que se anotan para hacerse si tenemos el tiempo para hacerlos

Importantes: Son requerimientos de gran valor, pero pueden esperar. Los requerimientos importantes se convierten en obligatorios con el tiempo, pero en el momento de registrarlos por primera vez son los que se negocian por otros prioritarios.

No implementables: Requerimientos deseables por algunos usuarios, pero agregan poco valor con un alto costo de desarrollo. Estos requerimientos suelen ser para muy pocos usuarios, o uno o dos son los que perciben el valor, pero la mayoría no. Suelen estar fuera de la línea de los objetivos del producto.

Obligatorios: Los requerimientos que le dan sentido al producto. Sin ellos, el producto no tiene razón de ser o se vuelve inútil. Estos requerimientos aportan el máximo valor, aún cuando su implementación tenga un alcance inicialmente pequeño.

Photo by cottonbro from Pexels

Como un ejemplo:

Un requerimiento obligatorio es que puedas guardar y editar la información de los clientes. Importante que puedas guardar y editar varios registros a la vez, en lugar de hacerlo uno por uno. Deseable, el poder editar en línea los registros (sin presionar el botón editar) y No implementable el que haya una animación con sonido cada vez que guardas un registro.

Pero, te estarás preguntado, ¿cómo sé cuáles serán los obligatorios y cuáles los demás? Para eso nos ayudan los niveles de requerimientos.

Niveles de requerimientos

Los requerimientos están en una jerarquía:

De negocio: Representan la razón de ser del producto de software. Aquí se plantean los objetivos a gran escala para alcanzar. Nos indican la dirección que debe tomar el proyecto y contestan la pregunta ¿Qué se debe hacer?

Los proveedores de estos requerimientos son los stakeholders del negocio, los tomadores de decisiones y los patrocinadores.

De usuario: Son las actividades de los usuarios, que se deberán incluir en el software. Estos describen los objetivos de trabajo que persigue el usuario y la forma de cumplirlos. Los procesos o actividades que se modelan en este nivel deben estar en línea con los objetivos planteados en los requerimientos del negocio. Suelen contestar a la pregunta ¿Para quién es el software?

De software: Describen lo que el software debe de hacer para incluir y completar las actividades de los usuarios, además de otros atributos del sistema, que conocemos como Requerimientos no funcionales. Estos describen con precisión las funciones que se deben incluir, y responden a la pregunta ¿cómo debe hacerse?

 

En todos los niveles encontraremos los tipos DINO; la forma de obtener los prioritarios y obligatorios será incluir los que se ayudan a alcanzar los objetivos de negocio (primer nivel). Todos los que no aportan a los objetivos serán clasificados como No implementables, y los que apoyan indirectamente son Deseables. 

Una observación: todos los requerimientos no funcionales son obligatorios. No los podemos omitir.

Conclusión

Para poder priorizar tus requerimientos, primero debes identificar a los stakeholders. Es una de tus primeras tareas.

Después, obtener los requerimientos y saber en qué nivel de la jerarquía se encuentran. 

Basándonos en esto, podremos clasificarlos por prioridad e importancia.

Así, podrás tener tu backlog siempre ordenado y con la información suficiente.

Photo by Andrea Piacquadio from Pexels

¡Hola! Bienvenido a la serie "Cómo deleitar a tus usuarios". En esta serie de videos hablaremos de Ingeniería de Requerimientos, un conjunto de actividades muy importantes, que nos permiten construir soluciones que deleitan a nuestros usuarios.

Esta es una serie de siete videos. En este primer video, te hablaré de qué son y en qué consisten las actividades de requerimientos, de su importancia y el propósito que tiene hacerlo.

Visita mis redes:

Facebook: https://www.facebook.com/SoftwareEngineeringCoach/

Twitter: https://twitter.com/EdgarTeamCoach

Web: https://www.edgarfernandez.com

Conoce nuestro seminario para ejecutivos aquí: https://www.aprend-is.net/seminario-adaptabilidad

Mi curso de Estimación: https://www.udemy.com/course/estimacion-de-proyectos-de-software-de-novato-a-ninja/?referralCode=6C624A3632E6B57E501E