Principios de Ingeniería de Software
Apuntan al proceso
de ingeniería y el producto final: el proceso correcto ayudará a obtener el
producto correcto. Asimismo, el producto afectará la elección de qué proceso
usar.
Los principios son
afirmaciones abstractas que describen propiedades deseables del proceso y del
producto. Para aplicarlas, los ingenieros deben contar con métodos y técnicas
que incorporen dichos principios.
Ø Métodos: guías
para la ejecución de alguna actividad, aproximaciones rigurosas, sistemáticas y
disciplinadas.
Ø Técnicas: son más
mecánicas que los métodos y tienen aplicabilidad más restringida.
Ambos se usan como
sinónimos.
Los métodos y
técnicas se encapsulan para crear metodologías, que sirven para promover una
aproximación a la solución de problemas, preseleccionando los métodos y
técnicas a usar.
Las herramientas
son desarrolladas para apoyar la aplicación de los 3 niveles anteriores.
Lo que se busca con
este análisis es la confiabilidad de las aplicaciones. También se supone que
las aplicaciones serán lo suficientemente grandes para descomponerlas en partes
manejables.
Todo esto hace que
la confiabilidad y la evolución sean importantes y que afirmemos que la
elección de principios y técnicas son determinantes para las metas de calidad
del software.
- Rigor
y formalidad.
El rigor
es un complemento de la creatividad en la ingeniería. Con la aproximación
rigurosa podremos tener productos más confiables y mejores controles (de
tiempo, costos, etc.). El rigor mejora la creatividad, optimizando la confianza
en los resultados creativos, una vez analizados en base a una planificación
rigurosa.
Hay
varios grados de rigurosidad. El más alto es la formalidad, que es un
requerimiento más restrictivo que el rigor, que exige que el proceso de soft
sea dirigido y evaluado con leyes matemáticas. La formalidad implica rigor,
pero uno puede ser riguroso e informal.
En
ingeniería, el proceso de diseño son pasos bien definidos y con bases sólidas.
En cada paso el ingeniero sigue algún método o técnica basados en resultados
teóricos de un modelado formal de la realidad o en ajustes empíricos de
fenómenos no considerados por el modelo, o en reglas heurísticas que dependen
de la experiencia. Todo está resuelto en una aplicación rigurosa y sistemática (metodología),
fácilmente explicada y aplicada una y otra vez.
El
ingeniero debe saber cómo y cuándo ser formal, además de entender el nivel de
rigurosidad y formalidad a alcanzar, dependiendo de la dificultad de la tarea y
su criticidad. Ej.: podemos ser muy formales para las partes críticas de un
problema y para las partes estandarizadas aplicar una aproximación más simple.
La
formalidad aventaja al rigor en el sentido de que la primera puede ser la base
para mecanizar procesos. La única fase del desarrollo de software donde se usa
aproximación formal es en la programación. Los programas son objetos formales,
escritos en lenguajes cuya sintaxis y semántica están definidos. Estas
operaciones mecánicas, posibles por usar la formalidad, pueden mejorar la confiabilidad
y verificabilidad de los productos software.
El rigor
y la formalidad benefician también la mantenibilidad, reusabilidad,
portabilidad, comprensión e interoperabilidad del software. Ej.: la
documentación nos permite prever la evolución del proyecto, los recursos a
usar, etc., así como nos ayuda a mantener el producto, al usarla para cualquier
modificación que se requiera; y por último nos permite monitorear el software
en forma precisa, para garantizar el cumplimiento de los puntos de control y mejorar
la productividad.
- Separación
de intereses.
Es
involucrarse con distintos aspectos de un problema para concentrarse en ellos
separadamente. En cada proyecto debemos separar aspectos: primero, aislar los
factores relacionados más débilmente y luego considerar los factores en la
medida en que impactan el análisis.
Ø Separación
en base al tiempo: permite planificar las actividades de
manera precisa.
Ø Separación
en términos de calidades: manejar separadamente la eficiencia y la
corrección de un programa, diseñando software cuidadoso y estructuradamente,
tal que su corrección esté garantizada a priori y luego reestructurada para
mejorar su eficiencia.
Ø Separación
por vistas: separar los datos que fluyen de una actividad a otra
en el flujo de control que gobierna la sincronización de las actividades.
La
separación implica separación de responsabilidades para tratar los distintos
aspectos. Es la base para la asignación del trabajo en asignaciones específicas
para distintas personas con distintas habilidades.
- Modularidad.
División
de un sistema en partes más simples (módulos). Esto nos permite separar los
contextos en fases: cuando relacionamos cada módulo aislado y cuando
relacionamos todos los módulos globalmente, analizando sus conexiones e
integración.
Objetivos
de la modularidad:
Ø Capacidad
de descomposición de un sistema complejo: división del
problema original en subproblemas y luego dividir cada subproblema.
Ø Composición
de un sistema a partir de componentes existentes: partir de
componentes elementales hasta llegar al sistema terminado. Cuando un componente
falla, se reemplaza por uno nuevo. Podemos usar módulos de una biblioteca, que
al ser reutilizables, aceleran el proceso de construcción.
Ø Comprensión
del sistema mirándolo en partes: Nos facilita la reparación y
modificación, al buscar los errores en un componente en particular.
Para
lograr los tres objetivos, los módulos deben tener:
Ø Alta
cohesión:
sus elementos internos están muy relacionados y agrupados por razones lógicas.
Ø Bajo
acoplamiento: es la relación entre módulos y mide la
interdependencia entre 2 módulos. La idea es lograr que los módulos tengan un
nivel bajo.
Las
estructuras que cumplan esto nos permiten ver los módulos como cajas negras
cuando describimos la estructura total y verlos separadamente cuando analizamos
la funcionalidad de cada uno.
- Abstracción.
Es
identificar los aspectos importantes de un fenómeno e ignorar los detalles.
Esto depende de cada persona o de cada enfoque o propósito que se le dé a un
problema.
Los
modelos que construimos son abstracciones de la realidad, válidas también para
modelos de software.
Los
lenguajes de programación son abstracciones que nos permiten construir sin
preocuparnos por los detalles de hardware.
Este
principio es importante para aplicarlo a productos y procesos software. Cuando
la documentación de un programa o procedimiento se analiza, se supone que
suministra toda la información necesaria para entender las otras partes del
programa que usan ese procedimiento.
- Anticipación
al cambio.
Se
refiere a la mantenibilidad. Es poder predecir los cambios y trabajar para que
los cambios futuros sean fáciles de aplicar.
Esto es
importante en el software, ya que los productos están en ambientes donde
permanentemente surgen nuevos requerimientos.
La
reusabilidad también se ve afectada por esto. Un componente es reusable si se
puede emplear para generar un nuevo producto o si solo requiere pequeños
cambios para ello. La reusabilidad es la capacidad de evolucionar que tienen
los componentes.
Para anticiparse
al cambio debemos contar con herramientas de administración de versiones y
revisiones de software. Debemos poder almacenar y recuperar información,
módulos fuente y objetos, todo desde una base de datos central.
Asimismo
se afecta al proceso de soft, al considerar el mantenimiento de una aplicación
y asignando estructura y costos para apoyar la evolución del software.
- Generalidad.
Poder
descubrir un problema más general en la resolución de un primer problema. Este
puede ser menos complejo y proveer soluciones reutilizables. Puede surgir de un
paquete ya existente o lo podemos crear nosotros.
Sin
embargo, puede ser más costoso en términos de velocidad de ejecución,
requerimientos de memoria o tiempos de desarrollo.
Este
principio es fundamental si se busca desarrollar herramientas software para uso
amplio en el mercado.
Si el
problema puntual se puede reformular como una instancia de un problema general,
es conveniente adoptar el paquete en vez de una solución específica.
- Incrementalidad.
Desarrollar
paso a paso con incrementos, logrando aproximaciones sucesivas. Esto nos da un
proceso evolutivo.
Debemos
identificar subconjuntos primarios útiles para desarrollar y distribuir a los
clientes, de manera de obtener realimentación temprana. Esto nos permite que la
aplicación evolucione de manera controlada, en casos donde los requerimientos
iniciales no se comprendieron bien.
Las
etapas intermedias son prototipos del producto final, lo cual beneficia el
entendimiento de los requerimientos y permite usar un modelo de desarrollo
iterativo más flexible.
Debemos
tener mucho cuidado en la manipulación de documentos, programas, datos de
prueba y todo lo que usemos en las distintas versiones. Cada paso incremental
significativo debe ser registrado.
¿Qué
es el software?
Programas,
estructuras de datos, documentación y más.
Características:
Ø desarrollo,
no manufactura.
Ø Desgaste,
no gasto.
Ø Principalmente
desarrollado a medida.
Ø Mantenibilidad:
debe poder evolucionar y seguir cumpliendo sus especificaciones.
Ø Confiabilidad:
no debe causar daños físicos ni económicos en caso de fallos.
Ø Eficiencia:
no debe desperdiciar los recursos del sistema.
Ø Utilización
adecuada: debe contar con una interfaz adecuada y documentación.
Ø Actúa
como un diferenciador en los negocios, es estratégico.
Ø Captura
información, produce información y es información en sí mismo.
Productos
Software
Ø Genéricos: son
producidos por una organización para venderlos en el mercado.
Ø A
medida:
desarrollados bajo pedido a un desarrollador específico.
La mayor parte del
gasto del software es en productos genéricos, pero hay más esfuerzo en el
desarrollo a medida.
Componentes:
Mitos
del software:
Ø Estándares
y procedimientos bastan.
Ø Tecnología
de punta basta.
Ø Más
gente para ponerse al día.
Ø Programación
inmediata.
Ø Fácil
acomodo de los cambios.
Ø Programación:
fin del trabajo.
Ø Calidad:
solo del ejecutable.
Ø El
código es el único producto.
Evolución
del software:
Software
vs. Hardware:
