Trabajo de ingeniería de software

Presentado por:

Juan David Santana Molina

Jorge Edison Delgadillo
Robinson Andrés Peralta
Jhon Alejandro Soler Bello

Presentado a:
Davis Díaz

Séptimo semestre – Diurno

Curso

Fundación universitaria de San Gil – UNISANGIL

Facultad de ciencias naturales e ingeniería

Chiquinquirá Boyacá
2019
1. Conceptos y Principios del Diseño de Software

El Diseño es un proceso de aplicar distintas técnicas y principios con el propósito

de definir un dispositivo, un proceso o un sistema con suficientes detalles como
para permitir su realización física, el objetivo del diseñador es producir un modelo
o representación de una entidad que se va a construir posteriormente, el diseño
del software cambia continuamente a medida que evolucionan nuevos métodos,
mejores análisis y perspectivas más amplias.

El diseño de software es la primera de las tres actividades técnicas, diseño,

codificación y prueba Figura 1,

Figura 1: Proceso de desarrollo de software, Fuente: Análisis y diseño de un

sistema.

Cada uno del modelo de análisis proporciona información necesaria para crear
un modelo de diseño, los requisitos de software, manifestado por datos y
modelos funcionales y de comportamiento, componen la fase de diseño, como
lo son:

- Diseño de datos: Transforma el modelo de dominio de la información,

creado durante el análisis, en las estructuras de datos necesarias para
implementar el software. Los objetos de datos y las relaciones definidas en el
diagrama entidad – relación (DER) y el contenido detallado de datos del
diccionario de datos proporciona la base para la actividad de diseño de datos.
- Diseño arquitectónico: Define la relación entre los principales
elementos estructurales del programa. Esta representación del diseño se
 puede obtener del modelo de análisis y de la interacción de subsistemas,
definidos dentro del modelo de análisis. Diagrama de flujo de datos.
- Diseño de interfaz: describe cómo se comunica el software consigo mismo,
con los sistemas que operan con él y con los operadores que lo emplean.
Una interfaz implica un flujo de información, entonces los diagramas de flujo
de datos y control proporcionan información necesaria para el diseño de la
interfaz.
- Diseño procedimental: transforma elementos estructurales de la
arquitectura del programa en una descripción procedimental de los
componentes de software. La información se obtiene de EP, EC y DTE sirve
de base para el diseño procedimental.
(Universidad Nacional de la Patagonia San Juan Bosco, 2012)

1.1.1 El Proceso De Diseño

En el proceso de diseño, se evalúa la calidad del diseño por medio de una serie
de revisiones técnicas formales, tres características que sirven como guía para
la evulación de un buen diseño son:

- Debe implementar todos los requisitos explícitos contenidos en el modelo

de análisis y debe acomodar todos los requisitos implícitos que desea el
cliente.
- Debe ser una guía que puedan leer y entender los que construyan el código
y los que prueban y mantienen el software.
- Debería proporcionar una completa idea de lo que es el software,
enfocando los dominios de datos, funcional y de comportamiento desde la
perspectiva de la implementación.

1.1.1.1. Criterios técnicos para un buen diseño:

- Presentar una organización jerárquica que haga un uso inteligente del control
entre los componentes del software.
- Ser modular (partición lógica del software en elementos que realicen
funciones y sub funciones específicas).
- Contener abstracciones de datos y procedimentales.
- Producir módulos que presenten características funcionales independientes.
- Conducir a interfaces que produzcan la complejidad de las conexiones entre
los módulos y el entorno exterior.
- Producir un diseño usando un método que pudiera repetirse según la
información obtenida durante el análisis de requisitos del software.

1.1.1.2. Los métodos de diseño tienen características comunes:

- Un mecanismo para la transformación de un modelo de análisis en una

representación del diseño.
- Una notación para representar componentes funcionales y sus interfaces.
- Heurísticas para el refinamiento y la partición.
- Consejos para valorar la calidad.
1.1.2. Principios Del Diseño

1.1.2.1. Principios básicos del diseño

- El proceso del diseño no debería ponerse orejeras: considerar enfoques

alternativos – recursos disponibles – conceptos de diseño -.
- Se debería poder seguir los pasos del diseño hasta el modelo de análisis.
- El diseño no debe inventar nada que ya esté inventado: componentes de
diseño reutilizables-.
- El diseño debería minimizar la distancia intelectual.
- El diseño debería presentar uniformidad e integración.
- El diseño debería estructurarse para admitir cambios.
- El diseño debería estructurarse para degradarse poco a poco, incluso cuando
se enfrenta a datos, sucesos o condiciones operativas aberrantes
- El diseño no es escribir código y escribir código no es diseñar.
- Se debería valorar la calidad del diseño mientras se crea, no después de
terminarlo.
- Se debería revisar el diseño para minimizar los errores conceptuales.

Cuando se aplica los principios de diseño mencionados antes, se crea un diseño

óptimos y con factores de calidad externos y internos.

- Factores de calidad externos: son esas propiedades del software que pueden
ser observadas fácilmente por los usuarios (por ejemplo, velocidad, fiabilidad,
grado de corrección, usabilidad).
- Factores de calidad internos: tienen importancia para los ingenieros del
software. Desde una perspectiva técnica conducen a un diseño de calidad
alta. Para lograr los factores de calidad internos, el diseñador deberá
comprender los conceptos de diseño básicos.

