miércoles 5 de marzo de 2008

Inteligencia interconectada en red, era de oportunidades

No es sólo la interconexión en red de la tecnología, sino de la de los seres humanos mediante la tecnología. No es una era de maquinas inteligentes, sino de seres humanos que, mediante redes, combinan su inteligencia, conocimiento y creatividad para conseguir avances en la creación de riqueza y el desarrollo social.

Éste cambio esencial en el modo de canalizar la capacidad de innovación y creación de valor que tienen las empresas, la oleada de colaboración masiva ofrece enormes oportunidades. Las empresas pueden salir de sus cuatro paredes para sembrar las semillas de la innovación y recoger una abundante cosecha. De hecho, las empresas que entablan unas relaciones ágiles y basadas en la confianza con colaboradores externos están bien posicionadas para construir unos ecosistemas empresariales muy activos que crean valor con mayor eficacia que las empresas organizadas jerárquicamente.

Esta nueva forma de innovación y creación de valor se denomina producción entre iguales y describe lo que ocurre cuando masas de personas y empresas colaboran abiertamente para potenciar la innovación y el crecimiento en sus sectores. En su forma más pura, constituye una manera de producir bienes y servicios basada completamente en la autoorganización y en comunidades igualitarias de individuos que se unen de forma voluntaria para producir un resultado compartido. En realidad, la producción entre iguales combina elementos de jerarquía y autoorganización, y se fundamenta en principios meritocraticos de organización; en otras palabras, los miembros más cualificados y con más experiencia asumen el liderazgo y ayudan a integrar las aportaciones de la comunidad.

En muchas comunidades de producción entre iguales, las actividades productivas son voluntarias y no reportan beneficios monetarios. Son voluntarias en el sentido de que las personas hacen contribuciones a esas comunidades porque quieren y porque pueden. Nadie ordena a un trabajador que publique un artículo en Wikipedia o que aporte código al sistema operativo Linux. No reportan beneficios monetarios porque la mayoría de los participantes no se les paga por las contribuciones que hacen (al menos, no en forma directa) y los individuos determinan si quieren producir, qué producen y qué cantidad quieren producir. Sin embargo, que la gente no reciba un dinero por participar en producción entre iguales no implica que no se beneficien de otras maneras.

Por lo pronto, la producción entre iguales aprovecha motivaciones voluntarias de una manera que propicia la asignación de la persona adecuada a la tarea adecuada con mayor eficacia que las empresas tradicionales. La razón es la auto selección.

Las personas participan en comunidades de producción entre iguales por una amplia variedad de motivos intrínsecos y de interés propio, ya sea por diversión, altruismo, obtener status dentro de la comunidad para aspirar crecimiento profesional, etc etc.
Este tipo de producción funciona cuando se cumplen tres condiciones mínimas:

  1. El objeto de la producción es información o cultura, una circunstancia que mantiene a un nivel bajo el coste de participación para las personas que contribuyen,
  2. las tareas pueden descomponerse en porciones reducidas que los individuos pueden aportar con pequeños incrementos y con independencia de los demás productores (a saber, entradas de una enciclopedia o componentes de un programa informático) y
  3. el coste de combinar esas porciones para obtener un producto final terminado, incluyendo aquí el liderazgo y los mecanismos de control de calidad, debe ser bajo.
En definitiva, la producción entre iguales funciona porque pueden hacerlo.

Esto es lo que está sucediendo ahora, no sabemos cómo evolucionará, la velocidad y la forma que tomará. De seguro, aportará muchos beneficios para todos y no será una bala de plata universal.

(Nota: Varias partes han sido tomadas del libro Wikinomics de Don Tapscott)

martes 26 de febrero de 2008

Buenas practicas - lecciones aprendidas en la especificaciones de requerimientos

Definición
Un requerimiento es la condición o capacidad que necesita el usuario para resolver un problema o alcanzar un objetivo. Es la condición o capacidad que debe satisfacer o poseer un sistema o una componente de un sistema para satisfacer un contrato, un standard, una especificación u otro documento formalmente impuesto [IEEE610].

Recomendaciones / sugerencias para el documento de requerimientos
"
La experiencia es la mejor escuela para escribir requerimientos adecuados"

