UNIVERSIDAD NACIONAL

SANTIAGO ANTNEZ DE MAYOLO

FACULTAD DE CIENCIAS
ESCUELA ACADMICO PROFESIONAL DE INGENIERA DE SISTEMAS
E INFORMTICA

INGENIERA DE SOFTWARE II
PRINCIPIOS DE LA INGENIERA DE SOFTWARE

AUTORES
GONZALEZ BARRETO CRISTIAN YERSI
RIVERA VERGARAY KEVIN
ROJAS MENDEZ JIMMY
RURUSH ROSAS ALFONSO ROSSELL
TINOCO CORPUS ZINNIA MEDALIT

DOCENTE
Ing. SILVA ZAPATA MIGUEL NGEL
HUARAZ PER
2015

PRINCIPIOS DE LA INGENIERA DE SOFTWARE

I.

PRINCIPIO DE MODULARIDAD
Un sistema complejo puede dividirse en piezas ms simples
llamadas mdulos, un sistema compuesto de mdulos es llamado
modular. El principal beneficio de la modularidad es que permite la
aplicacin del principio de separacin de intereses en dos fases:
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 tiene tres objetivos principales:
-

Capacidad de descomponer un sistema complejo.

Capacidad de componerlo a partir de mdulos existentes.
Comprensin del sistema en piezas (o pedazos).

La posibilidad de descomponer un sistema se basa en dividir en

subproblemas de forma top-down el problema original y luego aplicar
el principio a cada subproblema en forma recursiva. Este
procedimiento refleja el bien conocido principio de Divide y Vencers.
La posibilidad de componer un sistema est basada en obtener el
sistema final de forma bottom up a partir de componentes
elementales. Idealmente en la produccin de software se quisiera
poder ensamblar nuevas aplicaciones tomando mdulos de una
biblioteca y combinndolos para formar el producto requerido; estos
mdulos deberan ser diseados con el objetivo expreso de ser
reusables.
La capacidad de comprender cada parte de un sistema en forma
separada ayuda a la modificabilidad del sistema. 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. Cuando se hace necesario
reparar el sistema, la modularizacin apropiada ayuda a restringir la
bsqueda de la fuente de error a componentes separados.
Para alcanzar estos objetivos los mdulos en los que se divida el
sistema deben tener alta cohesin y bajo acoplamiento.
Un mdulo tiene alta cohesin si todos sus elementos estn
fuertemente relacionados y son agrupados por una razn lgica, esto
3

es todos cooperan para alcanzar un objetivo comn que es la funcin

del mdulo. La cohesin es una propiedad interna de cada mdulo,
por el contrario el acoplamiento caracteriza las relaciones de un
mdulo con otros. El acoplamiento mide la interdependencia de dos
mdulos, por ejemplo si el mdulo A hace una llamada a una rutina
provista por el mdulo B o accede a una variable declarada por el
mdulo B. Si dos mdulos dependen fuertemente uno del otro tienen
un alto acoplamiento lo que los vuelve difciles de analizar,
comprender, modificar, testear o reusar en forma separada.
Idealmente se quiere que los mdulos de un sistema tengan bajo
acoplamiento.
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.
Divisin de un sistema en partes ms simples (mdulos). Esto nos
permite separar los contextos en fases: cuando relacionamos cada
mdulo aislado y cuando relacionamos todos los mdulos
globalmente, analizando sus conexiones e integracin.

Objetivos de la modularidad:

Capacidad de descomposicin de un sistema complejo: divisin

del problema original en subproblemas y luego dividir cada
subproblema.
Composicin 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 mdulos de una biblioteca, que al ser reutilizables, aceleran el
proceso de construccin.
Comprensin del sistema mirndolo en partes: Nos facilita la
reparacin y modificacin, al buscar los errores en un componente en
particular.

Para lograr los tres objetivos, los mdulos deben tener:

Alta cohesin: sus elementos internos estn muy relacionados y

agrupados por razones lgicas.

 Bajo acoplamiento: es la relacin entre mdulos y mide la

interdependencia entre 2 mdulos. La idea es lograr que los mdulos
tengan un nivel bajo.

Las estructuras que cumplan esto nos permiten ver los mdulos
como cajas negras cuando describimos la estructura total y verlos
separadamente cuando analizamos la funcionalidad de cada uno.

II.

PRINCIPIO DE ANTICIPACIN AL CAMBIO

