From 5ea76eb7b2a4ce83c15b94a7c63e793400e51a22 Mon Sep 17 00:00:00 2001 From: Juan Marín Noguera Date: Sun, 11 Apr 2021 22:10:09 +0200 Subject: Requisito requisito por qué eres tan putito MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- gpds/n3.lyx | 395 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 392 insertions(+), 3 deletions(-) (limited to 'gpds') 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 -- cgit v1.2.3 From 3b66d0cbefd532395ff7b0f24bb5dc0231e79775 Mon Sep 17 00:00:00 2001 From: Juan Marín Noguera Date: Wed, 14 Apr 2021 16:37:27 +0200 Subject: SWENG/2.0-TRANSACTIONAL --- gpds/n3.lyx | 28 ++++++++++++++++++---------- 1 file changed, 18 insertions(+), 10 deletions(-) (limited to 'gpds') diff --git a/gpds/n3.lyx b/gpds/n3.lyx index d965493..88d6f47 100644 --- a/gpds/n3.lyx +++ b/gpds/n3.lyx @@ -535,17 +535,27 @@ lean \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 +\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 Standard @@ -553,9 +563,7 @@ Diapo 77 status open \begin_layout Plain Layout -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 -- cgit v1.2.3 From 9acc591166dfe4db91abb9113957cda9365b35a2 Mon Sep 17 00:00:00 2001 From: Juan Marín Noguera Date: Wed, 14 Apr 2021 16:53:39 +0200 Subject: Fases genéricas [shared] MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- gpds/n3.lyx | 4 +-- pds/n1.lyx | 86 +++++++++++++++++++++++++++++++++++++++++++++++++++---------- 2 files changed, 74 insertions(+), 16 deletions(-) (limited to 'gpds') diff --git a/gpds/n3.lyx b/gpds/n3.lyx index 88d6f47..7d844ba 100644 --- a/gpds/n3.lyx +++ b/gpds/n3.lyx @@ -163,8 +163,8 @@ Ingeniería del software 4D \end_layout \begin_layout Standard -El conocimiento en ingeniería de software se puede clasificar según 4 dimensione -s mediante 2 visiones: +El SEI clasifica el conocimiento en ingeniería de software en 4 dimensiones + mediante 2 visiones: \end_layout \begin_layout Enumerate diff --git a/pds/n1.lyx b/pds/n1.lyx index 2cfeca8..0c0953d 100644 --- a/pds/n1.lyx +++ b/pds/n1.lyx @@ -721,31 +721,89 @@ Independientemente del área o la complejidad del proyecto, el desarrollo \begin_layout Enumerate \series bold -Definición: +Definición \series default - Se analiza cuál es la funcionalidad del -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Diapo 51 +, +\series bold +análisis +\series default + o +\series bold +qué hacer: +\series default + Se analiza cuál es la funcionalidad del sistema, qué información debe manejar + y las restricciones de diseño, elaborando una +\series bold +especificación de requisitos del sistema +\series default + ( +\series bold +SyRS +\series default +, +\emph on +\lang english +System Requirements Specification +\emph default +\lang spanish +) y +\series bold +del software +\series default + ( +\series bold +SRS +\series default +, +\emph on +\lang english +Software Requirements Specification +\emph default +\lang spanish +), y se planifica el proyecto. \end_layout -\end_inset - +\begin_layout Enumerate +\series bold +Desarrollo +\series default + o +\series bold +cómo hacerlo: +\series default + Consta del +\series bold +diseño +\series default + de las estructuras de datos, los algoritmos, las interfaces y la forma + de pasar del diseño al lenguaje de programación y hacer la prueba; la +\series bold +implementación +\series default + o +\series bold +codificación +\series default + de los programas, incluyendo documentación, y la +\series bold +prueba +\series default +. \end_layout \begin_layout Enumerate -, + \series bold -desarrollo +Mantenimiento \series default - (diseño, implementación y prueba) o + o \series bold -mantenimiento +gestión de cambios: \series default -. + Una vez construido y desplegado el software, este se mejora, se adapta + a nuevas necesidades de los usuarios y se corrigen los fallos que se encuentran. + Es donde suele recaer la mayor parte del coste del sistema. \end_layout \end_body -- cgit v1.2.3 From 6131541e2234e1136b276a27cb5430dcb02c2f89 Mon Sep 17 00:00:00 2001 From: Juan Marín Noguera Date: Wed, 14 Apr 2021 18:14:59 +0200 Subject: GPDS tema 3 (y lo correspondiente de PDS tema 1) --- gpds/n.lyx | 2 +- gpds/n1.lyx | 414 ++++++++++++++++++++++++++++++++++++++++++++++++++--- gpds/n3.lyx | 462 ++++++++++++++++++++++-------------------------------------- pds/n1.lyx | 30 +--- 4 files changed, 572 insertions(+), 336 deletions(-) (limited to 'gpds') 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 @@ -135,6 +396,127 @@ La tecnología puede ser muy útil con los procesos apropiados, pero no siempre para trabajar en un mundo cambiante de forma productiva. \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 diff --git a/pds/n1.lyx b/pds/n1.lyx index 0c0953d..c2db4b5 100644 --- a/pds/n1.lyx +++ b/pds/n1.lyx @@ -732,35 +732,7 @@ análisis qué hacer: \series default Se analiza cuál es la funcionalidad del sistema, qué información debe manejar - y las restricciones de diseño, elaborando una -\series bold -especificación de requisitos del sistema -\series default - ( -\series bold -SyRS -\series default -, -\emph on -\lang english -System Requirements Specification -\emph default -\lang spanish -) y -\series bold -del software -\series default - ( -\series bold -SRS -\series default -, -\emph on -\lang english -Software Requirements Specification -\emph default -\lang spanish -), y se planifica el proyecto. + y las restricciones de diseño, y se planifica el proyecto. \end_layout \begin_layout Enumerate -- cgit v1.2.3