GUÍA 1 DE APRENDIZAJE

Metodologías avanzadas de desarrollo de software

Levantamiento de requerimientos

1. Presentación

El software desde una perspectiva técnica es un conjunto de programas (rutinas e

instrucciones) que se ejecutan en un computador con el propósito de solucionar e
innovar un problema o proceso.

Esta definición es parcial porque complementando también es un producto/servicio

que requiere una organización o personas. De tal forma que además del programa
informático se adjunta documentación, formación a las personas que lo vayan a a
utilizar, soporte directa y mantenimiento y mejoramiento del mismo.

El desarrollo de software es entonces un procedimiento que implica en llevar a cabo

un diagnóstico inicial, un análisis de las necesidades, un diseño de posibles
soluciones, un desarrollo profesional de la solución, una prueba de la misma y una
implantación del mismo en la organización.

1.1 Actividad de Reflexión inicial.

El desarrollo de software bajo una metodología puede traer sendos problemas más
allá de sencillamente desarrollar el software. Miremos la siguiente gráfica:

Página 1 de 10
TAREA 1:
¿Qué se debe tener en cuenta para que la metodología de desarrollo de software impida
entregar un producto/servicio adecuado al cliente?

A continuación se presenta las metodologías de desarrollo de

software que han evolucionado en el tiempo. La metodología en
cascada fue de las primeras que se utilizaron con la finalidad de
organizar el caos que implicaba desarrollar software:
Recuerde
que:

En esta se evidencia las etapas que se tienen en cuenta en forma

general para el desarrollo. Estás eran desarrolladas al 100% para
continuar a la siguiente etapa.

Una variante de la metodología en cascada es la llamada en “V” en

las que se confirma que para cada etapa (análisis, diseño, desarrollo
e implantación) se debe confirmar unos productos que son probados

Página 2 de 10
para confirmar el objetivo de cada etapa. Aquí se evidencia la
importancia de retroalimentar a través de los productos las etapas
“hacia atrás” de manera que fuera posible ajustar algún elemento de
la etapa inmediatamente anterior.

La evolución de estas metodologías fueron aquellas que se llamaban

de orden incremental el cual aplica secuencias lineales en forma
escalonada a medida que avanza el calendario de actividades. Cada
secuencia lineal produce “incrementos” de software susceptibles de
entregarse.

El proceso incremental se centra en que en cada incremento se

entrega un producto que ya opera. Los primeros incrementos son
versiones desnudas del producto final, pero proporcionan capacidad
que sirve al usuario y también le dan una plataforma de evaluación.
Esta da inicio a pensar en procesos evolutivos aun cuando enfatiza
en la entrega de un producto final funcional.

En el tiempo se propone la metodología de proceso evolutivo

iterativo. Se caracterizan por la manera en la que permiten desarrollar
versiones cada vez más completas del software. Una manera de
hacerlo es a través de la elaboración de prototipos (interfaces de
usuario) que permitan trabajar las fases incluyendo fases como la
comunicación y la planeación.

Página 3 de 10
Otra propuesta evolutiva iterativa es la llamada de espiral. El software
se desarrolla en una serie de entregas evolutivas. Durante las
primeras iteraciones, lo que se entrega puede ser un modelo o
prototipo. En las iteraciones posteriores se producen versiones cada
vez más completas del sistema cuya ingeniería se está haciendo.

Un modelo en espiral es dividido por el equipo de software en un

conjunto de actividades estructurales. Para fines ilustrativos, se
utilizan las actividades estructurales generales ya analizadas.

Página 4 de 10
La primera iteración da como resultado el desarrollo de una
especificación del producto; las vueltas sucesivas se usan para
desarrollar un prototipo y, luego, versiones cada vez más sofisticadas
del software.

NOTA: Para esta guía se trabajará con la metodología escogida

como pueden ser: programación extrema, scrump o kanban.

TAREA 1:
Para el proyecto se propone que se desarrolle como se avanza el desarrollo de
los siguientes entregables de un proyecto de desarrollo de software:

- El lenguaje UML (Diagramas estáticos y dinámicos): Como tal, UML es un

lenguaje de propósito general (intenta cubrir todos los posibles modelos de
todos los tipos de software) y visual (los modelos se representan,
principalmente, en forma de diagramas). Como lenguaje, la utilidad principal
del UML es permitir la comunicación. La adopción por parte de toda la
industria de un mismo lenguaje permite que todo el mundo pueda entender
los modelos creados por otra persona o equipo y, por lo tanto, que se
puedan discutir las propiedades de un sistema a partir de los modelos.

EL UML presenta entonces dos tipos de diagramas (dinámicos y estáticos). El

modelo dinámico está constituido por los aspectos de un sistema
relacionados con el tiempo y con los cambios en los objetos y sus relaciones
a lo largo del tiempo. Con el modelo dinámico se describe el control en el
sistema, es decir, las secuencias de operaciones que ocurren como respuesta
a estímulos externos, sin tener en cuenta lo que hacen las operaciones,
sobre qué operan o cómo se implementan.

Página 5 de 10
 Por su parte los diagramas estáticos son aquellos que ayudan a recabar los
requerimientos y darle forma a los cimientos y estructura del sistema. En
otras palabras determinar los casos de uso, la entidad/relación, las
actividades y el despliegue.

- Relevamiento de requerimientos: El levantamiento de requerimientos se

refiere a la identificación y documentación de los requerimientos de un
sistema, a partir de los usuarios, clientes o interesados (Stakeholders). A la
práctica también se le conoce como Recopilación de requerimientos. Para
realizarlo se puede utilizar 7 técnicas para realizar el levantamiento de
requerimientos de software, entre ellas las de Análisis de documentación,
observación, entrevistas, cuestionarios, mesas de trabajo, tormentas de
ideas e historias de usuario.

- Arquitectura de software: Se refiere a la estructuración del sistema que,

idealmente, se crea en etapas tempranas del desarrollo. Esta estructuración
representa un diseño de alto nivel del sistema que tiene dos propósitos
primarios: satisfacer los atributos de calidad (desempeño, seguridad,
modificabilidad), y servir como guía en el desarrollo. Al igual que en la
ingeniería civil, las decisiones críticas relativas al diseño general de un
sistema de software complejo deben de hacerse desde un principio. El no
crear este diseño desde etapas tempranas del desarrollo puede limitar
severamente el que el producto final satisfaga las necesidades de los
clientes. Además, el costo de las correcciones relacionadas con problemas en
la arquitectura es muy elevado. Es así que la arquitectura de software juega
un papel fundamental dentro del desarrollo.

Bajo esta perspectiva y de acuerdo a la metodología escogida para el proyecto,

resuelva las siguientes preguntas:

1) ¿Cómo puede aportar el lenguaje UML al desarrollo del proyecto

aplicando la metodología escogida?, Mínimo una página, máximo dos
páginas.
2) ¿Cómo se entiende en la metodología escogida el concepto de los
requerimientos?, ¿Cómo se desarrolla específicamente el término en la
operatividad?, Mínimo una página, máximo dos páginas.
3) ¿La arquitectura de software es aplicable en el desarrollo de su
proyecto?, ¿tal vez otro aspecto lo reemplace?, Explique a detalle.
Mínimo una página, máximo dos páginas.

Página 6 de 10
 2. Profundización.

¿Qué son requerimientos?

Según el glosario de la IEEE, que corresponde a las siglas de (Institute of Electrical
and Electronics Engineers) en español, Instituto de Ingenieros Eléctricos y
Electrónicos, un requerimiento es:

- Una condición o necesidad de un usuario para resolver un problema o alcanzar un

objetivo.
- Una condición o capacidad que debe estar presente en un sistema o componentes
de sistema para satisfacer un contrato, estándar, especificación u otro documento
formal.

Analizando las definiciones anteriores, un requerimiento es una descripción de una

condición o capacidad que debe cumplir un sistema, ya sea derivada de una
necesidad de usuario identificada, o bien, estipulada en un contrato, estándar,
especificación u otro documento formalmente impuesto al inicio del proceso.

