Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

analisis y diseño de software, Summaries of Introduction to Software Engineering

analisis y metodologia del software

Typology: Summaries

2024/2025

Uploaded on 07/01/2025

christian-camilo-soto-corrales
christian-camilo-soto-corrales 🇺🇸

3 documents

1 / 22

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
1
Grupo de Ejecución de la Formación Virtual
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
Validación de requisitos
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16

Partial preview of the text

Download analisis y diseño de software and more Summaries Introduction to Software Engineering in PDF only on Docsity!

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

Validación de requisitos

  • Introducción...................................................................................................... Tabla de contenido
    1. Validación de requerimientos
    • 1.1. Revisiones de requerimientos
    • 1.2. Construcción de prototipos...................................................................
    • 1.3. Generación de casos de prueba
    1. Requerimientos duraderos y volátiles
    1. Herramientas para la gestión de requisitos
  • Síntesis............................................................................................................
  • Material complementario
  • Glosario
  • Referencias bibliográficas
  • Créditos

1. Validación de requerimientos

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:

  • Verificación de validez : los requerimientos son razonables e identifican

realmente todas las funciones necesarias para cumplir con las necesidades

del cliente.

  • Verificación de consistencia : los requerimientos no presentan

contradicciones.

  • Verificaciones de completitud : se incluyen todas las funcionalidades y

restricciones definidas por los usuarios del sistema.

  • Verificaciones de realismo : los requerimientos son realizables de acuerdo

con la tecnología existente, el presupuesto y los tiempos definidos.

  • Verificabilidad : es posible demostrar la realización de cada requerimiento

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.

1.1. Revisiones de requerimientos

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:

  • Verificabilidad : ¿Es posible probar este requerimiento en la realidad?
  • Comprensibilidad : ¿Es claro lo que expresa este requerimiento para las

personas que lo van a usar?

  • Rastreabilidad : ¿Es posible observar el origen del requerimiento y también

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:

  • El prototipado puede estimular un número excesivo de cambios de

peticiones.

  • Los prototipos operativos pueden inducir a pensar a la directiva y a los

clientes que el producto final está prácticamente dispuesto para su salida

al mercado.

  • Los prototipos pueden encarecer el producto.

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

2. Requerimientos duraderos y volátiles

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:

  • Requerimientos duraderos:

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.

  • Requerimientos volátiles:

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.

3. Herramientas para la gestión de requisitos

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:

  • Herramientas básicas

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.

  • Herramientas complejas

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:

  • Gestión de requisitos basados en modelos de información, como por

ejemplo casos de uso o historias de usuario.

  • Organización de requisitos: es fácil agrupar el conjunto de requisitos y

determinar su orden.

  • Acceso y gestión multiusuario: múltiples personas pueden participar en los

procesos de construcción o modificación de requisitos.

  • Gestión de la trazabilidad: se puede ver a nivel histórico los cambios

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/

  • Herramienta de requisitos automatizada.
  • REM. Totalmente desarrollada para la elicitación de requisitos.
  • OSRMT. Permite la descripción avanzada de diversos tipos de requisitos y

garantiza la trazabilidad entre todos los documentos relacionados con la

ingeniería de requisitos (funcionalidades, requisitos, casos de uso, casos de

prueba).

Síntesis

A continuación, se presenta una síntesis de la temática estudiada en el

componente formativo:

Glosario

Á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

(ISO 29148).

Referencias bibliográficas

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