Ingenieria de Software II - 2021

Auditoria II
INGENIERÍA DEL
SOFTWARE II
INGENIERÍA DE SISTEMAS
Ingeniería del Software II
sfs
© Corporación Universitaria
Remington
Medellín, Colombia
Derechos Reservados ©2011
Quinta edición
2021
Yolfaris Naidit Fuertes Arroyo
Facultad de Ingenierías
Comité académico
Jorge Mauricio Sepúlveda Castaño
Decano de la Facultad de Ingenierías
jsepulveda@uniremington.edu.co
David Ernesto González Parra

Director de Educación a Distancia y Virtual
dgonzalez@unireminton.edu.co
Francisco Javier Álvarez Gómez

Coordinador CUR-Virtual
falvarez@uniremington.edu.co
Edición y Montaje
Dirección de Educación a Distancia y Virtual
Equipo de diseño gráfico
www.uniremington.edu.co
virtual@uniremington.edu.co
Derechos reservados: El módulo de estudio del curso de INGENIERÍA

DEL SOFTWARE II es propiedad de la Corporación Universitaria
Remington; las imágenes fueron tomadas de diferentes fuentes que
se relacionan en los derechos de autor y las citas en la bibliografía. El
contenido del módulo está protegido por las leyes de derechos de autor
que rigen al país. Este material tiene fines educativos y no puede
usarse con propósitos económicos o comerciales. El autor(es) certificó
(de manera verbal o escrita) No haber incurrido en fraude científico,
plagio o vicios de autoría; en caso contrario eximió de toda
responsabilidad a la Corporación Universitaria Remington y se declaró
como el único responsable.
Esta obra es publicada bajo la licencia Creative Commons.

Reconocimiento-No Comercial-Compartir Igual 2.5 Colombia
sfs
3
TABLA DE CONTENIDO
Pág.
1 UNIDAD 1: DISEÑO DE SOFTWARE 7

1.1.1 OBJETIVO GENERAL 7
1.1.2 OBJETIVOS ESPECÍFICOS 7
1.1.3 PRUEBA INICIAL 8
1.2 TEMA 1 ARQUITECTURA DE DISEÑO DE SOFTWARE 8

1.2.1 EJERCICIO DE APRENDIZAJE 10
1.2.2 TALLER DE ENTRENAMIENTO 10
1.3 TEMA 2 PATRONES DE DISEÑO DE SOFTWARE 11

1.1 TEMA 3 DISEÑO DE SOFTWARE 13

1.1.1 DISEÑO DE METODOLOGÍAS ÁGILES UTILIZANDO FRAMEWORKS 15
1.1.2 HERRAMIENTAS DE DESARROLLO DE INTERFAZ 17
1.1.3 EVALUACIÓN Y ANÁLISIS DE LA CALIDAD DEL DISEÑO 20
2 UNIDAD 2 GESTIÓN DE CONFIGURACIÓN DE SOFTWARE. 23

2.1.2 OBJETIVOS ESPECIFICOS 24
2.2 TEMA 1 GESTIÓN E IDENTIFICACIÓN DE OBJETOS EN LA CONFIGURACIÓN DEL SISTEMA 24

2.2.1 PROCESO DE CONTROL DE CAMBIOS 26
2.2.2 CONTROL DE VERSIONES 27
2.2.3 AUDITORÍA DE LA CONFIGURACIÓN E INFORME DE ESTADOS 28
2.3 TEMA 2 HERRAMIENTAS PARA LA GESTIÓN DE LA CONFIGURACIÓN DE SOFTWARE 31

2.3.1 EJERCICIOS DE APRENDIZAJES 33
3 UNIDAD 3 GESTIÓN DE PROYECTOS DE SOFTWARE ASOCIADO A LAS MÉTRICAS 35

3.1.2 OBJETIVOS ESPECIFICOS 35
3.2 TEMA 1 PLANEACIÓN Y MANEJO DE RIESGOS DE PROYECTOS DE SOFTWARE 37

sfs
4
3.3 TEMA 2 MÉTODOS Y ESTÁNDARES DE MEDICIÓN 46

3.3.1 EJERCICIOS DE APRENDIZAJES 48
3.4 TEMA 3 MÉTRICAS DE CALIDAD DEL SOFTWARE 49

3.4.1 METRICAS ASOCIADAS CON EL PROCESO 51
3.4.2 MÉTRICAS ASOCIADAS CON EL PRODUCTO Y LA ESTIMACIÓN DE PROYECTOS. 53
3.4.3 MÉTRICAS ASOCIADAS CON LAS PERSONAS 54
4 PISTAS DE APRENDIZAJE 58
5 GLOSARIO 59
6 BIBLIOGRAFÍA 60
sfs
PROPÓSITO GENERAL
INGENIERÍA DEL
SOFTWARE II
Integrar los diferentes conceptos del diseño de software, de la gestión de configuración
de software y de la gestión de proyectos de software asociado a las métricas, partiendo
de la evolución de las especificaciones de requerimientos iniciales, con el fin de construir
diseños que se adapten a las necesidades del cliente.
El educando aprenderá a planificar estrategias prácticas, que lo conduzca a la aplicación
de los métodos y modelados necesarios para el diseño de aplicativos que garanticen la
calidad del mismo, implementando un buen manejo de los posibles riesgos que se
presenten en el desarrollo del proyecto de software.
sfs
INGENIERÍA DE
SOFTWARE II
OBJETIVO GENERAL
Aplicar los conceptos, técnicas y metodologías de la ingeniería del
software, al diseño de aplicativos, teniendo como concepción la
arquitectura de software, los patrones y principios del diseño; propiciando
la gestión de la configuración de un diseño bajo normas y estándares de
calidad.
OBJETIVOS ESPECÍFICOS
➢ Analizar el nivel de complejidad de la Ingeniería del software, direccionado
a una visión sistémica, que permita la comprensión a través de la
estructura del conocimiento, de las diferentes filosofías, procesos,
métodos y herramientas, que ayudan al diseño de un software de calidad.
➢ Identificar los posibles riesgos que se presenten en el desarrollo de un
aplicativo, implementando un análisis de riesgos medibles y estimados, de
acuerdo al ámbito del producto y su viabilidad, teniendo presente la
gestión de la configuración del producto.
➢ Desarrollar diseños de software que respondan a las exigencias del
mercado.
UNIDAD 1 UNIDAD 2 UNIDA 3
Gestión de proyectos de
Gestión de configuración
Diseño de software software asociado a
de software
métricas
sfs
7
1 UNIDAD 1: DISEÑO DE SOFTWARE
Figura 1. Diseño de software.

Fuente: Elaboración propia (2020).
1.1.1 OBJETIVO GENERAL

Proporcionar al estudiante los conceptos, técnicas y herramientas necesarias para la las buenas
prácticas de la ingeniería del software, tomando como punto de partida la especificación de los
requisitos del cliente, direccionado a la entrega de un diseño que garantice la calidad.
1.1.2 OBJETIVOS ESPECÍFICOS

➢ Implementar las estrategias, métodos y herramientas que lleven a la construcción de un
aplicativo de calidad, el cual satisfaga las necesidades del cliente.
sfs
8
➢ Fortalecer en el estudiante las diversas estrategias de planificación, supervisión y control
de los métodos, técnicas y herramientas necesarias para el desarrollo de un diseño de
calidad.
➢ Identificar las diversas herramientas utilizables en el diseño de una interfaz de usuario.
1.1.3 PRUEBA INICIAL

1) ¿Con qué otro nombre se le conoce a la arquitectura del software? Se le conoce como
arquitectura lógica.
2) ¿Qué es un patrón de diseño de software? Es una técnica que facilitan la identificación y

resolución de posibles problemas que pueden presentarse en el desarrollo del producto
software.
3) ¿Qué se requiere para un mayor control de los diversos patrones de software? Se

requiere que los desarrolladores o profesionales en el campo del software, al identificar
estos en su campo de acción, documenten la posible solución, con el fin de tener a la mano
diversas alternativas de resolución a futuras problemáticas similares encontradas en
trabajos futuros.
4) ¿Qué ventajas conoce de la metodología ágil?
➢ Respuesta a cambios de requisitos.
➢ Entrega continua de software funcional.
➢ Trabajo entre el cliente y el desarrollador.
1.2 TEMA 1 ARQUITECTURA DE DISEÑO DE SOFTWARE

➢ Video: ¿Qué es ARQUITECTURA DE SOFTWARE?
➢ ” Ver Video”: https://www.youtube.com/watch?v=7ukajubprdE
sfs
9
La arquitectura de software, también conocida como arquitectura lógica, es el diseño estimado
de más alto nivel de la ordenación o estructura de un sistema; incluye sus diversos componentes,
sus propiedades externas y las relaciones entre estos; soportado en la obtención de requisitos
de atributos de calidad como cimiento orientador para el diseño de la arquitectura.
Importancia:
➢ Facilita la comunicación entre las partes interesadas en el desarrollo del software.
➢ Permite destacar las decisiones iníciales del diseño del sistema.
➢ Facilita la construcción de un modelo entendible que deja observar la forma como trabajan
los componentes del sistema.
Un buen diseño arquitectónico requiere las siguientes directrices:
➢ Diseños estructurales que se pueda implementar de forma creciente.
➢ Diseño modular.
➢ Diversas representaciones de datos.
➢ Estructuras de datos apropiadas.
➢ Reducción de la complejidad de las conexiones.
➢ Debe hacer referencia a la información recolectada en la parte de análisis.
➢ Claridad en lo que se quiere entregar al usuario final.
Existen métodos que proporcionan un horizonte claro de cómo se debe realizar una arquitectura
basada en las necesidades de atributos de calidad; esto involucra la estructura de los
componentes del programa o módulos, haciendo énfasis en la forma como estos interactúan para
alcanzar unos objetivos concretos, como los modelos del marco de trabajo que tienen una
arquitectura específica y orientadora para que el desarrollador o profesional en software logre
alcanzar los objetivos planteados.
sfs
10
1.2.1 EJERCICIO DE APRENDIZAJE
1) ¿Agile es una metodología o frameworks? Agile no es una metodología o frameworks,
son principios establecidos que se pueden adaptar de acuerdo a las necesidades de las
empresas dedicadas a la construcción de productos software.
2) ¿Qué es Scrum? es un frameworks de Agile y se utiliza para agilizar el proceso del

