1 files changed, 324 insertions, 45 deletions
diff --git a/gpds/n3.lyx b/gpds/n3.lyx
index 844f444..2b89c79 100644
--- a/gpds/n3.lyx
+++ b/gpds/n3.lyx
@@ -81,97 +81,376 @@ algorithm2e
 \begin_body
 
 \begin_layout Standard
-La 
+Un 
 \series bold
-ingeniería
+objeto
 \series default
- es la aplicación del conocimiento y el método científicos al diseño y la
- creación de productos complejos.
- La ingeniería de software es 
+ es una entidad relevante del mundo real, una 
 \series bold
-sistemática
+función
 \series default
-, con planes y procedimientos metódicos; 
+ es una acción o secuencia de acciones que se puede llevar a cabo sobre
+ objetos y un 
 \series bold
-disciplinada
+estado
 \series default
-, sujeta a control respecto a ciertos estándares, y 
+ es una situación en que se puede encontrar un objeto.
+\end_layout
+
+\begin_layout Standard
+Un 
 \series bold
-cuantificable
+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.
+ 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 requisito es 
+\series bold
+funcional
+\series default
+ si describe qué hace el sistema y cuáles son sus entradas, salidas y funciones
+ de transformación, y es 
+\series bold
+no funcional
 \series default
-, pues tanto su realización como sus resultados son medibles.
+ si describe cómo funciona, incluyendo aspectos de compatibilidad, confidenciali
+dad, disponibilidad, eficiencia, escalabilidad, extensibilidad, fiabilidad,
+ seguridad, usabilidad, etc.
 \end_layout
 
 \begin_layout Standard
 Un 
 \series bold
-artefacto
+accionista
 \series default
- es algo tangible creado con un propósito práctico.
- Un 
+ o 
 \series bold
-proceso software
+parte interesada
 \series default
- es un conjunto coherente de políticas, estructuras organizativas, tecnologías,
- procedimientos y artefactos para concebir, desarrollar, implantar y mantener
- un producto software.
- Una 
+ 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 Section
+Ingeniería de requisitos
+\end_layout
+
+\begin_layout Standard
+La 
 \series bold
-actividad
+ingeniería de requisitos
 \series default
- es un proceso en el espacio-tiempo en el que un agente actúa con ciertos
- objetivos.
+ 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.
 \end_layout
 
 \begin_layout Standard
-El 
+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.
+ 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
+
+\begin_layout Standard
+Consta de:
+\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
-ciclo de vida
+estudio de viabilidad
 \series default
- de un producto o proyecto software es su evolución desde su concepción
- hasta que deja de usarse, y puede describirse según las actividades que
- se realizan en él.
- El 
+ 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
-modelo de ciclo de vida del software
+Adquisición.
+
 \series default
- es la especificación de las fases o el curso general de este ciclo de vida.
+ 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
-Un 
+Se decide si usar 
 \series bold
-método
+ingeniería inversa
 \series default
- es la especificación de una secuencia de acciones orientadas a un cierto
- propósito, y determina el orden y la forma de llevar a cabo unas actividades.
- Una 
+, 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
-metodología
+validan
 \series default
- es un conjunto coherente de métodos relacionados por principios comunes.
+ los modelos construidos con los requisitos y se 
+\series bold
+verifica
+\series default
+ la corrección interna y externa de los modelos.
+ Se hacen 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
-La ingeniería de software se puede ver desde 2 perspectivas:
+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
+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
+
+\begin_layout Standard
+Muchos proyectos software no dan los resultados esperados, se retrasan,
+ exceden el presupuesto o terminan llenos de errores, y muchas veces la
+ causa es un mal análisis de requisitos.
+ Esto es porque en general los clientes o usuarios no tienen realmente claro
+ qué quieren o cuál es el problema que quieren resolver, y por una mala
+ estimación del tiempo y coste del proyecto.
+\end_layout
+
+\begin_layout Standard
+Los errores relacionados con requisitos son los más caros de corregir.
+ 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
+Según 
+\emph on
+\lang english
+Standish Group
+\emph default
+\lang spanish
+, creadora de los informes 
+\lang english
+CHAOS
+\lang spanish
+, en 1995, las empresas y agencias del gobierno en Estados Unidos gastaron
+ 81000 millones de dólares en proyectos de software fallidos.
+\end_layout
+
+\begin_layout Standard
+Una 
+\series bold
+revisión de requisitos
+\series default
+ es una reunión en la que se presentan los requisitos de un elemento de
+ hardware, software o sistema a algunas partes interesadas para obtener
+ información o aprobación.
+ Forma parte de la 
 \series bold
-Visión proceso
+validación de requisitos
 \series default
-, propuesta para estructurar su corpus de conocimiento.
-\begin_inset Note Note
-status open
+.
+\end_layout
 
-\begin_layout Plain Layout
-diapo 7
+\begin_layout Standard
+El análisis de requisitos permite alcanzar un acuerdo entre clientes, productore
+s de software y usuarios sobre lo que hay que producir; proporciona la base
+ para el diseño; sirve de soporte para la verificación y validación de los
+ productos, y orienta a potenciales clientes sobre la definición de los
+ productos, creando a veces catálogos de requisitos alternativos para elegir.
 \end_layout
 
-\end_inset
+\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 elaboran 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
+).
+ En ambos, los requisitos deben tener un identificador único.
+\end_layout
 
+\begin_layout Standard
+Un SRS documenta todo lo que el software debe hacer y lo que no, incluyendo
+ restricciones que debe contemplar el futuro sistema, mediante requisitos
+ esenciales (funcionales, de rendimiento, restricciones de diseño y atributos)
+ del software y de sus interfaces externas.
+\end_layout
 
+\begin_layout Standard
+En una especificación de requisitos, los requisitos tienen un identificador
+ único; están 
+\series bold
+priorizados
+\series default
+, clasificados según prioridad, y se hace un 
+\series bold
+seguimiento
+\series default
+ de ellos para conocer su 
+\series bold
+estado
+\series default
+, de entre especificado, verificado, analizado, etc.
+ Un requisito debe ser verificable y puede ser 
+\series bold
+cuantificable
+\series default
+, pudiendo medir el grado de cumplimiento.
 \end_layout
 
 \end_body