• Necesidad: Lo que pretende el cliente o desea que se le proporcione para su aplicación.
  • Lo que se está pidiendo que el sistema haga.
  • Se consideran equivalentes los siguientes términos:
    • NECESIDAD = ISSUE = CARACTERÍSTICA = REQUERIMIENTO = REQUISITO CANDIDATO = Requisitos de Usuario.




• Requisito: También denominado Requisito del Sistema. Capacidad que debe tener el sistema para satisfacer las necesidades de los usuarios del sistema. Incluye Requisitos Funcionales y Requisitos No Funcionales.
  • Lo que se necesita para cumplir con lo que se está pidiendo que el sistema haga.




• Caso de Uso: Secuencia de acciones que el sistema puede llevar a cabo interactuando con sus actores, incluyendo alternativas dentro de la secuencia.
  • Estructuración de la funcionalidad requerida en el sistema, a través de secuencia de pasos e interacciones con sistemas externos (usuario).

Ejemplo:

Necesidad: Contestar un mensaje de correo.

Requisito: Tener un ordenador conectado a Internet; tener un software de correo electrónico; Poder seleccionar destinatarios; Poder modificar el mensaje; y más requisitos…

Casos de Uso: Seleccionar Destinatarios; Editar Mensaje; Insertar Firma; etc…

Un saludo,

Él sabe que soy muy básico, no me gusta demasiado trastear y seguro que me podrá aportar alguna idea más de mejora.

Me resulta curioso cómo actuamos respecto de estos temas. Somos capaces de asimilar fácilmente todo lo relacionado con nuestras páginas web, widgets, bitácoras, feeds, etc. Para ello necesitamos realizar los pasos que se nos indican, seguimos procedimientos.

Todos mis compañeros utilizan un montón de utilidades, tienen una facilidad pasmosa. Pero luego, a la hora de aplicar una metodología en un proceso de desarrollo, todo son problemas. Qué si hay que hacer un master para seguir los procedimientos, qué que tedioso, qué no me he dado cuenta y se me ha olvidado algún paso, qué si no se permite creatividad alguna, etc…

Me hace llegar a una conclusión un poco triste, cuando se trata de ocio todos somos capaces de todo, pero cuando se trata de trabajo, no vemos nada más que problemas.

Por otra lado, ¿cuántas horas pasamos trabajando?, ¿no sería fantástico que conocieramos perfectamente nuestros procedimientos de trabajo? ¿cuánto stress nos evitaría? ¿cuánto más felices nos haría estar en el día a día?

Quizás éste sea uno de los grandes objetivos de los responsables de las Metodologías en los proyectos, hacer ver a los miembros del equipo las ventajas, no sólo las necesidades, de conocer y utilizar bien la metodología definida. Trasmitir que conocer bien la metodología y aplicarla correctamente te va a permitir acceder a aspectos fundamentales del proyecto.

Leyendo sobre Scrum, me he encontrado un par de sitios dónde hacen referencia a la regla del Shuhari.

¿Qué es el Shuhari? ¿Qué relación puede tener con las metodologías de desarrollo?

Bien, en primer lugar, el Shuhari es un concepto japonés de artes marciales, y describe las etapas desde el aprendizaje hasta la maestría.

• Shu –> Aprendizaje tradicional.
• Ha –> Romper la tradición.
• Ri –> Trascender.

La relación se puede ver con la necesidad de aplicar la regla del Shuhari en la utilización de cualquier metodología de desarrollo:

1. Aprended la regla.
2. Experimentar con la regla.
3. Cuando se haya encontrado con lo que realmente funciona, disolved la regla.

Además y esto es de mi querido Bruce: “Be water, my friend!”

• ¿Qué es el Ciclo de Vida?–> Es el conjunto de fases por las que pasa el sistema desde que se concibe hasta que se retira del servicio. Indica cuáles son las actividades a realizar y el orden en que se van a realizar. Además identifica las transiciones entre fases.
• ¿Qué es la Metodología? –> Indica el procedimiento de trabajo para avanzar en la construcción del sistema. Cómo se realizan las actividades y con qué técnicas.

Según esto, el Ciclo de Vida únicamente identifica las fases y actividades que habrán de realizarse y el orden que tendrán, mientras que la Metodología contempla cómo realizar dichas actividades y con qué técnicas.

Cuando se inicia un proyecto, según los principios generales de la Ingeniería del Software, se debe seleccionar el Modelo de Ciclo de Vida a seguir. Este Modelo se debe elegir en función de las características del proyecto, ya que no hay un modelo aplicable en todos los proyectos.

Podemos entender la confusión que se produce entre ambos términos, en ocasiones debido a que hay metodologías que proponen un ciclo de vida, caso de RUP. En cualquier caso, debemos pensar que son dos conceptos íntimamente relacionados pero distintos.