desarrollo de proyectos, productos y aplicaciones con el objetivo de obtener resultados
viables y satisfactorios para el mercado.
3) ¿Cómo se debe diseñar una interfaz gráfica? se debe diseñarse utilizando imágenes y
objetos gráficos, a través de los cuales se visualizará la información y se realizarán las
diversas acciones que ejecute el usuario; la interfaz debe ser entendibles y de fácil uso
para el usuario final.
1.2.2 TALLER DE ENTRENAMIENTO

Apreciado estudiante, a continuación, se propone un taller para reforzar los conocimientos
adquiridos.
Construya un mapa mental, haciendo uso de cualquier software online acerca de los siguientes
temas:
a) Diseño de software.
b) Calidad de software.
c) Evaluación de la calidad del diseño de software.
TIPS
Un buen diseño asegura el éxito de la construcción y viabilidad del
producto
sfs
11
1.3 TEMA 2 PATRONES DE DISEÑO DE SOFTWARE
➢ Video: ¿Qué son los Patrones de Diseño de Software?
➢ ” Ver Video”: https://www.youtube.com/watch?v=bx5WqFEndoo
Los problemas identificados en el desarrollo de un producto, bien sea tangible o intangible, deben
entenderse con claridad para aplicar un determinado patrón que lleve al estudio de posibles
soluciones que den resultados positivos de acuerdo a la necesidad requerida. Este patrón debe
tener diversas características enfocadas a la efectividad de las problemáticas analizadas, debido
a que su estructura describe el núcleo de la solución del problema.
Cada profesional según su campo de acción utiliza variados patrones específicos que le sirven
como base para implementar nuevas ideas, trabajos o propuestas de proyectos; por supuesto,
teniendo presente la gran variabilidad que se tiene entre uno y el otro.
Un patrón de diseño de software es una técnica que facilitan la identificación y resolución de

posibles problemas que pueden presentarse en el desarrollo del producto software. La
integración de un patrón está compuesta por clases y objetos relacionados entre sí, facilitando su
comunicación interna, a través de lo cual, se busca resolver el problema para la obtención de un
producto intangible de calidad.
Elementos de un patrón.
➢ Nombre: Hace énfasis específicamente al problema de diseño
➢ Problema: Entrega una guía o pautas que indican cuando se debe aplicar el patrón.
➢ Solución: Facilita la descripción de los elementos que integran el diseño, sus relaciones,
responsabilidades y colaboración.
El patrón permite recordar cuales son las posibles soluciones que se han tenido presente al
momento de resolver problemáticas identificadas en ocasiones anteriores, las cuales se pueden
aplicar como buenas prácticas a nuevos problemas que tengan similitud a los anteriores. Es una
solución probada a un problema recurrente.
Para un mayor control de los diversos patrones, se requiere que los desarrolladores o
profesionales en el campo del software, al identificar estos en su campo de acción, documenten
sfs
12
la posible solución, con el fin de tener a la mano diversas alternativas de resolución a futuras
problemáticas similares encontradas en trabajos futuros.

Apreciado estudiante, usted debe analizar las siguientes preguntas y escoger una única respuesta
correcta.
1) ¿Un patrón de diseño de software es?
a) Una Metodología Ágil que facilitan la identificación y resolución de posibles problemas

que pueden presentarse en el desarrollo del producto software.
b) Una técnica que facilitan la identificación y resolución de posibles problemas que

pueden presentarse en el desarrollo del producto software.
c) Una documentación de creatividad que facilitan la identificación y resolución de

posibles problemas que pueden presentarse en el desarrollo del producto software.
Respuesta B
2) ¿Los elementos de un patrón son?
a) Documentación, información, ciencia y arte.
b) Información, tecnología, solución.
c) Nombre, problema, solución.
Respuesta C
3) ¿Qué se requiere para un mayor control de los patrones?
a) Estudiantes y profesores.
b) Usuario final y desarrollador.
c) Desarrolladores o profesionales en software.
Respuesta C
sfs
13
Construya una infografía que permita relacionar una síntesis de los siguientes temas:
a) Características de los patrones de diseño de software.
b) Ventajas de los patrones de diseño de software.
c) Sociedad de la información.
TIPS
El patrón permite recordar cuales son las posibles soluciones que se han
tenido presente al momento de resolver problemáticas identificadas
en ocasiones anteriores
1.1 TEMA 3 DISEÑO DE SOFTWARE

➢ Video: Diseño en software
➢ ” Ver Video”: https://www.youtube.com/watch?v=JIY-8OGQxOs
El diseño de software es el proceso por medio del cual se define la arquitectura, componentes,
interfaces y especificaciones de diversas características del sistema. El diseño debe implementar
todos los requisitos contenidos en el modelo de análisis; debe hacer las veces de una guía
legible que oriente a los profesionales en software al momento de generar código, realizar
pruebas y dar soporte al sistema; esta guía debe proporcionar una imagen completa del software
dando direcciones a los dominios de datos, funcionales y de comportamiento desde una
perspectiva de implementación.
Un buen diseño debe:
➢ Ser rastreable hasta el modelo de análisis: El modelo enuncia el dominio de la

información del problema, las funciones que el usuario puede visualizar, el
comportamiento del sistema y el conjunto de clases que empaquetan los objetos.
sfs
14
➢ Considerar la arquitectura del sistema que se va a construir: Es el esqueleto del software
que se va a construir afectando las interfaces, la estructura de datos, el flujo, el control
del programa, las pruebas y el mantenimiento.
➢ Estructurar muy bien los datos para que ayuden a simplificar el flujo del programa, el
diseño y la implementación de todas las partes del software.
➢ Considerar la interfaz: Las interfaces (internas y externas) deben diseñarse con cuidado:
La forma como se manejan los datos en un sistema reflejará la eficiencia de su proceso,
evita errores y simplifica el diseño. Una interfaz bien diseñada ayuda a la realización de
pruebas y validar sus funciones, además, debe ajustarse a las necesidades del usuario
final. Lo más importante del diseño de la interfaz es la facilidad de uso para satisfacción
del usuario no importando como esté estructurado internamente evitando la percepción
que los usuarios le pueden dar por su simplicidad en donde dicen que está “mal” hecho.
➢ A nivel de componentes: Ser independiente del modo funcional. La funcionalidad que se

entrega debe centrarse en una función únicamente y terminada en su totalidad. Los
componentes deben estar apareados entre sí en forma mínima y vinculada con el
ambiente externo.
➢ Proyectar una presentación entendible a los ojos del usuario final: Si el diseño no es fácil
de entender, es difícil que sirva como medio efectivo de comunicación, la idea principal es
comunicar información a los que generan el código, a los que probarán el software o a
quienes continúen con el software en dl futuro.
➢ Desarrollarse de manera iterativa: En cada iteración el diseñador debe buscar la mayor

simplicidad. El diseño es algo iterativo en donde los primeros pasos sirven para refinar y
corregir errores pero que luego en los nuevos avances se busaca la simplicidad del diseño
procurando mostrar la mejor calidad posible que se da en el desarrollo de aplicaciones.
Dentro de la práctica del diseño, es recomendable destacar la gran responsabilidad que se

tiene para que el software o la solución puedan lograr alcanzar lo esperado por el cliente,
teniendo claridad que este comprende en el diseño, el ingreso y salida de información.
sfs
15
1.1.1 DISEÑO DE METODOLOGÍAS ÁGILES UTILIZANDO FRAMEWORKS
De acuerdo a Jaramillo (2016, Pp. 24 - 25):
La historia de las metodologías ágiles y su apreciación como tal en la comunidad de la

ingeniería del software tiene sus inicios en la creación de una de las metodologías utilizada
como arquetipo: XP – eXtreme Programing, dada la poca calidad del sistema que se estaba
desarrollando.
Es así como que este tipo de metodologías fueron inicialmente llamadas “metodologías
livianas”, aunque no contaban con una aprobación pues se le consideraba por muchos
desarrolladores como meramente intuitiva. Luego, con el pasar de los años, en febrero de
2001, tras una reunión celebrada en Utah-EEUU, nace formalmente el término “ágil”
aplicado al desarrollo de software.
DENTRO DE LAS PRINCIPALES CARACTERÍSTICAS DE ESTE TIPO DE METODOLOGÍAS TENEMOS:
➢ Basadas en heurísticas provenientes de prácticas de producción de código.
➢ Especialmente preparadas para cambios durante el proyecto.
➢ Impuestas internamente ( por el equipo)
➢ Proceso menos controlado, con pocos principios.
➢ No existe contrato tradicional o al menos es bastante flexible.
➢ El cliente es parte del equipo de desarrollo.
➢ Grupos pequeños trabajando en el mismo sitio.
➢ Pocos artefactos.
➢ Pocos roles.
➢ Menos énfasis en la arquitectura del software.
VENTAJAS DE ESTAS METODOLOGÍAS:
➢ Capacidad de respuesta a cambios de requisitos a lo largo del desarrollo.