1.1.3. Conceptos Del Diseño

Cada fase del proceso es de suma importancia, debido a que la solución o

desarrollo de software es un refinamiento de nivel abstracto (Tovar, 2010), es
decir:

- abstracción procedimental: es una secuencia dada de instrucciones que

tienen una función específica y limitada.
- Abstracción de datos: es una colección determinada de datos que
describen un objeto de datos.
- Abstracción de control: implica un mecanismo de control del programa sin
especificar los detalles internos.

Abstracto: Permite al diseñador especificar procedimientos, datos y suprimir

detalles de bajo nivel.

Refinamiento: Ayuda al diseñador a revelar detalles de bajo nivel a medida que

progresa el diseño.
Modularidad: se divide al software en componentes identificables y tratables por
separado denominados módulos, que están integrados para satisfacer los
requisitos del programa. Cuatro criterios para evaluar un método de diseño con
respecto a su capacidad de definir un sistema modular eficaz (Tovar, 2010).
- capacidad de descomposición modular.
- Capacidad de empleo de componentes modulares.
- Capacidad de comprensión modular
- Protección modular

Arquitectura del software: el diseño del software debe crear una versión
arquitectónica de un sistema. Propiedades que deberían especificarse como
parte de un diseño arquitectónico:
- Propiedades estructurales: define los componentes de un sistema, la
manera que se empaquetan estos componentes y como interactúan con los
otros.
- Propiedades extra-funcionales: el diseño arquitectónico debería ocuparse
como consigue la arquitectura del diseño los requisitos de rendimiento,
capacidad, fiabilidad, seguridad, etc.
- Familias de sistemas relacionados: debería tener la capacidad de utilizar
bloques de construcción arquitectónica reutilizados.

1.1.4. Documentación del diseño

I) AMBITO.
II) DISEÑO DE DATOS.
III) DISEÑO ARQUITECTÓNICO
IV) DISEÑO DE INTERFAZ
V) DISEÑO PROCEDIMENTAL
VI) REFERENCIA CRUZADA DE REQUISITOS.
VII) RECURSOS DE PRUEBAS
VIII) NOTAS ESPECIALES
IX) APENDICE.

2. La Independencia funcional en el diseño modular

La independencia funcional se logra desarrollando módulos con funciones

“miopes” que tengan “aversión” a la interacción excesiva con otros módulos.
Dicho de otro modo, debe diseñarse software de manera que cada módulo
resuelva un subconjunto específico de requerimientos y tenga una interfaz
sencilla cuando se vea desde otras partes de la estructura del programa.
Es lógico preguntar por qué es importante la independencia.
El software con modularidad eficaz, es decir, con módulos independientes, es
más fácil de desarrollar porque su función se subdivide y las interfaces se
simplifican (cuando el desarrollo es efectuado por un equipo hay que considerar
las ramificaciones).
Los módulos independientes son más fáciles de mantener (y probar) debido a
que los efectos secundarios causados por el diseño o por la modificación del
código son limitados, se reduce la propagación del error y es posible obtener
módulos reutilizables. En resumen, la independencia funcional es una clave para
el buen diseño y éste es la clave de la calidad del software.
La independencia se evalúa con el uso de dos criterios cualitativos: la cohesión
y el acoplamiento.

1 Cohesión: Es una extensión natural del concepto de ocultamiento de

información. Un módulo cohesivo ejecuta una sola tarea, por lo que requiere
interactuar poco con otros componentes en otras partes del programa. En pocas
palabras, un módulo cohesivo debe (idealmente) hacer sólo una cosa.
Aunque siempre debe tratarse de lograr mucha cohesión (por ejemplo, una sola
tarea), con frecuencia es necesario y aconsejable hacer que un componente de
software realice funciones múltiples. Sin embargo, para lograr un buen diseño
hay que evitar los componentes “esquizofrénicos” (módulos que llevan a cabo
funciones no relacionadas).

2 Acoplamiento: Es una indicación de la interconexión entre módulos en una

estructura de software, y depende de la complejidad de la interfaz entre módulos,
del grado en el que se entra o se hace referencia a un módulo y de qué datos
pasan a través de la interfaz. En el diseño de software, debe buscarse el mínimo
acoplamiento posible.

El grado de acoplamiento mide la interrelación entre dos módulos, según el tipo

de conexión y la complejidad de las interfaces:

Fuerte
Por contenido, cuando desde un módulo se puede cambiar datos locales de otro.
Común, se emplea una zona común de datos a la que tienen acceso varios
módulos.

Moderado
De control, la zona común es un dispositivo externo al que están ligados los
módulos, esto implica que un cambio en el formato de datos los afecta a todos.

Débil
De datos, viene dado por los datos que intercambian los módulos. Es el mejor.
Sin acoplamiento directo, es el acoplamiento que no existe.

3 Comprensibilidad: Para facilitar los cambios, el mantenimiento y la reutilización

de módulos es necesario que cada uno sea comprensible de forma aislada.
Para ello es bueno que posea independencia funcional, pero además es
deseable:
Identificación, el nombre debe ser adecuado y descriptivo.
Documentación, debe aclarar todos los detalles de diseño e implementación que
no queden de manifiesto en el propio código.

4 Adaptabilidad: La adaptación de un sistema resulta más difícil cuando no hay

independencia funcional, es decir, con alto acoplamiento y baja cohesión, y
cuando el diseño es poco comprensible.
Otros factores para facilitar la adaptabilidad:

 Previsión: Es necesario prever que aspectos del sistema pueden ser

susceptibles de cambios en el futuro, y poner estos elementos en módulos
independientes, de manera que su modificación afecte al menor número
de módulos posibles.
 Accesibilidad: Debe resultar sencillo el acceso a los documentos de
especificación, diseño, e implementación para obtener un conocimiento
suficiente del sistema antes de proceder a su adaptación.
 Consistencia: Después de cualquier adaptación se debe mantener la
consistencia del sistema, incluidos los documentos afectados.

3. Modelo Estructurado Diseño de Sistemas

En el modelo estructurado se examinan brevemente las nueve actividades y

los tres terminadores que lo componen. Los terminadores son los usuarios, los
administradores, y el personal de operaciones. Los cuales se tratan de
individuos o grupos que proporcionan la entrada al equipo del proyecto, y son
los beneficiados finales del sistema.

Figura: Modelo Estructurado

Actividad 1: La encuesta

Esta actividad también se conoce como el estudio de factibilidad o como el

estudio inicial de negocios. Empieza cuando el usuario solicita que una o más
partes de su sistema se automaticen. Los principales objetivos de la encuesta
son:

 Identificar a los usuarios responsables y crear “”un campo de

actividad” inicial del sistema.
 Identificar las deficiencias actuales en el ambiente del usuario.
 Establecer metas y objetivos para un sistema nuevo.
 Determinar si es factible automatizar el sistema y de ser así, sugerir
escenarios aceptables.
 Preparar el esquema que se usará para guiar el resto del proyecto.

En general, la encuesta ocupa sólo del 5 al 10 por ciento del tiempo y los
recursos de todo el proyecto, y para los proyectos pequeños y sencillos pudiera
ni siquiera ser una actividad formal. A pesar de todo lo anterior, es una
actividad importante debido a que la administración pudiera decidir cancelar el
proyecto si no parece atractivo desde el punto de vista de costo-beneficio.
Actividad 2: El análisis de sistemas
El propósito principal de la actividad de análisis es transformar sus dos
entradas – o insumos o factores – principales, las políticas del usuario y el
esquema del proyecto, en una especificación estructurada. Esto implica
modelar el ambiente del usuario con diagramas de flujo de datos, diagramas de
entidad-relación, diagramas de transición de estado, etc.
El proceso paso a paso del análisis de sistemas implica el desarrollo de un
modelo ambiental y el desarrollo de un modelo de comportamiento, los cuales
se combinan para formar el modelo esencial que representa una descripción
formal de lo que el nuevo sistema debe hacer, independientemente de la
naturaleza de la tecnología que se use para cubrir los requerimientos.
Al final de la actividad de análisis también se debe preparar un conjunto de
presupuestos y cálculos de costo y beneficio más precisos y detallados.

Actividad 3: El diseño

La actividad de diseño se dedica a asignar porciones de la especificación

(modelo esencial) a procesadores adecuados (máquinas o humanos) y a
labores apropiadas (o tareas, particiones, etc.) dentro de cada procesador.
Dentro de cada labor, la actividad de diseño se dedica a la creación de una
jerarquía apropiada de módulos de programas y de interfases entre ellos para
implantar la especificación creada en la actividad 2. Además, se ocupa de la
transformación de modelos de datos de entidad-relación en un diseño de base
de datos.

Actividad 4: Implantación

Esta actividad incluye la codificación y la integración de módulos en un

esqueleto progresivamente más complejo del sistema final. Por eso, la
actividad 4 incluye tanto programación estructurada como implantación
descendente.

Actividad 5: Generación de pruebas de aceptación

La especificación estructurada debe contener toda la información necesaria

para definir un sistema que sea aceptable desde el punto de vista del usuario.
Por eso, una vez generada la especificación, puede comenzar la actividad de
producir un conjunto de casos de prueba
de aceptación desde la especificación estructurada.

Actividad 6: Garantía de calidad

La garantía de calidad también se conoce como la prueba final o la prueba de

aceptación. Esta actividad requiere como entradas los datos de la prueba de
aceptación generada en la actividad 5 y el sistema integrado producido en la
actividad 4.

Actividad 7: Descripción del procedimiento

Esta actividad implica la generación de una descripción formal de las partes del
sistema que se harán en forma manual, lo mismo que la descripción de como
interactuarán los usuarios con la parte automatizada del nuevo sistema. El
resultado de la actividad 7 es un manual para el usuario.

Actividad 8: Conversión de bases de datos

En algunos proyectos, la conversión de bases de datos involucraba más trabajo

que el desarrollo de programas de computadoras para el nuevo sistema. En
otros casos, pudiera no haber existido una base de datos que convertir. En el
caso general, esta actividad requiere como entrada las base de datos actual del
usuario, al igual que la especificación del diseño producida por medio de la
actividad 3.

Actividad 9: Instalación

En esta actividad sus entradas son el manual del usuario producido en la

actividad 7, la base de datos convertida que se creó con la actividad 8 y el
sistema aceptado producido por la actividad 6. En algunos casos la instalación
pudiera significar simplemente un cambio de la noche a la mañana al nuevo
sistema; en otros casos, la instalación pudiera ser un proceso gradual, en el
que un grupo tras otro de usuario van recibiendo manuales y entrenamiento y
comenzado a usar el nuevo sistema.

4. MODELO DE OBJETOS

La técnica de Modelado de Objetos (Object Modeling Technique OMT) se basa

en un conjunto de conceptos que definen que es Orientación a Objetos y sus
componentes o características, de igual manera una notación gráfica
independiente, de modo que la OMT propone una forma de pensar de modo
abstracto acerca de problemas a resolver empleando conceptos del mundo real
y no conceptos de computadoras, La notación gráfica propuesta ayuda al
desarrollo de software visualizando el problema sin recurrir en forma prematura
a la implementación.
El modelo y diseño orientado a objetos tiene como principal función resolver los
problemas empleando métodos que se han organizado y creado a base de
conceptos de la vida cotidiana, se debe tener en cuenta que la unidad básica
es el objeto que combina una serie de estructuras de datos con los
comportamientos en una entidad.
La Metodología OMT se extiende desde el análisis hasta la implementación
pasando por el diseño. En primer lugar, se construye un modelo de análisis
para abstraer los aspectos esenciales del dominio de la aplicación sin tener en
cuenta la implementación eventual. En este modelo se toman decisiones
importantes que después se completan para optimizar la implementación en
segundo lugar. Los objetos del dominio de la aplicación constituyen el marco de
trabajo del modelo de diseño, pero se implementan en términos de objetos del
dominio de la computadora. Por último, el modelo de diseño se implementa en
algún lenguaje de programación, base de datos o hardware (Rossi, Britos, &
Garcia, s.f.).
1. CONCEPTOS BASICOS DEL MODELO DE OBJETOS
Hay diversos conceptos que son propios de la orientación a objetos, que
tienen como objetivo reducir el tiempo de desarrollo, el desarrollo
orientado a objetos puede requerir más tiempo que el desarrollo
convencional porque se pretende que promueva la reutilización futura y
la reducción de los posteriores errores y el futuro mantenimiento.
1.1.1. Orientación a objetos: Significa que el software está organizado
por varios objetos discretos, el cual contiene tantos la estructura
de datos como el comportamiento.
1.1.2. Identidad: Los dato están cuantificados en entidades discretas y
distinguibles denominados objetos, se debe tener en cuenta que
los objetos son distintos aun así cuando pueden repetir sus
atributos, pero el nombre del objeto o entidad son diferentes.
1.1.3. Identificación: en el mundo real los objetos se limitan a existir,
pero dentro de un entorno de computación cada objeto posee una
identificación mediante la cual se puede hacer alusión a él de
modo exclusivo.
1.1.4. Clasificación: significa que los objetos con la misma estructura de
datos o atributos y comportamiento o operaciones son ejemplos
de clases.
1.1.5. Clase: es una abstracción que describe propiedades importantes
para una aplicación y que ignora el resto. La selección de clases
es arbitraria y depende de la aplicación. Una clase contienen el
molde (estructura, esquema) a partir del cual se crean los objetos
que pertenecen a ella y el código que debe ejecutarse cada vez
que un objeto de la clase recibe un mensaje. Una clase contiene
la descripción de las características comunes de todos los objetos
que pertenecen a ella: la especificación del comportamiento, la
definición de la estructura interna y la implementación de los
métodos. (Rossi, Britos, & Garcia, s.f.)
1.1.6. Instancia: Toda instancia de una clase posee su propio valor para
cada uno de los atributos pero comparte los atributos y las
operaciones con las demás clases o instancias.
1.1.7. Operación: Es una acción que lleva a cabo a un objeto, por
ejemplo, mover, se justifica la ubicación del objeto, es decir,
operaciones que afecten al objeto.
1.1.8. Método: Es una implementación especifica de una operación
ejecutada desde una clase.
1.1.9. Polimorfismo: significa que una operación puede comportarse de
modos distintos en distintas clases teniendo el mismo nombre de
método.
1.1.10. Herencia: es compartir atributos y operaciones entre clases
tomando como base una relación jerárquica. En términos
generales se puede definir una clase que después se irá
refinando sucesivamente para producir subclases.
1.1.11. Encapsulamiento: El encapsulamiento evita que el
programa sea tan interdependiente que un pequeño cambio tenga
 efectos secundarios masivos. La implementación de un objeto se
puede modificar sin afectar a las aplicaciones que la utilizan.
1.1.12. Combinación de datos y comportamiento: Es cuando un
objeto invoca una operación no necesita considerar cuantas
implementaciones existen en una operación dada; por otro lado el
mantenimiento es código que se llama y no necesita ser
modificado cuando se añade o importa una nueva clase.
1.1.13. Reutilización: la herencia tanto de estructuras de datos
como de comportamientos, permite compartir una estructura
común entre varias subclases similares sin redundancia. Una de
las principales ventajas de los lenguajes orientadas a objetos es
compartir código empleando la herencia. Todavía más importante
que el ahorro de código es la claridad conceptual que surge al
reconocer que distintas operaciones son todas ellas, realmente,
una misma cosa. Esto reduce el número de clases distintas que
es preciso comprender y analizar (Rossi, Britos, & Garcia, s.f.).
En conclusión el modelo de objetos tiene como finalidad capturar la
estructura del sistema a través de objetos clases que se utilizan en el
sistema, formular relaciones entre objetos y caracterizar cada clase del
objeto con asignaciones de atributos que describen sus características,
estados y operaciones donde especifican su funcionamiento.
El modelo de objetos es el más importante de una aplicación. En la
metodología orientada a objetos se enfatiza el estudio de los objetos en
vez de la funcionalidad (análisis estructurado), porque constituye una
descripción más próxima a la realidad y facilita los cambios y
adaptaciones posteriores.
El modelo de objetos proporciona una representación gráfica intuitiva
que constituye una descripción de la naturaleza de la aplicación y puede
ser utilizada como base de comunicación entre diseñadores y de estos
con los usuarios Figura 1, así mismo es la base de la documentación de
la estructura del sistema (Drake & Lopéz, 2008).
 (Montilva, Nelson, & Colmenares, 2008) (López, 2011) (Díaz, 2010)
(Adictos al trabajo, 2006) (Garcia, 2011) (Irby, 2016)

Figura 1: Análisis orientado a objetos, Fuente (Drake & Lopéz, 2008).

5. Modelo Dinámico

Es el proceso de desarrollo de software puede definirse como un conjunto de

herramientas, métodos y prácticas que se emplean para producir software.
Como cualquier otra organización, las dedicadas al desarrollo de software
mantienen entre sus principales fines, la producción de software de acuerdo con
la planificación inicial realizada, además de una constante mejora con el fin de
lograr los tres objetivos últimos de cualquier proceso de producción: alta calidad
y bajo coste, en el mínimo tiempo. La gestión de un PDS engloba, por tanto,
todas las funciones que mantengan a un proyecto dentro de unos objetivos de
coste, calidad y duración previamente estimados.

A continuación, se presentaran algunos modelos dinámicos cuyas aportaciones

fundamentales se centran en añadir nuevas capacidades y aplicaciones al
Modelo de Abdel-Hamid y Madnick. Estos modelos se pueden dividir en dos
grandes grupos:

1. existen dos principales caracteres generales creados para simular entornos

específicos de desarrollo dentro de una determinada organización :
 El Modelo SEPS (Software Engineering Process Simulation). Elaborado en el
laboratorio JPL (Jet Propulsion Laboratory). Diseñado para simular el
comportamiento de proyectos grandes considerando la existencia de un doble
ciclo de vida: el proceso de desarrollo propiamente dicho y el proceso de toma
de decisiones. Además, introduce sistemas expertos con lógica fuzzy en la
interfaz del modelo.

- El Modelo de Draper Laboratory. El Modelo de Draper constituye una

ampliación del Modelo de Abdel-Hamid y Madnick. Presenta como novedad la
incorporación de la etapa de Análisis de Requisitos (no tratada en el Modelo de
Abdel-Hamid y Madnick) contemplando la posibilidad de que estos requisitos
pueden cambiar a lo largo del proyecto e incorpora también una serie de
variables y relaciones para analizar la influencia que puede tener en el proyecto
las relaciones con el cliente.

2. Los tres caracteres más principales específicos para analizar problemas

concretos presentados en la gestión de PDS son:

- El Modelo de Chichakli. Este modelo realizado para estudiar el impacto de un

cambio de tecnología, concretamente el cambio de C a C++, dentro de una
empresa de desarrollo de aplicaciones para Macintosh poniendo de manifiesto
la reacción de oposición o resistencia por parte de los técnicos ante la
implantación de cualquier tipo de cambio en las técnicas o métodos de trabajo
empleados normalmente.

- El Modelo Aranda/Friddaman/Oliva. Este modelo añade aspectos nuevos al

modelo de Abdel-Hamid y Madnick como son los efectos del empleo de las
técnicas TQM (Total Quality Management) para el control de calidad, la
ampliación del horizonte temporal del proyecto con el fin de recoger las diferentes
versiones del software producido y el estudio del impacto comercial del producto
final.

- El modelo Multiproyecto. Este modelo estudia las transferencias netas de

personal que se producen cuando interactúan dos proyectos por los mismos
recursos.

6. Reutilización de software

Es el proceso de creación de sistemas de software a partir de un software

existente, en lugar de tener que rediseñar desde el principio.

En los años 60, se construyeron bibliotecas de subrutinas científicas reutilizables

con un dominio de aplicación limitado, en la actualidad se crean componentes
comunes a varios procesos con el fin de poder utilizarlos en la construcción de
software.

Podemos definirla como el empleo de elementos de software u otros de nivel

superior, creados en desarrollo anteriores, para de este modo reducir los tiempos
y simplificar el desarrollo del software, mejorando la calidad y reduciendo su
costo.
Elementos que intervienen en la reutilización

 Especificaciones de requerimientos previamente concebidas

 Diseños previamente definidos (Estructuras de datos, algoritmos, etc.)
 Código probado y depurado con anterioridad
 Planes y casos de prueba previamente utilizados
 Personal cualificado (aprovechamiento de la experiencia de los ingenieros
de un proyecto a otro)
 Paquetes de software de propósito general

Conceptos de reutilización de software

 La reutilización de software aparece como una alternativa para desarrollar

aplicaciones y sistemas SW de un manera más eficiente, productiva y
rápida.
 La idea es reutilizar elementos y componentes SW en lugar de tener que
desarrollarlos desde un principio.
 Surge formalmente de 1968
 La idea principal era producir componentes de software como si de
componentes eléctricos se tratara.
 El objetivo es reutilizar lo existente sin tener que volver a rediseñar desde
el principio.

Dificultades de la reutilización

 En muchas empresas no existe plan de reutilización (No se considera

prioritario)
 Escasa formación
 Resistencia del personal
 Pobre soporte metodológico
 Uso de métodos que no promueven la reutilización (Estructurados)
 Necesario métodos para:
 Desarrollo para reutilización
 Desarrollo con reutilización

Ventajas

 Reducir el tiempo de desarrollo.

 Reducir los costos.
 Incrementar la productividad.
 No tener que reinventar las soluciones.
 Facilitar la compartición de productos del ciclo de vida.
 Mayor fiabilidad
 Mayor eficiencia (Aunque al principio pueda parecer que no)
 Consistencia y la familiaridad, los patrones dentro del software serán más
consistentes, tendiendo a facilitar el mantenimiento del producto.

Desventajas
  Necesidad de invertir antes de obtener resultados.
 Carencia de métodos adecuados.
 Necesidad de formar al personal.
 Convencer a los “manager”.
 Dificultad para institucionalizar los procesos.

Categorías de recurso de software

1. Componentes ya desarrollados

El software existente se puede adquirir de una tercera parte o provenir de uno

desarrollado internamente para un proyecto anterior. Llamados componentes
CCYD (componentes comercialmente ya desarrollados), estos componentes
están listos para utilizarse en el proyecto actual y se han validado totalmente.

2. Componentes ya experimentados
Especificaciones, diseños, código o datos de prueba existentes desarrollados
para proyectos anteriores que son similares al software que se va a construir
para el proyecto actual. Los miembros del equipo de software actual ya han
tenido la experiencia completa en el área de la aplicación representada para
estos componentes. Las modificaciones, por tanto, requeridas para
componentes de total experiencia, tendrán un riesgo relativamente bajo.

3. Componentes con experiencia parcial

Especificaciones, diseños, código o datos de prueba existentes desarrollados
para proyectos anteriores que se relacionan con el software que se va a construir
para el proyecto actual, pero que requerirán una modificación sustancial. Los
miembros del equipo de software actual han limitado su experiencia sólo al área
de aplicación representada por estos componentes. Las modificaciones, por
tanto, requeridas para componentes de experiencia parcial tendrán bastante
grado de riesgo.

4. Componentes nuevos
Los componentes de software que el equipo de software debe construir
específicamente para las necesidades del proyecto actual.

Unidades de software que se reutilizan:

 Reutilización de sistemas de aplicación

 Se incorpora sin ningún cambio en otros sistemas
 Configuración de la aplicación para diferentes clientes
 Reutilización de componentes
 Varía en tamaño desde subsistemas hasta objetos simple
 Reutilización de objetos y funciones
 Reutilización de componentes software que implemente una única
función

Tipos de reutilización
 Oportunista
  El ingeniero de software reutiliza piezas que él sabe que se ajustan al
problema
 Sistemática
 Esfuerzo a nivel organizacional y planificado de antemano
 Todo componente reutilizado ha de ser ideado, a priori, para ser
reutilizado
 mplica inversiones iniciales para recoger frutos en el futuro
 Diseñar componentes genéricos para que sean reutilizados con facilidad

 Se desarrollan pequeños componentes para una determinada aplicación

 Se incorpora a un repositorio

 Se determinan las piezas necesarias que encajan unas con otras

 Se van desarrollando poco a poco
 Requiere alta inversión a comienzo
 Se recogerán beneficios en el futuro

Análisis de escenarios para la reutilización

Existen al menos 4 escenarios en los que un proyecto de software requerirá

elementos de reutilización.

1.El proyecto es similar a un anterior (reutilización de un proyecto existente).

2.Mismo proyecto con configuración diferente (reutilizan productos actuales)
3.Características de uso basados en productos existentes
4.Nueva Arquitectura con capacidades o elementos existentes

Patrones de diseño
 Descripción del problema y la esencia de una solución, de forma que la
solución se pueda reutilizar en diferentes situaciones
 No es una especificación detallada
 Es una descripción de conocimiento y experiencia acumulada

Los patrones y los lenguajes de patrones son formas de describir las mejores
prácticas, buenos diseños y encapsulan la experiencia de tal forma que es
posible para otros reutilizar dicha experiencia

Elementos esenciales de un patrón de diseño

Nombre que es una referencia significativa del patrón
Una descripción del área del problema que explica cuándo puede aplicarse el
patrón
Descripción de las partes de la solución del diseño, sus relaciones y sus
responsabilidades.
Una declaración de las consecuencias de aplicar el patrón

Tipos de patrones
1. Patrones de creación
Permiten que el sistema sea independiente de cómo se crean, componen o
representan sus objetos
Encapsulan el conocimiento sobre las clases concretas que se van a utilizar
Ejemplos: Abstract factory, Builder, Factory Method, Singleton
2. Patrones estructurales
Facilitar y mejorar las relaciones entre objetos
Manera en que las instancias se comunican entre si.
Ejemplos: Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy
3. Patrones de comportamiento
Están relacionados con el flujo de control del sistema
Ciertas formas de organizar el control en un sistema pueden derivar en grandes
beneficios para la eficiencia y el mantenimiento del sistema
Ejemplos: Chain of Responsability, Comand, Interpreter, Iterator, Mediator,
Memento, Observer, State, Strategy, Template Method, Visitor

Niveles de Reutilización
1. Reutilización de Código
 Librerías de funciones, editores, inclusión de ficheros, mecanismos
de herencia en POO, componentes, etc.
2. Reutilización de Diseños
 No volver a inventar arquitecturas
ejemplo: patrones de diseño.

ejemplo:patrones arquitectónicos (C/S, pipeline, OO, )

3. Reutilización de Especificaciones
 Reutilización de las abstracciones del dominio
 Debe estar asociada a la generación (semi)automática de los elementos
de diseño e implementación.

Aspectos para la reutilización de software existente

1. Si los componentes ya desarrollados cumplen los requisitos del proyecto,
El coste de la adquisición y de la integración de los componentes ya
desarrollados serán casi siempre menores que el coste para desarrollar el
software equivalente. Además, el riesgo es relativamente bajo.

2. Si se dispone de componentes ya experimentados, los riesgos asociados

a la modificación y a la integración generalmente se aceptan. El plan del
proyecto debería reflejar la utilización de estos componentes.

3. Si se dispone de componentes de experiencia parcial para el proyecto

actual, su uso se debe analizar con detalle. Si antes de que se integren
adecuadamente los componentes con otros elementos del software se requiere
una gran modificación, proceda cuidadosamente - el riesgo es alto. El coste de
modificar los componentes de experiencia parcial algunas veces puede ser
mayor que el coste de desarrollar componentes nuevos. De forma irónica, a
menudo se descuida la utilización de componentes de software reutilizables
durante la planificación, llegando a convertirse en la preocupación primordial
durante la fase de desarrollo del proceso de software. Es mucho mejor
especificar al principio las necesidades de recursos del software. De esta forma
se puede dirigir la evaluación técnica de alternativas y puede tener lugar la
adquisición oportuna.
7. SIMPLIFICAR LAS PRUEBAS

Una manera de aliviar en la experiencia de externalización es la de subcontratar

solamente el control de calidad. Todas las empresas de desarrollo
externalizadas con las que he trabajado ofrecen servicios de control de calidad,
así como el desarrollo. Al contratar las pruebas no sólo obtendrá el valor del
servicio prestado, sino que también podrá evaluar la compañía para ver si el
equipo consigue sus plazos y en general actúa de una manera profesional.
Paso 1. Demostración
Antes de firmar el contrato de servicios, ofrezca una demostración de su
aplicación al proveedor que seleccione para tercerizar su desarrollo de software.
El equipo debe estar ansioso por impresionarlo, así que escuche las preguntas
que hacen y sus ideas sobre cómo hacer las pruebas. Esté en guardia para
preguntas formuladas o indicaciones de que lo están leyendo de un guión. Si
tratan de profundizar en los detalles durante una demostración, es una buena
señal de que harán lo mismo más adelante. Usted aprenderá mucho acerca de
sus competencias y habilidades al escuchar lo que hacen, y si no, pregunte.

Paso 2. Pregunte sobre herramientas automatizadas

El aseguramiento de la calidad (QA) se compone de una combinación de la rutina

y la exploración. Las pruebas de regresión (regression testing) evalúan las
características existentes, supuestamente sin modificar, y aseguran que nada se
rompe accidentalmente mientras se hace un cambio. Las pruebas de regresión
se benefician de la automatización debido a que los mismos pasos y
comprobaciones deben hacerse una y otra vez. Pagarle a una persona para
hacer esto es un desperdicio y es propenso a errores, por lo que el proveedor de
servicios debe contar con herramientas de automatización de pruebas para
manejar esta situación.

Estas herramientas automatizadas deberían ser más que simples formas rápidas
de introducción de datos en la base de datos de errores. Los paquetes de
software, tales como Selenium, permiten que el equipo de control de calidad
escriba código que inicia la aplicación e interactúa con ella al igual que lo haría
un usuario. El software puede pulsar botones, introducir datos, elegir diferentes
opciones y luego leer la pantalla para garantizar que se hayan dado las
respuestas correctas. Es importante saber qué herramienta utiliza el equipo de
control de calidad porque sus desarrolladores de aplicaciones pueden modificar
ligeramente la forma en que construyen el software para hacer que el proceso
de prueba automatizado sea más fácil y más productivo.

Paso 3. Disponga de una base de datos de errores

La empresa que elija para externalizar el desarrollo de software probablemente

le permitirá utilizar su base de datos de errores, incluso presentándolo como una
ventaja para hacer negocios con ellos. Esto sería un error. La información sobre
los errores encontrados y la forma en que se tratan es de vital importancia para
usted, así que no debería dejar que alguien más tenga el control de ello.
Conseguir su propia base de datos de errores es tan fácil como escribir el número
de su tarjeta de crédito. Sólo búsque "Bug Database Hosting" (hospedaje de
bases de datos de errores) y encontrará muchas opciones. Si usted no tiene una
preferencia, o no tiene el tiempo para investigar cuál es la mejor, pregunte a su
socio tercerizado cuál es la que utiliza.

Paso 4. Formación

No sea víctima de la "maldición del conocimiento". Usted ha estado pensando y

trabajando con su aplicación por un tiempo, así que por supuesto le parece obvio
cómo debe y no debe funcionar. No será tan obvio para los demás. Invierta el
tiempo para entrenar adecuadamente al equipo externo sobre la forma en que
su aplicación debería funcionar. Parte de esta formación es decirles lo que no
debería ocurrir. Anticipe los errores frecuentes o comunes y dígale al equipo de
control de calidad que esté atento a ellos.

Además, no espere hacer esto una sola vez. Este es un proceso continuo, por lo
que debe asignar tiempo para hacerlo cuando sea necesario.

Paso 5. Inicie las pruebas

Es el momento de comenzar la prueba. Envíe las credenciales de inicio de sesión

al equipo de control de calidad para el servicio de seguimiento de errores y
proporcióneles un poco de dirección. Inicialmente enfoque su prueba en un área
pequeña que puedan terminar dentro de una semana y luego deje que ellos
hagan su magia.

Cuando registren errores en su gestor de fallos (bug tracker), puede comprobar

su progreso para asegurarse de que se están centrando en las cosas correctas.

Paso 6. Pruebas paralelas internas

Es difícil y peligroso externalizar por completo todo el control de calidad. Algún

tipo de control interno debe mantenerse para asegurar que nada se escape. A
medida que adquiera confianza en el equipo externo, el equipo de pruebas en
paralelo pueden ser eliminado a favor de una sola persona, pero no es
aconsejable dejar que el equipo externo sea el único control de calidad para el
proyecto.
Las pruebas en paralelo tienen otra ventaja –saca a la luz la formación adicional
que el equipo tercerizado necesita. El registro de errores que no son válidos (es
decir, la aplicación está funcionando correctamente) significa que no entienden
el área de la aplicación.

Con esto en mente, es importante que el equipo externo y el interno se lleven

bien. Deje a su equipo interno con el equipo externo para asegurar que todas las
personalidades se combinan bien.
Referencias
Adictos al trabajo. (22 de junio de 2006). Adictos al trabajo. Obtenido de
Presente y Futuro de:
https://www.adictosaltrabajo.com/2006/06/22/reuse/
Díaz, L. (8 de julio de 2010). SlideShare. Obtenido de Seminario 3,
Reutilización de Software: http://www.slideshare.net/pto0404/seminario-
3-reutilizacin-del-software
Drake, J., & Lopéz, P. (2008). unican. Obtenido de Ingenieria de Software:
https://www.ctr.unican.es/asignaturas/Ingenieria_Software_4_F/Doc/M5_
08_Analisis-2011.pdf
Garcia, v. (13 de diciembre de 2011). PROGRAMACIÓN EN JAVA. Obtenido
de Reutilización de Software Ventajas y Desventajas:
https://programarjava.wordpress.com/2011/12/13/reutilizacion-de-
software-ventajas-y-desventajas/
Irby, B. (29 de abril de 2016). Search Data Center. Obtenido de Cómo
simplificar la forma en que externaliza el desarrollo de software:
https://searchdatacenter.techtarget.com/es/consejo/Como-simplificar-la-
forma-en-que-externaliza-el-desarrollo-de-software
López, J. (2011). Scribd. Obtenido de Ingenieria de Software:
http://www.giro.infor.uva.es/oldsite/docpub/ideas-2001.pdf
Montilva, J., Nelson, A., & Colmenares, J. (2008). webdelprofesor. Obtenido de
Desarrollo de Software Basado en Componentes :
http://webdelprofesor.ula.ve/ingenieria/jonas/Productos/Publicaciones/Co
ngresos/CAC03%20Desarrollo%20de%20componentes.pdf
Rossi, B., Britos, p., & Garcia, R. (s.f.). laboratorios.fi.uba.ar. Recuperado el 4
de 11 de 2019, de MODELADO DE OBJETOS:
http://laboratorios.fi.uba.ar/
Tovar, R. (29 de mayo de 2010). Scribd. Obtenido de CAPITULO_13
CONCEPTOS Y PRINCIPIOS DE DISEÑO:
https://es.scribd.com/doc/32165504/CAPITULO-13-CONCEPTOS-Y-
PRINCIPIOS-DE-DISENO
Universidad Nacional de la Patagonia San Juan Bosco. (2012). Análisis y
Diseño de Sistemas. Obtenido de Unidad 4: El Proceso de Diseño:
http://www.ing.unp.edu.ar/asignaturas/ayd/teoria/Unidad04-I.pdf
Chichakly K., The Bifocal Vantage Point. Managing software projects from a
systems thinking perspective.
http://www.sc.ehu.es/jiwdocoj/remis/docs/modelos.html.

Lin C. Y., Walking on Battlefields: Tools for Strategic software mangement.