GPDS tema 3 (y lo correspondiente de PDS tema 1)

3 files changed, 571 insertions, 307 deletions

diff --git a/gpds/n.lyx b/gpds/n.lyx
index aec1292..06184b3 100644
--- a/gpds/n.lyx
+++ b/gpds/n.lyx
@@ -163,7 +163,7 @@ ISO/IEC 15504
 \end_layout
 
 \begin_layout Chapter
-Modelos de mejora de procesos
+Ingeniería de software
 \end_layout
 
 \begin_layout Standard
diff --git a/gpds/n1.lyx b/gpds/n1.lyx
index 5fd21ef..03f04c8 100644
--- a/gpds/n1.lyx
+++ b/gpds/n1.lyx
@@ -81,10 +81,271 @@ algorithm2e
 \begin_body
 
 \begin_layout Standard
-La ingeniería de software busca satisfacer el deseo de las organizaciones
- de construir productos y servicios de software de alta calidad cada vez
- más complejos y dedicando menos tiempo y dinero, mediante la construcción,
- adquisición e integración de componentes.
+La 
+\series bold
+ingeniería
+\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 
+\series bold
+ingeniería de software
+\series default
+ busca satisfacer el deseo de las organizaciones de construir productos
+ y servicios de software de alta calidad cada vez más complejos y dedicando
+ menos tiempo y dinero, mediante la construcción, adquisición e integración
+ de componentes.
+ Es 
+\series bold
+sistemática
+\series default
+, con planes y procedimientos metódicos; 
+\series bold
+disciplinada
+\series default
+, sujeta a control respecto a ciertos estándares, y 
+\series bold
+cuantificable
+\series default
+, pues tanto su realización como sus resultados son medibles.
+\end_layout
+
+\begin_layout Standard
+Un 
+\series bold
+artefacto
+\series default
+ es algo tangible creado con un propósito práctico.
+ Un 
+\series bold
+proceso software
+\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 
+\series bold
+actividad
+\series default
+ es un proceso en el espacio-tiempo en el que un agente actúa con ciertos
+ objetivos.
+ Las 4 actividades básicas en ingeniería de software son especificación,
+ desarrollo, validación y evolución.
+\end_layout
+
+\begin_layout Standard
+El 
+\series bold
+ciclo de vida
+\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.
+ Estas son actividades técnicas, colaborativas y de gestión que forman parte
+ de las 4 actividades básicas, que suelen entrelazarse debido a que el software
+ se modifica continuamente a lo largo de su ciclo de vida en respuesta a
+ los requisitos cambiantes y las necesidades del cliente.
+ El 
+\series bold
+modelo de ciclo de vida del software
+\series default
+ es la especificación de las fases o el curso general de este ciclo de vida.
+\end_layout
+
+\begin_layout Standard
+Un 
+\series bold
+método
+\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 
+\series bold
+metodología
+\series default
+ es un conjunto coherente de métodos relacionados por principios comunes.
+\end_layout
+
+\begin_layout Section
+Dimensiones
+\end_layout
+
+\begin_layout Standard
+El SEI clasifica el conocimiento en ingeniería de software en 4 dimensiones
+ mediante 2 visiones:
+\end_layout
+
+\begin_layout Enumerate
+
+\series bold
+Visión proceso
+\series default
+, propuesta para estructurar su corpus de conocimiento en base a dos dimensiones
+:
+\end_layout
+
+\begin_deeper
+\begin_layout Enumerate
+
+\series bold
+Actividad
+\series default
+, que clasifica las actividades realizadas en ingeniería de software:
+\end_layout
+
+\begin_deeper
+\begin_layout Enumerate
+
+\series bold
+Desarrollo:
+\series default
+ Actividades que producen artefactos, como análisis de requisitos, especificació
+n, diseño, implementación y pruebas.
+\end_layout
+
+\begin_layout Enumerate
+
+\series bold
+Control:
+\series default
+ Actividades que moderan el desarrollo, como evolución del software (control
+ de versiones, cambios, gestión de configuraciones, etc.) y calidad del software
+ (aseguramiento, control y prueba, etc.).
+\end_layout
+
+\begin_layout Enumerate
+
+\series bold
+Gestión:
+\series default
+ Actividades que implican a ejecutivos, administrativos y supervisores,
+ incluyendo las actividades técnicas de soporte a su trabajo, como planificación
+ de proyectos, estimación de costes, asignación de recursos, constitución
+ de equipos o asuntos legales y de contratación.
+\end_layout
+
+\begin_layout Enumerate
+
+\series bold
+Operaciones:
+\series default
+ Actividades relacionadas con el uso del software en la organización, como
+ la formación, la planificación de la puesta en marcha, la puesta en marcha,
+ la transición al nuevo sistema, la operación del software y la gestión
+ de su retirada.
+\end_layout
+
+\end_deeper
+\begin_layout Enumerate
+
+\series bold
+Aspecto
+\series default
+, con los aspectos similares de cada actividad:
+\end_layout
+
+\begin_deeper
+\begin_layout Enumerate
+
+\series bold
+Abstracciones:
+\series default
+ Principios fundamentales como ocultación de información o principios de
+ diseño, y modelos formales como de proceso de desarrollo (en cascada, prototipa
+do, etc.), de computación secuencial y concurrente (máquinas de estado finito,
+ redes de Petri, etc.) o de estimación de costes (COCOMO, etc.)
+\end_layout
+
+\begin_layout Enumerate
+
+\series bold
+Representación:
+\series default
+ Notaciones como tablas de decisión, DFD o PERT, y lenguajes como Ada.
+\end_layout
+
+\begin_layout Enumerate
+
+\series bold
+Métodos:
+\series default
+ Métodos formales como pruebas de corrección para la verificación o especificaci
+ones ejecutables; intuitivos como AE, AOO o DOO, y prácticas comunes como
+ la programación estructurada para la implementación).
+\end_layout
+
+\begin_layout Enumerate
+
+\series bold
+Herramientas:
+\series default
+ Integradas o de software individual, como correo electrónico, procesador
+ de textos, CASE o compiladores.
+\end_layout
+
+\begin_layout Enumerate
+
+\series bold
+Evaluación:
+\series default
+ Métricas, análisis y evaluación de los productos y el proceso software
+ y del impacto en las organizaciones, para mejorar futuros desarrollos.
+\end_layout
+
+\begin_layout Enumerate
+
+\series bold
+Comunicación:
+\series default
+ Oral y escrita en forma de documentación o formación.
+\end_layout
+
+\end_deeper
+\end_deeper
+\begin_layout Enumerate
+
+\series bold
+Visión producto
+\series default
+, que amplía la presentación unidimensional basada en el ciclo de vida típico
+ de análisis de requisitos, especificación, diseño, implementación, prueba
+ y mantenimiento con dos dimensiones:
+\end_layout
+
+\begin_deeper
+\begin_layout Enumerate
+
+\series bold
+Clase de sistema software
+\series default
+, con características específicas de un software concreto, por ejemplo el
+ software concurrente, para el que existen distintos lenguajes y notaciones
+ de diseño y especificación.
+ Los grupos resultantes de la clasificación no tienen por qué ser disjuntos.
+\end_layout
+
+\begin_deeper
+\begin_layout Standard
+Según el dominio distinguimos sistemas de comunicación, de aviación, sistemas
+ operativos, bases de datos, etc.
+ Según el tipo de relación con el entorno distinguimos sistemas por lotes,
+ reactivos, interactivos, de tiempo real, embebidos, etc.
+\end_layout
+
+\end_deeper
+\begin_layout Enumerate
+
+\series bold
+Requisitos del sistema
+\series default
+, con las propiedades que debería tener el sistema a construir.
+ Se suele restringir a aspectos funcionales, pero la consecución de los
+ no funcionales depende de muchas de las actividades realizadas en el proceso.
+\end_layout
+
+\end_deeper
+\begin_layout Section
+Procesos software
 \end_layout
 
 \begin_layout Standard
