Parte de GPDS.4

1 files changed, 137 insertions, 83 deletions

diff --git a/gpds/n3.lyx b/gpds/n3.lyx
index 0ad2114..b6c6037 100644
--- a/gpds/n3.lyx
+++ b/gpds/n3.lyx
@@ -105,9 +105,13 @@ requisito
  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 Alan Davis, 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.
+ 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
@@ -178,6 +182,65 @@ n, el modelado y la comunicación, y si quiere hacerse, debe justificarse
 \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
 
@@ -268,13 +331,6 @@ verifica
 \series default
  la corrección interna y externa de los modelos, usando prototipos, inspecciones
  y revisiones.
- 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 Enumerate
@@ -341,88 +397,61 @@ proceso de estudio y perfeccionamiento de los requisitos del sistema, hardware
 \end_layout
 
 \begin_layout Standard
-\begin_inset Note Comment
-status open
-
-\begin_layout Plain Layout
-\begin_inset Note Greyedout
-status open
-
-\begin_layout Plain Layout
-Es el proceso de estudio de las necesidades de los usuarios para llegar
- a una definición de los requisitos del sistema; el de estudio y perfeccionamien
-to de estos requisitos; la investigación de los requisitos de usuario para
- llegar a una definición de sistema, o la determinación del desempeño específico
- de un producto y sus características funcionales basada en análisis de
- las necesidades, expectativas y limitaciones del cliente, el concepto operativo
-, los entornos de utilización proyectados para personas, productos y procesos,
- y medidas de eficacia.
- Forma parte de la fase de definición del sistema software.
-\end_layout
-
-\end_inset
-
-
-\end_layout
-
-\end_inset
-
-
-\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.
+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
-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.
+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
-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
+No es viable que los requisitos queden 
+\begin_inset Quotes cld
+\end_inset
 
-\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}$
+congelados
+\begin_inset Quotes crd
 \end_inset
 
- de altura.
+, 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
@@ -498,5 +527,30 @@ cuantificable
 , pudiendo medir el grado de cumplimiento.
 \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 la adaptación del sistema a nuevos usuarios
+ y máquinas.
+\end_layout
+
+\begin_layout Section
+Reglas de negocio
+\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
+
 \end_body
 \end_document