- Wiegers
  • Oraciones con gramática, sintaxis y puntuación adecuada
  • Oraciones cortas y directas
  • Voz activa, imperativos: "el sistema debe hacer algo" y no "algo debe hacerse"
  • Usar los términos consistentemente y de acuerdo a la definición del glosario
  • No use sinónimos: no varíe el lenguaje para atraer al lector
  • Descomponga un requerimiento de alto nivel en detalle suficiente para clarificarlo y eliminar la ambigüedad
  • Use una forma consistente de redactar: "el sistema debe"+verbo
  • Especifique la acción que dispara el comportamiento del sistema
  • Evite el "debería", "podría" y condicionales
  • En "El usuario debe..." especifique al usuario: "El cajero debe..."
  • Presente información visualmente, las masas de texto no ayudan
  • Enfatice la información más importante
Términos ambiguos y su modificación
























Término ambiguoFormas de mejorarlo
aceptable, adecuadoDefina qué constituye la aceptabilidad y cómo el sistema la juzga
tanto como sea practicableNo deje en manos de los desarrolladores determinar qué es practicable.
al menos, como mínimo, no más que, no excederEspecificar los valores mínimos y máximos aceptables
EntreDefina si los puntos extremos están o no en el rango
depende deDescriba la naturaleza de la dependencia. ¿Otro sistema provee input a este sistema, debe instalarse otro sistema antes que su sofwtware sea ejecutado o su sistem depende de otro para ejecutar algún cálculo o servicio?
EficienteDefina como el sistema usa eficientemente recursos, cuan rápidamente ejecuta operaciones o como es de fácil para la gente usarlo
rápido, velozEspecifique la mínima velocidad aceptable a la que el sistema ejecuta alguna acción
FlexibleDescriba las formas en la que el sistema debe cambiar en respuesta a condiciones cambiantes o necesidades del negocio
mejorado, mejor, más rápido, superiorCuantifique cuanto mejor o más rápido constituye una mejora adecuada en un área funcional específica
incluyendo, incluyendo pero no limitado a, y así sucesivamente, etc. tal comoLa lista de ítems debería incluir todas las posibilidades. De otro modo no podría usarse para diseño o testeo
maximice, minimice, optimiceEstablezca los valores máximo y mínimo aceptable para algún parámetro
normalmente, idealmenteDescriba también el comportamiento del sistema bajo condiciones anormales o no-ideales
OpcionalmenteClarifique si se trata de una opción del sistema, del usuario o del desarrollador
razonable, cuando es necesario, donde sea apropiadoExplique como se produce este juicio
RobustoDefina como el sistema maneja las excepciones y responde a condiciones operacionales no esperadas
transparente, suave, grácilTraduzca las expectativas del usuario en caracterísrticas observables del producto
VariosEstablezca cuantos o proveea las cotas mínima y máxima del rango
no deberíaEstablezca los requerimientos positivos, diciendo que hará el sistema
estado del arteDefina qué significa
SuficienteExplique con cuanto de algo se establece la suficiencia
soporte, disponibleDefina exactamente que funciones debe ejecutar el sistema que soporten alguna capacidad
Amistoso, fácil, simpleDescriba las características del sistema que alcanzarán las necesidades de uso del usuario y las expectativas de usabilidad

Características de una buena especificación de requerimientos - factores de calidad de una especificación de requerimientos
  • Correcta
  • No ambigua
  • Completa
  • Consistente
  • Rankeada / Clasificacion por importancia
  • Verificable
  • Modificable
  • Traceable
  • Independiente del diseño
  • Concisa / Breve
  • Organizada
  • Anotada
Correcta
Una especificación de requerimientos es correcta "sí y sólo si todo requerimiento formular en ella es uno que el software debe satisfacer"

No ambigua
Una especificación de requerimientos no es ambigua "sí y sólo si todo requerimiento formulado en ella tiene una sola interpretación".
Ello requiere que al menos cada característica del producto final se describa con un único término.
Debe evitarse toda afirmación ambigua:
"Todos los clientes tienen el mismo campo de control"
"Todos los archivos son controlados por un bloque de control de archivo"
El lenguaje natural es fuente de ambigüedades.