@@ -136,6 +397,127 @@ La tecnología puede ser muy útil con los procesos apropiados, pero no siempre
 \end_layout
 
 \begin_layout Section
+Estrategias de desarrollo de software
+\end_layout
+
+\begin_layout Standard
+El 
+\series bold
+ciclo de desarrollo
+\series default
+ de un producto software es la parte de su ciclo de vida desde el análisis
+ hasta la entrega.
+ Algunas estrategias son:
+\end_layout
+
+\begin_layout Enumerate
+
+\series bold
+Modelo en cascada
+\series default
+, en que se hacen las fases en orden secuencial.
+ Útil cuando los requisitos son fijos y el trabajo avanza de forma lineal,
+ al contrario que en la actualidad.
+\end_layout
+
+\begin_layout Enumerate
+
+\series bold
+Iterativo
+\series default
+ e 
+\series bold
+incremental
+\series default
+, con iteraciones en las que se hacen todas las fases para lo siguiente
+ a implementar.
+\end_layout
+
+\begin_layout Enumerate
+
+\series bold
+MDD
+\series default
+ (
+\series bold
+\emph on
+\lang english
+Model-Driven Development
+\series default
+\emph default
+\lang spanish
+): La principal salida del proceso son los modelos, no los programas.
+ Un 
+\series bold
+PSM
+\series default
+ (
+\series bold
+\emph on
+\lang english
+Platform-Specific Model
+\series default
+\emph default
+\lang spanish
+) describe una solución desde la perspectiva de una plataforma concreta.
+ También hay 
+\series bold
+CIMs
+\series default
+ (
+\emph on
+\lang english
+Computing-Independent Models
+\emph default
+\lang spanish
+) y 
+\series bold
+PIMs
+\series default
+ (
+\emph on
+\lang english
+Platform-Independent Models
+\emph default
+\lang spanish
+).
+\end_layout
+
+\begin_layout Standard
+La estrategia más adaptativa, y la menos prescriptiva, es hacer lo que sea.
+ De las usadas, de la más adaptativa a la más prescriptiva, están Kanban
+ (
+\emph on
+\lang english
+lean
+\emph default
+\lang spanish
+, 3 reglas), Scrum (ágil, 9 reglas), XP (ágil, 13 reglas) y RUP (más de
+ 120 reglas).
+\end_layout
+
+\begin_layout Standard
+Los métodos ágiles, iterativos y 
+\emph on
+lean
+\emph default
+ tienen más posibilidades de éxito y menos de fallo que los ad-hoc, al contrario
+ de lo que ocurre a los tradicionales en cascada.
+\end_layout
+
+\begin_layout Standard
+
+\series bold
+DevOps
+\series default
+ se apoya en los principios 
+\emph on
+lean
+\emph default
+ y ágil para proporcionar ingeniería de software continua.
+\end_layout
+
+\begin_layout Section
 Modelos de mejora
 \end_layout
 
