#LyX 2.3 created this file. For more info see http://www.lyx.org/
\lyxformat 544
\begin_document
\begin_header
\save_transient_properties true
\origin unavailable
\textclass book
\use_default_options true
\begin_modules
algorithm2e
\end_modules
\maintain_unincluded_children false
\language spanish
\language_package default
\inputencoding auto
\fontencoding global
\font_roman "default" "default"
\font_sans "default" "default"
\font_typewriter "default" "default"
\font_math "auto" "auto"
\font_default_family default
\use_non_tex_fonts false
\font_sc false
\font_osf false
\font_sf_scale 100 100
\font_tt_scale 100 100
\use_microtype false
\use_dash_ligatures true
\graphics default
\default_output_format default
\output_sync 0
\bibtex_command default
\index_command default
\paperfontsize default
\spacing single
\use_hyperref false
\papersize default
\use_geometry false
\use_package amsmath 1
\use_package amssymb 1
\use_package cancel 1
\use_package esint 1
\use_package mathdots 1
\use_package mathtools 1
\use_package mhchem 1
\use_package stackrel 1
\use_package stmaryrd 1
\use_package undertilde 1
\cite_engine basic
\cite_engine_type default
\biblio_style plain
\use_bibtopic false
\use_indices false
\paperorientation portrait
\suppress_date false
\justification true
\use_refstyle 1
\use_minted 0
\index Index
\shortcut idx
\color #008000
\end_index
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\paragraph_indentation default
\is_math_indent 0
\math_numbering_side default
\quotes_style french
\dynamic_quotes 0
\papercolumns 1
\papersides 1
\paperpagestyle default
\tracking_changes false
\output_changes false
\html_math_output 0
\html_css_as_file 0
\html_be_strict false
\end_header

\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 
\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
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:
\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
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).
\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 Standard
\begin_inset Note Note
status open

\begin_layout Plain Layout

\end_layout

\end_inset


\end_layout

\end_body
\end_document