Entender los requerimientos de un problema es una de las tareas más difíciles que
enfrenta el profesional de análisis y desarrollo de sistemas. Cuando se piensa por
primera vez, no parece tan difícil desarrollar un entendimiento claro de los
requerimientos. Después de todo, ¿acaso no sabe el cliente lo que se necesita? ¿No
deberían tener los usuarios finales una buena comprensión de las características y
funciones que le darán un beneficio? Sorprendentemente, en muchas instancias la
respuesta a estas preguntas es “no”. E incluso si los clientes y los usuarios finales
explican sus necesidades, éstas cambiarán mientras se desarrolla el proyecto.

A continuación se presentan preguntas y respuestas que se puede uno hacer

respecto al desarrollo de requerimientos del sistema y que es el punto de reflexión
inicial de esta guía:

-¿Quién lo hace? Los profesionales en el análisis y desarrollo de sistemas (que en el

mundo de las tecnologías de información a veces son llamados ingenieros de
sistemas o analistas) y todos los demás participantes del proyecto (gerentes, clientes
y usuarios) intervienen en la ingeniería de requerimientos.

-¿Por qué es importante? Diseñar y construir un elegante programa de computador

que resuelva el problema equivocado no satisface las necesidades de nadie. Por eso
es importante entender lo que el cliente desea antes de comenzar a diseñar y a
construir un sistema basado en computador.

-¿Cuáles son los pasos? La ingeniería de requerimientos comienza con la

concepción, tarea que define el alcance y la naturaleza del problema que se va a
resolver. Va seguida de la indagación, labor que ayuda a los participantes a definir lo

Página 7 de 10
que se requiere. Después sigue la elaboración, donde se refinan y modifican los
requerimientos básicos. Cuando los participantes definen el problema, tiene lugar una
negociación: ¿cuáles son las prioridades, qué es lo esencial, cuándo se requiere?
Por último, se especifica el problema de algún modo y luego se revisa o válida para
garantizar que hay coincidencia entre la comprensión que usted tiene del problema y
la que tienen los participantes.

- ¿Cuál es el producto final? El objetivo de los requerimientos de ingeniería es

proporcionar a todas las partes un entendimiento escrito del problema. Esto se logra
por medio de varios productos del trabajo: escenarios de uso, listas de funciones y de
características, modelos de requerimientos o especificaciones.

- ¿Cómo me aseguro de que lo hice bien? Se revisan con los participantes los
productos del trabajo de la ingeniería de requerimientos a fin de asegurar que lo que
se aprendió es lo que ellos quieren decir en realidad. Aquí cabe una advertencia: las
cosas cambiarán aun después de que todas las partes estén de acuerdo, y seguirán
cambiando durante todo el proyecto.

Los requerimientos deben ser:

• Especificado por escrito: como todo contrato o acuerdo entre dos partes.
• Posible de probar o verificar: si un requerimiento no se puede comprobar,
entonces ¿cómo se sabe si se cumplió con él o no?.
• Conciso: un requerimiento es conciso si es fácil de leer y entender. Su redacción
debe ser simple y clara para aquellos que vayan a consultarlo en un futuro.
• Completo: un requerimiento está completo si no necesita ampliar detalles en su
redacción, es decir, si se proporciona la información suficiente para su comprensión.
• Consistente: es consistente si no es contradictorio con otro requerimiento.
• No ambiguo: un requerimiento no es ambiguo cuando tiene una sola interpretación.
El lenguaje usado en su definición, no debe causar confusiones al lector.

Los requerimientos de software pueden dividirse en dos categorías: requerimientos

funcionales y no funcionales.

• Los requerimientos funcionales son los que definen las acciones que el sistema
será capaz de realizar, describen las transformaciones que el sistema hace sobre las
entradas para producir salidas. Es importante que se describa el ¿qué? y no el
¿cómo? se deben hacer esas transformaciones. Estos requerimientos al tiempo que
avanza el proyecto de software se convierten en los algoritmos, la lógica y gran parte
del código del sistema.