@@ -403,12 +785,12 @@ Una organización de software puede adoptar modelos de mejora de procesos
  industria.
 \end_layout
 
-\begin_layout Section
-ISO/IEC 33000
-\end_layout
-
 \begin_layout Standard
-Es una familia de normas de evaluación de procesos en ingeniería en general,
+
+\series bold
+ISO/IEC 33000
+\series default
+ es una familia de normas de evaluación de procesos en ingeniería en general,
  que suplanta al estándar 
 \series bold
 ISO/IEC TR 15504
@@ -525,14 +907,14 @@ Proceso de Gestión de Riesgos, Proceso de Verificación del Software, Proceso
 re.
 \end_layout
 
-\begin_layout Section
-ITmark
-\end_layout
-
 \begin_layout Standard
-Certificación orientada a PYMES del grupo TECNALIA del ESI, con presencia
- en más de 16 países en Europa y América latina, que combina modelos y estándare
-s de calidad y mejora de procesos como CMMi, ISO 20000, 
+
+\series bold
+ITMark
+\series default
+ es una certificación orientada a PYMES del grupo TECNALIA del ESI, con
+ presencia en más de 16 países en Europa y América latina, que combina modelos
+ y estándares de calidad y mejora de procesos como CMMi, ISO 20000, 
 \series bold
 ISO 27000
 \series default