sfs
16
➢ Entrega continua y en plazos breves de software funcional.
➢ Trabajo conjunto entre el cliente y el equipo de desarrollo.
➢ Importancia de la simplicidad, eliminado el trabajo innecesario.
➢ Atención continua a la excelencia técnica y al buen diseño.
➢ Mejora continua de los procesos y el equipo de desarrollo.
FRAMEWORKS AGILES:
Agile no es una metodología o frameworks, son principios establecidos que se pueden

adaptar de acuerdo a las necesidades de las empresas dedicadas a la construcción de
productos software.
Un frameworks es un esquema que tiene como funcionalidad la estructuración del código, de

forma recursiva y práctica; lo cual les ahorra tiempo y esfuerzos a los desarrolladores o
profesionales en software.
Uno de los frameworks más destacados de Agile, es Scrum. Según lo afirman Fuertes y Sepúlveda
(2016):
La herramienta Scrum se utiliza para agilizar el proceso del desarrollo de proyectos,

productos y aplicaciones con el objetivo de obtener resultados viables y satisfactorios para
el mercado. De acuerdo con Avella y Vázquez [8], el desplazamiento empresarial hacia un
paradigma basado en la agilidad tiene sus raíces en el desarrollo de una nueva era de los
negocios, que se cimenta en el cambio como principal característica y que revela la
existencia de nuevas tendencias en la gestión y organización de las empresas. Esto es lo
que abre las puertas a la fabricación ágil de productos que tiene como resultado la
propuesta de modelos productivos, soportados en las diferentes tendencias
organizacionales para garantizar la competitividad (p. 47).
sfs
17
1.1.2 HERRAMIENTAS DE DESARROLLO DE INTERFAZ
Una interfaz gráfica se debe diseñarse utilizando imágenes y objetos gráficos, a través de los
cuales se visualizará la información y se realizarán las diversas acciones que ejecute el usuario; la
interfaz debe ser entendibles y de fácil uso para el usuario final.
EQUIPO DISEÑO DE INTERFAZ

USUARIO FINAL
DESARROLLADOR SOFTWARE GRÁFICA
ALGUNAS CARACTERÍSTICAS QUE DEBE TENER UNA BUENA INTERFAZ
CLARIDAD COHERENCIA LEGIBILIDAD
INTERACTIVIDAD
EFICIENCIA FLEXIBILIDAD FÁCIL USO
Figura 2. Características de una buena interfaz.

De acuerdo a Durán (2018), en cuanto al manejo de color, las siguientes herramientas facilitan el
diseño de una interfaz:
MATERIAL DESINGN COLOR ADOBE COLOR CC PALETTON
UPLABS
MATERIAL PALETTE FRONT AWESOME THE NOUN PROJECT
Figura 3. Herramientas de interfaz.

sfs
18
Las siguientes herramientas son recomendadas en el diseño de la interfaz:
MARVEL BOSQUEJO AXURE
INVISION
PROTO.IO MOCKFLOW FRAMER X
Figura 4. Herramientas de interfaz.

El diseño de la interfaz define la forma, función, utilidad, lineamientos visuales, entre otros
aspectos, que caracterizarán y materializará la comunicación entre el sistema y el usuario final.
De acuerdo a Patiño (2011. Pp. 50 – 52), las reglas del diseño de la interfaz de usuario, son las
siguientes:
➢ DAR CONTROL AL USUARIO
Se definen varios principios de diseño que permiten al usuario mantener el control: Definir
los modos de interacción de forma que el usuario no realice acciones innecesarias o
indeseables, proporcionar una interacción flexible, incluir las opciones de interrumpir y
deshacer la interacción del usuario, depurar la interacción a medida que aumentan los grados
de destreza y permitir que se personalice la interacción, oculte al usuario ocasional los
elementos técnicos internos, diseñar interacción directa con los objetos que aparecen en la
pantalla.
➢ REDUCIR LA CARGA EN LA MEMORIA DEL USUARIO
Los principios de diseño que logran que una interfaz reduzca la carga de memoria que recae
en el usuario: reducir la demanda de memoria a corto plazo, definir valores por defecto que
tengan significado, definir accesos directos intuitivos, el formato visual de la interfaz debe
basarse en una metáfora tomada de la realidad, desglosar la información de manera
progresiva.
➢ LOGRAR QUE LA INTERFAZ SEA CONSISTENTE

sfs
19
Los principios de diseño que ayudan a construir una interfaz consistente: Permitir que el
usuario incluya la tarea actual en un contexto que tenga algún significado; mantener la
consistencia en toda una familia de aplicaciones; si modelos interactivos anteriores han
generado expectativas en el usuario, no hacer cambios a menos que haya razones
inexcusables.
En cuanto al análisis y desarrollo de la interfaz de usuario, Patiño expresa:
Cuando se analiza y se diseña una interfaz de usuario entran en juego cuatro modelos
diferentes. Un ingeniero del software establece un modelo del usuario; el ingeniero del
software crea un modelo de diseño; el usuario final desarrolla una imagen mental que suele
denominarse modelo mental del usuario o percepción del sistema, y quienes implementan el
sistema crean un modelo de la implementación.
EL PROCESO:
➢ Análisis y modelado de usuarios, tareas y entornos.
➢ Diseño de la interfaz.
➢ Construcción (implementación) de la interfaz.
➢ Validación de la interfaz.
➢ PASOS DEL DISEÑO DE INTERFAZ:
• Con base en la información desarrollada durante el análisis de la información, definir los
• objetos y las acciones de la interfaz (operaciones).
• Definir eventos (acciones del usuario) que cambiarán el estado de la interfaz.
• Representar cada estado de la interfaz tal como lo verá el usuario final.
• Indicar cómo interpreta el usuario el estado del sistema a partir de la interfaz

proporcionada mediante la interfaz.
“Utilizar solo las funciones necesarias y procurar que el diseño sea intuitivo, se explique
por sí mismo, y que sus elementos concurran de manera lógica, para ayudar al usuario en
la realización de sus tareas es lo que hace una herramienta exitosa” (Ramírez, 2017).
sfs
20
1.1.3 EVALUACIÓN Y ANÁLISIS DE LA CALIDAD DEL DISEÑO
Un buen diseño asegura el éxito de la construcción y viabilidad del producto, ya que esto
proporciona la seguridad de que los demás procesos relacionados funcionarán adecuadamente y
que se direccionan a la necesidad requerida por el cliente.
Por consiguiente:
El diseño debe sujetarse a los requisitos del cliente, lo cual específicamente se documenta en
el modelado de análisis.
Debe proporcionar una imagen completa del software, dando direcciones a los dominios de
datos, funcionales y de comportamiento desde una perspectiva de implementación.
Figura 5. Modelado de diseño.

Fuente: Elaboración propia (2020). Software Edraw.
sfs
21
correcta.
1) ¿Cómo debe ser un buen diseño?
a) Rastreable hasta el modelo de análisis.
b) Individual y secuencial.
c) Instruccional y heurístico.
Respuesta A
2) ¿Cuál de los siguientes elementos pertenece a una de las características de la

metodología ágil?
a) Capacidad de respuesta a cambios inesperados.
b) El cliente es parte del equipo de desarrollo.
c) Importancia de la simplicidad.
Respuesta B
3) ¿Qué otro nombre recibe las metodologías ágiles?
a) Metodologías gruesas.
b) Metodologías horizontales.
c) Metodologías livianas.
Respuesta C

Apreciado estudiante, complete los siguientes conceptos:
sfs
22
a) Características que debe tener una buena interfaz: ______________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
b) Herramientas recomendadas en el diseño de una buena interfaz:

________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
c) Partes del modelado de diseño: _______________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
TIPS
El diseño debe sujetarse a los requisitos del cliente

23
2 UNIDAD 2 GESTIÓN DE CONFIGURACIÓN DE
SOFTWARE.
Figura 6. Gestión de configuración de software.


Comprender la importancia de la gestión de configuración de proyectos de software, sujeta al
control de integración de cambios, como bases sólidas en el aseguramiento de la calidad y
consistencia del aplicativo; manteniendo el resguardo, documentación y protección de la
información como cimiento de la confidencialidad, disponibilidad e integridad de los datos.
24
2.1.2 OBJETIVOS ESPECIFICOS
➢ Realizar un análisis de requisitos que proporcione el más adecuado direccionamiento en
la aplicabilidad del desarrollo del producto, apuntando a la mejora continua del mismo.
➢ Identificar como el control de versiones, la gestión de incidencias, gestión de

documentación y el sistema de gestión de proyectos, proporcionan ventajas competitivas
evidenciadas en la calidad del producto o aplicativo.

1) ¿Qué aporta la gestión de cambios?
Al crecimiento de la empresa, debido a que fomenta su estabilidad y posicionamiento.
2) ¿Qué combina el control de cambios?
Los procedimientos humanos y las herramientas automáticas.
3) ¿A qué hace referencia el control de versiones?
A la gestión de los cambios significativos que se realizan en uno o más objetos del
software. Su estado actual define su última edición.
2.2 TEMA 1 GESTIÓN E IDENTIFICACIÓN DE OBJETOS EN LA

CONFIGURACIÓN DEL SISTEMA
➢ Video: Gestión de la configuración del software
➢ ” Ver Video”: https://www.youtube.com/watch?v=7S4k7hsfwbU
Se aplica para controlar los cambios que sean requeridos durante el ciclo de vida del producto
software. Para lo cual, se requiere:
➢ Identificación de los cambios.
➢ Control de los cambios.

25
➢ Control de versiones.
➢ Realizar proceso de auditoría para verificación y control de los cambios.
➢ Documentar los cambios.
A continuación, se muestra las relaciones de la gestión de la configuración de software y los

elementos característicos del proceso de cambios.
Figura 7. GSC.
Fuente: Metaute (2016).
26
Gestionar los cambios durante el proceso del ciclo de vida del desarrollo del software, requiere
del análisis de los elementos que pueden requerir cambio; como los datos, los programas (fuentes
y ejecutables) y los manuales necesarios, entre estos: el técnico, de usuario y de implementación.
La gestión de cambios aporta al crecimiento de la empresa, debido a que fomenta su estabilidad

