Requisito requisito por qué eres tan putito

1 files changed, 392 insertions, 3 deletions

diff --git a/gpds/n3.lyx b/gpds/n3.lyx
index 844f444..d965493 100644
--- a/gpds/n3.lyx
+++ b/gpds/n3.lyx
@@ -121,6 +121,8 @@ 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
@@ -131,6 +133,10 @@ ciclo de vida
  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
@@ -152,8 +158,13 @@ metodología
  es un conjunto coherente de métodos relacionados por principios comunes.
 \end_layout
 
+\begin_layout Section
+Ingeniería del software 4D
+\end_layout
+
 \begin_layout Standard
-La ingeniería de software se puede ver desde 2 perspectivas:
+El conocimiento en ingeniería de software se puede clasificar según 4 dimensione
+s mediante 2 visiones:
 \end_layout
 
 \begin_layout Enumerate
@@ -161,12 +172,390 @@ La ingeniería de software se puede ver desde 2 perspectivas:
 \series bold
 Visión proceso
 \series default
-, propuesta para estructurar su corpus de conocimiento.
+, 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
+Ingeniería de 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.
+\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.
+\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
+ 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.
+\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.
+ 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
+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 
+\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).
+ 
+\begin_inset Note Note
+status open
+
+\begin_layout Plain Layout
+Diapo 77
+\end_layout
+
+\end_inset
+
+
+\end_layout
+
+\begin_layout Standard
 \begin_inset Note Note
 status open
 
 \begin_layout Plain Layout
-diapo 7
+De mayor a menor proyectos exitosos, Lean, Iterative, Agile, Ad-Hoc, Traditional
+ (Agile es el que menos fallidos tiene, seguido de Iterative, Lean, Ad-Hoc,
+ Traditional).
 \end_layout
 
 \end_inset