diff --git a/gpds/n3.lyx b/gpds/n3.lyx
index 7d844ba..2b89c79 100644
--- a/gpds/n3.lyx
+++ b/gpds/n3.lyx
@@ -81,310 +81,239 @@ algorithm2e
 \begin_body
 
 \begin_layout Standard
-La 
-\series bold
-ingeniería
-\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 
+Un 
 \series bold
-sistemática
+objeto
 \series default
-, con planes y procedimientos metódicos; 
+ es una entidad relevante del mundo real, una 
 \series bold
-disciplinada
+función
 \series default
-, sujeta a control respecto a ciertos estándares, y 
+ es una acción o secuencia de acciones que se puede llevar a cabo sobre
+ objetos y un 
 \series bold
-cuantificable
+estado
 \series default
-, pues tanto su realización como sus resultados son medibles.
+ es una situación en que se puede encontrar un objeto.
 \end_layout
 
 \begin_layout Standard
 Un 
 \series bold
-artefacto
-\series default
- es algo tangible creado con un propósito práctico.
- Un 
-\series bold
-proceso software
-\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 
-\series bold
-actividad
+requisito
 \series default
- es un proceso en el espacio-tiempo en el que un agente actúa con ciertos
- objetivos.
- Las 4 actividades básicas en ingeniería de software son especificación,
- desarrollo, validación y evolución.
+ 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
-El 
+Un requisito es 
 \series bold
-ciclo de vida
+funcional
 \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.
- Estas son actividades técnicas, colaborativas y de gestión que forman parte
- de las 4 actividades básicas, que suelen entrelazarse debido a que el software
- se modifica continuamente a lo largo de su ciclo de vida en respuesta a
- los requisitos cambiantes y las necesidades del cliente.
- El 
+ si describe qué hace el sistema y cuáles son sus entradas, salidas y funciones
+ de transformación, y es 
 \series bold
-modelo de ciclo de vida del software
+no funcional
 \series default
- es la especificación de las fases o el curso general de este ciclo de vida.
+ 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
-método
+accionista
 \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 
+ o 
 \series bold
-metodología
+parte interesada
 \series default
- es un conjunto coherente de métodos relacionados por principios comunes.
+ 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 del software 4D
+Ingeniería de requisitos
 \end_layout
 
 \begin_layout Standard
-El SEI clasifica el conocimiento en ingeniería de software en 4 dimensiones
- mediante 2 visiones:
+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.
 \end_layout
 
-\begin_layout Enumerate
+\begin_layout Standard
+Se le suele dedicar el 
+\begin_inset Formula $\unit[10]{\%}$
+\end_inset
 
-\series bold
-Visión proceso
-\series default
-, propuesta para estructurar su corpus de conocimiento en base a dos dimensiones
-:
+ 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_deeper
 \begin_layout Enumerate
 
 \series bold
-Actividad
-\series default
-, que clasifica las actividades realizadas en ingeniería de software:
+Identificación y consenso.
 \end_layout
 
 \begin_deeper
 \begin_layout Enumerate
 
 \series bold
-Desarrollo:
+Contexto.
+
 \series default
- Actividades que producen artefactos, como análisis de requisitos, especificació
-n, diseño, implementación y pruebas.
+ Se establecen las necesidades iniciales de la organización y se delimita
+ el alcance del proyecto.
 \end_layout
 
 \begin_layout Enumerate
 
 \series bold
-Control:
-\series default
- Actividades que moderan el desarrollo, como evolución del software (control
- de versiones, cambios, gestión de configuraciones, etc.) y calidad del software
- (aseguramiento, control y prueba, etc.).
-\end_layout
-
-\begin_layout Enumerate
+Trabajo preliminar.
 
+\series default
+ Se identifican los interlocutores concretos y suministradores de información.
+ Se hace un 
 \series bold
-Gestión:
+estudio de viabilidad
 \series default
- Actividades que implican a ejecutivos, administrativos y supervisores,
- incluyendo las actividades técnicas de soporte a su trabajo, como planificación
- de proyectos, estimación de costes, asignación de recursos, constitución
- de equipos o asuntos legales y de contratación.
+ 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
-Operaciones:
+Adquisición.
+
 \series default