y posicionamiento; pero esto exige identificar plenamente la necesidad del cambio, además de
orientarlo para facilitar la toma de decisiones sobre el mismo.
Por consiguiente, se requiere definir claramente el objeto a cambiar, justificando específicamente

el cambio al cual se someterá el objeto y analizar el impacto que el mismo tendrá en el software.
De acuerdo a Metaute (2016) un cambio lo puede generar:
➢ Nuevos negocios o condiciones comerciales que dictan los cambios en los requisitos del
producto o en las normas comerciales.
➢ Nuevas necesidades del cliente que requieren la modificación de los datos producidos por
el sistema. Reorganización y crecimiento o reducción del negocio que provoca cambios en
las prioridades del proyecto o en la estructura del equipo de Ingeniería de Software.
➢ Restricciones de presupuesto o de planificación que provocan una redefinición del sistema

o producto.
El control de cambios combina los procedimientos humanos y las herramientas automáticas.

A nivel de Ingeniería de Software es preocupante el cambio, ya que una diminuta perturbación
en el código puede crear un gran fallo en el producto, pero también puede reparar un gran
fallo o habilitar excelentes capacidades nuevas. El cambio incontrolado lleva rápidamente al
caos.
2.2.1 PROCESO DE CONTROL DE CAMBIOS

Para controlar el cambio, de acuerdo a lo que afirma Metaute, se recomiendan los siguientes
pasos:
➢ Recibir la solicitud o petición de cambio por parte del cliente.
➢ Evaluar la Petición de Cambio (Esfuerzo técnico, efectos secundarios, impacto global sobre
otras funciones del sistema y sobre otros objetos de configuración).
27
➢ Informe de cambios a la Autoridad de Control de Cambios (ACC) quien toma la decisión,
evaluando impacto del cambio en software, hardware, rendimiento, calidad, fiabilidad
entre otras)
➢ Orden de Cambio de Ingeniería (OCI) (cambio a realizar, restricciones que deben respetar,
criterios de revisión y de Auditoría).
Analícese la siguiente propuesta de flujo secuencial de la gestión de cambios.
Figura 8. Gestión de cambio.

Fuente: Metaute (2016).
2.2.2 CONTROL DE VERSIONES

Hace referencia a la gestión de los cambios significativos que se realizan en uno o más objetos del
software. Su estado actual define su última edición.
Al llevar un control de cada una de las versiones en que se encuentra el desarrollo del producto,
en ocasiones trae muchas complicaciones, debido a que se realizan diversas copias del mismo
28
proyecto, para lo cual se recomienda almacenar las copias en diversos dispositivos, debido a que,
si se guarda en un solo dispositivo y este presenta fallas, se pierde el esfuerzo realizado.
También es necesario llevar un control del personal capacitado y destinado para realizar las
copias, ya que, si muchos colaboradores realizan diversas copias haciendo énfasis a la misma
versión, se puede presentar confusión a la hora de identificar la versión actual.
Según lo expresa Metaute (2016):
El control de versiones combina procedimientos y herramientas para gestionar las

versiones de los objetos con configuraciones alternativas asociando atributos particulares
a cada versión, creados durante el proceso del software. Es así que, para construir la
variante, de una determinada versión de un programa, a cada componente (objetos
compuestos u objetos básicos), se le asigna un registro que define si se ha de utilizar el
componente cuando se va a construir una determinada versión. Es importante tener
presente que, si el cambio solicitado por el cliente es de dimensiones mayores, se deberá
ser claro con él, explicándole detalladamente sobre los efectos que dicha solicitud podría
generar en el resto de los componentes del software, donde en muchas ocasiones sería
mejor esperar una nueva versión, donde el cliente tendría beneficios tanto económicos,
como de calidad en el producto versionado (p.65).
2.2.3 AUDITORÍA DE LA CONFIGURACIÓN E INFORME DE ESTADOS

El proceso de auditoría facilita la verificación y validación de la funcionalidad del producto
software; motivo que lleva a una gestión de cambio minuciosa, que exige la documentación de
los cambios aceptados, los cuales deben ser evidenciados después de un análisis detallado, con
el fin de identificar sus restricciones de acuerdo a su reporte de versión.
Para auditar los cambios realizados, de acuerdo a Metaute (2016), se debe:
➢ Realizar Revisiones Técnicas Formales: La cual se centra en la corrección técnica del

elemento que ha sido modificado, la evaluación del ECS, para determinar consistencia con
otros ECS, las omisiones o los posibles efectos secundarios.
➢ Implementar auditorías de configuración de software: Además de lo anterior se plantean

preguntas que permitan verificar que el proceso efectivamente se realizó y que además
de ello se obtuvo buenos resultados.
29
Las preguntas podrían ser similares a las siguientes:
• ¿Se ha hecho el cambio específico en la OCI?
• ¿Se ha incorporado modificaciones adicionales?
• ¿Se ha llevado a cabo una revisión técnica formal para evaluar la corrección técnica?
• ¿Se ha seguido el proceso o línea base establecida para la gestión de cambio?
• ¿Se ha aplicado adecuadamente los estándares de ingeniería de Software?
• ¿Se ha resaltado los cambios en el ECS?
• ¿Se ha especificado la fecha de cambio y el autor?
• ¿Reflejan los cambios los atributos del objeto de configuración?
• ¿Se ha seguido procedimientos de GCS para señalar el cambio, registrarlo y divulgarlo?
• ¿Se ha actualizado adecuadamente todos los ECS relacionados?
Cómo último paso de la auditoría, se debe informar al personal responsable de los

procesos de gestión el dictamen o informe de resultados obtenido por los cambios
realizados.
Este informe debe contener los siguientes interrogantes:
➢ ¿Qué pasó?
➢ ¿Quién lo hizo?
➢ ¿Cuándo pasó?
➢ ¿Qué más se vio afectado?
Para registrar dicha evidencia, se recomienda hacer uso de una base de datos interactiva,
donde se registre cada vez que: Se asigna un ECS (Elemento de Configuración de Software)
La ACC (Autoridad de Control de Cambios) aprueba un cambio. Se expide una OCI (Orden
de Cambio de Ingeniería). Se lleva a cabo una auditoria de configuración. Buscan con ello
que dicha GCS, se encuentre lo suficientemente documentada, para ser utilizada en el
momento que se requiera.
30
correcta.
1) ¿Qué facilita el proceso de auditoría en la configuración e informe de estados?
a) Los datos seleccionados y ordenados con un propósito específico.
b) Las probabilidades de gestionar el cambio.
c) La verificación y validación de la funcionalidad del producto.
d) La gestión de datos.
Respuesta C
2) ¿Cuál de los siguientes conceptos define lo que es el control de versiones?
a) Es la metodología para satisfacer una necesidad que entrega el cliente.
b) Es una herramienta fundamental para acceder a la información que nos brinda la era
de la tecnología.
c) Combina procedimientos y herramientas para gestionar las versiones de los objetos

con configuraciones alternativas asociando atributos particulares a cada versión,
creados durante el proceso del software.
Respuesta C
3) ¿Qué requieren definir la gestión de cambio?
a) El proyecto.
b) El objeto a cambiar.
c) El proceso.
d) El equipo de desarrollo.
Respuesta B
31
Apreciado estudiante, Conteste falso o verdadero, de acuerdo a sus conocimientos.
a) La gestión de la configuración del software se aplica para realizar el proceso de análisis de

requisitos. ( )
b) La gestión de cambios exige identificar plenamente la necesidad del cambio. ( )
c) La gestión de cambio facilita al equipo desarrollador la toma de decisiones. ( )
d) Es necesario llevar un control del personal capacitado y destinado para realizar las copias
de las diversas versiones que alimentan los cambios. ( )
e) El informe de auditoría para reportar los cambios debe contener los siguientes
interrogantes: ¿Qué pasó?, ¿Quién lo hizo?, ¿Cuándo pasó? Y ¿Qué más se vio afectado?
( )
TIPS
Al terminar la auditoría, se debe informar al personal responsable de
los procesos de gestión el dictamen o informe de resultados obtenido
por los cambios realizados.
2.3 TEMA 2 HERRAMIENTAS PARA LA GESTIÓN DE LA

CONFIGURACIÓN DE SOFTWARE
➢ Video: Calidad del Software - Unidad 6: Gestión de la Configuración del SW
➢ ” Ver Video”: https://www.youtube.com/watch?v=wDvpj2KsDfk
Existen diversas herramientas destinadas a la gestión de la configuración del software, entre las
cuales se destaca las de gestión de la configuración de nube para múltiples plataformas.
32
La computación en la nube facilita el rastreo y control de cambios, así como de los recursos
necesarios que apoyen la prestación del servicio.
Linthicum (2017) afirma:
Las empresas se enfrentan a una importante elección: utilizar los servicios nativos de
gestión de configuración en una plataforma de nube pública, o emplear una herramienta
de terceros, como Ansible y CFengine. La elección no es fácil. Las herramientas de gestión
de configuración de nube nativas hacen que una empresa se vuelva más dependiente de
su proveedor de nube pública, aumentando el riesgo de quedarse con un solo proveedor.
Por ejemplo, cuando una empresa utiliza dos o más nubes públicas, como Amazon Web
Services (AWS) y Google, la herramienta de configuración nativa no funcionará bien en
ambas plataformas.
Entre las opciones de gestión de configuración; a continuación, se mencionan algunas