• Por otra parte los requerimientos no funcionales tienen que ver con características
que de una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento
(en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema,
disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares, entre
otras.

Página 8 de 10
Dificultades para definir los requerimientos

Durante la etapa de especificación de requerimientos se pueden presentar muchos

inconvenientes los cuales son importantes de identificar y prevenir, a continuación se
presenta un listado con los problemas más comunes en este proceso:

• Los requerimientos no son obvios y vienen de muchas fuentes.

• Son difíciles de expresar en palabras (el lenguaje es ambiguo).
• La cantidad de requerimientos en un proyecto puede ser difícil de manejar.
• Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.
• El usuario no puede explicar lo que hace.
• Tiende a recordar lo excepcional y olvidar lo rutinario.
• Se habla de lo que no funciona.
• Los usuarios tienen distinto vocabulario a los desarrolladores.
• Usan el mismo término con distinto significado.

Recomendaciones para la toma de requerimientos

Para realizar la toma de requerimientos se deben tener en cuenta unas
recomendaciones, pues la tarea de análisis de estos, es un proceso de
descubrimiento y refinamiento. Se analizan y asignan a los distintos elementos de los
programas las soluciones alternativas.

El ingeniero desarrollador y el cliente tienen un papel muy activo en la especificación

de requerimientos. El cliente intenta explicar su idea, algo confusa de la función y
comportamiento de los programas en detalles concretos, el ingeniero desarrollador
del software actúa como interrogador, consultor y el que resuelve los problemas. La
tarea de análisis parece una labor sencilla pero se debe tener mucho cuidado, pues
lo que el cliente trata de expresar no siempre es lo mismo que el ingeniero entiende,
por ello se debe tener una estrecha comunicación para comprender todos los
requerimientos que se están tomando, esto evita los cambios por mala interpretación
o falta de información. Los requerimientos de un sistema de software, cuando se ven
en su conjunto son extensos y detallados, y además contienen múltiples relaciones
entre sí.

El análisis de requerimientos facilita al ingeniero de sistemas especificar la función y

comportamiento de los programas, indicar la interfaz con otros elementos y
establecer las ligaduras de diseño que debe cumplir el programa, también permite
refinar la asignación de software y representar el dominio de la información que será
tratada por el sistema y permite diseñar la representación de la información y las
funciones que pueden ser traducidas en datos, arquitectura y diseño procedimental.
Finalmente, la especificación de requerimientos suministra al técnico y al cliente, los
medios para valorar la calidad de los programas.

TAREA 2:

Página 9 de 10
 Teniendo en cuentas los aspectos presentados de los requerimientos, describa el proceso
que entiende debe llevarse a cabo a partir de la metodología escogida (mínimo dos
páginas). Además presente los resultados obtenidos en el desarrollo del proceso (es decir
presente los productos que desde su metodología se entiende como los requerimientos.
Claro en las condiciones que la metodología exige).

3. BIBLIOGRAFÍA
 Beltrán, J., Carmona, M., Carrasco, R., Rivas, M., & Tejedor, F. (2002). Guía para una
gestión basada en procesos. Instituto Andaluz de Tecnología. Govern de les Illes Balears.
 García, M., Quispe, C., & Ráez, L. (2003). Mejora continua de la calidad en los procesos.
Industrial Data, 6(1).
 Martínez, R., & Fernández, A. (2008). Árbol de problema y áreas de intervención. México:
CEPAL.
 Martínez Guerrero, J. M., & Silva Delgado, C. A. (2010). Guía metodológica para el
levantamiento y análisis de requerimientos de software con base en procesos de negocio
(Bachelor's thesis).
 Pressman, R. S. (2010). Ingeniería del Software Un enfoque práctico, Séptima edición ed.
 Yañez, C. (2008). Sistema de gestión de calidad en base a la norma ISO 9001.
Recuperado de: http://internacionaleventos. com/articulos/articuloISO. pdf.

Página 10 de 10