path: root/pds/n1.lyx

#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
\begin_preamble
\input{../defs}
\end_preamble
\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
El 
\series bold
software
\series default
 esta formado por instrucciones para la máquina, estructuras de datos, bases
 de datos, documentos, entrenamiento, soporte al consumidor e instalación.
 Al ser un elemento lógico, no físico, es más difícil de medir, validar
 y verificar que el hardware, y aunque no se estropea, su calidad suele
 ir deteriorándose por los cambios.
\end_layout

\begin_layout Section
Calidad del software
\end_layout

\begin_layout Standard
Sommerville define los siguientes factores de calidad del software:
\end_layout

\begin_layout Itemize
Facilidad de mantenimiento: Legibilidad.
\end_layout

\begin_layout Itemize
Confiabilidad: Fiabilidad (que ofrezca los mismos resultados en las mismas
 condiciones), seguridad y protección.
 Se distingue entre seguridad informática (
\emph on
\lang english
security
\emph default
\lang spanish
); seguridad humana o protección (
\emph on
\lang english
safety
\emph default
\lang spanish
) y privacidad.
\end_layout

\begin_layout Itemize
Eficiencia.
\end_layout

\begin_layout Itemize
Facilidad de uso.
\end_layout

\begin_layout Standard
También queremos que el software sea correcto (se ajuste a las especificaciones
 dadas por el usuario), no erróneo, robusto (tolerante a fallos), portable,
 adaptable o extensible y reutilizable.
\end_layout

\begin_layout Standard
Con el avance del hardware, cada vez se pueden hacer aplicaciones más complejas
 y con frecuencia el software es la parte más compleja de un sistema, dando
 lugar a problemas para estimar el tiempo, coste y esfuerzo para el desarrollo
 y para asegurar la calidad.
 Hay tanto 
\series bold
complejidad esencial
\series default
, la complejidad de tratar con muchos conceptos a la vez, y 
\series bold
complejidad accidental
\series default
, derivada de aspectos como la notación o la organización del proyecto software.
\end_layout

\begin_layout Standard
Como el software no es físico, es más difícil de probar, y como es maleable,
 es más fácil dejar fallos y resolverlos después que hacer un análisis exhaustiv
o de corrección.
 Además hay problemas de comunicación con los clientes y, tradicionalmente,
 se dedica poco tiempo al análisis y el diseño.
 Los métodos tradicionales de gestión de proyectos no funcionan demasiado
 bien en el software.
 No hay demasiados datos previos de guía ni estándares ampliamente usados,
 y la base formal no se suele usar.
 Todo esto hace que el tiempo y el coste del desarrollo sean elevados, el
 software entregado contenga errores y constatar el progreso en el desarrollo
 sea difícil.
\end_layout

\begin_layout Standard
No hay una única solución para todo, pero pueden ayudar la adquisición de
 componentes en vez de su construcción desde cero, el refinamiento de requisitos
, el prototipado rápido y el desarrollo incremental, así como tener buenos
 diseñadores.
\end_layout

\begin_layout Standard
La 
\series bold
ingeniería del software
\series default
 es una parte de la ingeniería de sistemas, que Boehm define como la aplicación
 práctica y sistemática de conocimiento científico a la producción de programas
 correctos a tiempo y dentro de las estimación de presupuestos, así como
 de su documentación para desarrollarlos, usarlos y mantenerlos.
 Es una parte de la ingeniería de sistemas que se fundamente en campos como
 las ciencias de la computación, la programación, la ingeniería, la administraci
ón, las matemáticas o la economía.
\end_layout

\begin_layout Section
Historia
\end_layout

\begin_layout Standard
En la década de los 50, se escribían aplicaciones sencillas en lenguajes
 de bajo nivel como añadido al hardware, desarrolladas a medida.
 En los 60 se concibió el software como producto y se crearon las primeras
 aplicaciones complejas, que todavía eran mayoritariamente monolíticas,
 con poco uso de componentes.
\end_layout

\begin_layout Standard
En 1968–69 tienen lugar las 
\emph on
\lang english
Software Engineering Conferences
\emph default
\lang spanish
 de la OTAN, donde se acuña en 1968 el término 
\series bold
crisis del software
\series default
 para referirse a la dificultad de manejar la creciente complejidad, y se
 decide que la producción de programas debe abordarse como una ingeniería
 más.
\end_layout

\begin_layout Standard
En los 70 surgen la programación estructurada, el modelado de datos y el
 relacional y los primeros métodos estructurados.
 En los 80 coge fuerza la programación orientada a objetos y aparecen los
 primeros métodos orientados a objetos.
 Surge tecnología CASE pero fracasa.