herramientas de configuración de nube de terceros y proveedores.
TERCEROS:
➢ Chef.
➢ Puppet.
➢ Terraform.
➢ SmartFrog.
➢ Ansible.
➢ Nuevas de proveedor:
➢ AWS Config.
➢ Microsoft System Center Configuration Manager.
➢ Autoescalador de Google Cloud Platform.
➢ Grupos de instancias de Google Cloud Platform y grupos de instancias administradas.

33
La gestión de la configuración en la nube es multiplataforma, lo cual define su eficacia.
Dentro de las herramientas de gestión de la configuración, se puede relacionar las direccionadas

a tecnología, como: pruebas software SAP, Oracle Siebel Testing, eCommerce, pruebas en
dispositivos móviles.
2.3.1 EJERCICIOS DE APRENDIZAJES

Dentro de las herramientas de gestión de la configuración ¿cuáles se pueden relacionar?
➢ Pruebas software SAP.
➢ Oracle Siebel Testing.
➢ ECommerce.
➢ Pruebas en dispositivos móviles.

Responda y justifique su respuesta:
• ¿Es posible valorar la calidad del software si el cliente cambia con frecuencia lo que se
supone debe hacer?
• La calidad y la fiabilidad son conceptos relacionados, pero fundamentalmente diferentes

en varias formas. Cuáles son estas diferencias.
• ¿Puede un programa ser correcto y aun así no ser fiable? Explíquese.
• ¿Puede un programa ser correcto y aun así no mostrar buena calidad? Explíquese.
• ¿Un gestor técnico imperativo puede ser problema para un equipo de software?
• Cuál es el factor principal que influye en la buena organización y respuesta de un equipo

de software.
34
• ¿Cuál es el activo más importante de una organización?
• ¿Cuál es el elemento principal de una organización?
• Cree usted que el dinero puede ser considerado como la sangre de la empresa. Si_____,
No______, ¿por qué?
TIPS
La gestión de configuración de nubes es para múltiples plataformas
35
3 UNIDAD 3 GESTIÓN DE PROYECTOS DE SOFTWARE
ASOCIADO A LAS MÉTRICAS
Figura 9. Gestión de proyectos de software.

Fuente: Elaboración propia (2020)

Analizar como una medida proporciona una indicación cuantitativa de la extensión, cantidad y
capacidad o tamaño de los atributos determinados de un producto, con el fin de obtener
indicadores que garanticen la calidad del aplicativo o software.
3.1.2 OBJETIVOS ESPECIFICOS

➢ Comprender los principios básicos de la medición.
➢ Indagar ¿cuánto tiempo tomará construir el producto, cuánto esfuerzo requerirá y cuánto
personal estará involucrado?
36
➢ Entender el proceso de validación de las métricas.
➢ Identificar los diversos indicadores útiles para el equipo del proyecto.
1) ¿De qué forma se especifica un riesgo para el campo del software? como la posibilidad
de que ocurra un evento negativo que perjudique el avance del proyecto.
2) ¿Qué elementos podría tener un plan de riesgo?
➢ Metodología.
➢ Roles y responsabilidades.
➢ Presupuesto.
➢ Tiempo.
➢ Categorías.
➢ Definiciones de probabilidad e impacto.
➢ Niveles de tolerancia.
➢ Formatos de reportes.
➢ Seguimiento.
3) ¿De qué forma se clasifica el análisis de los riesgos?
➢ Cualitativo.
➢ Cuantitativo.
37
3.2 TEMA 1 PLANEACIÓN Y MANEJO DE RIESGOS DE
PROYECTOS DE SOFTWARE
Un riesgo para el campo del software, se especifica como la posibilidad de que ocurra un evento
negativo que perjudique el avance del proyecto.
De acuerdo a Metaute (2016):
La planeación de la gestión de riesgo es el proceso por el cual se define como realizar las
actividades de gestión de riesgos para un proyecto (en éste caso de software), asegurando
el nivel, el tipo y la visibilidad del riesgo, teniendo en cuenta los recursos y el tiempo
suficiente para las actividades de gestión de riesgos y para establecer una base adecuada
para la evaluación. Éste proceso se debe iniciar al concebirse el proyecto, antes de ponerlo
en ejecución.
Un plan de riesgo podría tener los siguientes elementos:
➢ Metodología: Define como se realizará el proceso de gestión de riesgos para el proyecto.
➢ Roles y responsabilidades: Funciones que representa cada integrante del equipo de

trabajo.
➢ Presupuesto: Cuanto cuesta la realización del proceso de gestión de riesgos.
➢ Tiempo: En cuantas horas se debe realizar el proceso de gestión de riesgos.
➢ Categorías: Lista posibles causas de riesgos que pueden afectar el proyecto.
➢ Definiciones de probabilidad e impacto: Escalas definidas para evaluar la posibilidad de

ocurrencia y el efecto sobre los objetivos del proyecto.
➢ Niveles de tolerancia: Miden el nivel de aceptación de los riesgos por parte de los
interesados.
➢ Formatos de reportes: Se define los elementos que se tendrán en cuenta para la

elaboración de los reportes de riesgos.
➢ Seguimiento: Se definen los procesos de auditoría, monitoreo y retroalimentación.

Identificación del Riesgo: Se determinan los riesgos que pueden afectar positiva o
negativamente al proyecto, sacando un listado de amenazas y oportunidades para el
proyecto
38
El proceso para identificar los riesgos, podría tener los siguientes pasos:
➢ Determinar el equipo de trabajo para la identificación de los riesgos.
➢ Recolectar información histórica de proyectos similares.
➢ Sacar un listado de los riesgos.
➢ Documentar todos los riesgos identificados.
➢ Recolectar información adicional que ayuden completar la información sobre el riesgo.
En cuanto al análisis cualitativo y cuantitativo de los riesgos, esta autora expresa:
Cualitativo: Es el proceso que consiste en priorizar los riesgos identificados, determinando la

posibilidad de ocurrencia y el impacto sobre los objetivos del proyecto. Éste análisis es subjetivo
y su certeza depende muchas veces de la experiencia del personal en asuntos de riesgos.
Cuantitativo: Proceso que consiste en analizar numéricamente el efecto de los riesgos

identificados sobre los objetivos del proyecto. El análisis cuantitativo, no siempre es requerido en
el proceso de gestión de riesgos.
La forma como se analizan los riesgos, tanto de forma cuantitativa como cualitativa, conduce a la
perfección de la Calidad del producto.
Planeación de Respuestas: Consiste en determinar las acciones de respuesta efectiva que son
apropiadas para minimizar o eliminar el riesgo. Pasos recomendados:
➢ Seleccionar la(s) estrategia(s) de respuesta al riesgo.
➢ Por cada acción registrar: fecha de inicio, fecha final, responsable de cada acción del
riesgo, estado del riesgo.
➢ Registrar el plan de contingencia y el responsable de ejecutarlo.
➢ Registrar el disparador de cada riesgo.
➢ Determinar las reservas de contingencia.
➢ Confirmar el responsable del riesgo.

39
➢ Comunicar los riesgos a los responsables de los riesgos.
➢ Comunicar las acciones a los responsables de las acciones de los riesgos.
➢ Comunicar a los interesados principales las actualizaciones al plan de dirección del

proyecto. Monitoreo y control de riesgos: se realiza seguimiento a los riesgos
identificados, se monitorean los riesgos, se identifican nuevos riesgos, y se evalúa la
efectividad del proceso de gestión de riesgos, informándolos y registrando las nuevas
lecciones aprendidas.
Figura 10. Riesgos en la construcción de un producto software.

Fuente: Elaboración propia (2021). Adaptado de Metaute (2016).
De acuerdo a Metaute (2016), a continuación, se presenta una lista de los riesgos antes
mencionados:
➢ RIESGOS DEL TAMAÑO DEL PRODUCTO:
• ¿Tamaño estimado del producto en LDC o FP?
• ¿Grado de seguridad en la estimación del tamaño?
• ¿Tamaño estimado del producto en número de programas, archivos y transacciones?
• ¿Porcentaje de desviación en el tamaño del producto respecto a la medida de productos

anteriores?
• ¿Tamaño de la base de datos creada o empleada por el producto?

40
• ¿Número de usuarios del producto?
• ¿Número de cambios previstos a los requisitos del producto? ¿Antes de la entrega?

¿Después de la entrega?
➢ RIESGOS DE IMPACTO EN EL NEGOCIO:
• ¿Efecto del producto en los ingresos de la compañía?
• ¿Viabilidad del producto para los gestores expertos?
• ¿Es razonable la fecha límite de entrega?
• ¿Número de clientes que usarán el producto y la consistencia de sus necesidades relativas

al producto?
• ¿Número de otros productos/sistemas con los que el producto debe tener inter-
operatividad?
• ¿Sofisticación del usuario final?
• ¿Cantidad y calidad de la documentación del producto que debe ser elaborada y

entregada al cliente?
• ¿Limitaciones gubernamentales en la construcción del producto?
• ¿Costos asociados por un retraso en la entrega?
• ¿Costos asociados con un producto defectuoso?
➢ RIESGOS RELACIONADOS CON EL CLIENTE:
• ¿Ha trabajado con el cliente anteriormente?
• ¿Tiene el cliente una idea formal de lo que se requiere?
• ¿Está dispuesto el cliente a establecer una comunicación fluida con el desarrollador?
• ¿Está dispuesto el cliente a participar en las revisiones?

41
• ¿Es sofisticado técnicamente el área del producto?
• ¿Está dispuesto el cliente a dejar a su personal hacer el trabajo?
• ¿Entiende el cliente el proceso del software?
➢ RIESGOS DEL PROCESO DE SOFTWARE:
• ¿Posee la empresa de desarrollo procesos estándar para el desarrollo del software?
• ¿El equipo de trabajo está dispuesto a usar procesos estandarizados para el desarrollo de
software?
• ¿El equipo de desarrollo cuenta con las suficientes competencias para realizar el trabajo?
• ¿Se ha proporcionado una copia de los estándares de Ingeniería de Software publicados a