- Actividades relacionadas con el uso del software en la organización, como
- la formación, la planificación de la puesta en marcha, la puesta en marcha,
- la transición al nuevo sistema, la operación del software y la gestión
- de su retirada.
+ 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
-Aspecto
-\series default
-, con los aspectos similares de cada actividad:
-\end_layout
-
-\begin_deeper
-\begin_layout Enumerate
+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
-Abstracciones:
+poder expresivo
 \series default
- Principios fundamentales como ocultación de información o principios de
- diseño, y modelos formales como de proceso de desarrollo (en cascada, prototipa
-do, etc.), de computación secuencial y concurrente (máquinas de estado finito,
- redes de Petri, etc.) o de estimación de costes (COCOMO, etc.)
+: la variedad de tipos de requisitos que pueden ser capturados y la capacidad
+ para suministrar mucha información en poco espacio.
 \end_layout
 
-\begin_layout Enumerate
-
+\begin_deeper
+\begin_layout Standard
+Se decide si usar 
 \series bold
-Representación:
+ingeniería inversa
 \series default
- Notaciones como tablas de decisión, DFD o PERT, y lenguajes como Ada.
+, 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
-Métodos:
-\series default
- Métodos formales como pruebas de corrección para la verificación o especificaci
-ones ejecutables; intuitivos como AE, AOO o DOO, y prácticas comunes como
- la programación estructurada para la implementación).
-\end_layout
-
-\begin_layout Enumerate
+Análisis.
 
+\series default
+ Se 
 \series bold
-Herramientas:
+validan
 \series default
- Integradas o de software individual, como correo electrónico, procesador
- de textos, CASE o compiladores.
-\end_layout
-
-\begin_layout Enumerate
-
+ los modelos construidos con los requisitos y se 
 \series bold
-Evaluación:
+verifica
 \series default
- Métricas, análisis y evaluación de los productos y el proceso software
- y del impacto en las organizaciones, para mejorar futuros desarrollos.
+ la corrección interna y externa de los modelos.
+ Se hacen prototipos, inspecciones y revisiones.
 \end_layout
 
 \begin_layout Enumerate
 
 \series bold
-Comunicación:
+Documentación y comunicación.
+
 \series default
- Oral y escrita en forma de documentación o formación.
+ Se organiza la información.
 \end_layout
 
-\end_deeper
-\end_deeper
 \begin_layout Enumerate
 
 \series bold
-Visión producto
-\series default
-, que amplía la presentación unidimensional basada en el ciclo de vida típico
- de análisis de requisitos, especificación, diseño, implementación, prueba
- y mantenimiento con dos dimensiones:
-\end_layout
-
-\begin_deeper
-\begin_layout Enumerate
+Gestión y mantenimiento.
 
+\series default
+ Se sigue la vida de los requisitos por todo el proceso de desarrollo para
+ conseguir 
 \series bold
-Clase de sistema software
+trazabilidad
 \series default
-, con características específicas de un software concreto, por ejemplo el
- software concurrente, para el que existen distintos lenguajes y notaciones
- de diseño y especificación.
- Los grupos resultantes de la clasificación no tienen por qué ser disjuntos.
-\end_layout
-
-\begin_deeper
-\begin_layout Standard
-Según el dominio distinguimos sistemas de comunicación, de aviación, sistemas
- operativos, bases de datos, etc.
- Según el tipo de relación con el entorno distinguimos sistemas por lotes,
- reactivos, interactivos, de tiempo real, embebidos, etc.
-\end_layout
-
-\end_deeper
-\begin_layout Enumerate
-
+.
+ Se definen los procedimientos de 
 \series bold
-Requisitos del sistema
+gestión de cambios de requisitos
 \series default
-, con las propiedades que debería tener el sistema a construir.
- Se suele restringir a aspectos funcionales, pero la consecución de los
- no funcionales depende de muchas de las actividades realizadas en el proceso.
-\end_layout
-
-\end_deeper
-\begin_layout Section
-Ingeniería de requisitos
+, 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
-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.
+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 Standard
-Un 
-\series bold
-requisito
-\series default
- es una declaración de una necesidad a satisfacer por un producto, junto
- a sus limitaciones y condiciones.
- 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.
+\begin_layout Section
+Análisis de requisitos
 \end_layout
 
 \begin_layout Standard