\end_layout

\begin_layout Standard
En los 90 se populariza Internet.
 La programación orientada a objetos se generaliza, surge la programación
 virtual y se crea UML, que acaba con la guerra de los métodos y permite
 tecnología CASE de segunda generación.
 En la década de los 2000 surgen los métodos ágiles y se asume la importancia
 de la seguridad, y en la de los 2010 surgen la computación móvil y en la
 nube y se popularizan las redes sociales, los grandes datos, el aprendizaje
 computacional y el desarrollo de software global.
\end_layout

\begin_layout Section
Actualidad
\end_layout

\begin_layout Standard
Actualmente existe un consenso en la importancia de la ingeniería del software
 y se niega la vigencia de la crisis de software, pero la disciplina no
 es tan madura como otras ingenierías.
 Los principales problemas son:
\end_layout

\begin_layout Itemize

\series bold
Heterogeneidad:
\series default
 El software debe trabajar con componentes muy heterogéneos, incluyendo
 
\series bold
sistemas heredados
\series default
 antiguos que no se adhieren a las prácticas actuales.
\end_layout

\begin_layout Itemize

\series bold
Entrega:
\series default
 Se prefiere usar actualizaciones incrementales a una sola entrega puntual,
 y el modelo de desarrollo debe ser acorde.
\end_layout

\begin_layout Itemize

\series bold
Confianza:
\series default
 Muchos sistemas dependen del software, y se debe poder confiar en su seguridad,
 privacidad, protección, disponibilidad, etc.
\end_layout

\begin_layout Standard
Algunas aproximaciones son los métodos ágiles como XP o Scrum y métodos
 
\emph on
\lang english
lean
\emph default
\lang spanish
 como Kanban, el 
\series bold
SWEBOK
\series default
 (
\emph on
\lang english
guide to the SoftWare Engineering Body Of Knowledge
\emph default
\lang spanish
), títulos universitarios de grado y máster en ingeniería de software, comités
 para acreditar estos títulos, CMMi y las 
\series bold
DevOps
\series default
 (automatización en el desarrollo y el despliegue del software).
\end_layout

\begin_layout Section
UML
\end_layout

\begin_layout Standard
Un 
\series bold
sistema
\series default
 es algo que se está desarrollando.
 Un 
\series bold
modelo
\series default
 es una abstracción de un sistema para comprenderlo mejor.
\end_layout

\begin_layout Standard
El modelo permite una mayor expresividad y capacidad de comunicación que
 un lenguaje de programación típico, y sirve como documentación.
 Puede conectarse a lenguajes de programación mediante ingeniería directa
 e inversa y desarrollo dirigido por modelos.
\end_layout

\begin_layout Standard
Los modelos se expresan en un lenguaje, y a mediados de los 90 había muchos
 lenguajes de modelado orientado a objetos.
 Algunos métodos que usan este tipo de modelos son:
\end_layout

\begin_layout Enumerate

\series bold
OMT
\series default
, especialmente útil para datos.
\end_layout

\begin_layout Enumerate

\series bold
\emph on
\lang english
Booch Method
\series default
\emph default
\lang spanish
, especialmente útil para sistemas concurrentes y de tiempo real, muy relacionad
o con el lenguaje Ada.
\end_layout

\begin_layout Enumerate

\series bold
OOSE
\series default
 de Jacobson, guiado por los casos de uso.
\end_layout

\begin_layout Standard
Esto producía mucha confusión y una 
\series bold
guerra de los métodos
\series default
.
\end_layout

\begin_layout Standard
\begin_inset ERT
status open

\begin_layout Plain Layout


\backslash
sremember{TDS}
\end_layout

\end_inset


\end_layout

\begin_layout Standard
En 1994, [...] Booch, [...] Rumbaugh [...][y] Jacobson crean el 
\series bold
UML
\series default
 [...], un lenguaje para visualizar, especificar construir y documentar modelos
 de un sistema de software desde una perspectiva orientada a objetos que
 busca eliminar confusión y reunir los puntos fuertes de cada método, y
 este es estandarizado por el 
\series bold
OMG
\series default
 [(
\emph on
\lang english
Object Management Group
\emph default
\lang spanish
)] [...].
 [...]
\end_layout

\begin_layout Standard
\begin_inset ERT
status open

\begin_layout Plain Layout


\backslash
eremember
\end_layout

\end_inset


\end_layout

\begin_layout Standard
La notación UML también añadió mejoras, dio estabilidad al mercado y permitió
 mejores herramientas CASE.
 Permite modelar sistemas desde los requisitos hasta los ejecutables, es
 escalable a sistemas grandes y los pueden usar tanto personas como máquinas,
 debido a un equilibrio entre expresividad y simplicidad.
