2015 - II
INTRODUCCIN
En el siguiente informe les presentamos los principios del software que
tratan tanto del proceso de ingeniera de software como del producto
final. El proceso adecuado ayudar a desarrollar el producto deseado,
pero tambin el producto deseado afectar la eleccin del proceso a
utilizar. Un problema tradicional de la ingeniera de software es poner el
nfasis en el proceso o en el producto excluyendo al otro, sin embargo,
ambos son importantes.
Estos principios son suficientemente generales para ser aplicados a lo
largo del proceso de construccin y gestin del software, sin embargo no
son suficientes para guiar el desarrollo ya que describen propiedades
deseables de los procesos y productos de software; para aplicarlos es
necesario contar con mtodos apropiados y tcnicas especficas. Los
mtodos son guas generales que gobiernan la ejecucin de alguna
actividad, presentan enfoques rigurosos, sistemticos y disciplinados,
por otro lado, las tcnicas son ms mecnicas y se refieren a aspectos
ms tcnicos que los mtodos y tienen aplicacin restringida.
Una metodologa es un conjunto de mtodos y tcnicas cuyo propsito
es promover cierto enfoque para la resolucin de un problema mediante
ese conjunto seleccionado. Las herramientas son desarrolladas para
apoyar la aplicacin de tcnicas, mtodos y metodologas. Los
principios son la base de todos los mtodos, tcnicas, metodologas y
herramientas.
PRINCIPIOS DE LA INGENIERA DE SOFTWARE
Los principios son afirmaciones abstractas que describen propiedades deseables
del proceso y del producto. Para aplicarlas, los ingenieros deben contar con
mtodos y tcnicas que incorporen dichos principios.
A continuacin definiremos dos conceptos que se manejan para interpretar el
sentido de los principios de la ingeniera de software:
Mtodos: guas para la ejecucin de alguna actividad, aproximaciones
rigurosas, sistemticas y disciplinadas.
Tcnicas: son ms mecnicas que los mtodos y tienen aplicabilidad ms
restringida.
Estos principios apuntan al proceso de ingeniera y el producto final: el proceso
correcto ayudar a obtener el producto correcto. Asimismo, el producto afectar la
eleccin de qu proceso usar.
GRFICO:
HERRAMIENTAS
Las herramientas son
desarrolladas para
apoyar la aplicacin de
los 3 niveles anteriores.
METODOLOGAS
Una metodologa es un conjunto
de mtodos y tcnicas cuyo
propsito es promover cierto
enfoque para la resolucin de un
problema mediante ese conjunto
seleccionado PRINCIPIO
1. RIGOR Y FORMALIDAD
METODOS Y TCNICAS
Los mtodos y tcnicas se
encapsulan
para
crear
metodologas, que sirven para
promover una aproximacin a
la solucin de problemas,
preseleccionando los mtodos
y tcnicas a usar.
Definiendo:
El rigor es un complemento de la creatividad en la ingeniera. Con la
aproximacin rigurosa podremos tener productos ms confiables y mejores
controles (de tiempo, costos, etc.).
La formalidad aventaja al rigor en el sentido de que la primera puede ser la
base para mecanizar procesos.
APLICACIN:
La aplicacin del principio de rigor y formalidad tiene influencia beneficiosa
en la obtencin de cualidades del software como la confiabilidad,
verificabilidad, mantenibilidad, reusabilidad, portabilidad, comprensibilidad e
interoperabilidad. Por ejemplo, una documentacin del software rigurosa o
incluso
formal
documentacin
puede
informal
mejorar todas estas cualidades sobre una
que
incompleta.
2. SEPARACIN DE INTERESES
puede
ser
ambigua,
inconsistente
Este principio permite enfrentarse a los distintos aspectos individuales de
un problema de forma de concentrarse en cada uno por separado.
La nica forma de enfrentar la complejidad de un proyecto es separar los
distintos intereses.
Separacin por intereses:
La primera forma en la que se pueden separar los distintos intereses es
SEGN EL TIEMPO, lo que permite planificar las distintas actividades y
eliminar el trabajo extra que implica cambiar de una a otra en forma no
restringida.
Otra forma de separacin de intereses es EN TRMINOS DE LAS
CUALIDADES que deberan tratarse por separado, por ejemplo podran
enfrentarse separadamente la eficiencia y correctitud de un programa,
primero disendolo cuidadosa y estructuradamente para garantizar su
correctitud a priori y luego reestructurarlo para mejorar su eficiencia.
Otro tipo importante de separacin de intereses permite que DISTINTAS
VISIONES DEL SOFTWARE sean analizadas en forma separada, por ejemplo
al analizar los requerimientos de una aplicacin podra ser de ayuda
concentrarse por un lado en los datos que fluyen de una actividad a otra y
por otro lado en el flujo de control que gobierna la sincronizacin de dichas
actividades. Ambas ayudan a entender el sistema y ninguna de las dos
provee una visin completa del mismo.
Otra forma ms de aplicacin de este principio es enfrentar partes del
mismo sistema en forma separada, esto es EN TRMINOS DE TAMAO.
Este es un concepto fundamental que debe dominarse para enfrentar la
complejidad de la produccin de software, y es tan importante que se trata
como un punto aparte bajo el principio de modularidad.
Por tanto la separacin de intereses podra resultar en la separacin de
responsabilidades al enfrentarse a los distintos aspectos a tener en cuenta,
por lo tanto es la base para dividir el trabajo en un problema complejo en
asignaciones de trabajo especficas posiblemente a personas distintas con
distintas habilidades.
Ejemplo 01:
Para conocer los costos reales de las actividades econmicas de una
empresa, es necesario recurrir o analizar aspectos de manera
individual que influyen en los costos de manera directa y/o
indirectamente, como los descuentos o recargos, entre otros: estos
nos dan los datos precisos, lo ms cercano a la realidad, que no
sera posible si analizramos los costos de forma directa sin ver los
diferentes aspectos que influyen en los costos.
Ejemplo 02:
Otro caso es para un sistema de almacn, se podra decir que
simplemente es la entrada y salida de productos, este anlisis sera
muy genrico y no estaramos separando adecuadamente los
intereses del sistema, por lo tanto no podramos implementar un
software adecuado, para ello necesitamos identificar los intereses
ms relevantes como el producto, registro del producto, clasificacin,
etc.
3. MODULARIDAD
El principal beneficio de la modularidad es que permite la aplicacin del
principio de separacin de intereses en dos fases: al enfrentar los detalles
de cada mdulo por separado ignorando detalles de los otros mdulos, y al
enfrentar las caractersticas globales de todos los mdulos y sus relaciones
para integrarlos en un nico sistema coherente. Si estas fases son
ejecutadas en ese orden se dice que el sistema es diseado de abajo
hacia arriba (bottom up), en el orden inverso se dice que el sistema es
diseado de arriba hacia abajo (top down).
El principio de modularidad se basa en 3 objetivos principales los cuales
son:
Capacidad de descomponer un sistema complejo
Capacidad de componer el sistema a partir de mdulos existentes
Comprensin del sistema en piezas (o pedazos)
Podemos encontrar una forma de componer y descomponer sistemas,
segn lo referenciado anteriormente podemos describir cmo:
o Para descomponer: Se basa en dividir el problema original en
subproblemas y luego aplicar el principio a cada subproblema de
forma recursiva.
o Para componer: La posibilidad de componer un sistema est
basada en obtener el sistema final de forma bottom up a partir de
componentes elementales.
Debido a la naturaleza evolutiva del software muchas veces se debe volver
hacia atrs al trabajo previo y modificarlo. Si el sistema solo puede ser
comprendido como un todo las modificaciones sern difciles de aplicar y el
resultado ser poco confiable.
Una estructura modular con alta cohesin y bajo acoplamiento permite ver
los mdulos como cajas negras cuando se describe la estructura global del
sistema y luego encarar cada mdulo por separado cuando se analiza o
describe la funcionalidad del mdulo.
Ejemplo 01:
Modularidad de MySQL:
Paso 1: Crear base de datos.
Paso 2:
Paso 3:
Paso 4:
Ejemplo 02:
10
Paso 1: Renombrar la base de datos.
Paso 2:
4.
11
5. ANTICIPACIN AL CAMBIO.
Es la prediccin de los cambios y poder trabajar para que los cambios que
puedan necesitarse en algn momento futuro sean fciles de aplicar. Es
12
importante en el software, debido a que los productos estn en ambientes
donde permanentemente surgen nuevos requerimientos y esto lleva a hacer
cambios constantemente, esto est relacionado con el mantenimiento y es
necesario poder anticiparlos para que no haya ningn problema al aplicar
estos nuevos requerimientos. Para anticiparse al cambio debemos contar
con herramientas de administracin de versiones y revisiones de software
donde podamos almacenar y recuperar informacin, mdulos fuente y
objetos, todo desde una base de datos central.
La reusabilidad tambin se ve afectada por esto, ya que un componente se
puede emplear para generar un nuevo producto, en ciertos casos se
requerir hacer pequeos cambios para esto, cuando se aplique, el
componente tendr la capacidad de evolucionar y as poder ser reutilizado.
Generalidad.
Establece que al tener que resolver un problema se debe buscar un
problema ms general, al descubrir un problema ms general, este puede
13
ser menos complejo y posiblemente la solucin al problema general tenga
potencial de reso. Puede surgir de un paquete ya existente o lo podemos
crear nosotros. Este principio es fundamental si se busca desarrollar
herramientas software para uso amplio en el mercado.
Sin embargo, puede ser ms costoso en trminos de velocidad de
ejecucin, requerimientos de memoria o tiempos de desarrollo.
Si el problema puntual se puede reformular como una instancia de un
problema general, es conveniente adoptar el paquete en vez de una
solucin especfica.
7. Incrementalidad.
La incrementalidad caracteriza un proceso que se desarrolla en forma de
pasos, en incrementos, alcanzando el objetivo deseado mediante
aproximaciones sucesivas al mismo, esto nos da un proceso evolutivo,
14
donde cada aproximacin es alcanzada a travs de un incremento de la
previa.
Debemos identificar subconjuntos primarios tiles para desarrollar y
distribuir a los clientes, de manera de obtener realimentacin temprana.
Esto nos permite que la aplicacin evolucione de manera controlada, en
casos donde los requerimientos iniciales no se comprendieron bien.
Muchas veces no es posible obtener todos los requerimientos antes de
comenzar el desarrollo de una aplicacin sino que stos van emergiendo a
partir de la experimentacin con la aplicacin o partes de sta. Por lo tanto,
lo antes que se pueda contar con feedback del usuario sobre la utilidad de
la aplicacin, ms fcil ser incorporar los cambios requeridos la producto.
Este principio est ligado al principio de anticipacin al cambio y es otro de
los principios en los que se basa la evolucionabilidad.
Las etapas intermedias son prototipos del producto final, lo cual beneficia el
entendimiento de los requerimientos y permite usar un modelo de desarrollo
iterativo ms flexible.
Debemos tener mucho cuidado en la manipulacin de documentos,
programas, datos de prueba y todo lo que usemos en las distintas
versiones. Si no se realiza con cuidado, un intento de desarrollo evolutivo
podra
rpidamente
indisciplinado
evolucionabilidad.
transformarse
perderse
todas
en
las
un
desarrollo
ventajas
de
potenciales
software
de
la
15
