path: root/gpds/n3.lyx

#LyX 2.3 created this file. For more info see http://www.lyx.org/
\lyxformat 544
\begin_document
\begin_header
\save_transient_properties true
\origin unavailable
\textclass book
\use_default_options true
\begin_modules
algorithm2e
\end_modules
\maintain_unincluded_children false
\language spanish
\language_package default
\inputencoding auto
\fontencoding global
\font_roman "default" "default"
\font_sans "default" "default"
\font_typewriter "default" "default"
\font_math "auto" "auto"
\font_default_family default
\use_non_tex_fonts false
\font_sc false
\font_osf false
\font_sf_scale 100 100
\font_tt_scale 100 100
\use_microtype false
\use_dash_ligatures true
\graphics default
\default_output_format default
\output_sync 0
\bibtex_command default
\index_command default
\paperfontsize default
\spacing single
\use_hyperref false
\papersize default
\use_geometry false
\use_package amsmath 1
\use_package amssymb 1
\use_package cancel 1
\use_package esint 1
\use_package mathdots 1
\use_package mathtools 1
\use_package mhchem 1
\use_package stackrel 1
\use_package stmaryrd 1
\use_package undertilde 1
\cite_engine basic
\cite_engine_type default
\biblio_style plain
\use_bibtopic false
\use_indices false
\paperorientation portrait
\suppress_date false
\justification true
\use_refstyle 1
\use_minted 0
\index Index
\shortcut idx
\color #008000
\end_index
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\paragraph_indentation default
\is_math_indent 0
\math_numbering_side default
\quotes_style french
\dynamic_quotes 0
\papercolumns 1
\papersides 1
\paperpagestyle default
\tracking_changes false
\output_changes false
\html_math_output 0
\html_css_as_file 0
\html_be_strict false
\end_header

\begin_body

\begin_layout Standard
\begin_inset Note Comment
status open

\begin_layout Plain Layout
Un 
\series bold
objeto
\series default
 es una entidad relevante del mundo real, una 
\series bold
función
\series default
 es una acción o secuencia de acciones que se puede llevar a cabo sobre
 objetos y un 
\series bold
estado
\series default
 es una situación en que se puede encontrar un objeto.
\end_layout

\end_inset


\end_layout

\begin_layout Standard
Un 
\series bold
requisito
\series default
 es una declaración muy específica, precisa y sin ambigüedad de una o más
 necesidades particulares a satisfacer por un producto, junto a sus limitaciones
 y condiciones.
 Según 
\lang english
Alan Davis
\lang spanish
, un requisito define un objeto, función o estado; limita o controla las
 acciones asociadas a uno, o define relaciones entre objetos, funciones
 y estados.
\end_layout

\begin_layout Standard
Un 
\series bold
accionista
\series default
 o 
\series bold
parte interesada
\series default
 es una persona, un grupo o una organización con interés directo o indirecto
 en un producto o proyecto, como un usuario, cliente, jefe de proyecto,
 ingeniero de requisitos, analista o programador.
\end_layout

\begin_layout Standard
Una 
\series bold
regla de negocio
\series default
 es una condición que se debe satisfacer cuando se hace una actividad de
 negocio.
 El software puede ignorar la regla para que los usuarios la manejen manualmente
; avisar al usuario cuando esta se incumple para que el usuario decida si
 incumplirla o no, o forzar su cumplimiento con algún mecanismo de excepción.
\end_layout

\begin_layout Standard
La 
\series bold
ingeniería de requisitos
\series default
 es la parte de la ingeniería de software que comprende las actividades
 de desarrollo relacionadas con la gestión y definición de requisitos para
 sistemas software, mediando los dominios de adquisidor y proveedor.
 Sus objetivos son:
\end_layout

\begin_layout Enumerate
Alcanzar un acuerdo entre clientes, desarrolladores y usuarios sobre lo
 que hay que desarrollar.
\end_layout

\begin_layout Enumerate
Ser la base para el diseño de software.
\end_layout

\begin_layout Enumerate
Permitir la verificación y validación de los productos obtenidos.
\end_layout

\begin_layout Enumerate
Orientar a potenciales clientes sobre la definición de los productos mediante
 catálogos de requisitos alternativos.
\end_layout

\begin_layout Standard
Se le suele dedicar el 
\begin_inset Formula $\unit[10]{\%}$
\end_inset

 del esfuerzo de un proyecto, aunque dedicar más esfuerzo disminuye el tiempo
 total del proyecto según estudios como los del informe SERENA.
\end_layout

\begin_layout Standard
\begin_inset Note Comment
status open

\begin_layout Plain Layout
Requiere habilidades distintas de las de un buen programador, como la abstracció
n, el modelado y la comunicación, y si quiere hacerse, debe justificarse
 ante la dirección.
\end_layout

\end_inset


\end_layout

\begin_layout Section
Importancia
\end_layout

\begin_layout Standard
Según 
\lang english
Robert Glass
\lang spanish
, las principales causas de fracaso de proyectos de software son la inestabilida
d de los requisitos, pues en general los clientes o usuarios no tienen realmente
 claro qué quieren o qué problema que quieren resolver, y una mala estimación
 de el tiempo y el coste del proyecto.
\end_layout

\begin_layout Standard
Los errores en las primeras fases del desarrollo son más caros de corregir
 porque pasa más tiempo hasta terminar las fases y obtener retroalimentación,
 siendo los más caros los errores en los requisitos.
 Algunos son:
\end_layout

\begin_layout Enumerate
No descubrir requisitos relevantes a tiempo, debido a una mala identificación
 de los accionistas o una mala búsqueda de requisitos.
 Es lo más difícil de corregir.
\end_layout

\begin_layout Enumerate
Una explosión de los requisitos derivados, los que surgen para satisfacer
 una cierta solución de diseño, por la complejidad del proceso de la solución,
 llegando a haber 50 veces más requisitos derivados que requisitos originales.
\end_layout

\begin_layout Enumerate
No detectar a tiempo ambigüedades entre requisitos.
 Si no se llegan a detectar, pueden causar defectos en el sistema que hagan
 que el software no llegue a usarse.
\end_layout

\begin_layout Standard
El cohete europeo Ariane 5 explotó debido a un desbordamiento al convertir
 un valor en coma flotante de doble precisión a un entero de 16 bits con
 signo, como resultado de mantener un requisito de software del Ariane 4
 que no era necesario en el 5, relacionado con la velocidad horizontal y
 el ángulo de ataque detectados por un sensor de vuelo.
\end_layout

\begin_layout Standard
La NASA perdió el contacto con el Mars Polar Lander 10 minutos antes de
 su aterrizaje previsto debido a que el software malinterpretó señales que
 debía ignorar y creyó que uno de los brazos de la sonda había tocado suelo
 cuando estaba a 
\begin_inset Formula $\unit[40]{m}$
\end_inset

 de altura.
\end_layout

\begin_layout Section
Fases
\end_layout

\begin_layout Enumerate

\series bold
Identificación y consenso.
\end_layout

\begin_deeper
\begin_layout Enumerate

\series bold
Contexto.

\series default
 Se establecen las necesidades iniciales de la organización y se delimita
 el alcance del proyecto.
\end_layout

\begin_layout Enumerate

\series bold
Trabajo preliminar.

\series default
 Se identifican los interlocutores concretos y suministradores de información.
 Se hace un 
\series bold
estudio de viabilidad
\series default
 para ver que el proyecto sea viable técnicamente con el presupuesto y el
 tiempo dados, y se decide entre crear el producto, comprarlo o subcontratar
 el desarrollo.
\end_layout

\begin_layout Enumerate

\series bold
Adquisición.

\series default
 Se establecen procedimientos de compra, adquisición y contratación si es
 necesario, y se prepara la adquisición y recogida de información.
\end_layout

\end_deeper
\begin_layout Enumerate

\series bold
Representación y modelado.

\series default
 Se escogen técnicas de representación y modelado apropiadas y se construyen
 modelos que reflejen las necesidades de los usuarios.
 Las técnicas de modelado (lenguajes y notaciones) se eligen según su 
\series bold
poder expresivo
\series default
: la variedad de tipos de requisitos que pueden ser capturados y la capacidad
 para suministrar mucha información en poco espacio.
\end_layout

\begin_deeper
\begin_layout Standard
Se decide si usar 
\series bold
ingeniería inversa
\series default
, obtención de información a partir de un producto accesible al publico
 para determinar su composición, cómo funciona y cómo fue fabricado.
\end_layout

\end_deeper
\begin_layout Enumerate

\series bold
Análisis.

\series default
 Se 
\series bold
validan
\series default
 los modelos construidos con los requisitos y se 