cada desarrollador y gestor de software?
• ¿Se han desarrollado diseños de documentos y ejemplos para todas las entregas definidas
como parte del proceso del software?
• ¿Se llevan a cabo regularmente revisiones técnicas formales de las especificaciones de

requisitos, diseño y código?
• ¿Se llevan a cabo regularmente: revisiones técnicas de los procedimientos de prueba y de

los casos de prueba?
• ¿Se documentan todos los resultados de las revisiones técnicas, incluyendo los errores
encontrados y recursos empleados?
• ¿Existe algún mecanismo para asegurarse de que el trabajo realizado en un proyecto se

ajusta a los estándares de Ingeniería de Software?
• ¿Se emplea una gestión de configuración para mantener la consistencia entre los
requisitos del sistema/software, diseño, código y casos de prueba?
• ¿Hay algún mecanismo de control de cambios de los requisitos del cliente que impacten
en el software?
42
• ¿Está debidamente elaborado en contrato con el cliente en relación a funcionalidad del
producto, costos y tiempos de entrega?
• ¿Se sigue algún procedimiento para hacer un seguimiento y revisar el proceso de

construcción del software?
➢ ASPECTOS TÉCNICOS:
• ¿Se emplean técnicas de especificación de aplicaciones para ayudar en la comunicación

entre el cliente y el desarrollador?
• ¿Se emplean métodos específicos para el análisis del software?
• ¿Emplea un método específico para el diseño de datos y arquitectónico?
• ¿Está escrito su código en más de un 90 por ciento en lenguaje de alto nivel?
• ¿Se han definido y empleado reglas específicas para la documentación del código?
• ¿Emplea métodos específicos para el diseño de casos de prueba?
• ¿Se emplean herramientas de software para apoyar la planificación y el seguimiento de

las actividades?
• ¿Se emplean herramientas de software de gestión de configuración para controlar y seguir

los cambios a lo largo de todo el proceso del software?
• ¿Se emplean herramientas de software para apoyar los procesos de análisis y diseño del
software?
• ¿Se emplean herramientas para crear prototipos software?
• ¿Se emplean herramientas de software para dar soporte a los procesos de prueba?
• ¿Se emplean herramientas de software para soportar la producción y gestión de la

documentación?
• ¿Se han establecido métricas de calidad para todos los proyectos de software?
• ¿Se han establecido métricas de productividad para todos los proyectos de software?
43
➢ RIESGOS TECNOLÓGICOS:
• ¿Es nueva para su organización la tecnología a construir?
• ¿Demandan los requisitos del cliente la creación de nuevos algoritmos o tecnología de

entrada o salida?
• ¿El software interactúa con hardware nuevo o no probado?
• ¿Interactúa el software a construir con productos software suministrados por el vendedor

que no se hayan probado?
• ¿Interactúa el software a construir con un sistema de base de datos cuyo funcionamiento

y rendimiento no se han comprobado en esta área de aplicación?
• ¿Demandan los requisitos del producto una interfaz de usuario especial?
• ¿Demandan los requisitos del producto la creación de componentes de programación

distintos de; los que su organización haya desarrollado hasta ahora?
• ¿Demandan los requisitos el empleo de nuevos métodos de análisis, diseño o pruebas?
• ¿Demandan los requisitos el empleo de métodos de 'desarrollo del software no

convencionales, tales como los métodos formales, enfoques basados en IA y redes
neuronales?
• ¿Imponen excesivas restricciones de rendimiento los requisitos del producto?
• ¿No está seguro el cliente de que la funcionalidad pedida sea factible?
➢ RIESGOS EN EL ENTORNO DE DESARROLLO:
• ¿Se tiene disponible una herramienta de gestión del proceso del software?
• ¿Existen herramientas de análisis y diseño disponibles?
• ¿Proporcionan las herramientas de análisis y diseño, métodos apropiados para el

producto a construir?
44
• ¿Hay disponibles compiladores o generadores de código apropiados para el producto a
construir?
• ¿Hay disponibles herramientas de pruebas apropiadas para el producto a construir?
• ¿Se tiene disponibles herramientas de gestión de configuración software?
• ¿Hace uso el entorno de bases de datos o información almacenada?
• ¿Están todas las herramientas de software integradas entre sí?
• ¿Se ha formado a los miembros del equipo del proyecto en todas las herramientas?
• ¿Existen expertos disponibles para responder todas las preguntas que surjan sobre las
herramientas?
• ¿Es adecuada la ayuda en línea y la documentación de las herramientas?
• ¿Tiene el personal todos los conocimientos adecuados?
• ¿Se tiene suficiente personal?
• ¿Se ha asignado al personal para toda la duración del proyecto?
• ¿Dispone el personal de las expectativas correctas sobre el trabajo?
• ¿Ha recibido el personal la formación adecuada?

correcta.
1) ¿Qué es el análisis cualitativo de riesgos?
a) La técnica que consiste en priorizar los riesgos identificados, determinando la

posibilidad de ocurrencia y el impacto sobre los objetivos del proyecto.
45
b) b. La metodología que consiste en priorizar los riesgos identificados, determinando la
c) c. El proceso que consiste en priorizar los riesgos identificados, determinando la

Respuesta C
2) ¿Qué es el análisis cuantitativo de riesgos?
a) Tecnología de operación y tecnología de producto
b) Metodología que consiste en separar los riesgos para darle soluciones asertivas.
c) Proceso que consiste en analizar numéricamente el efecto de los riesgos identificados

sobre los objetivos del proyecto. El análisis cuantitativo, no siempre es requerido en el
proceso de gestión de riesgos. Tecnología limpia.
Respuesta C

Construya un mapa conceptual que permita relacionar los siguientes temas:
a) Monitoreo y control de riesgos.
b) Características de los riesgos tecnológicos.
c) Ventajas de identificar los riesgos de impacto de negocio.
d) Riesgos del tamaño del producto.
e) Riesgos del entorno de desarrollo del producto.

46
3.3 TEMA 2 MÉTODOS Y ESTÁNDARES DE MEDICIÓN
➢ Video: Calidad del software | MODELOS Y ESTÁNDARES DE UN PRODUCTO
➢ ” Ver Video”: https://www.youtube.com/watch?v=2lycHFiG-co
Figura 11. Estándares.

Fuente: Patiño (2011).
Un estándar se define como un conjunto de criterios bien documentados para el desarrollo

correcto de aplicaciones de calidad, cumpliendo con las normas y parámetros reglamentarios.
LOS QUE MIDEN EL LOS QUE CONTROLA Y SE

LOS QUE MIDEN EL PROCESO
PRODUCTO ENFOCAN EL TI
SPICE
ISO 9126 ITIL
CMMI
SQUARE COBIT
SCAMPI
Figura 12. Descripción de los Estándares.

Fuente: Fuente: Patiño (2011).
47
La Ingeniería del software debe enmarcarse en parámetros de calidad; en primer lugar, de
desarrollo de proyectos informáticos, y en segundo lugar, de gestión de las organizaciones; en los
cuales debe contemplar un perfecto entendimiento con estándares internacionales que
garanticen el éxito de proyectos. Además, debe interiorizar a través de herramientas, métodos,
procesos, filosofías y/o enfoques, los planteamientos filosóficos integracionistas emanados por
las potencias en los cuales se busca la unificación de las sociedades.
Entre los estándares internacionales más relacionados, tenemos:
Goal Questión metric (GQM): “Proporciona una manera útil para definir mediciones tanto del
proceso como de los resultados de un proyecto. Se enfoca en los objetivos perseguidos para
alcanzar la meta proyectada” (Maya, 2016).
De acuerdo a Maya, los pasos que propone GQM son:
➢ Establecer las metas.
➢ Generación de preguntas.
➢ Especificación de medidas.
➢ Preparar recolección de datos.
➢ Recolectar, validar y analizar los datos para la toma de decisiones.
➢ Analizar los datos para el logro de los objetivos y el aprendizaje.
IEEE 802.3 - 802.11: Específicamente desarrollados para operar en redes de computadoras.
ISO / IEC 15939: 2007: Estándar internacional direccionado a la medición de sistemas y software
informáticos.
CMMI: Es un estándar que relaciona las buenas prácticas enfocado a la mejora continua de
los procesos empresariales.
ISO 25000: Norma que se enfoca en la evaluación de los requisitos de calidad del producto
software. De acuerdo a Crespo (2018) “La ISO 25000 proporciona una guía para el uso de la nueva
48
serie de normas internacionales denominadas Sistemas y Requisitos de calidad del Software y
Evaluación (SQUARE)”.
3.3.1 EJERCICIOS DE APRENDIZAJES

correcta.
1) ¿Un estándar se define cómo?
a) Un conjunto de criterios bien documentados para el desarrollo correcto de

aplicaciones de calidad, cumpliendo con las normas y parámetros reglamentarios.
b) Un conjunto de metodologías bien documentadas para el desarrollo correcto de

c) Un conjunto de herramientas bien documentadas para el desarrollo correcto de

d) Un conjunto de estructuras bien documentadas para el desarrollo correcto de

Respuesta A
2) ¿Cuál de los siguientes estándares relaciona las buenas prácticas del software?
a) COBIT
b) ITIL
c) CMMI
d) SQUARE
Respuesta C
49
Instrucciones:
a) Organice un equipo conformado máximo por 3 estudiantes.
b) El equipo de trabajo debe realizar las siguientes actividades:
1. Diseñar un mapa de ideas que relacione los siguientes temas.
1.1 ISO 25000
1.2 ISO / IEC 15939 DE 2007
1.3 IEEE 802.3
1.4 IEEE 802.11
1.5 SPICE
1.6 SCAMPI
1.7 ITIL
TIPS
IEEE 802.3 es un estándar desarrollado para operar en redes de
computadoras
3.4 TEMA 3 MÉTRICAS DE CALIDAD DEL SOFTWARE

➢ Video: Definiendo métricas de calidad
➢ ” Ver Video”: https://www.youtube.com/watch?v=h296BiVb0R0
50
Se determina como el cumplimiento de los requisitos funcionales y de desempeño explícitamente
establecidos, además de los estándares de desarrollo documentados y las características
implícitas que se evidencian durante el ciclo de vida del software.
Una métrica se define como una medida cuantitativa utilizada en la estimación y valoración de la
calidad de un producto software; la medición puede variar dependiendo de las necesidades de
los clientes o las organizaciones. Estas medidas indican el porcentaje de calidad en que se
encuentra el desarrollo del producto, la productividad de la mano de obra directa, los beneficios
que aportan las herramientas o métodos implementados en el proceso de desarrollo del
producto; teniendo como cimiento los principios, estándares y reglamentaciones de la ingeniería
del software.
Directas
TIPOS DE
MEDIDAS
Indirectas
De acuerdo a Metaute (2016):
➢ Medidas Directas: Son aquellas medidas que se encuentran de forma directa, sin
necesidad de ser procesadas como por ejemplo el valor de una hora de trabajo, las líneas
de código producidas en determinado tiempo, la velocidad de ejecución del programa, el
tamaño de memoria, el número de defectos observados en un determinado periodo de
tiempo, entre otras.
51
➢ Medidas Indirectas: Son medidas que se basan en las directas como por ejemplo el
esfuerzo utilizado para desarrollar una actividad (número de horas por número de
personas), la funcionalidad, calidad, complejidad, eficiencia, fiabilidad, facilidad de
mantenimiento, etc. Dichas medidas se sacan de la combinación entre medidas directas e
indirectas.
MÉTODOS MÁS UTILIZADOS PARA LA APLICACIÓN DE MÉTRICAS DE SOFTWARE
Métricas orientadas en las Métricas orientadas a los Métricas orientadas en los

líneas de código (LDC) puntos de función ajustada casos de uso (COCOMO)
(PFA)
3.4.1 METRICAS ASOCIADAS CON EL PROCESO

Proporcionan indicadores para mejorar los procesos de desarrollo del producto software a largo
plazo. Se usan con fines estratégicos.
De acuerdo a lo que afirma Macías (2011), estas métricas permiten obtener un conjunto de
indicadores de proceso, los cuales conducen a la mejora de los mismos. En el proceso de mejora
del proceso, según lo que expresa este autor, se tiene en cuenta:
1) INFLUENCIA DE TRES FACTORES:
➢ Destreza y motivación del personal.
➢ Complejidad del producto.
➢ Tecnología.
2) CONDICIONES AMBIENTALES:
➢ Entorno de desarrollo.
➢ Condiciones de riesgo.
➢ Características del cliente.

52
Este autor expresa que para mejorar un proceso es necesario:
1) MEDIR SUS ATRIBUTOS:
➢ Errores descubiertos antes de liberar el sw.
➢ Defectos que detectan y reportan los usuarios finales.
➢ Productos de trabajos entregados.
2) DESARROLLAR UN CONJUNTO DE MÉTRICAS:
➢ Métricas privadas: Defectos por individuo, por componente, durante el desarrollo.
➢ Métricas públicas: Índices de defectos a nivel de proyecto, esfuerzo, planificación, etc.
3) OFRECER INDICADORES QUE CONDUZCAN A ESTRATEGIAS DE MEJORA PARA QUE LAS

MÉTRICAS NO CREEN PROBLEMAS:
➢ Aplicar sentido común y sensibilidad para interpretarlas.
➢ Ofrecer retroalimentación a quienes las recopilan.
➢ No utilizarlas para evaluar o amenazar individuos.
➢ Establecer metas claras y las métricas que se usarán para conseguirlas.
➢ No considerar negativos los datos que identifican áreas problemas.
➢ No obsesionarse sólo con una métrica.
Métricas en los dominios del proceso y del proyecto

53
Figura 13. Métricas para el desarrollo de software.

Fuente: Elaboración propia (2020). Adaptado de Pressman.
3.4.2 MÉTRICAS ASOCIADAS CON EL PRODUCTO Y LA ESTIMACIÓN DE

PROYECTOS.
Por su naturaleza, la ingeniería es una disciplina cuantitativa. Los ingenieros usan números como
apoyo para el diseño y la evaluación del producto a construir. Las métricas del producto software,
ayudan a conocer mejor el diseño y la construcción del aplicativo que se elabora; estas métricas
se concentran en atributos específicos de los productos de trabajo de la ingeniería del software y
se recopilan a medida que se realizan las tareas técnicas (análisis, diseño, codificación y pruebas).
El objetivo de la métrica de software, es servir de apoyo para construir un producto de mayor
calidad.
“En la mayoría de los desafíos técnicos, las métricas nos ayudan a entender tanto el proceso
técnico que se utiliza para desarrollar un producto, como el propio producto” (Macías, 2011).
Las métricas de producto hacen referencia a las características del software que se pueden
medir de una forma factible
En cuanto a las métricas de proyecto, estas son tácticas. La primera aplicación de las métricas del
proyecto, en la mayoría de los proyectos de software, ocurre durante la estimación del proyecto
54
(esfuerzo y tiempo). La estimación permite determinar cuánto dinero, esfuerzo, recursos y
tiempo tomará construir un sistema o producto específico basado en software. Esta es una tarea
compleja que requiere de una buena documentación del proyecto a estimar, su planificación y
recursos disponibles para su ejecución. El planificador de proyectos debe estimar tres factores
antes de que un proyecto comience:
➢ ¿Cuánto tiempo tomará?
➢ ¿Cuánto esfuerzo requerirá?
➢ ¿Cuánto personal estará involucrado?
Además, el planificador debe predecir los recursos (hardware y Software) que se requerirán y el
riesgo involucrado. La descripción del ámbito ayuda al planificador a desarrollar estimaciones
empleando una o más técnicas que se clasifican en dos amplias categorías: descomposición, la
cual requieren un bosquejo de las principales funciones del software, seguido por estimaciones;
y modelado empírico, usa expresiones para esfuerzo y tiempo obtenidas de la Ingeniería del
Software.
Todas las aplicaciones de métricas tienen un significado conforme el software evoluciona desde
los requisitos hasta el diseño; se recopilan métricas para valorar la calidad del diseño y mejorar
los indicadores que influirán en el enfoque que se adopte para la generación y prueba del código.
Las métricas de proyecto permiten valorar el estado en que se encuentran los proyectos en
cursos
“Las métricas pueden ser usadas para medir el estado del proyecto, efectividad o progreso de las
actividades de un proyecto y así a contribuir a tomar decisiones estratégicas ante los
desvíos, incidentes o diferentes problemas que surgen en su ejecución” (Macías, 2011).
3.4.3 MÉTRICAS ASOCIADAS CON LAS PERSONAS

Es uno de los factores que influye en la calidad del software. Estas medidas ofrecen indicadores
útiles para el equipo del proyecto. La meta primordial de la ingeniería del software es producir un
sistema, aplicación o producto de alta calidad dentro de un marco temporal que satisfaga
necesidades en el mercado.
55
Este tipo de métrica de acuerdo a Macías (2011), “proporciona medidas e información sobre la
forma que la gente desarrolla el software de computadoras y sobre todo el punto de vista humano
de la efectividad de las herramientas y métodos”.
JERARQUÍA ORGANIZACIONAL DEL EQUIPO EJECUTOR
GESTOR
EJECUTIVO
GESTOR TÉCNICO
PROFESIONALES
CLIENTE
USUARIO FINAL
Figura 14. Jerarquía organizacional de un equipo desarrollador.

Fuente: Elaboración propia (2021). Adaptado de Pressman.

Apreciado estudiante, usted debe analizar las siguientes preguntas o afirmaciones y escoger una
única respuesta correcta.
1) ¿UNA MÉTRICA SE DEFINE COMO?
a) Medida cuantitativa utilizada en la estimación y valoración de la calidad de un

producto software La confidencialidad de la información.
56
b) Medida cualitativa utilizada en la estimación y valoración de la calidad de un producto
software La disponibilidad de la información.
c) Medida mixta utilizada en la estimación y valoración de la calidad de un producto

software
Respuesta A
2) ¿DE QUÉ DEPENDE QUE VARÍE UNA MEDICIÓN?
a) De las necesidades del cliente o las organizaciones.
b) De la amplitud de la gestión de la métrica de proceso.
c) De los principios y estándares aplicados.
d) De los riesgos de la infraestructura o información.
Respuesta A
3) ¿EN QUE SE BASAN LAS MEDIDAS INDIRECTAS DE LA CALIDAD DE SOFTWARE?
a) En medidas de longitud.
b) En medidas de pie.
c) En medidas directas.
d) En medidas indirectas.
Respuesta C

Instrucciones:
Organice un mapa semántico acerca de los siguientes temas:
a) Estimación de proyectos de software.