La anticipacin al cambio es posiblemente el principio que ms
distingue al software de otros tipos de produccin industrial. Muchas
veces una aplicacin de software es desarrollada mientras sus
requerimientos an no estn completamente comprendidos, al ser
liberado y obtener retroalimentacin del usuario debe evolucionar con
nuevos requerimientos o cambios a los requerimientos ya existentes
los cuales pueden tener distintos orgenes, por ejemplo debido a
cambios en el ambiente de la organizacin
La habilidad del software para evolucionar no viene sola sino que
requiere esfuerzo especial para anticipar cmo y cundo pueden
ocurrir estos cambios. Cuando se identifican posibles cambios
futuros, se debe tener cuidado de proceder de forma que estos sean
fciles de aplicar, es importante aislar los posibles cambios en
porciones especficas del software de tal forma que estn
restringidos a esas partes.
Por lo tanto este principio puede ser utilizado para lograr la
evolucionabilidad del software y tambin la reusabilidad de
componentes, viendo la reusabilidad como evolucionabilidad de
granularidad ms fina, a nivel de componentes.
La aplicacin de este principio requiere que se disponga de
herramientas apropiadas para gestionar las varias versiones y
revisiones del software en forma controlada. Debe ser posible
almacenar y recuperar documentacin, fuentes, ejecutables, etc. de
una base de datos que acte como repositorio central de
componentes reusables, y el acceso a la misma debe estar
controlado. Un sistema de software debe mantenerse consistente,
incluso cuando se aplican cambios a algunos de sus componentes.
La disciplina que estudia esta clase de problemas es la Gestin de
Configuracin y se ver posteriormente.
La anticipacin al cambio tambin aplica al proceso de desarrollo de
software, por ejemplo, en la gestin del proyecto los gerentes
deberan anticipar los efectos de una reduccin de personal, estimar
5

los costos y disear la estructura de la organizacin que apoyar la

evolucin del software, y decidir cuando vale la pena invertir tiempo y
esfuerzo en la produccin de componentes reusables tanto como
parte de un proyecto de desarrollo de software o como un esfuerzo
de desarrollo paralelo.
Se refiere a la mantenibilidad. Es poder predecir los cambios y
trabajar para que los cambios futuros sean fciles de aplicar.
Esto es importante en el software, ya que los productos estn en
ambientes donde permanentemente surgen nuevos requerimientos.
La reusabilidad tambin se ve afectada por esto. Un componente es
reusable si se puede emplear para generar un nuevo producto o si
solo requiere pequeos cambios para ello. La reusabilidad es la
capacidad de evolucionar que tienen los componentes.

III.

PRINCIPIO DE GENERALIDAD
El principio de generalidad establece que al tener que resolver un
problema se debe buscar un problema ms general que
posiblemente est oculto tras el problema original, puesto que puede
suceder que el problema general no sea mucho ms complejo (a
veces puede ser incluso ms simple) que el original y posiblemente
la solucin al problema general tenga potencial de reuso, o exista en
el mercado como paquete o se disee un mdulo que puede ser
invocado por ms de un punto en la aplicacin en lugar de tener
varias soluciones especializadas.
Por otro lado, una solucin general posiblemente sea ms costosa en
trminos de rapidez de ejecucin, requerimientos de memoria o
tiempo de desarrollo, que una solucin especializada al problema
original, por lo que debe evaluarse la generalidad respecto al costo y
la eficiencia al momento de decidir qu vale ms la pena, una
solucin general o una especializada.
La generalidad es un principio fundamental si se tiene como objetivo
el desarrollo de herramientas generales o paquetes para el mercado,
ya que para ser exitosas debern cubrir las necesidades de distintas
personas. Estos productos de propsito general, off-the-shelf como
por ejempo los procesadores de texto, representan una tendencia
general en el software; para cada rea especfica de aplicacin
existen paquetes generales que proveen soluciones estndares a
problemas comunes. Esta tendencia es idntica a lo que ocurri en
otras reas de la industria como por ejemplo, los automviles que en
los inicios de la tecnologa automotriz era posible hacer autos de
acuerdo a los requerimientos especficos de un cliente, pero a
medida que el rea se fue industrializando solo podan encargarse a
6

partir de un catlogo y actualmente no es posible pedir un diseo de

auto personal a menos que se est dispuesto a pagar una enorme
cantidad de dinero.
Poder descubrir un problema ms general en la resolucin 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 ms costoso en
trminos de velocidad de ejecucin, 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
solucin especfica.