\series bold
verifica
\series default
 la corrección interna y externa de los modelos, usando prototipos, inspecciones
 y revisiones.
\end_layout

\begin_layout Enumerate

\series bold
Documentación y comunicación.

\series default
 Se organiza la información.
\end_layout

\begin_layout Enumerate

\series bold
Gestión y mantenimiento.

\series default
 Se sigue la vida de los requisitos por todo el proceso de desarrollo para
 conseguir 
\series bold
trazabilidad
\series default
.
 Se definen los procedimientos de 
\series bold
gestión de cambios de requisitos
\series default
, manteniendo la integridad de los mismos durante la evolución del sistema
 y gestionando y documentando los cambios.
 Estos procedimientos deben aplicarse siempre tras la aprobación de los
 requisitos.
\end_layout

\begin_layout Standard
También se definen métricas sobre los productos del proceso de desarrollo,
 especificando pruebas, lo que permite estimar el coste de desarrollo y
 los recursos necesarios y refinar la planificación.
\end_layout

\begin_layout Section
Análisis de requisitos
\end_layout

\begin_layout Standard
El ISO/IEC/IEEE 24765:2017 lo define como un 
\begin_inset Quotes cld
\end_inset

proceso de estudio de las necesidades del usuario para llegar a una definición
 de los requisitos del sistema, hardware o software
\begin_inset Quotes crd
\end_inset

 o un 
\begin_inset Quotes cld
\end_inset

proceso de estudio y perfeccionamiento de los requisitos del sistema, hardware
 o software
\begin_inset Quotes crd
\end_inset

.
\end_layout

\begin_layout Standard
Una 
\series bold
revisión de requisitos
\series default
 es un proceso en que se presentan requisitos a partes interesadas para
 su aprobación o retroalimentación, o bien es un grupo de revisores que
 buscan errores, contradicciones, descripciones ambiguas, etc.
\end_layout

\begin_layout Standard
Si hay conflictos de intereses entre las partes, se hace una 
\series bold
negociación de requisitos
\series default
, en la que se detectan y resuelven los posibles conflictos; se definen
 de forma más precisa los limites del sistema y las interacciones de este
 con el entorno, y se eliminan redundancias, inconsistencias y puntos de
 desencuentro.
\end_layout

\begin_layout Standard
No es viable que los requisitos queden 
\begin_inset Quotes cld
\end_inset

congelados
\begin_inset Quotes crd
\end_inset

, pero tampoco lo es que cambien continuamente, por lo que en cierto momento
 se hace una 
\series bold
\emph on
\lang english
sign-off
\series default
\emph default
\lang spanish
, una aprobación de ciertos requisitos por el cliente.
 Una 
\series bold
\emph on
\lang english
baseline
\series default
\emph default
\lang spanish
 es un conjunto de requisitos identificados y acordados en un instante de
 tiempo, normalmente tras la 
\emph on
\lang english
sign-off
\emph default
\lang spanish
.
\end_layout

\begin_layout Section
Especificación de requisitos
\end_layout

\begin_layout Standard
Una 
\series bold
especificación
\series default
 es un elemento de información que identifica de forma completa, precisa
 y verificable unas características esperadas de un sistema, servicio o
 proceso.
 En el análisis de requisitos se elabora un 
\series bold
documento de especificación de requisitos del software
\series default
 (
\series bold
SRS
\series default
, 
\emph on
\lang english
Software Requirements Specification
\emph default
\lang spanish
) y, en su caso, uno de 
\series bold
requisitos del sistema
\series default
 (
\series bold
SyRS
\series default
, 
\emph on
\lang english
System Requirements Specification
\emph default
\lang spanish
).
\end_layout

\begin_layout Standard
Un buen SRS documenta todo lo que el software debe hacer y lo que no mediante
 requisitos esenciales (funcionales, de rendimiento, restricciones de diseño
 y atributos) del software y de sus interfaces externas.
 También se puede elaborar una
\end_layout

\begin_layout Standard
Una buena SRS establece la base para el acuerdo entre clientes y proveedores,
 la estimación de costes, la planificación y futuras mejoras; reduce el
 esfuerzo de desarrollo al evitar re-diseñar o re-programar; sirve de referencia
 para la verificación y validación (V&V) y para comprobar el grado de cumplimien
to del contrato, y facilita adaptar el sistema a nuevos usuarios y máquinas.
\end_layout

\end_body
\end_document