\end_layout

\begin_layout Standard
Una 
\series bold
vista
\series default
 es una proyección de la estructura del sistema centrada en algún aspecto.
 Un 
\series bold
diagrama
\series default
 es una representación gráfica de elementos de un modelo.
\end_layout

\begin_layout Standard
UML tiene 5 vistas, cada una con varios tipos de diagramas:
\end_layout

\begin_layout Enumerate

\series bold
Vista de casos de uso
\series default
, centrada el comportamiento, con diagramas de casos de uso.
\end_layout

\begin_layout Enumerate

\series bold
Vista de diseño
\series default
, centrada en el vocabulario del programa y su funcionalidad, con diagramas
 de clases, de estados y de interacción.
\end_layout

\begin_layout Enumerate

\series bold
Vista de procesos
\series default
, con los mismos diagramas que la de diseño pero centrada en el funcionamiento,
 la escalabilidad y el rendimiento.
\end_layout

\begin_layout Enumerate

\series bold
Vista de implementación
\series default
, con diagramas de estados, de interacción y de componentes.
\end_layout

\begin_layout Enumerate

\series bold
Vista de despliegue
\series default
, con diagramas de estado, de interacción y de despliegue.
\end_layout

\begin_layout Standard
Muchas empresas de software hacen poco o ningún modelado, pues este requiere
 un proceso de desarrollo, personas formadas en las técnicas, tiempo y herramien
tas.
\end_layout

\begin_layout Section
Fases del desarrollo
\end_layout

\begin_layout Standard
Independientemente del área o la complejidad del proyecto, el desarrollo
 de un sistema estará al menos en uno de los siguientes procedimientos genéricos
:
\end_layout

\begin_layout Enumerate

\series bold
Definición
\series default
, 
\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, y se planifica el proyecto.
\end_layout

\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
Mantenimiento
\series default
 o 
\series bold
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

\begin_layout Section
Responsabilidad ética
\end_layout

\begin_layout Standard
Esta cobrando más interés en los últimos años el que la responsabilidad
 de los ingenieros de software no es exclusivamente técnica, sino que también
 hacia la profesión y la sociedad.
 Hay áreas en las que la conducta aceptable, si los ingenieros quieren ser
 respetados como profesionales,
\begin_inset Foot
status open

\begin_layout Plain Layout
Es decir, por sus clientes o jefes.
\end_layout

\end_inset

 no está limitada solo por la ley sino también por una noción de 
\series bold
responsabilidad profesional
\series default
, con mandamientos como los siguientes:
\begin_inset Foot
status open

\begin_layout Plain Layout
Un código ético no debe tomarse de forma dogmática, sino que debemos usar
 la razón para decidir si este tiene razón o no y en qué contextos.
 Por ejemplo, algunos de los siguientes pueden contradecir el imperativo
 moral del software libre según del contexto.
 Por otro lado, un código ético es necesariamente incompleto, y debemos
 esforzarnos por determinar qué es bueno o malo y actuar en consecuencia.
 Una forma de hacerlo es no aceptar trabajar en proyectos o empresas cuyos
 fines probables sean moralmente cuestionables si hay alternativas viables.
\end_layout

\end_inset


\end_layout

\begin_layout Enumerate
Respetarás la confidencialidad de tu jefe o clientes, aunque no hayas firmado
 un contrato de confidencialidad.
\end_layout

\begin_layout Enumerate
No aceptarás conscientemente trabajo fuera de tu competencia.
\end_layout

\begin_layout Enumerate
Conocerás las leyes de 
\begin_inset Quotes cld
\end_inset

propiedad intelectual
\begin_inset Quotes crd
\end_inset

 y protegerás la 
\begin_inset Quotes cld
\end_inset

propiedad intelectual
\begin_inset Quotes crd
\end_inset

 de tus jefes y clientes.
\end_layout

\begin_layout Enumerate
No usarás de forma incorrecta los ordenadores de otros.
 Por ejemplo, no jugarás con un ordenador de 
\begin_inset Quotes cld
\end_inset

tu
\begin_inset Quotes crd
\end_inset

 empresa ni diseminarás virus.
\end_layout

\begin_layout Standard
ACM e IEEE tienen un código de ética y conducta profesional que hay que
 aceptar para ser miembro de dichas organizaciones, y que ha sido adoptado
 por SISTEDES.
 El principio 8 establece como obligación el aprendizaje continuo a través
 de toda la vida profesional.
\end_layout

\end_body
\end_document