diff options
Diffstat (limited to 'gpds')
| -rw-r--r-- | gpds/n3.lyx | 395 |
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 |