rhernando.net

procrastinando en la red

Toma de Requisitos

Introducción

Los requisitos son una especificación de lo que debe implementarse. Son descripciones de cómo debe comportarse el sistema, o de una propiedad o atributo del sistema. Pueden ser una restricción en el proceso de desarrollo del sistema.

Tipos de requisito

  • Requisito de negocio
    Objetivo de negocio de alto nivel de la organización que construye un producto o de un cliente que lo adquiere.
  • Regla de negocio
    Política, directriz, estándar o regulación que define o restringe algún aspecto del negocio. No es un requisito de software en sí mismo, sino el origen de varios tipos de requisitos de software.
  • Restricción
    Limitación impuesta a las opciones disponibles para el desarrollador en el diseño y construcción del producto.
  • Requisito de interfaz externa
    Descripción de una conexión entre un sistema y un usuario, otro sistema o un dispositivo.
  • Característica
    Una o más capacidades del sistema lógicamente relacionadas que proveen valor a un usuario y están descritas mediante un conjunto de requisitos funcionales.
  • Requisito funcional
    Descripción de un comportamiento que un sistema presentará bajo determinadas condiciones.
  • Requisito no funcional
    Descripción de una propiedad o característica qeu un sistema presentará o una restricción que debe respetar.
  • Atributo de calidad
    Tipo de requisito no funcional que describe un servicio o característica de rendimiento de un producto.
  • Requisito de sistema
    Requisito de alto nivel de un producto que contiene múltiples subsistemas, que pueden ser todos software o software y hardware.
  • Requisito de usuario
    Objetivo o tarea que específicos tipos de usuario debe conseguir con un sistema, o un atributo de producto deseado.
    Los requisitos de usuario se pueden representar mediante casos de uso, historias de usuario y tablas evento-respuesta. Idealmente los propios usuarios deberían proporcionar esta información.

Gestión de Proyectos

Gestión de Personas

  • Reuniones semanales individuales
  • Respetar su espacio y su tiempo
  • Tomar notas
  • Encajar a cada persona en su rol
  • Proveer feedback (retroalimentación)

Cómo motivar al equipo

  1. Empezar por uno mismo; para motivar a otros se debe estar motivado y notarse en todas las situaciones.

  2. Siempre compartir la información que se tenga acerca del proyecto, el equipo debe hacer suyo al proyecto y conocer las circunstancias que le rodean y sus limitaciones, esto también puede llevar a que el equipo tome iniciativas para hacer sugerencias sobre nuevas formas de mejorar el proyecto.

  3. Mantener un ambiente amigable. Las fechas y compromisos deben ser un reto, de tal forma que el equipo se sienta orgulloso de alcanzarlas, en lugar que sean una obligación impuesta.

  4. Señalar los hitos del proyecto. Se puede preparar una celebración especial al alcanzarlos.

  5. Mostrar aprecio por los miembros de su equipo. Al comunicarse ser humilde, elija las palabras cuidadosamente, utilizar más el nosotros que el yo.

  6. No culpar a nadie. Para un buen ambiente se debe entender que es un logro de equipo o un error de equipo.

  7. Dar retroalimentación positiva. Mencionar qué es lo que se ha realizado correctamente, las deficiencias y cómo el equipo lo puede hacer mejor. Terminar siempre la retroalimentación con una nota positiva.

  8. Escuchar a los miembros del equipo.

  9. Ganarse el respeto con acciones y no con palabras.

  10. Apoyar siempre al equipo.

  11. No todo el mundo puede realizar todos los trabajos. Al jefe del proyecto le corresponde escoger a la persona adecuada para el trabajo correcto. Aunque un miembro poco convencido de enfrentar una tarea nueva podría ganar mucha confianza al completar exitosamente el objetivo, el impacto a la moral es enorme en caso de no conseguirlo.

  12. Comer juntos es un constructor de relaciones.

  13. Permitir la creatividad del equipo.

  14. Inculcar un sentido de propiedad o pertenencia en el equipo.

  15. Realizar sesiones de tormenta de ideas.

  16. Dividir el proyecto en partes, para poder dar metas alcanzables.

  17. Considerar la pirámide de Maslow de las necesidades. No todos tenemos la misma motivación y necesidades.

Documentación de Software

Proceso de escritura

  1. Planificación
    • Propósito
    • Audiencia
    • Entrega
  2. Investigación
    • Preguntando a expertos
    • Revisando documentación
    • Utilizando el Software
  3. Escritura
    1. Organizar contenido e ideas
    2. Escribir el primer borrador
    3. Repasar y corregir
  4. Revisión/Edición
    • Reorganizar contenido
    • Modificar estilo
    • Corregir gramática y puntuación
    • Incorporar resultados de las pruebas
  5. Lanzamiento
    • Como parte final crear un plan para las actualizaciones

Estimación de Pi por el método de Montecarlo

Introducción

Intento de estimar el valor de \(\pi\) mediante el método de Montecarlo basándonos en un círculo y su cuadrado circunscrito asociado.

Se hacen distintos lanzamientos aleatorios obteniendo puntos del cuadrado y se ve si están dentro del círculo o no. Como el área del círculo es \(\pi r^2\) y el del cuadrado circunscrito es \(4 r^2\), tomando puntos aleatorios del cuadrado la probabilidad de caer en el círculo será de \(\frac{\pi r^2}{4 r^2}= \frac{\pi}{4}\). Por tanto podemos aproximar Pi de la forma:

\[\pi \simeq 4 \cdot \frac{aciertos}{tiradas},\]

siendo acierto el caer dentro del círculo.

En la figura se muestra un experimento con 1000 intentos, de los que 783 han caído dentro del círculo (puntos rojos) y 217 fuera (puntos azules). Este experimento daría la siguiente estimación de pi:

\[\pi \simeq 4 \cdot \frac{783}{1000} = 3.132\]

¿Quién verifica la confianza de las autoridades de certificación?

Interesante pregunta que se hacen en StackExchange.

Una autoridad de certificación (CA, Certificaction Authority) es una entidad de confianza, responsable de emitir y revocar los certificados.

La autoridad de certificación verifica la identidad de un certificado antes de su expedición o, cuando ya están expedidos, comprueba su identidad para, en caso necesario, revocarlos.

Pero, como se pregunta A. Hersean en StackExchange ¿quién se encarga de verfiicar que esas autoridades de certificación son de confianza?