57
b) Estimación de costos.
c) Métricas asociadas con el producto y proyecto.
d) Métricas de dominio del proceso y el proyecto.
e) Métricas asociadas con las personas.
TIPS
La meta primordial de la ingeniería del software es producir un sistema,
aplicación o producto de alta calidad dentro de un marco temporal que
satisfaga necesidades en el mercado.
58
4 PISTAS DE APRENDIZAJE
➢ Tenga Presente que: La clase en software, es la descripción general de un objeto, donde los
atributos son las variables y los métodos son las funcionalidades del sistema
➢ Recuerde que: La estimación permite determinar cuánto dinero, esfuerzo, recursos y tiempo
tomará construir un sistema o producto específico basado en software.
➢ Es importante tener presente que: Las métricas de software ayudan a detectar errores y
defectos a tiempo, minimizando reproceso y pérdida de recursos.
➢ No olvide que: Las métricas de personas son medidas que ofrecen indicadores útiles para el
equipo del proyecto.
➢ Tenga presente que: Al llevar un control de cada una de las versiones en que se encuentra el
desarrollo del producto, en ocasiones trae muchas complicaciones, debido a que se realizan
diversas copias del mismo proyecto, para lo cual se recomienda almacenar las copias en
diversos dispositivos, debido a que si se guarda en un solo dispositivo y este presenta fallas,
se pierde el esfuerzo realizado.
➢ Recuerde que: Existen diversas herramientas destinadas a la gestión de la configuración del
software, entre las cuales se destaca las de gestión de la configuración de nube para múltiples
plataformas.
➢ Tenga presente que: Las métricas, no son utilizadas actualmente, en todos los procesos del
ciclo de vida del software, sólo se utilizan en su mayoría en las etapas de codificación y
pruebas.
➢ Recuerde que: El proceso de auditoría facilita la verificación y validación de la funcionalidad
del producto software
➢ No olvide que: La Ingeniería de Software es una disciplina joven, que viene aprendiendo de
las buenas prácticas.
59
5 GLOSARIO
• Agile: Metodología de trabajo liviana.
• Metodologías: Es una buena práctica de desarrollo para contar con la mayor cantidad de
alternativas en el desarrollo.
• Codificar: Expresión de los procesos lógicos mediante un lenguaje de programación.
• Buenas prácticas: Una buena práctica es el proceso más óptimo y de mayor alcance a
futuro.
• Herramientas: Conjunto de opciones de hardware o software que se tienen en para la

elaboración de un aplicativo.
• Calidad: Se relaciona con el grado de satisfacción del cliente en relación al producto de

software y las funcionalidades de éste en cuanto a requisitos de usuario, requisitos
funcionales y requisitos no funcionales.
• Clase. Estructura estática relacionada con la programación orientada a objetivos, que se

utiliza para definir las características de un objeto y las acciones que se pueden ejecutar
sobre dichos objetos, como por ejemplo la clase estudiante y la acción consultar
estudiante.
• Configuración de software: conjunto de procesos que se realizan para asegurar la calidad

del software, en caso de generarse cambios que requieran la adaptación del sistema a
nuevas necesidades.
• Componentes: son los elementos que posee un objeto como los atributos, identidad,
relaciones y métodos.
60
6 BIBLIOGRAFÍA
• Jaramillo, C. (2016). Arquitectura de
Este capítulo recomienda al estudiante las Software. Corporación Universitaria
fuentes de consulta bibliográficas y digitales Remington. Módulo de estudio.
para ampliar su conocimiento, por lo tanto,
deben estar en la biblioteca digital de la • Metaute, P. (2016). Ingeniería del Software
Remington. Utilice la biblioteca digital II. Corporación Universitaria Remington.
http://biblioteca.remington.edu.co/es/ para
Cuarta versión.
la consulta de bibliografía a la cual puede
acceder el estudiante. • Linthicum, D. (2017). Elija las herramientas
de gestión de la configuración de nube para
FUENTES BIBLIOGRÁFICAS
múltiples plataformas. TechTarget.
• Crespo, A. (2018). ISO 25000: La calidad del Disponible en
producto software. Disponible en https://searchdatacenter.techtarget.com/es
https://www.excentia.es/iso-25000 /consejo/Elija-las-herramientas-de-gestion-
de-la-configuracion-de-nube-para-multiples-
• Durán, K. (2018). Herramientas para facilitar plataformas
el diseño de una interfaz. Disponible en
https://medium.com/@KatDuranSanzana/h • Macías, J. (2011). Métricas de proceso y
erramientas-para-facilitar-el-dise%C3%B1o- proyecto. Slideshare. Disponible en
de-una-interfaz-ea3b96a7a1dd https://es.slideshare.net/jose_macias/mtric
as-de-procesos-y-proyectos
• Fuertes, Y. y Sepúlveda, J. (2016). Scrum,
Kanban y Canvas en el sector comercial, • Maya, E. (2016). Metodología GQM.
industrial y educativo - Una revisión de la Slideshare. Disponible en
literatura. Revista Antioqueña de las Ciencias https://es.slideshare.net/netozack/metodol
Computacionales y la Ingeniería de Software oga-gqm-59163173
– RACCIS. Recuperado de
https://www.researchgate.net/profile/Jorge • Patiño, R. (2011). Módulo de Ingeniería del
_Sepulveda_Castano/publication/30515802 Software III. Corporación Universitaria
3_Scrum_Kanban_y_Canvas_en_el_sector_c Remington.
omercial_industrial_y_educativo_-
• Ramírez, K. (2017). Interfaz y experiencia de
_Una_revision_de_la_literatura/links/599dc
usuario: parámetros importantes para un
b7aaca272dff12fd7d4/Scrum-Kanban-y-
diseño efectivo. Revista Tecnología en
Canvas-en-el-sector-comercial-industrial-y-
Marcha. Vol. 30. Disponible en
educativo-Una-revision-de-la-literatura.pdf
https://www.scielo.sa.cr/scielo.php?scri
pt=sci_arttext&pid=S0379-
39822017000500049

Ingenieria de Software II - 2021

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Ingenieria de Software II - 2021

Cargado por

Copyright:

Formatos disponibles

Auditoria II

David Ernesto González Parra

Francisco Javier Álvarez Gómez

Derechos reservados: El módulo de estudio del curso de INGENIERÍA

Esta obra es publicada bajo la licencia Creative Commons.

1 UNIDAD 1: DISEÑO DE SOFTWARE 7

1.2 TEMA 1 ARQUITECTURA DE DISEÑO DE SOFTWARE 8

1.3 TEMA 2 PATRONES DE DISEÑO DE SOFTWARE 11

1.1 TEMA 3 DISEÑO DE SOFTWARE 13

2 UNIDAD 2 GESTIÓN DE CONFIGURACIÓN DE SOFTWARE. 23

2.2 TEMA 1 GESTIÓN E IDENTIFICACIÓN DE OBJETOS EN LA CONFIGURACIÓN DEL SISTEMA 24

2.3 TEMA 2 HERRAMIENTAS PARA LA GESTIÓN DE LA CONFIGURACIÓN DE SOFTWARE 31

3 UNIDAD 3 GESTIÓN DE PROYECTOS DE SOFTWARE ASOCIADO A LAS MÉTRICAS 35

3.2 TEMA 1 PLANEACIÓN Y MANEJO DE RIESGOS DE PROYECTOS DE SOFTWARE 37

3.3 TEMA 2 MÉTODOS Y ESTÁNDARES DE MEDICIÓN 46

3.4 TEMA 3 MÉTRICAS DE CALIDAD DEL SOFTWARE 49

UNIDAD 1 UNIDAD 2 UNIDA 3

Figura 1. Diseño de software.

1.1.1 OBJETIVO GENERAL

1.1.2 OBJETIVOS ESPECÍFICOS

➢ Identificar las diversas herramientas utilizables en el diseño de una interfaz de usuario.

1.1.3 PRUEBA INICIAL

2) ¿Qué es un patrón de diseño de software? Es una técnica que facilitan la identificación y

3) ¿Qué se requiere para un mayor control de los diversos patrones de software? Se

4) ¿Qué ventajas conoce de la metodología ágil?

➢ Respuesta a cambios de requisitos.

➢ Entrega continua de software funcional.

➢ Trabajo entre el cliente y el desarrollador.

1.2 TEMA 1 ARQUITECTURA DE DISEÑO DE SOFTWARE

➢ Facilita la comunicación entre las partes interesadas en el desarrollo del software.

➢ Permite destacar las decisiones iníciales del diseño del sistema.

Un buen diseño arquitectónico requiere las siguientes directrices:

➢ Diseños estructurales que se pueda implementar de forma creciente.

➢ Diversas representaciones de datos.

➢ Estructuras de datos apropiadas.

➢ Reducción de la complejidad de las conexiones.

➢ Debe hacer referencia a la información recolectada en la parte de análisis.

➢ Claridad en lo que se quiere entregar al usuario final.

2) ¿Qué es Scrum? es un frameworks de Agile y se utiliza para agilizar el proceso del

1.2.2 TALLER DE ENTRENAMIENTO

c) Evaluación de la calidad del diseño de software.

Un patrón de diseño de software es una técnica que facilitan la identificación y resolución de

➢ Nombre: Hace énfasis específicamente al problema de diseño

1.3.1 EJERCICIO DE APRENDIZAJE

1) ¿Un patrón de diseño de software es?

a) Una Metodología Ágil que facilitan la identificación y resolución de posibles problemas

b) Una técnica que facilitan la identificación y resolución de posibles problemas que

c) Una documentación de creatividad que facilitan la identificación y resolución de

2) ¿Los elementos de un patrón son?

a) Documentación, información, ciencia y arte.

b) Información, tecnología, solución.

c) Nombre, problema, solución.

3) ¿Qué se requiere para un mayor control de los patrones?

b) Usuario final y desarrollador.

c) Desarrolladores o profesionales en software.

a) Características de los patrones de diseño de software.

b) Ventajas de los patrones de diseño de software.

1.1 TEMA 3 DISEÑO DE SOFTWARE

Un buen diseño debe:

➢ Ser rastreable hasta el modelo de análisis: El modelo enuncia el dominio de la

➢ A nivel de componentes: Ser independiente del modo funcional. La funcionalidad que se

➢ Desarrollarse de manera iterativa: En cada iteración el diseñador debe buscar la mayor

Dentro de la práctica del diseño, es recomendable destacar la gran responsabilidad que se