Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Community
Ask the community for help and clear up your study doubts
Discover the best universities in your country according to Docsity users
Free resources
Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors
analisis y metodologia del software
Typology: Summaries
1 / 22
This page cannot be seen from the preview
Don't miss anything!
Breve descripción:
En este componente formativo se abordan los temas de técnicas de validación de
requisitos (revisiones, prototipos y casos de prueba) y el tema de los requerimientos
duraderos y volátiles.
Mayo 2024
La validación de los requerimientos busca ratificar que los requerimientos
realmente están especificando lo que el cliente desea y necesita. Este proceso es muy
importante, pues un error en un documento de requerimientos puede ocasionar el
desgaste importante de muchos recursos si estos errores son detectados en etapas más
avanzadas del proyecto como diseño, construcción o despliegue a producción. Los
costos asociados para el arreglo de problemas en los requerimientos siempre van a ser
menores que en otras etapas, ya que un error en los requerimientos se propaga en
cascada en todas las fases subsiguientes del ciclo de vida.
Según Sommerville (2011), en el proceso de validación de requerimientos se
llevan a cabo las siguientes verificaciones:
realmente todas las funciones necesarias para cumplir con las necesidades
del cliente.
contradicciones.
restricciones definidas por los usuarios del sistema.
con la tecnología existente, el presupuesto y los tiempos definidos.
y que hace lo que debe hacer. Es decir, existe una forma clara en la que se
le pueda realizar pruebas.
Existen varias técnicas que pueden usarse para la validación de requisitos, como
se puede revisar a continuación.
Las revisiones de los requerimientos son un proceso manual que involucra la
participación de personas de parte de la organización constructora del software así
como la de los clientes. Por lo general, en este proceso se revisa el documento de
requerimientos tratando de encontrar alguna anomalía y/u omisiones en la escritura de
estos.
Esta revisión se puede realizar de manera informal o formal (Sommerville, 2011).
En una revisión informal, se requiere verificar, con tantos stakeholders como sea
posible, el documento generado para recibir confirmación por parte de ellos de que lo
escrito sí refleja su deseo. Esta revisión informal permite, de manera muy sencilla,
detectar muchos problemas antes de establecer cualquier formalismo de revisión.
En una revisión formal, el equipo de desarrollo debe introducir al cliente por cada
uno de los requerimientos establecidos y explicando cada una de sus implicaciones. El
equipo encargado de la revisión deberá verificar cada requerimiento de forma
individual y realizar el análisis de conjunto. Además, en el proceso de verificación debe
resolverse cada una de las siguientes preguntas:
personas que lo van a usar?
evaluar los cambios que pueden generar en el sistema?
Síntesis del video: Construcción de prototipos
Un prototipo es una versión inicial de un sistema que permite probar
conceptos, opciones de diseño, flujos y otros aspectos por medio de la interacción
directa de los clientes o usuarios finales en las primeras etapas del proceso del
software. Un prototipo puede ayudar en la obtención y validación de los requisitos
del sistema, permite explorar soluciones y posibles interfaces de usuario, y
finalmente ayudan en el proceso de pruebas. Por medio de los prototipos, los clientes
y usuarios finales tienen una idea más clara de cómo el sistema puede apoyar sus
labores, puede generar nuevas ideas para los requerimientos e identificar fortalezas y
debilidades de la forma en cómo hasta el momento se consigue cada requerimiento
por parte de los desarrolladores.
También, un prototipo puede revelar errores y omisiones en los requerimientos
que no fueron detectados en el momento de la escritura de estos. Cuando se analizan
los requerimientos escritos, no es fácil detallar problemas relacionados con las
funcionalidades combinadas con otras en un sistema completo, por lo que los
prototipos son ideales para encontrar elementos faltantes o sobrantes en las
definiciones de los requerimientos.
La construcción de prototipos para procesos de validación de requerimientos
tiene los siguientes beneficios: los prototipos son fácilmente modificables y
prescindibles, el prototipado mejora la relación entre desarrolladores y usuarios.
Puede proporcionar la prueba conceptual necesaria para la consolidación en el
proceso, pueden procurar una pronta preparación para los futuros usuarios del
sistema. El prototipado puede evitar sorpresas desagradables al destacar los
requerimientos incompletos o inconsistentes y la falta de funcionalidad. Puede
reducir los malos entendidos entre desarrolladores y clientes, puede reducir los
costes de rediseño si los problemas se detectan pronto y cuando son fáciles de
localizar, resultará en un producto que se ajusta mejor a los requerimientos del
usuario. El prototipado puede fortalecer la especificación de los requerimientos; los
usuarios entienden mejor los prototipos que las especificaciones de papel.
Por otra parte, el uso inadecuado de los prototipos también puede generar
algunos riesgos, entre los que se encuentran:
peticiones.
clientes que el producto final está prácticamente dispuesto para su salida
al mercado.
Para la fase de verificación de requisitos se recomienda el uso de prototipos de
baja fidelidad (presentación de escenarios con maquetas estáticas) y de tipo
exploratorio (prototipos no reutilizables, usados únicamente para la clarificación e
identificación de requerimientos).
Aunque un prototipo podría ser una sencilla representación gráfica del sistema
en papel o la representación de interfaces del sistema usando herramientas de
ofimática, existen varias herramientas gratuitas y de pago que facilitan la construcción
de prototipos, algunas de ellas solo requieren un registro de correo electrónico para
De otra parte, el diseño de un caso de prueba requiere: i) la construcción de un
instrumento donde se debe detallar para cada requerimiento si existen precondiciones,
es decir, si se requieren de actividades o valores previos para poder iniciar la ejecución
del requerimiento; ii) identificar los pasos a seguir para la validación de un requisito y
iii) los resultados esperados de la realización de cada paso.
La siguiente es la estructura que lleva el instrumento de registro de caso de
prueba:
Figura 1. Formato de caso de prueba
Los requerimientos de un proyecto inevitablemente sufren variaciones en el
tiempo y puede ser por varios motivos, entre los que se podrían destacar cambios en
las políticas gubernamentales, sociales, económicas o, sencillamente, por solicitudes de
los clientes.
Según Sommerville (2011), dependiendo de la perspectiva evolutiva de los
requerimientos, estos se pueden clasificar en dos grupos:
Son relativamente estables y normalmente se derivan de las actividades
principales de la organización y están directamente relacionados con el
dominio del sistema. Por ejemplo, en un sistema académico los
requerimientos relacionados con la gestión de estudiantes, profesores y
grupos hacen parte del dominio y, seguramente, el modelo de negocio
asociado a estos requerimientos no va a cambiar mucho en el tiempo.
Son los que, muy probablemente, cambian durante el proceso del
desarrollo del sistema o después que este entra en funcionamiento. Por
ejemplo, en un sistema académico un requerimiento asociado al proceso
de pago de pensión podría definirse de forma manual en un principio; es
decir, la secretaria una vez reciba el dinero o los recibos de pago registra el
pago en el sistema, más adelante si la institución educativa adquiere un
servicio de pasarela de pagos en línea el requerimiento podría modificarse
totalmente.
En la actualidad, existe una variedad de herramientas para ser utilizadas
específicamente en la gestión de requisitos, la utilización de estas ayuda a mejorar la
calidad del desarrollo de un proyecto y permite un mayor control en el mantenimiento,
previniendo posibles errores durante la ejecución del proyecto.
Las herramientas de gestión de requisitos variarán según las metodologías de
proyecto y los objetivos, la manera en la cual se aborden los requisitos también
dependerá según la metodología. Por ejemplo, algunos equipos usan otra palabra para
requisitos como “historias de usuarios”, “requisitos de productos” o, simplemente,
“características”.
Existen herramientas básicas de requerimientos y herramientas complejas, las
cuales se explican a continuación:
Se manejan en la planeación de gestión de requisitos muy básica y se
pueden utilizar las hojas de cálculo, o una plantilla de documento en Word;
es difícil su utilización cuando se trata de actualización con varias personas
y el manejo de las versiones de los documentos.
Para una planificación de gestión de requisitos más compleja, se necesita
un sistema de software completo para administrar las relaciones entre los
requisitos, analizar el impacto de cualquier cambio, administrar las
aprobaciones y demás aspectos.
De acuerdo con el mismo autor, las herramientas de gestión de requisitos se
caracterizan por las siguientes propiedades:
ejemplo casos de uso o historias de usuario.
determinar su orden.
procesos de construcción o modificación de requisitos.
realizados en los requisitos con su marca de tiempo y usuarios
involucrados.
Las siguientes herramientas principalmente ayudan a documentar, analizar,
buscar, priorizar y trazar los requisitos:
Tabla 1. Herramientas de gestión de requisitos
Requirements
Management
Tool
Company URL
IBM Rational
DOORS
IBM Rational
DOORS
https://www.ibm.com/products/requirements-
management?mhsrc=ibmsearch_a&mhq=rational%20doors
Visure
Requirements
Visure Solutions https://visuresolutions.com/es/
Reqtify Dassault Systèmes https://www.3ds.com/products/catia/reqtify
Jama Jama Software https://www.jamasoftware.com/
Accept 360 Accept Software https://www.acceptmission.com/es/
garantiza la trazabilidad entre todos los documentos relacionados con la
ingeniería de requisitos (funcionalidades, requisitos, casos de uso, casos de
prueba).
A continuación, se presenta una síntesis de la temática estudiada en el
componente formativo:
Ágil : comprende un conjunto de tareas o acciones que se utilizan para producir y
mantener productos, así como para lograr los objetivos del proceso. La actividad
incluye los procedimientos, estándares, políticas y objetivos para crear y modificar un
conjunto de productos de trabajo.
Ciclo de vida software : se refiere a la aplicación de metodologías para el
desarrollo del sistema software (AECC, 1986).
Método : indica cómo construir técnicamente el software. Se incluyen técnicas
de modelado y otras técnicas descriptivas.
Metodología : colección de métodos para resolver un tipo de problemas.
Requerimiento : el requerimiento se refiere a la petición que se hace de algo que
se solicita.
Requisito : es la condición que debe cumplir algo, en general el requisito cumple
con lo que se requiere con el requerimiento.
Stakeholders : individuo u organización que comparte, reclama o le interesa un
sistema o le compete una característica que satisface sus necesidades y expectativas
Baar, B. (2006). Using Stakeholder Analysis in Software Project Management.
Universidad de Amsterdam.
Braude, J. (2003). Ingeniería de software, una perspectiva orientada a objetos.
Alfaomega.
Cohen, L. (2011). Métodos de investigación educativa. La Muralla.
Cohn, M. (2004). User Stories Applied for Agile Software Development. Pearson
Education, Inc.
Cox, K., Niazi, M., y Verner, J. (2009). Empirical study of Sommerville and Sawyer’s
requirements engineering practices. IET Software, 3(5), 339. https://digital-
library.theiet.org/content/journals/10.1049/iet-sen.2008.
Curso de interacción persona-ordenador. (2021). Storyboarding.
https://mpiua.invid.udl.cat/storyboarding/
Denscombe, M. (2010). The Good Research Guide. McGraw-Hill Education.
Dornyei, Z. (2010). Questionnaires in Second Language Research: Construction,
Administration, and Processing. Routledge.
Durán, A., Bernárdez, B., Ruiz, A. y Toro, M. (1999). A Requirements Elicitation
Approach Based in Templates and Patterns.
https://www.researchgate.net/publication/2890318_A_Requirements_Elicitation_Appr
oach_Based_in_Templates_and_Patterns
