PDS tema 5

1 files changed, 433 insertions, 0 deletions

diff --git a/gpds/n4.lyx b/gpds/n4.lyx
new file mode 100644
index 0000000..56b5950
--- /dev/null
+++ b/gpds/n4.lyx
@@ -0,0 +1,433 @@
+#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
+Un 
+\series bold
+documento de requisitos
+\series default
+ (
+\series bold
+del proyecto
+\series default
+) o 
+\series bold
+especificación funcional
+\series default
+ combina un SRS y un SyRS.
+ Contiene un conjunto exhaustivo y preciso de los requisitos, validados,
+ y sirve como contrato entre el cliente y los desarrolladores.
+\end_layout
+
+\begin_layout Standard
+Se prepara en un bucle de 4 fases:
+\end_layout
+
+\begin_layout Enumerate
+
+\series bold
+Obtención
+\series default
+, en que se determinan los requisitos para llegar un conocimiento suficiente
+ del problema y establecer los límites del sistema.
+\end_layout
+
+\begin_layout Enumerate
+
+\series bold
+Análisis
+\series default
+, en que se examinan los requisitos para delimitarlos y definirlos exactamente.
+\end_layout
+
+\begin_layout Enumerate
+
+\series bold
+Especificación
+\series default
+, en que se escriben los requisitos.
+\end_layout
+
+\begin_layout Enumerate
+
+\series bold
+Validación
+\series default
+, en que se examina si los documentos de requisitos definen el software
+ que los usuarios esperan.
+\end_layout
+
+\begin_layout Standard
+Puede estructurarse como:
+\end_layout
+
+\begin_layout Enumerate
+Necesidades del usuario o requisitos del negocio.
+\end_layout
+
+\begin_layout Enumerate
+Documento de Requisitos del Producto (
+\series bold
+PRD
+\series default
+, 
+\emph on
+\lang english
+Product Requirements Document
+\emph default
+\lang spanish
+).
+\end_layout
+
+\begin_layout Enumerate
+Especificación de requisitos de software (SRS) o hardware.
+\end_layout
+
+\begin_layout Enumerate
+
+\emph on
+\lang english
+Tests
+\emph default
+\lang spanish
+ para los requisitos de software (
+\series bold
+STS
+\series default
+, 
+\emph on
+\lang english
+Software Test Specification
+\emph default
+\lang spanish
+) o hardware.
+\end_layout
+
+\begin_layout Standard
+Otra posible estructura es:
+\end_layout
+
+\begin_layout Enumerate
+
+\series bold
+Documento de Visión
+\series default
+ (
+\series bold
+y Alcance
+\series default
+), con la lista de participantes clave, los requisitos de negocio y el PRD.
+\end_layout
+
+\begin_layout Enumerate
+
+\series bold
+Documento de Casos de Uso
+\series default
+, con los requisitos de usuario como casos de uso.
+\end_layout
+
+\begin_layout Enumerate
+SRS.
+\end_layout
+
+\begin_layout Standard
+El tipo y número de documentos de requisitos, la organización y preparación
+ de estos y la forma de definir interrelaciones o jerarquías entre los requisito
+s deben estar claras desde el principio del proyecto, y aunque pueden variar
+ de un proyecto a otro según las características de cada uno, es preferible
+ que se conviertan en una norma.
+\end_layout
+
+\begin_layout Section
+Clasificación de requisitos
+\end_layout
+
+\begin_layout Standard
+Los requisitos pueden ser:
+\end_layout
+
+\begin_layout Itemize
+
+\series bold
+Del dominio del problema:
+\series default
+ 
+\series bold
+requisitos de empresa
+\series default
+ o 
+\series bold
+de producto
+\series default
+, 
+\series bold
+objetivos
+\series default
+, 
+\series bold
+necesidades
+\series default
+ o 
+\series bold
+reglas de negocio
+\series default
+, y son requisitos de alto nivel de la organización o el cliente, recogidos
+ en el PRD.
+ Información general de las necesidades de los usuarios.
+ Reglas.
+\end_layout
+
+\begin_layout Itemize
+
+\series bold
+Del dominio de la solución: Requisitos de usuario
+\series default
+, tareas que el usuario debe poder realizar con el producto, representadas
+ mediante texto, casos de uso o descripciones de escenarios.
+ 
+\series bold
+Requisitos de software
+\series default
+, funcionales o no, atributos de calidad y restricciones de diseño.
+ Requisitos de hardware.
+\end_layout
+
+\begin_layout Standard
+CMMi 2.0 distingue requisitos:
+\end_layout
+
+\begin_layout Description
+Del
+\begin_inset space ~
+\end_inset
+
+cliente Resultado de obtener necesidades; resolver conflictos entre ellas
+ y las expectativas, limitaciones e interfaces, y definir las soluciones
+ con las partes interesadas afectadas de forma aceptable para ellas.
+\end_layout
+
+\begin_layout Description
+Contractual Resultado del análisis y refinamiento de los requisitos del
+ cliente en un conjunto de requisitos adecuado para su inclusión en solicitudes
+ o acuerdos con proveedores.
+\end_layout
+
+\begin_layout Description
+
+\series bold
+De
+\begin_inset space ~
+\end_inset
+
+producto
+\series default
+ Refinamiento de los requisitos de cliente en lenguaje próximo a los desarrollad
+ores para guiar el diseño del sistema.
+\end_layout
+
+\begin_layout Description
+De
+\begin_inset space ~
+\end_inset
+
+componente
+\begin_inset space ~
+\end_inset
+
+de
+\begin_inset space ~
+\end_inset
+
+producto Especificación completa de un componente de un producto o servicio,
+ incluyendo ajuste, forma y función.
+\end_layout
+
+\begin_layout Description
+De
+\begin_inset space ~
+\end_inset
+
+contexto Estándares aplicables, leyes, políticas, prácticas habituales,
+ decisiones de dirección, rendimiento, etc.
+\end_layout
+
+\begin_layout Description
+Derivados Inferidos de requisitos de contexto o necesarios para especificar
+ un componente.
+ Puede aparecer también en el análisis y diseño de componentes.
+\end_layout
+
+\begin_layout Description
+Asignado
+\begin_inset space ~
+\end_inset
+
+(
+\emph on
+allocated
+\series bold
+\emph default
+)
+\series default
+ Requisito resultante de imponer todo o parte de un requisito de nivel superior
+ a un componente de diseño de nivel inferior, lógico o físico, incluyendo
+ una persona, un consumible, un incremento de la entrega o la arquitectura.
+\end_layout
+
+\begin_layout Description
+Técnicos Propiedades de productos o servicios a ser adquiridos o desarrollados.
+\end_layout
+
+\begin_layout Description
+No
+\begin_inset space ~
+\end_inset
+
+técnicos Afectan a la adquisición o el desarrollo del sistema pero no son
+ propiedades de este.
+\end_layout
+
+\begin_layout Standard
+Los requisitos se pueden definir mediante:
+\end_layout
+
+\begin_layout Itemize
+
+\series bold
+Lenguaje natural.
+
+\series default
+ Si el texto es preciso, es lo más fácil de entender, pero si la especificación
+ es grande o compleja puede no ser manejable.
+\end_layout
+
+\begin_layout Itemize
+
+\series bold
+Texto y técnicas
+\series default
+ intuitivas o formales, como diagramas, lenguajes de descripción de diseños
+ o especificaciones lógicas formales.
+ Es lo ideal para sistemas de tamaño medio o grande.
+\end_layout
+
+\begin_layout Itemize
+
+\series bold
+Solo técnicas.
+
+\series default
+ Difícil de entender y rastrear.
+\end_layout
+
+\begin_layout Section
+Estándares
+\end_layout
+
+\begin_layout Standard
+La NASA, la ESA y el Departamento de Defensa de EE.UU.
+ tienen sus propios estándares para especificación de requisitos, pero los
+ más usados son:
+\end_layout
+
+\begin_layout Itemize
+
+\series bold
+IEEE Std.
+ 830-1998
+\begin_inset Note Note
+status open
+
+\begin_layout Plain Layout
+
+\series bold
+diapo 28
+\end_layout
+
+\end_inset
+
+
+\end_layout
+
+\end_body
+\end_document