-Un 
-\series bold
-análisis de requisitos
-\series default
- es un proceso de estudio de las necesidades del usuario para llegar a una
- definición de los requisitos del sistema, de estudio y perfeccionamiento
- de estos requisitos, de investigación de los requisitos de usuario para
- llegar a una definición de sistema, o de determinación del desempeño específico
- de un producto y las características funcionales basado en análisis de
+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 una mala especificación de requisitos.
+ 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.
@@ -429,146 +358,99 @@ CHAOS
 \end_layout
 
 \begin_layout Standard
-Se suele dedicar el 
-\begin_inset Formula $\unit[10]{\%}$
-\end_inset
-
- del esfuerzo de un proyecto a los requisitos, aunque dedicar más esfuerzo
- disminuye el tiempo total del proyecto.
-\end_layout
-
-\begin_layout Section
-Estrategias de desarrollo de software
-\end_layout
-
-\begin_layout Standard
-El 
+Una 
 \series bold
-ciclo de desarrollo
+revisión de requisitos
 \series default
- de un producto software es la parte de su ciclo de vida desde el análisis
- hasta la entrega.
- Algunas estrategias son:
-\end_layout
-
-\begin_layout Enumerate
-
+ 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
-Modelo en cascada
+validación de requisitos
 \series default
-, en que se hacen las fases en orden secuencial.
- Útil cuando los requisitos son fijos y el trabajo avanza de forma lineal,
- al contrario que en la actualidad.
+.
 \end_layout
 
-\begin_layout Enumerate
-
-\series bold
-Iterativo
-\series default
- e 
-\series bold
-incremental
-\series default
-, con iteraciones en las que se hacen todas las fases para lo siguiente
- a implementar.
+\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
 
-\begin_layout Enumerate
+\begin_layout Section
+Especificación de requisitos
+\end_layout
 
+\begin_layout Standard
+Una 
 \series bold
-MDD
-\series default
- (
-\series bold
-\emph on
-\lang english
-Model-Driven Development
+especificación
 \series default
-\emph default
-\lang spanish
-): La principal salida del proceso son los modelos, no los programas.
- Un 
+ 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
-PSM
+documento de especificación de requisitos del software
 \series default
  (
 \series bold
+SRS
+\series default
+, 
 \emph on
 \lang english
-Platform-Specific Model
-\series default
+Software Requirements Specification
 \emph default
 \lang spanish
-) describe una solución desde la perspectiva de una plataforma concreta.
- También hay 
+) y, en su caso, uno de 
 \series bold
-CIMs
+requisitos del sistema
 \series default
  (
-\emph on
-\lang english
-Computing-Independent Models
-\emph default
-\lang spanish
-) y 
 \series bold
-PIMs
+SyRS
 \series default
- (
+, 
 \emph on
 \lang english
-Platform-Independent Models
+System Requirements Specification
 \emph default
 \lang spanish
 ).
+ En ambos, los requisitos deben tener un identificador único.
 \end_layout
 
 \begin_layout Standard
-La estrategia más adaptativa, y la menos prescriptiva, es hacer lo que sea.
- De las usadas, de la más adaptativa a la más prescriptiva, están Kanban
- (
-\emph on
-\lang english
-lean
-\emph default
-\lang spanish
-, 3 reglas), Scrum (ágil, 9 reglas), XP (ágil, 13 reglas) y RUP (más de
- 120 reglas).
-\end_layout
-
-\begin_layout Standard
-Los métodos ágiles, iterativos y 
-\emph on
-lean
-\emph default
- tienen más posibilidades de éxito y menos de fallo que los ad-hoc, al contrario
- de lo que ocurre a los tradicionales en cascada.
+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
-DevOps
+priorizados
 \series default
- se apoya en los principios 
-\emph on
-lean
-\emph default
- y ágil para proporcionar ingeniería de software continua.
-\end_layout
-
-\begin_layout Standard
-\begin_inset Note Note
-status open
-
-\begin_layout Plain Layout
-
-\end_layout
-
-\end_inset
-
-
+, 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