Completa
Una especificación de requerimientos es completa "sí y sólo si incluye los siguientes elementos:
Todos los requerimientos significativos que impone al software
Todas las respuestas del software a todas las clases posibles de inputs
Todas las etiquetas y referencias a las figuras, tablas y diagramas de la especificación de requerimiento y las definiciones de los términos y unidades de medida"
Este atributo es el más difícil de definir y detectar violaciones, por lo que hay que dedicarle tiempo y trabajar a conciencia.

Consistente
(Hablamos de consistencia interna)
Una especificación de requerimientos es internamente consistente sí y sólo si ningún subconjunto de requerimientos está en conflicto.
Tipos de inconsistencias
Comportamiento conflictivo: dos partes especifican diferentes y conflictivos: estímulos para inducir una respuesta, respuestas a un mismo estímulo y condición.
Términos conflictivos: dos términos diferentes se utilizan para definir lo mismo
Características conflictivas: dos partes requieren rasgos contradictorios
Inconsistencia temporal: dos partes requieren comportamientos temporales contradictorios.

Rankeada / Clasificacion por importancia
Que cada requerimiento tenga una identificación que indica la importancia. Se los puede clasificar, por ejemplo, en "Esenciales" (el software no es aceptable sin éstos), "Condicionales" (pueden mejorar el software, pero no es inaceptable si está ausente) u "Opcionales" (esa función puede o no estar presente).
Que cada requerimiento tenga una identificación de la estabilidad. La estabilidad se puede expresar en términos del número de cambios que se esperan.

Verificable
Todo requerimiento incluido en ella es "verificable", es decir que exista un proceso finito y efectivo en costo con el que chequear que el sistema a construir satisface el requerimiento.
En general los requerimientos ambiguos no son verificables.
Ejemplos de requerimientos no verificables:
- El producto debe trabajar bien
- El producto debería tener una buena interfase
- El programa no debe entrar nunca en un loop infinito
- El output del programa debe estar habitualmente dentro de los 10 segundos
Ejemplos de requerimientos verificables
- A partir de producido el evento X, se obtendrá el output del proceso: debe estar dentro de los 20 segundos el 60% de las transacciones y dentro de los 30 segundos el 99% de las transacciones.
- Algunas de las fuentes de no verificabilidad son las ambigüedades, problemas no resolubles y cantidades no medibles.

Modificable
Cualquier cambio puede hacerse: fácilmente, manteniendo la "completitud" y consistentemente.
Requiere tener una organización coherente y fácil de usar, no ser redundante.

Traceable / Rastreable
Si es claro el origen de cada requerimiento y facilita la referencia de cada requerimiento en futuros desarrollos o mejoras de la documentación.
Tipos de rastreabilidad: hacia delante y hacia atrás.
Beneficios:
- Importancia en operaciones y mantenimiento
- Claridad del origen de cada requerimiento
- Facilita negociar los requerimientos
- Facilita referenciar cada requerimiento individual establecido en la especificación de requerimientos

Independiente del diseño
No debe implicar una arquitectura específica de software o algoritmo, dado que no se debe limitar a esta instancia de una única alternativa de diseño. Hay excepciones aceptables.

Concisa / Breve
A igualdad de cualidades, la mejor es la mas corta

Organizada
Una especificación de requerimientos es organizada si los requerimientos que contiene son fácilmente localizables

Anotada
Las anotaciones a una especificación de requerimientos proveen guía al desarrollo de la organización del documento. Hay dos casos de anotaciones requeridas: necesidad y estabilidad

Tipos de requerimientos según las capacidades o características

Necesidades
: Capacidades o características requeridas al sistema de software para resolver el problema. Posibles formas:
Funcionalidad
Comportamiento del sistema
Performance, tiempo de respuesta
Necesidades operacionales
Características de las interfaces de hw y sw.

Deseos: Capacidades o características de un sistema de software deseadas por los stakeholders, no son imprescindibles para resolver el problema. Posibles formas:
Funcionalidad extra
Comportamientos específicos del sistema
Características de la interfase del usuario
Algoritmos particulares

Expectativas: Capacidades o características del sistema de software esperadas por los stakeholders. A menudo no explícitas, y por ello se pierden fácilmente. Posibles formas:
Aspectos específicos del dominio, funcionalidad
Confiabilidad
Características de la interfase con el usuario
Características de performance

Referencias
[IEEE610] Definición IEEE-Std-610 (1990)