diff options
| -rw-r--r-- | gpds/n.lyx | 4 | ||||
| -rw-r--r-- | gpds/n1.lyx | 239 | ||||
| -rw-r--r-- | gpds/n3.lyx | 166 |
3 files changed, 263 insertions, 146 deletions
@@ -167,7 +167,7 @@ ISO/IEC 15504 status open \begin_layout Plain Layout -Objetivos: a3d, ... +Objetivos: a3f, ... \end_layout \end_inset @@ -180,7 +180,7 @@ Objetivos: a3d, ... status open \begin_layout Plain Layout -TODO a3d, v. +TODO a3f, v. TODO en n3 \end_layout diff --git a/gpds/n1.lyx b/gpds/n1.lyx index 5820de5..81f40ed 100644 --- a/gpds/n1.lyx +++ b/gpds/n1.lyx @@ -108,7 +108,7 @@ ingeniería de software \begin_layout Standard Según el Vocabulario de la Ingeniería del Software y de Sistemas, ISO/IEC/IEEE - 24765 en su edición de 2017, la + 24765:2017, la \series bold ingeniería de software \series default @@ -134,7 +134,7 @@ disciplinada \series bold cuantificable \series default -, pues tanto su realización como sus resultados son medibles. +, con realización y resultados medibles. \end_layout \begin_layout Section @@ -316,29 +316,154 @@ Requisitos del sistema \end_deeper \begin_layout Section -Procesos software +Informes +\lang english +CHAOS \end_layout \begin_layout Standard -Un +Son informes de pago de +\emph on +\lang english +Standish Group +\emph default +\lang spanish +, liberados cuando tienen cierta antigüedad, sobre el desarrollo de la ingenierí +a de software, y clasifican los proyectos en: +\end_layout + +\begin_layout Itemize + \series bold -proceso software +Éxitos: +\series default + Se entregan a tiempo dentro de su presupuesto y con las funciones requeridas. +\end_layout + +\begin_layout Itemize + +\series bold +Deficientes: \series default - es un conjunto coherente de políticas, estructuras organizativas, tecnologías, - prácticas, -\begin_inset Note Note + Se entregan tarde, sobrepasando el coste o sin todas las funciones requeridas. +\end_layout + +\begin_layout Itemize + +\series bold +Fracasos: +\series default + Se cancelan antes de terminar o se entregan pero nunca se usan. +\end_layout + +\begin_layout Standard +Según el informe de 2020, el +\begin_inset Formula $\unit[31]{\%}$ +\end_inset + + de los proyectos son éxitos, el +\begin_inset Formula $\unit[50]{\%}$ +\end_inset + + son deficientes y el +\begin_inset Formula $\unit[19]{\%}$ +\end_inset + + son fracasos. +\end_layout + +\begin_layout Standard +\begin_inset Note Comment status open \begin_layout Plain Layout -TODO Esta lista esta hay que arreglarla +Según el de 2012, el +\begin_inset Formula $\unit[18]{\%}$ +\end_inset + + de los proyectos son cancelados antes de terminar de desarrollarse o no + son usados, y el +\begin_inset Formula $\unit[43]{\%}$ +\end_inset + + son +\begin_inset Quotes cld +\end_inset + +comprometidos +\begin_inset Quotes crd +\end_inset + +, sobrepasando el coste o el plazo o no satisfaciendo las necesidades de + los clientes. + Las cancelaciones y compromisos aumentan con el tamaño del proyecto. +\end_layout + +\begin_layout Plain Layout +Según , 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 Plain Layout +Una +\series bold +revisión de requisitos +\series default + es una reunión en la que se presentan los requisitos de un elemento de + hardware, software o sistema a algunas partes interesadas para obtener + información o aprobación. + Forma parte de la +\series bold +validación de requisitos +\series default +. +\end_layout + +\begin_layout Plain Layout +El análisis de requisitos permite alcanzar un acuerdo entre clientes, productore +s de software y usuarios sobre lo que hay que producir; proporciona la base + para el diseño; sirve de soporte para la verificación y validación de los + productos, y orienta a potenciales clientes sobre la definición de los + productos, creando a veces catálogos de requisitos alternativos para elegir. \end_layout \end_inset - artefactos y transformaciones usados para construir software y productos - asociados como planes de proyecto, documentos de requisitos, documentos - de análisis o diseño, codificación, casos de prueba, manuales de usuario, - etc., formado por: + +\end_layout + +\begin_layout Section +Procesos software +\end_layout + +\begin_layout Standard +Un +\series bold +artefacto +\series default + es algo tangible creado con un propósito práctico. + Una +\series bold +actividad +\series default + es una actuación de un agente con ciertos objetivos. +\end_layout + +\begin_layout Standard +Un +\series bold +proceso software +\series default + es un conjunto coherente de estructuras organizativas, políticas, prácticas, + tecnologías, artefactos y transformaciones usados para concebir, desarrollar, + implantar y mantener software y productos asociados, como planes de proyecto, + documentos de requisitos, documentos de análisis o diseño, codificación, + casos de prueba, manuales de usuario, etc. + Está formado por: \end_layout \begin_layout Enumerate @@ -368,14 +493,6 @@ control de configuración \end_layout \begin_layout Standard -Un -\series bold -artefacto -\series default - es algo tangible creado con un propósito práctico. -\end_layout - -\begin_layout Standard \begin_inset Note Comment status open @@ -384,20 +501,7 @@ status open status open \begin_layout Plain Layout -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, +Las 4 actividades básicas en ingeniería de software son especificación, desarrollo, validación y evolución. \end_layout @@ -465,38 +569,6 @@ status open status open \begin_layout Plain Layout -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 - -\end_inset - - -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -\begin_inset Note Comment -status open - -\begin_layout Plain Layout -\begin_inset Note Greyedout -status open - -\begin_layout Plain Layout La tecnología puede ser muy útil con los procesos apropiados, pero no siempre se usa de forma muy efectiva, y aunque las personas tengan buena experiencia y formación, un buen proceso puede ayudar a trabajar mejor, más rápido @@ -522,15 +594,26 @@ Estrategias de desarrollo de software \end_layout \begin_layout Standard -Algunas estrategias son: +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. + Algunas metodologías: \end_layout \begin_layout Enumerate \series bold -Modelo en cascada +En cascada: \series default -, en que se hacen las fases en orden secuencial. + 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 @@ -542,10 +625,10 @@ Iterativo \series default e \series bold -incremental +incremental: \series default -, con iteraciones en las que se hacen todas las fases para lo siguiente - a implementar. + con iteraciones en las que se hacen todas las fases para lo siguiente a + implementar. \end_layout \begin_layout Enumerate @@ -599,6 +682,16 @@ Platform-Independent Models \end_layout \begin_layout Standard +Según una encuesta de Ambler, las metodologías más exitosas son +\emph on +\lang english +lean +\emph default +\lang spanish +, iterativa y ágil. +\end_layout + +\begin_layout Standard \begin_inset Note Comment status open diff --git a/gpds/n3.lyx b/gpds/n3.lyx index 202c6d9..0ad2114 100644 --- a/gpds/n3.lyx +++ b/gpds/n3.lyx @@ -81,10 +81,6 @@ algorithm2e \begin_body \begin_layout Standard -\begin_inset Note Greyedout -status open - -\begin_layout Plain Layout Un \series bold objeto @@ -101,7 +97,7 @@ estado es una situación en que se puede encontrar un objeto. \end_layout -\begin_layout Plain Layout +\begin_layout Standard Un \series bold requisito @@ -109,13 +105,9 @@ requisito 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 - -\end_inset - - + Según Alan Davis, un requisito 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 @@ -132,10 +124,6 @@ parte interesada ingeniero de requisitos, analista o programador. \end_layout -\begin_layout Section -Ingeniería de requisitos -\end_layout - \begin_layout Standard La \series bold @@ -144,16 +132,38 @@ ingeniería de requisitos 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. - Se le suele dedicar el + Sus objetivos son: +\end_layout + +\begin_layout Enumerate +Alcanzar un acuerdo entre clientes, desarrolladores y usuarios sobre lo + que hay que desarrollar. +\end_layout + +\begin_layout Enumerate +Ser la base para el diseño de software. +\end_layout + +\begin_layout Enumerate +Permitir la verificación y validación de los productos obtenidos. +\end_layout + +\begin_layout Enumerate +Orientar a potenciales clientes sobre la definición de los productos mediante + catálogos de requisitos alternativos. +\end_layout + +\begin_layout Standard +Se le suele dedicar el \begin_inset Formula $\unit[10]{\%}$ \end_inset del esfuerzo de un proyecto, aunque dedicar más esfuerzo disminuye el tiempo - total del proyecto. + total del proyecto según estudios como los del informe SERENA. \end_layout \begin_layout Standard -\begin_inset Note Greyedout +\begin_inset Note Comment status open \begin_layout Plain Layout @@ -167,8 +177,8 @@ n, el modelado y la comunicación, y si quiere hacerse, debe justificarse \end_layout -\begin_layout Standard -Consta de: +\begin_layout Section +Fases \end_layout \begin_layout Enumerate @@ -256,8 +266,15 @@ validan \series bold verifica \series default - la corrección interna y externa de los modelos. - Se hacen prototipos, inspecciones y revisiones. + la corrección interna y externa de los modelos, usando prototipos, inspecciones + y revisiones. + Una +\series bold +revisión de requisitos +\series default + es un proceso en que se presentan requisitos a partes interesadas para + su aprobación o retroalimentación, o bien es un grupo de revisores que + buscan errores, contradicciones, descripciones ambiguas, etc. \end_layout \begin_layout Enumerate @@ -302,6 +319,32 @@ Análisis de requisitos \end_layout \begin_layout Standard +El ISO/IEC/IEEE 24765:2017 lo define como un +\begin_inset Quotes cld +\end_inset + +proceso de estudio de las necesidades del usuario para llegar a una definición + de los requisitos del sistema, hardware o software +\begin_inset Quotes crd +\end_inset + + o un +\begin_inset Quotes cld +\end_inset + +proceso de estudio y perfeccionamiento de los requisitos del sistema, hardware + o software +\begin_inset Quotes crd +\end_inset + +. +\end_layout + +\begin_layout Standard +\begin_inset Note Comment +status open + +\begin_layout Plain Layout \begin_inset Note Greyedout status open @@ -317,13 +360,9 @@ to de estos requisitos; la investigación de los requisitos de usuario para Forma parte de la fase de definición del sistema software. \end_layout -\begin_layout Plain Layout -Muchos proyectos software no dan los resultados esperados, se retrasan, - exceden el presupuesto o terminan llenos de errores, y muchas veces la - causa es un mal análisis de requisitos. - Esto es porque en general los clientes o usuarios no tienen realmente claro - qué quieren o cuál es el problema que quieren resolver, y por una mala - estimación del tiempo y coste del proyecto. +\end_inset + + \end_layout \end_inset @@ -332,7 +371,20 @@ Muchos proyectos software no dan los resultados esperados, se retrasan, \end_layout \begin_layout Standard -Los errores relacionados con requisitos son los más caros de corregir. +Según +\lang english +Robert Glass +\lang spanish +, las principales causas de fracaso de proyectos de software son la inestabilida +d de los requisitos, pues en general los clientes o usuarios no tienen realmente + claro qué quieren o qué problema que quieren resolver, y una mala estimación + de el tiempo y el coste del proyecto. +\end_layout + +\begin_layout Standard +Los errores en las primeras fases del desarrollo son más caros de corregir + porque pasa más tiempo hasta terminar las fases y obtener retroalimentación, + siendo los más caros los errores en los requisitos. Algunos son: \end_layout @@ -355,50 +407,22 @@ No detectar a tiempo ambigüedades entre requisitos. \end_layout \begin_layout Standard -\begin_inset Note Greyedout -status open - -\begin_layout Plain Layout -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 Plain Layout -Una -\series bold -revisión de requisitos -\series default - es una reunión en la que se presentan los requisitos de un elemento de - hardware, software o sistema a algunas partes interesadas para obtener - información o aprobación. - Forma parte de la -\series bold -validación de requisitos -\series default -. -\end_layout - -\begin_layout Plain Layout -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. +El cohete europeo Ariane 5 explotó debido a un desbordamiento al convertir + un valor en coma flotante de doble precisión a un entero de 16 bits con + signo, como resultado de mantener un requisito de software del Ariane 4 + que no era necesario en el 5, relacionado con la velocidad horizontal y + el ángulo de ataque detectados por un sensor de vuelo. \end_layout +\begin_layout Standard +La NASA perdió el contacto con el Mars Polar Lander 10 minutos antes de + su aterrizaje previsto debido a que el software malinterpretó señales que + debía ignorar y creyó que uno de los brazos de la sonda había tocado suelo + cuando estaba a +\begin_inset Formula $\unit[40]{m}$ \end_inset - + de altura. \end_layout \begin_layout Section |