0% encontró este documento útil (0 votos)
23 vistas119 páginas

Porta Folio

Descargar como pdf o txt
Descargar como pdf o txt
Descargar como pdf o txt
Está en la página 1/ 119

UNIVERSIDAD TÉCNICA DE MACHALA

D. L. No. 69-04 DE 14 DE ABRIL DE 1969


Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información

ASIGNATURA:
INGENIERIA DE SOFTWARE I
PROFESOR:
HERNAN MAURICIO SANCHEZ
MENDIETA
ESTUIDANTE:
FREDDY JEFFERSON CEDILLO RIVERA
CICLO:
QUINTO
PARALELO:
‘‘A’’
SECCIÓN:
VESPERTINA
AÑO:
2023-2
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
Contenido
CLASE 1: FUNDAMENTOS DE LA INGENIERIA DE SOFTWARE ......................................3
CLASE 2: PROCESO DEL SOFTWARE - MODELO PROCESO SOFTWARE .......................7
CLASE 3: COSTOS Y METODOS INGENIERIA DE SOFTWARE ........................................14
CLASE 4: HERRAMIENTAS CASE ........................................................................................25
CLASE 5: ATRIBUTOS DE UN BUEN SOFTWARE ..............................................................33
CLASE 6: RETOS FUNDAMENTALES INGENIERIA SOFTWARE .....................................41
TALLER CLASE 1 FUNDAMENTOS INGENIERÍA SOFTWARE ........................................83
TALLER CLASE 2 PROCESO DEL SOFTWARE - MODELO PROCESO SOFTWARE .......86
TALLER CLASE 3: COSTOS Y METODOS INGENIERIA DE SOFTWARE ........................95
TALLER CLASE 4: HERRAMIENTAS CASE ......................................................................104
TALLER CLASE 5: ATRIBUTOS DE UN BUEN SOFTWARE ............................................110
TALLER CLASE 6: RETOS FUNDAMENTALES INGENIERÍA SOFTWARE ...................117
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
CLASE 1: FUNDAMENTOS DE LA INGENIERIA DE
SOFTWARE

FUNDAMENTOS DE INGENIERÍA DE SOFTWARE


La ingeniería de software es una disciplina formada por un conjunto de métodos, herramientas y
técnicas que se utilizan en el desarrollo de los programas informáticos (software). El ingeniero de
software se encarga de toda la gestión del proyecto para que éste se pueda desarrollar en un plazo
determinado y con el presupuesto previsto. Incluye el análisis previo de la situación, el diseño del
proyecto, el desarrollo del software, las pruebas necesarias para confirmar su correcto
funcionamiento y la implementación del sistema. El proceso de desarrollo de software implica lo
que se conoce como ciclo de vida del software, que está formado por cuatro etapas: concepción,
elaboración, construcción y transición.
Los Ingenieros de Software deben:

✓ Adoptar un enfoque sistemático para llevar a cabo su trabajo.

✓ Utilizar las herramientas y técnicas apropiadas para resolver el problema planteado, de acuerdo
a las restricciones de desarrollo y a los recursos disponibles.

¿QUÉ ES SOFTWARE?

El software: es el conjunto de instrucciones o programas que le dicen a una computadora qué


hacer. Es independiente del hardware y hace que las computadoras sean programables.

TIPOS BÁSICOS DE SOFTWARE


Software del sistema: para proporcionar funciones básicas como sistemas operativos,
administración de discos, servicios, administración de hardware y otras necesidades
operacionales.
Software de programación: para brindar a los programadores herramientas como editores de texto,
compiladores, enlazadores, depuradores y otras herramientas para crear código.
Software de aplicación: (aplicaciones o apps) para ayudar a los usuarios a realizar tareas. Las
suites de productividad de Office, el software de gestión de datos, los reproductores multimedia
y los programas de seguridad son algunos ejemplos.
Software integrado: El software de sistemas integrados se utiliza para controlar máquinas y
dispositivos que normalmente no se consideran computadoras, como redes de
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
telecomunicaciones, automóviles, robots industriales y más.

TIPOS DE SOFTWARE DEPENDIENDO DE LA DISTRIBUCIÓN


• Freeware, en el caso de aquellos softwares que se compartan de una manera totalmente gratuita.
• De pago. Que se puede comprar o bien funciona bajo suscripción.
• Adware, que incluye anuncios publicitarios.
• Shareware, el cual viene a reflejar los programas que están limitados en el caso de no pasar por
la pasarela de pago.
• Software libre, en el cual el propio usuario puede llegar a modificar el programa si le resulta
conveniente.

¿QUÉ ES LA INGENIERÍA DEL SOFTWARE?


La ingeniería del software es una disciplina que implica el uso de estructuras, herramientas y
técnicas para construir programas informáticos.

Incluye el análisis previo de la situación, la redacción del proyecto, la creación del software y las
pruebas necesarias para garantizar su correcto funcionamiento antes de que el sistema esté
operativo. Esta ingeniería aborda todas las fases del ciclo de vida de desarrollo de cualquier tipo
de sistema de información y es aplicable a una amplia gama de ámbitos de la informática y la
ciencia de los ordenadores.

OBJETIVOS DE LA INGENIERÍA DE SOFTWARE


UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
1. Diseño de programas informáticos adaptados a las necesidades y exigencias de los clientes.
2. Guiar y coordinar el desarrollo de una programación difícil.
3. Estimar los costos y el plazo de ejecución de un proyecto.
4. Actuar como líder del equipo de desarrollo de software.
5. Diseño, desarrollo y administración de bases de datos.
6. Solucionar problemas de programación.
7. Estar presente en todas las fases del ciclo de vida de un producto.
8. Realizar el seguimiento del presupuesto y cumplir los plazos de entrega.
9. Incluir procesos de calidad en las aplicaciones, como la medición de métricas y medidas y la
evaluación de la calidad del software.
10. Solucionar problemas de programación.
11. Estar presente en todas las fases del ciclo de vida de un producto.
12. Realizar el seguimiento del presupuesto y cumplir los plazos de entrega.
13. Incluir procesos de calidad en las aplicaciones, como la medición de métricas y medidas y la
evaluación de la calidad del software.

ETAPAS DE LA INGENIERÍA DE SOFTWARE


• Concepción: En esta primera fase se desarrolla el modelo de negocio.
• Elaboración: Se detalla las características de la estructura del software.
• Construcción: Tal y como su nombre indica en este paso empezamos a elaborar de forma tangible
todo aquello que, de momento, solo hemos plasmado en forma de ideas.
• Transición: Es el momento de la implementación y el desarrollo para los clientes o usuarios.
Otra fase conocida como mantenimiento. Es una de las etapas más importantes ya que se
solucionan los problemas o errores que puedan surgir durante su implementación y también su
posterior puesta en marcha. Relacionado con la ingeniería de software también se encuentra la
arquitectura de sistemas. Consiste en la esquematización de la estructura general del proyecto a
desarrollar.
“Hay que tener en cuenta que existen dos tipos de softwares. Por un lado, destacamos el estándar,
más generalista y que se puede adaptar a varios modelos de negocio. Mientras que, por el otro
lado, tenemos el personalizado. Se trata de un tipo de software que se desarrolla para el uso
exclusivo de un cliente”.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
CLASE 2: PROCESO DEL SOFTWARE - MODELO PROCESO
SOFTWARE

¿QUÉ ES UN PROCESO DEL SOFTWARE?


La meta de la ingeniería de software es construir productos de software, o mejorar los existentes;
en ingeniería de procesos, la meta es desarrollar o mejorar procesos.
Un proceso de software es una serie de actividades relacionadas que conduce a la elaboración de
un producto de software. Estas actividades pueden incluir el desarrollo de software desde cero en
un lenguaje de programación estándar como Java o C. Sin embargo, las aplicaciones de negocios
no se desarrollan precisamente de esta forma. El nuevo software empresarial con frecuencia ahora
se desarrolla extendiendo y modificando los sistemas existentes, o configurando e integrando el
software comercial o componentes del sistema.
Permite estandarizar esfuerzos, promover re-uso, repetición y consistencia entre proyectos.

 Provee la oportunidad de introducir mejores prácticas de la industria.


 Permite entender que las herramientas deben ser utilizadas para soportar un proceso.
 Establece la base para una mayor consistencia y mejoras futuras.
Un proceso de software:
 Define cómo manejar los cambios y liberaciones a sistemas de software existentes.
 Define cómo lograr la transición del software a la operación, y cómo ejecutar los
esfuerzos de operación y soporte.
Existen diferentes procesos de software, pero todos deben incluir cuatro actividades que son
fundamentales:
o Especificación del software: tienen que definirse tanto la funcionalidad del software
como las restricciones de su operación.
o Diseño e implementación del software: debe desarrollarse el software para cumplir con
las especificaciones.
o Validación del software: hay que validar el software para asegurarse de que cumple lo
que el cliente quiere.
o Evolución del software: El software tiene que evolucionar para satisfacer las necesidades
cambiantes del cliente.
Al igual que las actividades, también las descripciones de los procesos deben incluir:
Productos: resultados de una actividad del proceso.
Roles: responsabilidades de la gente que interviene en el proceso.
Al igual que las actividades, también las descripciones de los procesos deben incluir:
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
Precondiciones y pos condiciones:
son declaraciones válidas antes y después de que se realice una actividad del proceso o
se cree un producto.
Principales roles o involucrados en el proceso de desarrollo de software
Cada uno de los involucrados aportará al conjunto, una parte del total necesario para tener
éxito en el desarrollo de software.
Los roles son necesarios para cubrir todas las especificaciones necesarias en el
cumplimiento de un proceso, ya que no todos tienen la misma preparación académica,
cualidades y experiencias profesionales.
Además, al asignar roles se definen objetivos y actividades para cada uno, evitando que
alguna actividad no sea asignada o que dos personas o equipos realicen el mismo trabajo.
Gerente de proyecto
Tiene por misión cumplir los plazos previstos del desarrollo, ofrecer las soluciones mitigadoras
de riesgos o correcciones de las desviaciones en la planificación, cumplir la realización del
proyecto en el presupuesto acordado, presentar los informes sobre los factores de riesgos
asociados.

Analista de requerimientos
Su objetivo es recopilar, analizar y verificar las necesidades del cliente para un sistema, se encarga
de la documentación de los requerimientos para así el resto del equipo lo pueda consultar en
cualquier momento

Desarrollador de software o programador


Es el responsable del diseño y desarrollo del software, escribe el código fuente, prueba lo que
programa y se encarga de hacer el mantenimiento y/o mejoras del código que se necesite realizar.
Testeado
Se encarga de diseñar y ejecutar las pruebas necesarias para validar las diferentes rutinas del
código fuente, en busca de errores críticos y no críticos que se le hubiesen pasado por alto al
programador y para lograr el correcto funcionamiento en las plataformas donde se ejecuten y sus
interacciones con otros sistemas preexistentes.

Arquitecto de software
Se encarga de estudiar y determinar las estructuras de la aplicación y las tecnologías con las que
se construirá el software, además se encarga del aseguramiento de la calidad, mejorando
continuamente la arquitectura del software y actualizando la misma.

¿QUÉ ES UN MODELO DE PROCESOS DEL SOFTWARE?


UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información

Modelos de proceso de software


Un modelo de procesos del software es una descripción simplificada de un proceso del software
que presenta una visión de ese proceso.
1.Un modelo de flujo de trabajo. Muestra la secuencia de actividades en el proceso junto con sus
entradas, salidas y dependencias.
2.Un modelo de flujo de datos o de actividad. Representa el proceso como un conjunto de
actividades, cada una de las cuales realiza alguna transformación en los datos.
3.Un modelo de rol/acción. Representa los roles de las personas involucrada en el proceso del
software y las actividades de las que son responsables.
La mayor parte de los modelos de procesos del software se basan en uno de los tres modelos
generales o paradigmas de desarrollo de software:
Cascada
Orientado al reúso (Component-based)
Iterativo
o Incremental
o Desarrollo Ágil
Etc. (existen más)

El enfoque en cascada.
Considera las actividades anteriores y las representa como fases de procesos separados, tales
como la especificación de requerimientos, el diseño del software, la implementación, las pruebas,
etcétera. Después de que cada etapa queda definida «se firma» y el desarrollo continúa con la
siguiente etapa.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información

Actividades fundamentales del desarrollo de enfoque en cascada:


1. Análisis y definición de requerimientos: Especificación del sistema.
2. Diseño del sistema y del software: Establece una arquitectura de sistema global.
3. Implementación y prueba de unidad: Verifica que cada unidad cumpla con su especificación.
4. Integración y prueba de sistema: Se realiza pruebas a todo el sistema, se libera el sistema de
software al cliente
5. Operación y mantenimiento: Incluye corregir los errores que no se detectaron en etapas
anteriores del ciclo de vida, mejorar la implementación de las unidades del sistema e incrementar
los servicios del sistema conforme se descubren nuevos requerimientos.

VENTAJAS DESVENTAJAS
Fácil de entender Es difícil regresar a una fase previa.
Fácil de manejar: cada fase tiene El software es entregado al final del
entregables específicos ciclo de vida del proyecto.
Refuerza buenos hábitos: No es apropiado para proyectos muy
Definir requerimientos antes de complejos o aquellos en los que los
diseñar; diseñar antes de codificar. requerimientos tienen alta
Dirigido en base a documentos, no probabilidad de cambio.
dependiente de las personas.

Desarrollo iterativo.
Este enfoque entrelaza las actividades de especificación, desarrollo y validación. Un
sistema inicial se desarrolla rápidamente a partir de especificaciones muy abstractas.
Este se refina basándose en las peticiones del cliente para producir un sistema que
satisfaga las necesidades de dicho cliente.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
El sistema puede entonces ser entregado.
Modelos iterativos:
Desarrollo incremental (iterativo + incrementos)
Desarrollo Ágil
Espiral
Rational Unified Process (RUP)
Etc.

VENTAJAS DESVENTAJAS
No hay que esperar hasta el final para Para los usuarios es difícil esperar
tener un sistema en producción. hasta que su funcionalidad esté lista
Las funcionalidades más importantes (reemplazo de sistema)
se desarrollan primero (se prueban A veces se complica identificar
más). servicios comunes a todos los
Se van descubriendo cambios en incrementos (el enfoque es por
requerimientos de los incrementos no incremento).
desarrollados (fácil incorporar Impacto en el proceso de contratación
cambios). (los requerimientos pueden cambiar a
Es más fácil acostumbrarse al nuevo medida que se desarrollan los
sistema. incrementos).

Ingeniería del software basada en componentes (CBSE).


Esta técnica supone que las partes del sistema existen.
El proceso de desarrollo del sistema se enfoca en la integración de estas partes más que
desarrollarlas desde el principio.

Análisis de componentes: Dada la especificación de requerimientos, se realiza una búsqueda de


componentes para implementar dicha especificación.
Modificación de requerimientos: Durante estas etapas se analizan los requerimientos usando
información de los componentes descubiertos.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
Diseño de sistema con reutilización: Durante esta fase se diseña el marco conceptual del sistema
o se reutiliza un marco conceptual existente.
Desarrollo e integración: Se diseña el software que no puede procurarsede manera externa, y se
integran los componentes y los sistemas COTS(Commercial-off-the-shelf), para crear el nuevo
sistema.
Ingeniería del software basada en componentes (CBSE).
Existen tres tipos de componentes de software que pueden usarse en un proceso orientado a la
reutilización:
1. Servicios Web que se desarrollan en concordancia para atender servicios estándares y que están
disponibles para la invocación remota.
2. Colecciones de objetos que se desarrollan como un paquete para su integración con un marco
de componentes como .NET o J2EE.
3. Sistemas de software independientes que se configuran para usar en un entorno particular.

VENTAJAS DESVENTAJAS
Reduce la cantidad de software que Se pierde el control sobre la evolución
debe ser del software si las nuevas versiones
desarrollado lo que reduce costos y de los componentes reusables no
riesgos. están bajo el control de la
Usualmente se disminuyen los organización.
tiempos de entrega del software. El ajuste de requerimientos podría
producir un sistema que no satisface
las necesidades reales del usuario.

Desarrollo Incremental
El sistema es entregado en partes (incrementos / módulos).
El cliente debe de clasificar las partes de acuerdo a su importancia (prioridad alta, media,
baja).
El incremento de más alta prioridad se entrega primero.
Cada incremento se pone en producción

 Requerimientos: Esta fase se refiere a todos los objetivos del proyecto, tanto el general o
central como los específicos.
 Se precisan las tareas e iteraciones: definir las tareas y las iteraciones con que las que los
concretaremos.
 Diseño de los incrementos: Se define cuál será la evolución del proyecto en las
iteraciones.
 Desarrollo del incremento: Las tareas definidas son llevadas a cabo y así los incrementos
previstos son desarrollados.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
 Validación de los incrementos: Los responsables de la gestión de proyecto han de verificar
que cada iteración culminada de los resultados esperados.
 Integración de los incrementos: integra todos los incrementos aprobados o validados por
la gestión de proyectos. Así se da la evolución global del proyecto, lo que también se
conoce como línea incremental.
 Entrega del producto: Una vez hecha la integración y se constante que el producto cumple
con los objetivos planteados, se realiza la entrega.

VENTAJAS DESVENTAJAS
No hay que esperar hasta el final para Para los usuarios es difícil esperar
tener un sistema en producción. hasta que su funcionalidad esté lista –
Las funcionalidades más importantes (reemplazo de sistema)
se desarrollan primero (se prueban A veces se complica identificar
más). servicios comunes a todos los
Se van descubriendo cambios en incrementos (el enfoque es por
requerimientos de los incrementos no incremento).
desarrollados (fácil incorporar Impacto en el proceso de contratación
cambios). (los requerimientos pueden cambiar a
Es más fácil acostumbrarse al nuevo medida que se desarrollan los
sistema. incrementos).
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
CLASE 3: COSTOS Y METODOS INGENIERIA DE
SOFTWARE

¿CUÁLES SON LOS COSTOS DE LA INGENIERÍA DE


SOFTWARE?
Elementos Identificados como Puntos de Función

Elementos de datos Funciones transaccionales


Ficheros lógicos internos (ILF). Entradas externas (EI).
Ficheros lógicos externos (EIF). Salidas externas (EO)
Consultas externas (EQ)

Aplicación Software Media

Definiciones:
1. Ficheros lógicos internos (ILF): Grupos de datos relacionados, visibles para el usuario,
relativos a datos o información de control de la aplicación, se mantienen adentro del
ámbito de la aplicación.

2. Ficheros lógicos externos (EIF): Grupos de datos relacionados, visibles para el usuario,
relativos a datos o información de control de la aplicación, se mantienen fuera del ámbito
de la aplicación.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
3. Tipo de Datos Elemental (DET): Campo único e irrepetible, visible al usuario.

4. Tipo Registro Elemental (RET): Grupo de datos relacionados dentro de un fichero lógico
externo o interno.

5. Tipo Fichero Referenciado (FTR): Archivo lógico interno o externo. Puede tener varios
RET. Un grupo de datos se considera RET si es opcional o independiente de los demás.

6. Salidas Externas (EO): Proceso elemental que genera datos que se envían más allá de la
frontera de la aplicación. Dicho proceso elemental debe realizar algún cálculo, generar
datos derivados, modificar algún ILF o el estado de la aplicación.

7. Consultas Externas (EQ): Proceso elemental de la aplicación siendo medida que envía
datos o información de control más allá de la frontera de la aplicación. Sólo muestra
información tal como está contenida en el sistema, sin realizar ningún tipo de
procesamiento extra más allá de la simple recuperación de datos.
¿Cuáles son los costos de la ingeniería de software?
Usualmente el profesional informático se vincula en los proyectos de software hasta la estimación
de horas-hombre requeridas. Otras decisiones como períodos de actualización tecnológica,
herramientas en las que invertir, proyectos a abordar, productos a discontinuar, contratar personal
o hacer outsourcing usualmente son ajenas al personal informático.

 Estimar y presupuestar, con la mayor precisión posible, el coste real asociado a la


construcción de un determinado sistema software.
 Controlar y gestionar los ingresos y gastos durante el proceso de construcción de dicho
sistema para que se cumplan las estimaciones anteriormente mencionadas.
No existe una respuesta simple a esta pregunta ya que la distribución de costos a través de las
diferentes actividades en el proceso del software depende del proceso utilizado y del tipo de
software que se vaya a desarrollar.

 En el enfoque en cascada, los costos de especificación, diseño, implementación e


integración se miden de forma separada.

 Si el software se desarrolla utilizando un enfoque iterativo, no existe división entre la


especificación, el diseño y el desarrollo. En este enfoque, los costos de la especificación
se reducen debido a que sólo se produce la especificación de alto nivel antes que el
desarrollo.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información

 La ingeniería del software basada en componentes sólo ha sido ampliamente utilizada


durante un corto periodo de tiempo. En este enfoque, no tenemos figuras exactas para los
costos de las diferentes actividades del desarrollo de software.

 Para sistemas software de larga vida, tales como sistemas de orden y de control que
pueden ser usados durante 10 años o más, estos costos exceden a los de desarrollo por un
factor de 3 o 4, como se muestra en la Figura. Sin embargo, los sistemas de negocio más
pequeños tienen una vida mucho más corta y, correspondientemente, costos de evolución
más reducidos.

COCOMO.
El Modelo Constructivo de Costos (COnstructive COst Model) es una jerarquía de modelos de
estimación para el software. Esta jerarquía está constituida por los siguientes modelos:

 Básico: modelo univariable estático que calcula el esfuerzo (y el costo) del desarrollo de
software en función del tamaño del programa expresando en líneas de código (LDC)
estimadas.
 Intermedia: calcula el esfuerzo del desarrollo de software en función del tamaño del
programa y de un conjunto de “conductores de costo”, que incluyen la evaluación
subjetiva del producto, del hardware, del personal y de los atributos del proyecto.
 Avanzada: incorpora todas las características de la versión intermedia y lleva a cabo una
evaluación de impacto de los conductores de costo en cada fase (análisis, diseño, etc.) del
proceso de ingeniería de software.
Las ecuaciones del modelo COCOMO básico tienen la siguiente forma:

E= esfuerzo aplicado en personas-mes.


D= tiempo de desarrollo en meses cronológicos.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
KLDC= es el número estimado de Líneas de Código distribuidas (en miles) para el proyecto.
Las ecuaciones del modelo COCOMO intermedio toma la forma:

E= esfuerzo aplicado en personas-mes.


KLDC= número estimado de Líneas de Código distribuidas para el proyecto.
TIPOS DE PROYECTO DE SOFTWARE
Modelo Orgánico: Proyectos de software relativamente pequeños y sencillos en los que trabajan
pequeños equipos, con buena experiencia en la aplicación, sobre el conjunto de requisitos poco
rígidos.
Modelo Semiacoplado: Proyectos de software intermedios (en tamaño y complejidad) en los que
los equipos, con variados niveles de experiencia, deben satisfacer requisitos poco o medio rígidos.
Modelo Empotrado: Proyectos de software que deben ser desarrollados en un conjunto de
hardware, software y restricciones operativas muy restringidas.
EL MODELO COCOMO II
COCOMO II, la forma evolucionada de COCOMO, en realidad es una jerarquía de modelos de
estimación que aborda las áreas siguientes:

 Modelo de composición de aplicación. Se usa durante las primeras etapas de la ingeniería


de software, cuando son primordiales la elaboración de prototipos de las interfaces de
usuario, la consideración de la interacción del software y el sistema, la valoración del
rendimiento y la evaluación de la madurez de la tecnología.
 Modelo de etapa temprana de diseño. Se usa una vez estabilizados los requisitos y
establecida la arquitectura básica del software.
 Modelo de etapa postarquitectónica. Se usa durante la construcción del software.
Como todos los modelos de estimación para software, los modelos COCOMO II requieren
información sobre dimensionamiento. Como parte de la jerarquía del modelo, están disponibles
tres diferentes opciones de dimensionamiento:
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información

líneas
Puntos
Puntos de
de
objeto código
función
fuente

Una vez determinada la complejidad, el número de pantallas, reportes y componentes se ponderan


de acuerdo con la tabla que se ilustra:

Entonces se determina el conteo de puntos de objeto multiplicando el número original de


instancias de objeto por el factor de ponderación que hay en la figura y se suman para obtener un
conteo total de puntos de objeto. Cuando debe aplicarse desarrollo basado en componente o reuso
de software general, se estima el porcentaje de reuso (%reuso) y el conteo de puntos de objeto se
ajusta:
NOP = (puntos de objeto) X [(100 − %reuso) /100]
Donde NOP se define como nuevos puntos de objeto.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
Para derivar una estimación del esfuerzo con base en el valor NOP calculado, debe derivarse una
“tasa de productividad”.

Para diferentes niveles de experiencia del desarrollador y de madurez del entorno de desarrollo.
Una vez determinada la tasa de productividad se calcula una estimación del esfuerzo del proyecto
usando.

¿QUÉ SON LOS MÉTODOS DE LA INGENIERÍA DEL


SOFTWARE?
Una metodología, desde un punto de vista de la ingeniería, escribe cómo se organiza un
proyecto.

 Establece el orden en el que la mayoría de las actividades tienen que realizarse y los
enlaces entre ellas.
 Indica cómo tienen que realizarse algunas tareas proporcionando las herramientas
concretas e intelectuales
Con una metodología se intentan cubrir las siguientes necesidades

 Mejores aplicaciones
 Mejor proceso de desarrollo
 Establecer un proceso estándar en una organización
DEFINICIÓN

“Un proceso para producir software de forma organizada, empleando una colección de técnicas
y convenciones de notación predefinidas” (Rumbaugh et al., 1991)
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
CARACTERÍSTICAS DESEABLES EN UNA METODOLOGÍA

 Un proceso de ciclo de vida completo, que comprenda aspectos tanto del negocio como
técnicos
 Un conjunto completo de conceptos y modelos que sean internamente consistentes
 Una colección de reglas y guías
 Una descripción completa de artefactos a desarrollar
 Una notación con la que trabajar, idealmente soportada por diversas herramientas CASE
y diseñada para una usabilidad óptima
 Un conjunto de técnicas probadas
 Un conjunto de métricas, junto con asesoramiento sobre calidad, estándares y
estrategias de prueba
 Identificación de los roles organizacionales
 Guías para la gestión de proyectos y aseguramiento de la calidad
 Asesoramiento para la gestión de bibliotecas y reutilización
METODOLOGÍAS ESTRUCTURADAS

 Proponen la creación de modelos del sistema que representan los procesos, los flujos y
la estructura de los datos de una manera descendente.
 Se pasa de una visión general del problema, nivel de abstracción alto, a un nivel de
abstracción sencillo
 Esta visión se puede enfocar
o Hacia un punto de vista funcional del sistema
 Metodologías orientadas a procesos
o Hacia la estructura de datos
 Metodologías orientadas a datos
METODOLOGÍAS ESTRUCTURADAS ORIENTADAS A PROCESOS

 La Ingeniería del Software se fundamenta en el modelo básico entrada/proceso/salida


de un sistema.
 Estas metodologías se enfocan fundamentalmente en la parte de proceso.
 Utilizan un enfoque de descomposición descendente para evaluar los procesos del
espacio del problema y los flujos de datos con los que están conectados.
 Este tipo de metodologías se desarrolló a lo largo de los años 70.
 Representantes de este grupo son las metodologías de análisis y diseño estructurado
como:
o Merise (Tardieu et al., 1986)
o YSM (Yourdon Systems Method) (Yourdon Inc., 1993)
o SSADM (Structured Systems Analysis and Design Method) (Ashworth y
Goodland, 1990)
o METRICA v.2.1 (MAP, 1995)
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
o METRICA v3.0 (Parcialmente) (MAP, 2001)
METODOLOGÍAS ORIENTADAS A OBJETOS

 Se fundamentan en la integración de los dos aspectos de los sistemas de información:


datos y procesos
 En este paradigma un sistema se concibe como un conjunto de objetos que se
comunican entre sí mediante mensajes.
 El objeto encapsula datos y operaciones
o Este enfoque permite un modelado más natural del mundo real y facilita
enormemente la reutilización del software
 Las metodologías orientadas a objetos acortan la distancia existente entre el espacio de
conceptos (lo que los expertos o usuarios conocen) y el espacio de diseño e
implementación
Evolución de las metodologías OO

METODOLOGÍAS ÁGILES

Las aproximaciones ágiles emplean procesos técnicos y de gestión que continuamente se


adaptan y se ajustan a (Turk et al., 2002)

 Cambios derivados de las experiencias ganadas durante el desarrollo


 Cambios en los requisitos
 Cambios en el entorno de desarrollo
La agilidad en el desarrollo del software no significa únicamente poner en el mercado o en
explotación los productos software más rápidamente

 Esto choca frontalmente con los modelos de procesos tradicionales que son monolíticos
y lentos, centrados en una única iteración o ciclo de larga duración
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
La agilidad significa respuesta efectiva al cambio, pero incluye. Estructuras de equipo y actitudes
para facilitar la comunicación entre los miembros

 Énfasis en la entrega rápida de software funcional, para lo que resta importancia a los
productos intermedios (lo cual siempre no es bueno)
 Adopción del cliente como parte del equipo de desarrollo
 Planificación incierta y, por tanto, flexible
EXTREME PROGRAMMING

Controvertido enfoque de desarrollo de software basado en el modelo incremental. Está


indicado para:

 Equipos de tamaño mediano o pequeño


 Requisitos imprecisos y cambiantes
Características (Beck, 2000)

 El juego de la planificación
 Versiones pequeñas
 Metáfora
 Diseño sencillo
 Hacer pruebas
 Refactorización
 Programación en parejas
 Propiedad colectiva
 Integración continua
 Cliente in-situ
 Estándares de codificación
SCRUM

Define un ciclo de vida iterativo e incremental, que mejora la gestión del riesgo y aumenta la
comunicación

 Propuesto por Jeff Sutherland y desarrollado por Shwaber y Beedle (Schwaber, 1995). El
conjunto de buenas prácticas de Scrum se aplica esencialmente a la gestión de proyecto
 Es un framework, por lo que es necesaria su adaptación en cada organización o incluso
en cada equipo
 El objetivo es obtener resultados rápidos con adaptación a los cambios de las
necesidades de los clientes.
Las principales características de Scrum

 El desarrollo software mediante iteraciones incrementales


 Las reuniones a lo largo del proyecto
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
Se basa en tres pilares:

 Transparencia
o Todos los aspectos del proceso que afectan al resultado son visibles para todos
aquellos que administran dicho resultado
 Inspección
o Se debe controlar con la suficiente frecuencia los diversos aspectos del proceso
para que puedan detectarse variaciones inaceptables en el mismo
 Revisión
o El producto debe estar dentro de los límites aceptables
o En caso de desviación se procederá a una adaptación del proceso y del material
procesado
o Mecanismo de mejora continua, esto es, de control, para adaptarse y mejorar

Roles

Scrum Master. Es el responsable de asegurar que el equipo Scrum siga las prácticas de Scrum.

Sus funciones son:

 Ayudar a que el equipo y la organización adopten Scrum


 Liderar el equipo Scrum para buscar la mejora en la productividad y la calidad de los
entregables
 Ayudar a la autogestión del equipo
 Gestionar e intentar resolver los impedimentos con los que el equipo se encuentra para
cumplir las tareas del proyecto
Product owner. Es la persona responsable de gestionar las necesidades que se quieren satisfacer
mediante el desarrollo del proyecto.

Sus funciones son:

 Recolectar las necesidades (historias de usuario)


 Gestionar y ordenar las necesidades
 Aceptar el producto software al finalizar cada iteración
 Maximizar el retorno de la inversión del proyecto
Equipo de desarrollo. Tiene las siguientes características

 Autogestionado. El mismo equipo supervisa su trabajo (no existe el rol clásico de jefe de
proyecto)
 Multifuncional. Cada integrante del equipo debe ser capaz de realizar cualquier función
 No distribuidos. Es conveniente que el equipo se encuentre en el mismo lugar físico
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
 Tamaño óptimo. Al menos tres personas, máximo nueve, sin contar al scrum master ni
al producto Owner.
Acciones de los patrones de proceso

 Retraso (pila de producto o product backlog): priorización de requisitos. Debe estar


detallado de manera adecuada, estimado, emergente y priorizado.
 Reuniones Scrum: reuniones breves dirigidas por el maestro Scrum.
 Demostraciones preliminares: entrega de un incremento al cliente.
 Sprints: unidades de trabajo requeridas para alcanzar un requisito. Es cada iteración. Se
recomiendan iteraciones cortas (1-4 semanas) y cuyo resultado será un producto
software potencialmente entregable.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
CLASE 4: HERRAMIENTAS CASE

¿QUÉ ES CASE?
CASE (Computer Aided Software Engineering) es un conjunto de herramientas que contiene
programas y aplicaciones informáticas diseñados con la finalidad de generar mayor
productividad, brindar facilidades de uso que ahorran tiempo y dinero en el desarrollo de
softwares o nuevas aplicaciones.
Terminología de la estructura CASE

 CASE de alto nivel: son aquellas herramientas que automatizan o apoyan las fases finales
o superiores del ciclo de vida del desarrollo de sistemas. Ejemplo: La planificación de
sistemas, el análisis de sistemas y el diseño de sistemas.
 CASE de bajo nivel: son aquellas herramientas que automatizan o apoyan las fases finales
o inferiores del ciclo de vida. Ejemplo: El diseño detallado de sistemas, la implantación
de sistemas y el soporte de sistemas.
 CASE cruzado: de ciclo de vida se aplica a aquellas herramientas que apoyan actividades
que tienen lugar a lo largo de todo el ciclo de vida. Ejemplo: La gestión de proyectos y la
estimación.

HERRAMIENTAS CASE
Las herramientas CASE son un conjunto de aplicaciones informáticas, usadas para automatizar
actividades del ciclo de vida de desarrollo de sistemas (SDLC).
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información

Las herramientas CASE son usadas por los directores de proyectos de software, analistas e
Ingenieros para desarrollar sistemas de software.
Finalidad de las herramientas CASE

 Desarrollar softwares de mayor calidad.


 Elaborar software a menor costo y en menor tiempo.
 Desarrollar software que garanticen una programación universal.
 Automatizar el desarrollo de softwares.
El uso de Herramientas CASE acelera el desarrollo del proyecto con tal de producir los resultados
deseados y ayuda a encontrar imperfecciones antes de proseguir con la siguiente etapa del
desarrollo de Software.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información

Componentes de las Herramientas CASE


Las herramientas CASE se pueden dividir en las siguientes partes en base a su uso en una etapa
concreta del SDLC:

 Repositorio (diccionario) donde se almacenan los elementos definidos o creados por la


herramienta, y cuya gestión se realiza mediante el apoyo de un Sistema de Gestión de
Base de Datos (SGBD) o de un sistema de gestión de ficheros.
 Metamodelo (no siempre visible), que constituye el marco para la definición de las
técnicas y metodologías soportadas por la herramienta.
 Carga o descarga de datos, son facilidades que permiten cargar el repertorio de la
herramienta CASE con datos provenientes de otros sistemas, o bien generar a partir de la
propia herramienta esquemas de base de datos, programas, etc. que pueden, a su vez,
alimentar otros sistemas. Este elemento proporciona así un medio de comunicación con
otras herramientas.
 Comprobación de errores, facilidades que permiten llevar a cabo un análisis de la
exactitud, integridad y consistencia de los esquemas generados por la herramienta.
 Interfaz de usuario, que constará de editores de texto y herramientas de diseño gráfico
que permitan, mediante la utilización de un sistema de ventanas, iconos y menús, con la
ayuda del ratón, definir los diagramas, matrices, etc. que incluyen las distintas
metodologías.
¿Cómo se clasifican las herramientas case?

 Herramientas Upper CASE - Las Herramientas Upper CASE se usan en las etapas de
planificación, análisis y diseño del SDLC.
 Herramientas Lower CASE - Las Herramientas Lower CASE se usan en la
implementación, las pruebas y en el mantenimiento.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
La Herramientas CASE se pueden agrupar todas juntas si tienen una funcionalidad similar, y
procesa actividades y la capacidad de integrarse con otras Herramientas.

 Herramientas Integrated CASE - Las Herramientas Integrated CASE son de utilidad en


todas las fases del SDLC, desde la deducción de requisitos y las pruebas hasta la
documentación.
 Juegos de herramientas o Tools-Case, son el tipo más simple de herramientas CASE.
Automatizan una fase dentro del ciclo de vida. Dentro de este grupo se encontrarían las
herramientas de reingeniería, orientadas a la fase de mantenimiento.
La Herramientas CASE se pueden agrupar todas juntas si tienen una funcionalidad similar, y
procesa actividades y la capacidad de integrarse con otras Herramientas.
Alcance de las herramientas, recorre el SDLC.

Casos de Herramientas CASE


Herramienta CASE Diagrama: Estas herramientas se usan para representar componentes del
sistema, datos, y a controlar la fluidez de varios componentes y estructura del software de manera
gráfica.
Herramientas para modelado de procesos: Las herramientas para el modelado de procesos ayudan
a los Directores a escoger un modelo de proceso o para modificarlo según los requerimientos del
producto software
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
Herramientas de administración de procesos: Estas herramientas se usan para la planificación del
proyecto, el coste y esfuerzo estimados, la temporalización y la organización de los recursos.
Herramientas de documentación: Las Herramientas de documentación generan documentos tanto
para el consumidor final como para consumidores de soporte técnico.
Herramientas de análisis: Estas herramientas ayudan a cumplir con los requisitos, de manera
automática examinan si hay alguna inconsistencia, o informaciones no acuradas en los diagramas,
buscan posibles redundancias o omisiones erróneas.
Herramientas de diseño: Estas herramientas ayudan a los diseñadores de software a crear la
estructura de los programas, la cual se puede más adelante desglosar en pequeños módulos usando
técnicas de perfeccionamiento. Estas herramientas aportan los detalles de cada módulo y la
interconexión presente entre estos.
Programming Tools: Estas herramientas constan de entornos de programación como IDE.
(Entorno de desarrollo integrado), módulos integrados biblioteca y herramientas de simulación.
Herramientas de programación: Estas herramientas consisten en entornos de programación como
IDE (Entorno de desarrollo integrado), biblioteca de módulos integrados y herramientas de
simulación.
Herramientas de desarrollo de software: Las Herramientas de modelos de prototipo CASEP,
esencialmente vienen con bibliotecas gráficas. Pueden crear interfaces de usuario independientes
del hardware y diseño.
Herramientas de desarrollo Web: Estas herramientas ayudan en el diseño de páginas Web con
todos los elementos relacionados como impresos, textos, secuencias de comando, gráficos y
demás.
Herramientas de Aseguramiento de la calidad: Las herramientas de Aseguramiento de la calidad,
constan de herramientas de control de cambios y configuración y de herramientas para pruebas
de software.
Herramientas de mantenimiento: Algunas de las herramientas CASE que ayudan en la
organización y la fase de mantenimiento del software del SDLC son las técnicas de inicio
automático y de reporte de error, producción automática de etiqueta de error y de Análisis de
Causa Raíz (ACR o RCA en sus siglas en inglés).
Beneficios de las Herramientas CASE
Entre los beneficios más significativos de las herramientas CASE se enumeran los siguientes:
1. Facilidad para la revisión de aplicaciones: Contar con un depósito central agiliza el
proceso de revisión ya que éste proporciona bases para las definiciones y estándares para
los datos.
2. Soporte para el desarrollo de prototipos de sistemas: Los ajustes necesarios al diseño se
hacen con rapidez para alterar la presentación y las características de la interface.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
3. Generación de código: La generación del código también asegura una estructura estándar
y consistente para el programa (lo que tiene gran influencia en el mantenimiento) y
disminuye la ocurrencia de varios tipos de errores, mejorando de esta manera la calidad.
4. Mejora en la habilidad para satisfacer los requerimientos del usuario: Las herramientas
CASE disminuyen el tiempo de desarrollo, una característica que es importante para los
usuarios.
5. Soporte interactivo para el proceso de desarrollo: Las herramientas CASE soportan pasos
interactivos al eliminar el tedio manual de dibujar diagramas, elaborar catálogos y
clasificar.
Lista de Herramientas CASE
En esta sección se mostrarán las herramientas CASE expuestas, su link a estos productos y con
una breve descripción. Mostrando 20 elementos

Herramienta Descripción
CASE
NetBeans Herramienta muy buena con características buenas como desarrollo
intuitivo gratis y open source drag-and-drop para mayor rapidez
Principalmente para desarrollo de escritorio Web Mobile y enterprise con
compatibilidad con java C/C++ Ruby PHP javascript tiene algunas mejoras
con UML aunque no es el más óptimo tiene algo muy interesante creador
de juegos para celulares
Microsoft Visio Herramienta de diagramación avanzada con gran variedad de plantillas que
permiten simplificar las tareas complejas con elementos visuales dinámicos
basados en datos, UML Bases de Datos Arquitectura ect con SharePoint con
más facilidad sin generar código Pero bastante atractiva para hacer distintos
diagramas
Eclipse/Omondo Eclipse dispone de un Editor de texto. La compilación es en tiempo real.
Tiene pruebas unitarias con JUnit, control de versiones con CVS, Como ya
sabemos código abierto Sobre el cual se pueden montar herramientas de
desarrollo para cualquier lenguaje mediante la implementación de los
plugins adecuados como omondo para la realización de diagramas UML
generando código.
OmniGraffle Es una herramienta de diagramación disponible para OS, muy práctica y
fácil de usar, con muchos elementos que facilitan la creación de DFD. Esta
herramienta brinda la posibilidad de exportar en varios formatos, es
accesible y se puede adquirir directamente en el Appstore
Serena Esta herramienta ayuda en el diseño de la interfaz gráfica y las definiciones
Composer iniciales del sistema, el producto final de este software es un reporte no
funcional que detalla el funcionamiento del sistema y una visión no
funcional del sistema (prototipo) que no puede ser reutilizado para la etapa
de desarrollo.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
Erwin Esta herramienta es de las más eficientes y completas, para la tarea de
realizar ingeniería inversa esta herramienta es sumamente sencilla, basta
con darle la orden, no hubo mucho que explicar pues es realmente sencilla.
GUI Design Es una herramienta enfocada solamente en el diseño de interfaces gráficas
Studio para aplicaciones, es muy sencillo de usar y contiene muchos elementos
para modelar pantallas de aplicaciones botones, cajas de texto, contraseñas,
tablas, iconos y es capaz de simular el paso de ventanas.
Eclipse Indigo Para la generación de diagramas de clases en Eclipse se necesita un plug-
*Plug-in "UML in, este tiene una facilidad de uso muy buena y es fácil de realizar diagramas
2 Tools" de Clases con todos los atributos necesarios.
Expression Esta herramienta de Microsoft permite hacer páginas web muy fácil ya que
Web 4 no es necesario meterse al código HTML, si no permite seleccionar los
elementos de una paleta y solo arrastrarlos para crear nuestra página.
Permite el uso de código PHP para hacer aplicaciones Web poderosas.
Edraw Es un programa muy completo para realizar diferentes tipos de diagramas
de varias metodologías, Es muy sencillo de usar ya que tiene una interfaz
muy parecida a la de Microsoft Visio.
ERwin Esta herramienta es muy eficaz cuando se busca hacer el diseño de una Base
de Datos ya que permite crear paralelamente el modelo físico y lógico de la
BD. Así mismo permite crear Triggers, Indices Stored Procedures, en
bastantes Manejadores de Base de Datos tanto para hacer una ingeniería
inversa o pasar el diseño a un manejador.
MOCKFLOW Herramienta CASE enfocada a la etapa de diseño ya sea web, móvil o
desktop. Tiene servicio en la nube.
yUML Herramienta CASE enfocada a diagramación de UML, servicio de la nube,
con diagramas de clase, actividad y casos de uso.
Oracle SQL Herramienta CASE especializada en Base de Datos, tiene varios módulos
Developer de modelado de datos entre otras y tiene compatibilidad con distintos
manejadores de Base de Datos.
DIA Es una herramienta CASE (proyecto de GNOME) tanto enfocada para
UML como para Base de Datos.
CASE Studio 2 es una herramienta case que es principalmente orientada al diseño y
modelado de diagramas de entidad relación.
SQL server herramienta para realizar ingeniería inversa

EASY CASE herramienta para realizar de análisis y diseño.


Poseidon herramienta para realizar diagramas UML.
Sharepoint plataforma de Microsoft de colaboración empresarial, funciones de
workflow colaboración, basado en el explorador web, módulos de administración de
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
proceso, módulos de búsqueda y una plataforma de administración de
documento
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
CLASE 5: ATRIBUTOS DE UN BUEN SOFTWARE

¿CUÁLES SON LOS ATRIBUTOS DE UN BUEN


SOFTWARE?
¿Qué son los atributos de calidad?
Un atributo de calidad es una propiedad medible de un sistema, que indica qué tan bien el sistema
lisonjear las necesidades de las partes interesadas. También conocidos como:

 Requerimientos no funcionales.
 Características de arquitectura.
 Propiedades de calidad.

Listado de atributos de calidad


No existe una lista definitiva de atributos. Sin embargo, hay algunos que son mucho más comunes
que otros.
1. Desplegabilidad (facilidad de despliegue).
2. Disponibilidad.
3. Escalabilidad.
4. Interoperabilidad.
5. Modificabilidad.
6. Rendimiento.
7. Seguridad.
8. Testeabilidad (facilidad de probar el sistema).
9. Usabilidad.
Otros pueden ser:
1. Accesibilidad.
2. Adaptabilidad.
3. Agilidad.
4. Confiabilidad.
5. Cumplimiento de estándares
6. Distribución del desarrollo. Elasticidad.
7. Extensibilidad.
8. Facilidad de desarrollo.
9. Facilidad de instalación (installability).
10. Factibilidad.
11. Internacionalización (i18n).
12. Localización (l10n).
13. Marketeabilidad (de marketing o mercado)
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
14. Mantenibilidad.
15. Movilidad.
16. Modularidad.
17. Monitoreabilidad.
18. Portabilidad.
19. Recuperabilidad.
20. Reusabilidad.
21. Tolerancia a fallos.
22. Variabilidad.
La familia de normas ISO/IEC 25000
Esta familia es el resultado de la evolución de otras normas anteriores, especialmente de las
normas ISO/IEC 9126, describen las particularidades de un modelo de calidad del producto
software abordando el proceso de evaluación de productos software.

Listado de atributos de calidad validados por el modelo de calidad ISO25010:


UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información

Compatibilidad
Capacidad de dos o más
sistemas o componentes
para intercambiar
Interoperabilidad:
información y/o llevar a Coexistencia: Estar en un
Facilidad de
cabo sus funciones contexto con otros
comunicación con
requeridas cuando sistemas.
componentes externos.
comparten el mismo
entorno hardware o
software.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información

Usabilidad
Capacidad del Protección
Reconocimiento Estética de la
producto contra errores Accesibilidad:
de idoneidad: Capacidad de Capacidad para interfaz de
software para de usuario: Capacidad del
Capacidad del aprendizaje: ser usado: usuario:
ser entendido, Capacidad del producto que
producto que Capacidad del Capacidad del Capacidad de la
aprendido, sistema para permite que sea
permite al producto que producto que interfaz de
usado y resultar proteger a los utilizado por
usuario permite al permite al usuario de
atractivo para el usuarios de usuarios con
entender si el usuario usuario operarlo agradar y
usuario, cuando hacer errores y determinadas
software es aprender su y controlarlo con satisfacer la
se usa bajo de darle características y
adecuado para aplicación. facilidad interacción con
determinadas FeedBack sobre discapacidades.
sus necesidades. el usuario.
condiciones. los mismos.

Fiabilidad / Confiabilidad
Capacidad de
recuperación:
Capacidad de un
Tolerancia a fallos: Capacidad del
sistema o Madurez: Disponibilidad:
Capacidad del producto software
componente para Capacidad del Capacidad del
sistema o para recuperar los
desempeñar las sistema para sistema o
componente para datos
funciones satisfacer las componente de
operar según lo directamente
especificadas, necesidades de estar operativo y
previsto en afectados y
cuando se usa bajo fiabilidad en accesible para su
presencia de fallos reestablecer el
unas condiciones y condiciones uso cuando se
hardware o estado deseado
periodo de tiempo normales. requiere.
software. del sistema en caso
determinados.
de interrupción o
fallo.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información

Adecuación Funcional
Representa la
capacidad del
producto software Pertinencia funcional:
Completitud Corrección funcional:
para proporcionar Capacidad del
funcional: Grado en Capacidad del
funciones que producto software
el cual el conjunto de producto o sistema
satisfacen las para proporcionar un
funcionalidades cubre para proveer
necesidades conjunto apropiado
todas las tareas y los resultados correctos
declaradas e de funciones para
objetivos del usuario con el nivel de
implícitas, cuando el tareas y objetivos de
especificados. precisión requerido.
producto se usa en las usuario especificados.
condiciones
especificadas.

Eficiencia de desempeño
Comportamiento
temporal: Los tiempos
de respuesta y
Esta característica Utilización de recursos:
procesamiento y los Capacidad: Grado en
representa el Las cantidades y tipos
ratios de throughput de que los límites máximos
desempeño relativo a la de recursos utilizados
un sistema cuando lleva de un parámetro de un
cantidad de recursos cuando el software lleva
a cabo sus funciones producto o sistema
utilizados bajo a cabo su función bajo
bajo condiciones software cumplen con
determinadas condiciones
determinadas en los requisitos.
condiciones. determinadas.
relación con un banco
de pruebas (benchmark)
establecido.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información

Seguridad
No repudio:
Integridad: Capacidad de
Capacidad de Confidencialidad:
Capacidad del demostrar las
protección de la Capacidad de
sistema o acciones o Responsabilidad: Autenticidad:
información y los protección contra
componente para eventos que han Capacidad de Capacidad de
datos de manera el acceso de
prevenir accesos tenido lugar, de rastrear de forma demostrar la
que personas o datos e
o modificaciones manera que inequívoca las identidad de un
sistemas no información no
no autorizados a dichas acciones o acciones de una sujeto o un
autorizados no autorizados, ya
datos o eventos no entidad. recurso.
puedan leerlos o sea accidental o
programas de puedan ser
modificarlos. deliberadamente.
ordenador. repudiados
posteriormente.

Mantenibilidad
Analizabilidad: Capacidad para ser
Esta característica Modularidad:
Facilidad con la que Capacidad para ser probado: Facilidad
representa la Capacidad de un
se puede evaluar el modificado: con la que se
capacidad del sistema o programa Reusabilidad:
impacto de un Capacidad del pueden establecer
producto software de ordenador Capacidad de un
determinado producto que criterios de prueba
para ser modificado (compuesto de activo que permite
cambio sobre el permite que sea para un sistema o
efectiva y componentes que sea utilizado en
resto del software, modificado de componente y con
eficientemente, discretos) que más de un sistema
diagnosticar las forma efectiva y la que se pueden
debido a permite que un software o en la
deficiencias o eficiente sin llevar a cabo las
necesidades cambio en un construcción de
causas de fallos en introducir defectos pruebas para
evolutivas, componente tenga otros activos.
el software, o o degradar el determinar si se
correctivas o un impacto mínimo
identificar las desempeño. cumplen dichos
perfectivas. en los demás.
partes a modificar. criterios.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información

Portabilidad
Adaptabilidad:
Capacidad para ser
Capacidad del
Capacidad para ser reemplazado:
Facultad del producto producto que le
instalado: Facilidad Capacidad del
o componente de ser permite ser adaptado
con la que el producto para ser
transferido de forma de forma efectiva y
producto se puede utilizado en lugar de
efectiva y eficiente de eficiente a diferentes
instalar y/o otro producto
un entorno hardware, entornos
desinstalar de forma software
software, operacional determinados de
exitosa en un determinado con el
o de utilización a otro. hardware, software,
determinado entorno. mismo propósito y en
operacionales o de
el mismo entorno.
uso.

PREGUNTAS DE RETROALIMENTACIÓN
1. ¿Cómo influyó el trabajo de Takeuchi y Nonaka, especialmente su introducción de
conceptos como agilidad, flexibilidad y colaboración multidisciplinaria, en la evolución
de la gestión de proyectos y áreas empresariales?

Da a conocer una nueva forma de gestionar proyectos en la que la agilidad, flexibilidad,


y la incertidumbre son los elementos principales.

2. Entre los roles de Scrum: ¿Quién es el Product Owner?

Es el encargado de comprobar que el modelo y la metodología funciona.

3. ¿Qué objetivo tiene la revisión del Backlog durante la fase de Sprint cero en el proceso
de preparación del proyecto?

Seleccionar de la lista Backlog del producto las funcionalidades sobre las que se va a
trabajar.

4. ¿Cuál es la finalidad de la Reunión de Planificación al inicio de cada Sprint en Scrum?


Su finalidad es de realizar una reunión, el Scrum Master y el equipo, con la intención de
seleccionar de la lista Backlog del producto las funcionalidades sobre las que se va a
trabajar.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información

5. ¿Cuál es el objetivo principal de la Reunión de Retrospectiva del Sprint?

Debatir temas relacionados con el Sprint recientemente finalizado y los cambios que se
podrían hacer para mejorar el próximo Spring y que sea más productivo.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
CLASE 6: RETOS FUNDAMENTALES INGENIERIA
SOFTWARE
¿CUÁLES SON LOS RETOS FUNDAMENTALES A LOS
QUE SE ENFRENTA LA INGENIERÍA DE SOFTWARE?
Un proceso tan laberintico como el desarrollo de un producto de software conlleva su propio
conjunto de retos, retos que puedes encontrar cada día.
Actualmente solo un 12% de los proyectos de software se terminan a tiempo previsto con el coste
estimado. Frente al 78% de los proyectos realizados en el seno de la ingeniería tradicional que lo
hicieron en tiempo y presupuesto. Curiosamente 90% de los proyectos de software que acabaron
en tiempo y presupuesto usaron métodos y herramientas de Ingeniera del software.

 El reto de la heterogeneidad: Desarrollar técnicas para construir software confiable que


sea lo suficientemente flexible para adecuarse a esta heterogeneidad.
 El reto de la entrega: Reducir los tiempos de entrega para sistemas grandes y complejos
sin comprometer la calidad del sistema.
 El reto de los sistemas legados: Sistemas añosos que tienen en funcionamiento un cliente
(un negocio) y que debe ser mantenidos y mejorados.

Muchas empresas poseen sistemas e infraestructuras heredadas, donde han invertido


muchísimos recursos financieros para mantenerlos. Por esta razón, es probable que se
vean reticentes a reemplazarlos por otros más nuevos, incluso si pudiese significar la
mejora en el flujo de trabajo o si ya no cumplen con sus expectativas.

 El reto de la confianza: Desarrollar técnicas que demuestren que los usuarios pueden
confiar en el software, es esencial que podamos confiar en el software desarrollado o
adquirido.
 El reto de la Formalidad: Existe una gran deprecación de que exista formalidad en el
proceso de desarrollo de software.
RETOS A LOS QUE SE ENFRENTA TODO
DESARROLLADOR DE PRODUCTOS DE SOFTWARE
1. Infraestructura del proyecto: Si el entorno no está disponible, no hay forma de seguir
adelante con el proyecto a tiempo y bajo presupuesto. Para garantizar un desarrollo
eficiente del proyecto, los entornos de prueba y preproducción deben estar disponibles
durante las fases de desarrollo, pruebas y pruebas de aceptación del usuario (UAT).

2. Expectativas de desarrollo y resultados: Una de las principales razones de la complejidad


de los proyectos de software es el cambio constante de los requisitos. Una solución sería
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
establecer un proceso y una línea de comunicación sólidos para garantizar que los
resultados del producto se ajustan a las expectativas y los requisitos.

3. Garantía de calidad: No revisar el código, o suprimir los errores, es un medio que utilizan
los desarrolladores para ahorrar tiempo y cumplir los plazos. Es imprescindible seguir un
proceso formal de garantía de calidad.

4. Normas de calidad no definidas: La identificación de defectos es inevitable durante las


pruebas de funcionalidad, aunque el producto haya sido sometido a pruebas unitarias
exhaustivas durante la fase de desarrollo. Se recomienda que cuando elabores el enfoque
de las pruebas, los escenarios, las condiciones, los casos y los guiones, asegúrate de que
tu plan de pruebas cubre todos los requisitos que se van a entregar, planificando varios
ciclos de pruebas

5. Adaptar las últimas tendencias del mercado: Adaptarse a los últimos requisitos
tecnológicos, como mobile-first o mobile-only o desktop-first, suele ser un reto.
Asegúrate estar al día de las tendencias del mercado y explorar las nuevas tecnologías y
tendencias que existen.

6. Influencias en el diseño: Los diseños de los productos están bajo la influencia constante
de las partes interesadas, la organización de desarrollo y otros factores internos y
externos. Refuerza la racionalización de tu diseño, ofrece una experiencia coherente en
todos los dispositivos, sistemas operativos y factores de forma.

7. Integración de sistemas y aplicaciones: La integración de aplicaciones de terceros o de


otras aplicaciones personalizadas, como tus sistemas ERP, tu sitio web o tu base de datos
de gestión de inventarios, añade una complejidad considerable a tu proyecto. Para adaptar
tu solución de software debes:

 Comprender claramente los requisitos del usuario final.


 Implementar un marco de trabajo para toda la empresa para la estructura de la
plataforma de la aplicación.
 Descubrir e investigar nuevas tecnologías.
 Diseñar y desarrollar nuevas soluciones.
 Probar y evaluar las ideas para garantizar una integración óptima.
 Presta especial atención a la investigación y el desarrollo, las pruebas y la
creación de prototipos.
 Probar, probar y volver a probar antes de desplegar la solución

8. Gestión de proyectos: Muy a menudo la multitarea puede dar más problemas de los
previstos. Los recursos no pueden centrarse en una sola tarea o módulo si su jefe les
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
bombardea con tareas. Aprovechar las herramientas de gestión de proyectos y mantener
los proyectos, los recursos y los equipos organizados y encaminados es una manera de
ser un excelente planificar.
Para ser exitosos hoy en día con el desarrollo de software es importante tener
conocimientos sobre gestión de proyectos. Saber realizar un contrato, manejar pagos,
clientes, expectativas, equipos y más es parte del trabajo que va de la mano con el
desarrollo de software.

9. Duplicación del entorno de pruebas: Probar un sistema de software en un entorno


controlado es difícil, ya que el usuario no está inmerso en una situación de trabajo
completamente realista. Para ver lo que funciona bien y lo que funciona mal en un vacío
frente al uso en la vida real el software, la aplicación o el producto debe ser probado en
un entorno de prueba independiente de la vida real.

El desarrollo de software es algo que requiere del cuidado de muchísimos detalles para
que todo fluya y no ocurran errores. Es por ello que se deben hacer muchísimas pruebas
y correcciones a fin de satisfacer al cliente. Además, esto debe ocurrir a medida que se va
creando el software para estar seguros de que todo va por buen camino y de que no hay
que comenzar desde cero ya muy avanzado en el camino.

10. Infraestructura de seguridad: Los fallos de seguridad van en aumento; un estudio reciente
estima que el 96% de todas las aplicaciones web contienen al menos una vulnerabilidad
grave. La seguridad no es sólo responsabilidad del ingeniero de software, sino también
de todas las partes implicadas.

 Mira más allá de la tecnología para mejorar la seguridad de tu software.


 Desarrolla el software utilizando lenguajes de programación de alto nivel con
características de seguridad incorporadas.
 Exige actividades de garantía de seguridad, como pruebas de penetración y
revisión del código.
 Realiza actividades esenciales para producir aplicaciones y sistemas seguro.

OTROS RETOS:
1. Mayor competencia en el sector: La creciente globalización ha hecho que la competencia
sea mayor. Una idea que tenga un desarrollador de software pudiese estarla teniendo
también otra persona, equipo o empresa en otro lugar del mundo. Quizás hasta ya tienen
un prototipo en marcha.
2. Sistemas SaaS: “un sistema SaaS o Software as a Service, es un modelo de distribución
de software en el que tanto el software como los datos manejados son centralizados y
alojados en un único servidor externo a la empresa. Esto implica que el software utilizado
por la empresa no se encuentra en la misma, sino que un proveedor se ocupa del hosting
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
de dicho software en la nube, así como del mantenimiento y el soporte” según sitio web
IEB School.

Este tipo de software permite a las Pymes acceder a excelentes funcionalidades a un


menor costo y es cada vez más utilizado.

3. Encontrar profesionales experimentados: Poder encontrar profesionales con la


experiencia requerida para afrontar los retos del puesto de trabajo es un gran desafío.
Mientras más complejo es el proyecto, mayor la experiencia que los miembros del equipo
de desarrollo de software deberán tener.
4. Diferentes niveles de usuario: Determinar derechos de acceso, permisos, entre otros para
usuarios, puede hacer que el despliegue se convierta en algo complicado.
5. Integraciones con otros desarrollos: Hoy en día, los desarrolladores no pueden pensar en
soluciones independientes, es importante que busquen integrarse con terceros, lo que es,
claramente, otro desafío hoy en día.

PREGUNTAS DE EXPOSICIÓN
1. ¿En qué principios clave se basa la programación extrema?

 JUEGO DE PLANEAMIENTO: Determina el alcance de la próxima liberación,


mediante la combinación de prioridades del negocio y estimaciones.
 PEQUEÑAS LIBERACIONES: Colocar un sistema simple en producción
rápidamente para luego liberar nuevas versiones.
 METÁFORA: Guía de todo el desarrollo con una historia simple y compartida
de cómo funciona todo el sistema.
 DISEÑO SIMPLE: El sistema deberá ser diseñado tan simple como sea posible
en cada momento.
 PRUEBAS: Debe correr sin problemas para que el desarrollo continúe.
 REFACTORIZACIÓN: Los programadores reestructuran el sistema sin cambiar
su comportamiento.
 PROGRAMACIÓN EN PARES: El código de producción es escrito por dos
programadores.

2. Identifique los principios faltantes del Extreme Programming, de la siguiente figura:


UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información

40 horas semanales, Pruebas

3. ¿Cuántos pasos tiene el ciclo recomendado por TDD (Desarrollo dirigido por prueba)?

El ciclo recomendado por TDD tiene 5 pasos:


1.Escribir una primera prueba
2.Comprobar que falla
3.Escribir el código mínimo necesario para pasar la prueba
4.Comprobar que pasa la prueba
5.Realizar la refactorización del código

4. ¿A que nos referimos cuando hablamos de comunicación y colaboración efectiva?

Programación efectiva.

5. Seleccione las ventajas que tiene el Extreme Programming

ENTREGA TEMPRANA DE SOFTWARE FUNCIONAL: Promueve la entrega


temprana y frecuente de software funcional, los equipos de XP desarrollan software
funcional desde las etapas iniciales del proyecto.

ADAPTABILIDAD A LOS CAMBIOS: El XP se destaca por su capacidad para adaptarse


rápidamente a los cambios en los requisitos y las circunstancias.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
COMUNICACIÓN Y COLABORACIÓN EFECTIVAS: La comunicación constante
ayuda a garantizar que todos los involucrados tengan una comprensión clara de los
objetivos del proyecto.

CALIDAD Y EFICIENCIA MEJORADAS: A través de prácticas como la programación


en parejas, los equipos de XP pueden identificar y resolver problemas de manera
temprana.

RETROALIMENTACIÓN CONSTANTE DEL CLIENTE: Permite ajustar el rumbo del


proyecto de manera oportuna y garantiza que el producto final cumpla con las
expectativas del cliente.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
CLASE 8: INTRODUCCIÓN A LOS MODELOS AGILES
En un proceso ágil se busca entregar software totalmente funcional en cada interacción
independientemente de su interfaz, lo que comúnmente se conoce como “funcionalidades
primero”.
En sus inicios, eran sistemas más cortos en el tiempo, con gran capacidad de procesamiento y
funcionalidades, aunque redujeron algunos procesos, presentaron inconsistencias en cuanto a la
capacidad de adaptación y los cambios de especificaciones particulares que se requerían. [2]
Con el tiempo, emergió el desarrollo de sistemas más cortos en el tiempo, con gran capacidad de
procesamiento y funcionalidades, este desarrollo de software se conoció como “métodos rápidos”
que logro incluir una gran cantidad de tareas, estructuras, avance interactivo, aplicaciones rápidas,
entre otras.
El punto de partida es fue el Manifiesto Ágil, que resume la filosofía ágil, según el Manifiesto se
valora:

 Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las


herramientas, es más importante construir un buen equipo que construir el entorno.
 Desarrollar software que funciona más que conseguir una buena documentación, el
objetivo es no producir documentos a menos que sean necesarios en la toma de una
decisión.
 La colaboración con el cliente más que la negociación de un contrato, esta colaboración
será la que marque la marcha del proyecto y asegure su éxito.
 Responder a los cambios más que seguir estrictamente un plan, la habilidad de responder
a los cambios que puedan surgir a lo largo del proyecto determina también el éxito o
fracaso del mismo.

Los principios de la Metodología Ágil:

 La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de software


que le aporte un valor.
 Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una
ventaja competitiva.
 Entregar frecuentemente software que funcione con el menor intervalo de tiempo posible
entre entregas.
 La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto.
 Construir el proyecto en torno a individuos motivados.
 La comunicación cara a cara es el método más eficiente y efectivo para comunicar
información dentro de un equipo de desarrollo.
 El software que funciona es la medida principal de progreso.
 Los procesos ágiles promueven un desarrollo sostenible, promueve la paz entre los
promotores, desarrolladores y usuarios.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
 La atención continua a la calidad técnica y al buen diseño mejora la agilidad.
 La simplicidad es esencial.
 Las mejores arquitecturas, requisitos y diseños surgen de los equipos organizados por sí
mismos.
 En intervalos regulares, el equipo reflexiona respecto a cómo llegar a ser más efectivo.
Ventajas de la metodología ágil:

 Mejora de la calidad del producto: Estas metodologías fomentan el enfoque proactivo


de los miembros del equipo en la búsqueda de la excelencia del producto.
 Mayor satisfacción del cliente: El cliente está más satisfecho al verse involucrado y
comprometido a lo largo de todo el proceso de desarrollo.
 Mayor motivación de los trabajadores: Los equipos de trabajo autogestionados,
facilitan el desarrollo de la capacidad creativa y de innovación entre sus miembros.
 Trabajo colaborativo: La división del trabajo por distintos equipos y roles junto al
desarrollo de reuniones frecuentes, permite una mejor organización del trabajo.
 Uso de métricas más relevantes: Las métricas utilizadas para estimar parámetros como
tiempo, coste, rendimiento, etc. son normalmente más reales en proyectos ágiles que en
los tradicionales.
 Mayor control y capacidad de predicción: La oportunidad de revisar y adaptar el
producto, esto permite a todos los miembros del proyecto ejercer un mayor control sobre
su trabajo.
 Reducción de costes: La gestión ágil del proyecto elimina prácticamente la posibilidad
de fracaso absoluto en el proyecto, porque los errores se van identificando a lo largo del
desarrollo en lugar de esperar a que el producto esté acabado y toda la inversión realizada.
Desventajas de la metodología ágil:

 Modificación: ha sido modificado por muchas organizaciones.


 Incorporación: su incorporación de las pruebas y las operaciones entre los desarrolladores
y el lado empresarial, ha sido menos exitoso.
 falta de énfasis en la tecnología, lo que puede dificultar la venta del concepto a los altos
directivos que no comprenden el papel que juega la cultura en el desarrollo de software.

DESARROLLO ÁGIL
Es la identificación de oportunidades comerciales en cada proyecto potencial, estimación del
tiempo y el trabajo que se requerirá para completar el proyecto.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información

INICIO: se identifican los miembros


del equipo, se establece la
financiación y se discuten los
requisitos iniciales con el cliente.

ITERACIÓN/CONSTRUCCIÓN: Es cuando los


LA JUBILACIÓN: Incorpora todas las
equipos comienzan a crear software de
actividades de fin de ciclo, como notificar a
trabajo basado en los requisitos y la
los clientes y la migración final.
retroalimentación continua.

LA LIBERACIÓN / LANZAMIENTO: implica la


LA PRODUCCIÓN: Los equipos de desarrollo prueba de garantía de calidad final, la
deben mantener el software funcionando resolución de cualquier defecto restante, la
sin problemas y al mismo tiempo enseñar a finalización del sistema y la documentación
los usuarios exactamente cómo usarlo. del usuario y, al final, la liberación de la
iteración final a producción.

El ciclo de Desarrollo de Software Ágil

AGILIDAD Y EL COSTO DEL CAMBIO


AGILIDAD

 Un equipo ágil es un equipo diestro que reacciona apropiadamente al cambio.


 Los cambios están siempre presentes: cambios en el software a construir, en los miembros
del equipo, en la tecnología o cambios de otro tipo que tienen repercusión en el proyecto
o en el producto.
COMUNICACIÓN

 La agilidad también fomenta actitudes y estructuras grupales que facilitan la


comunicación (entre integrantes del equipo, entre tecnólogos y ejecutivos, y entre
ingenieros de software y gerentes).
PLANIFICACIÓN
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
 La agilidad reconoce que la planificación bajo condiciones de incertidumbre tiene sus
límites y el plan de un proyecto debe ser flexible.
 La agilidad puede aplicarse a un proceso de software siempre y cuando el proceso permita
al equipo adaptar tareas y hacerlas más eficientes.
 La agilidad puede aplicarse a un proceso de software siempre y cuando:
o La planificación debe comprender la fluidez del enfoque ágil.
o Dejar sólo los productos de trabajo que sean esenciales y concisos.
o El cliente reciba software funcional de forma incremental lo más rápido posible
para el tipo de producto y ambiente de operación.
EL COSTO DEL CAMBIO

 Es un hecho que el costo del cambio se incrementa de forma no lineal conforme el


proyecto progresa.
 Los partidarios del desarrollo ágil argumentan que un proceso ágil bien diseñado permite
la incorporación tardía de cambios sin impacto drástico en tiempo y costo.
TIPO DE COSTOS DE CAMBIO

 Costes de búsqueda: Sea un producto, un servicio, una marca o un proveedor, si vamos


a cambiarlo, tenemos que buscar otro.
 Penalización: Un ejemplo de penalización habitual son los contratos de permanencia que
imponen muchas empresas.
 Coste de insatisfacción: Puede pasar que cambiemos de producto o servicio y el nuevo
no nos deje igual de satisfechos que el anterior.
 Coste de aprendizaje: Cambiar a un nuevo producto o servicio supone comenzar a usar
algo nuevo, aunque sea similar y de la misma familia que el anterior.
 Coste de equipamiento: El hecho de adquirir determinados productos y servicios,
implica que tenemos que comprar otros productos para poder usarlos.
 Coste de instalación: Dependiendo del tipo de producto, es posible que requiera
determinada instalación.
 Coste económico: Cambiarnos a otro producto o servicio puede suponer pagar más por,
lo que ya implica un detrimento económico.
LA AGILIDAD Y EL COSTO DEL CAMBIO

 El software está sujeto a cambios, el cambio tiene un costo de tiempo de trabajo debido
al talento humano expuesto en estos cambios y también un costo monetario.
 Cuando existe un cambio grande, el equipo debe replantear el diseño del software, esto
constituye mucho tiempo y esfuerzo, haciendo cambios de manera tardía reduce
significativamente el incremento del costo.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información

CURVA IDEAL COSTO-TIEMPO PARA DESARROLLO ÁGIL


UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
CLASE 9: ¿QUÉ SON LOS PROCESOS ÁGILES?
En el año 1999 Kent Beck publica un libro que cambiará los métodos de organización en el trabajo
para siempre. Se trata de “Programación extrema explicada, aceptando el cambio”. En este libro
Beck asienta las bases de lo que será la Agilidad con conceptos como entrega de valor continua,
adaptación permanente o métodos de trabajo Ágiles.
Dos años después, en 2001, el mismo Beck convoca a otros 16 analistas en Snowbird, Utah. El
fin era mejorar los procesos de software y rebatir los principios de los métodos formales,
incapaces de aportar soluciones al sector del software.
El resultado fueron los principios del Manifiesto Ágil, que darían origen al concepto formal de
Agilidad y a las múltiples metodologías que se basan en los preceptos de Beck.

El proceso ágil es también conocido como metodología liviana, esto es debido a que con este tipo
de metodologías se intenta que el grupo de desarrolladores se libre de actividades consideradas
como tortuosas, de modo que se intensifiquen las actividades más importantes enfocándose en el
cliente, el equipo de trabajo y los resultados del sistema.

ANÁLISIS,DISEÑO Y
CONSTRUCCIÓN: REQUERIMENTOS:
Estas 3 actividades a Los requeriminetos y
pesar de que se prioridades del
realicen de manera cliente siempre
correcta no siempre cambian.
son predecibles.

DISEÑO Y CONSTRUCCIÓN:
Existe el problema de no
saber a ciencia ciertacuanto
se debe diseñar el software
antes de su construcción.

Las 3 suposiciones clave de los proyectos de software


Un proceso ágil debe ser incrementalmente adaptable, es decir, la constante comunicación con el
cliente y los cambios que este requiera no afectan al equipo de trabajo y por tanto no afectan al
sistema.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
Para que un proceso sea ágil se necesitan 3 elementos importantes:

 Principios de desarrollo
 Políticas de desarrollo
 Factor humano

PRINCIPIOS
1. La prioridad es satisfacer al cliente.
2. Los cambios son bien vistos en etapas avanzadas.
3. Se hace entrega de un software que funcione cada vez mejor.
4. Todo el equipo y el cliente trabajaban conjuntamente.
5. Deber haber motivación.
6. El mejor método para el entendimiento es la comunicación cara a cara.
7. Un avance es un software que funcione.
8. Los procesos ágiles promueven el desarrollo.
9. La excelencia tecnica y el buen diseño mejora la agilidad.
10. Es esencial la simplicidad.
11. Se necesita organización de equipo para que haya mejoras.
12. Se reflexiona sobre cómo ser eficaz.
POLÍTICAS DE DESARROLLO
Por su puesto que ser ágil, nunca es una desventaja, pero ¿ser ágil conlleva también ser
organizado? , la respuesta es: NO, se necesitan ideas y políticas que deben asumir los
desarrolladores para crear un software que sea llevado a la perfección y entregado en el momento
adecuado.
FACTOR HUMANO
El factor humano se fija mucho en las características de cada uno de los personajes que intervienen
en el desarrollo de software y estas se explican a continuación:

 Competencia: Es el conocimiento o lo que sabe hacer cada uno de los miembros del
equipo de desarrollo.
 Enfoque común: La meta que tienen en común es la satisfacción del cliente, para esto se
debe adaptar el software continuamente.
 Colaboración: Todos los participantes deben colaborar en el entendimiento de los
requerimientos y todos deben proporcionar información.
 Capacidad para resolver problemas difusos: El equipo debe poder resolver un problema
de la manera más pronta posible.
 Habilidad para tomar decisiones: Las decisiones son tomadas en conjunto.
 Confianza y respeto mutuos: Debe existir confianza y respeto entre todos los miembros
del grupo de trabajo.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
 Organización propia: El equipo debe adaptarse al ambiente, los cambios, los
requerimientos, entre otros aspectos.

MODELOS DE DESARROLLO ÁGIL


Las metodologías ágiles han venido para irrumpir en la gestión empresarial… La ingeniería 4.0 y
el imparable desarrollo de los procesos en el entorno digital han derivado en un enfoque que
permite ejecutar cualquier proyecto a partir de etapas de corta duración según distintas iteraciones.

•Es una filosofia:


•Por lo tanto tiene características y normas o lineamientos.

¿QUÉ ES? •¿Cuáles son los lineamientos?


•La comunicación con con el cliente y el equipo es primordial y constante.
•La entrega debe ser rápida pero de calidad.

•Los ingenierios de software (Desarrolladores,


programadores, etc)
¿QUIÉN LO HACE? •Los gerentes.
•El usuario final, etc.

•Por que se necesita una evolución pronta del sistema.


¿POR QUÉ ES •Porque se necesita participación de todo el equipo de
trabajo.
IMPORTANTE?

•Se siguen utilizando las 5 actividades estructurales.


¿CUALES SON LOS •Las tares deben ser minizadas enfocandose en la
construcción y entrega.
PASOS?

•Es el incremento del software en la fecha acordada.


¿CUAL ES EL
PRODUCTO FINAL?
Invención Propia
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información

Scrum
Se trata de un método indicado para solventar problemas complejos y se basa en procesos
empíricos de control.
Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas para
trabajar colaborativamente, en equipo, y así obtener el mejor resultado posible de un proyecto. Se
realizan entregas parciales y regulares del producto final, priorizadas por el beneficio que aportan
al receptor del proyecto. Por ello, Scrum está especialmente indicado para proyectos en entornos
complejos, en los que se necesita obtener resultados inmediatos y en los que los requisitos son
cambiantes o poco definidos. En definitiva, donde la innovación, competitividad, flexibilidad y
productividad son fundamentales.
Cuenta con dos tipos de enfoque:

 Iterativo: en cada sprint se genera una nueva versión del producto que mejora la versión
del sprint anterior. Se trata de ir refinando y mejorando las propiedades del producto
conforme avanza el proyecto.
 Incremental: en cada periodo de tiempo corto se van añadiendo nuevas características al
producto.
Por otra parte, en un proyecto ágil bajo metodología Scrum se distinguen tres roles:

 Product Owner,
 Scrum Master
 equipo de desarrollo

XP
Es una metodología ágil exclusiva para el desarrollo de software. Sus siglas provienen de Extreme
Programming y, al igual que Scrum, contempla cambios frecuentes e iteraciones relativas a cortos
periodos de tiempo.
La metodología XP define cuatro variables para cualquier proyecto de software. Estas son las
siguientes:

 Coste
 Tiempo
 Calidad
 Alcance
Según el método, de estas cuatro variables, tres pueden ser fijadas por actores externos al equipo
de desarrollo. Es decir, por los clientes o por los responsables de proyectos. El restante debe ser
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
establecida por el mismo departamento, que fija su valor en función de las otras. El objetivo de
esto es intentar alcanzar un equilibrio entre las cuatro variables.
Kanban
Esta metodología consiste en la organización del trabajo diario en base a un panel de tareas. No
propone cambios en las prácticas de ingeniería ni una nueva definición de proceso o estilo de
trabajo. En cambio, se diseña para evitar la sobreproducción y para asegurarse de que los
componentes pasan de un subproceso al siguiente en el orden adecuado.
Uno de las principales ventajas de Kanban es la transparencia sobre el proceso. Esto se consigue
con el tablero Kanban, el cual muestra en un vistazo el estado del trabajo actual según las etapas
del ciclo de trabajo que se definan.
“Imagina que cada una de estas etapas representa un carril y son 3: Por hacer, haciendo y
finalizado. Es decir que el trabajo por hacer entra por la izquierda y una vez es terminado, sale
por la derecha.”
Adivina qué va en cada carril según su estado actual, exacto, ¡las tarjetas! Cada tarjeta representa
un elemento de trabajo y nos brindará tanta información como nosotros definamos. De ahí que
sea necesario que diseñemos nuestra pizarra Kanban.

Lean
Es considerada tanto una metodología de trabajo como una filosofía centrada en maximizar el
valor del cliente y minimizar el desperdicio. Esto traducido a los procesos de fabricación “pull”
radica en producir solo lo necesario y en el momento adecuado.
En este contexto, podemos decir que el Lean Start Up consiste en extender la metodología al
lanzamiento de nuevas empresas al mercado.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
CLASE 10: INTRODUCCIÓN SOBRE ASPECTOS HUMANOS
EN LA INGENIERÍA DEL SOFTWARE EQUIPOS DE
TRABAJO
Aspectos Humanos en la Ingeniería del Software
La Ingeniería del Software posee una abundante cantidad de técnicas y herramientas para mejorar
el proceso de desarrollo del software.
Leyes.
Hay muchas “leyes”, que expresan de forma popular, intuitiva y en ocasiones sarcástica
(Parkinson, Peter, Murphy) grandes verdades sobre el ser humano puesto en determinadas
circunstancias. A continuación, se recogen, para comentarlas en clase, algunas que tienen mucho
que ver con el manageware y que ponen un contrapunto sabio a muchas de las sofisticadas técnicas
que para dirigir o gestionar proyectos se proponen en tantos y tantos libros muy sofisticados.
Ley de Parkinson: El trabajo tiende a ocupar todo el tiempo disponible para él (Ley del mínimo
esfuerzo, o de la voluptuosidad de los trabajos).
Ley de Brooks: Añadir gente a un proyecto retrasado lo atrasará aún más (Ley estadística de los
proyectos).
Principio de Peter: Toda persona tiende a ascender hasta su nivel de incompetencia (Ley de las
organizaciones humanas, aplicable por tanto a jefes de proyecto).
Ley de Murphy: Las cosas pueden empeorar más allá de todo límite (Ley del pesimismo integral
o de la negrura generalizada).
Principio de Clausewitz: El movimiento de un grupo de personas se rige por la velocidad de la
más lenta.

Importancia del Equipo.


En algunos casos una persona, puede desarrollar un sistema, pero en la mayor parte de la industria,
solo un equipo puede hacer el trabajo. Un equipo de software será exitoso si la dinámica del
equipo es la correcta. Muchos profesionales del área tienen la reputación de no saber trabajar en
equipo. Es esencial aportar para el éxito del proyecto, ayudando a colegas y otros participantes
(Stakeholders) del proyecto
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información

¿POR QUÉ ES IMPORTANTE EL


TRABAJO EN EQUIPO EN EL TRABAJO?
La suma de
todos los
Favorece la Genera
componentes Facilita el
integración de Incrementa la sentido de
del equipo cumplimiento
las personas y motivación y pertenencia
tiene mejores de los
el desarrollo estimula la hacia el
resultados objetivos en
de habilidades creatividad. equipo y la
que los común.
sociales. empresa.
conocimientos
individuales.

Importancia del trabajo en equipo


Requerimientos para ser Ing. de Software
1. Facilidad para aprender herramientas tecnológicas. (lenguajes, bases de datos, redes).
2. Ser capaz de aplicar el conocimiento para resolver problemas en general.
3. Desarrollar el software y testearlo para obtener un producto de calidad.
4. Manejar las fechas, la responsabilidad, la comunicación con los participantes
(stakeholders). Seleccionar y utilizar las herramientas apropiadas según el proyecto.

Cualidades de un Ing. de Software


Un efectivo ingeniero/analista de software es alguien con:
1. Responsabilidad: entrega los productos en el plazo y con la calidad acordada.
2. Colaborativo: si un miembro necesita una solución que otro conoce, debe facilitar la
integración.
3. Honesto: Las opiniones deben ser honestas y sinceras. Es imposible saber todo: plazos,
lenguajes, etc.
4. Listo para el cambio: Pueden existir modificaciones en cuanto a performance,
tecnologías, licencias, etc.

¿Qué es un Equipo de Desarrollo?


UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
Cuando el equipo está unido, el resultado es mejor que la suma de las partes. Es el equipo de
desarrollo quien dará una ventaja competitiva y no basta con tener a los mejores, tienes que hacer
que como equipo entreguen el mayor valor al negocio y les quede claro cuál es la visión de la
empresa.
El equipo de desarrollo es el responsable de crear y mantener el software, y cualquier empresa
necesita un buen equipo de desarrollo para tener éxito.
No se puede crear una camarilla de desarrollo de software perfecto inmediatamente. Debe
considerar y decidir muchas cosas antes de empezar a reunir un equipo de desarrolladores de
software. Esto incluye cosas como la funcionalidad que desea lograr, la pila tecnológica que desea
utilizar, su presupuesto y más. Un equipo de desarrollo no tiene un tamaño de equipo establecido.
Esto depende del equipo y de sus objetivos empresariales.

¿Cómo armar un Equipo Exitoso?


Buscar que el equipo sea interdisciplinario: diferentes puntos de vista enriquecerán el proceso,
tener gente con:
1.Personalidad positiva, y habilidades de comunicación.
2.Visión de negocio.
3.Capacidad de proponer mejoras o cambios.
4.Capacidad de aceptar retroalimentación.
5.Apertura para entender que los logros del equipo se basan en los entregables de todo el
equipo.
¿Cómo formar un buen equipo de trabajo?
 Evaluar adecuadamente
Hay que evaluar muy bien a las personas antes de decidir incluirlas en los equipos de trabajo.
Dependiendo de las necesidades de la empresa, se requerirá de ciertos talentos humanos para
poder cumplir con las tareas y objetivos.

 Dar luz verde a la colaboración y a las ideas


Una vez que se tenga el equipo conformado hay que darles la bienvenida a los aportes de todos
los miembros. Es indispensable fomentar la comunicación entre todos y asegurarse de que
participen y colaboren entre sí.

 Delegar
Es conveniente dirigir al equipo hasta cierto punto, pero luego, se debe dar a los miembros la
oportunidad de llevar a cabo acciones por ellos mismos para que adquieran experiencia y
desarrollen sus habilidades eficazmente.

 Fomentar el feedback
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
Hay que ofrecer retroinformación a los miembros del equipo de manera rápida y precisa sobre su
desempeño, oportunidades de mejora y logros. Por otro lado, ellos deben estar abiertos a recibir
este tipo de observaciones y aportar en cualquier aspecto que consideren necesario.
 Apostar por la flexibilidad
Es más productivo centrarse en los resultados finales, en la calidad del trabajo y en el
cumplimiento de metas que en lugar de exigir horarios estrictos o jornadas largas de trabajo sin
resultado alguno. [5]
 Apoyo, apoyo y más apoyo
Es el aspecto más importante a la hora de formar un equipo de trabajo. Si no hay apoyo, no hay
soporte, comunicación y mucho menos productividad. Hay que brindarles todo el apoyo posible
para que ellos puedan realizar sus actividades. Incluso, si hay posibilidades de brindar
capacitación para adquirir nuevas técnicas, aún mejor.

 Dar reconocimiento
Reconocer los grandes y pequeños logros es vital para mantener al equipo de trabajo motivado y
con un buen ambiente laboral. Este tipo de acciones ayuda a construir y fortalecer el espíritu de
equipo y fomenta un clima laboral más productivo.

¿Cómo es un Equipo Exitoso?


Es un equipo capaz de:
1. Auto-administrarse.
2. Auto-motivarse.
3. Apoyarse mutuamente para la consecución de las metas.
4. Aceptar críticas.
5. Proponer mejoras y áreas de oportunidad.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
CLASE 11: COMPRENSIÓN DEL PROGRAMA
INSPECCIONES DE CÓDIGO Y REFACTORIZACIÓN
COMPRENSIÓN DEL PROGRAMA INSPECCIONES DE CÓDIGO
VERIFICACIÓN Y VALIDACIÓN

El objetivo de este tema es introducir la verificación y validación del software con énfasis en las
técnicas de verificación estática y en la prueba dinámica de código.

Verificación y Validación (V&V):


Conjunto de procesos de
comprobación y análisis que
aseguran que el software que se
desarrolla está acorde a su
especificación y cumple las
necesidades de los clientes.

Verificación:
Validación:
¿Estamos construyendo el
¿Estamos construyendo el
producto correctamente?
producto correcto?
Se comprueba que el software
Comprueba que el software
cumple los requisitos funcionales
cumple las expectativas que el
y no funcionales de su
cliente espera.
especificación.

Verificación y validación
INSPECCIONES DEL SOFTWARE:

 Se analizan las diferentes representaciones del sistema (diagramas de requerimientos,


diagramas de diseño y código fuente) en búsqueda de defectos.
 Son técnicas de validación estáticas => No requieren que el código se ejecute.
 Debe realizarse durante todo el ciclo de desarrollo.
PRUEBAS DEL SOFTWARE:

 Se contrasta dinámicamente la respuesta de prototipos ejecutables del sistema con el


comportamiento operacional esperado.
 Técnicas de validación dinámicas => El sistema se ejecuta
 Requiere disponer de prototipo ejecutables, por lo que sólo pueden utilizarse en ciertas
fases del proceso
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información

Verificación y validación estática y dinámica


PROCESO DE DEPURACIÓN:

 Proceso que localiza y corrige los errores descubiertos durante la verificación y


validación.
 La depuración es un proceso que consiste en dejar que su programa se ejecute hasta que
haga algo que no se esperaba que hiciese. Tras encontrar un error, modifique el programa
para que no encuentre el error cuando se encuentre en el estado exacto en el que se
produjo el error inicialmente. Esto se consigue mediante la combinación de rastreo,
intuición, pruebas y errores. El mayor obstáculo de una depuración eficaz es que al
eliminar un error pueden aparecer nuevos errores en el programa. Tiene que considerar
consejos generales de depuración y técnicas de depuración específicas de PL/I.
 Tenga en cuenta los siguientes consejos cuando depure programas.
o Realice cambios de uno en uno:
Cuando intente solucionar un error, realice un único cambio en el código fuente
del programa cada vez. Al hacer un solo cambio, puede comparar el
comportamiento del programa antes y después de cambio para observar de forma
precisa el efecto del mismo.
o Siga la secuencia lógica del programa:
Arregle los errores del programa en el orden en el que se detectaron al ejecutar
el programa.
o Espere resultados inesperados:
Localice un error determinado en el código fuente del programa en un punto que
corresponde a un cambio inesperado en el estado de ejecución del programa.

Por ejemplo, el cambio no deseado en el estado de ejecución del programa podría


ser la asignación no intencionada de un valor decimal "100" a una variable de
carácter "z". En este caso, es probable que el código fuente incluya un error que
asigna una variable errónea en una sentencia de asignación.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información

Proceso de depuración
INSPECCIONES DEL SOFTWARE

 Consisten en revisiones sistemáticas tanto de los documentos generados como de los


códigos fuentes con el único objetivo de detectar fallos.
 Las inspecciones se pueden aplicar a la detección de fallos en cualquiera de los
documentos generados
 Permiten detectar entre un 60 y un 90% de los fallos a unos costes mucho más bajos que
las pruebas dinámicas.
 Permiten detectar múltiples defectos en una simple inspección, mientras que las pruebas
solo suelen detectar un fallo por prueba.
¿POR QUÉ ES IMPORTANTE EL CODE REVIEW?
La inspección del código fuente o Code Review, permite identificar rápidamente los errores que
son difíciles o imposibles de encontrar con técnicas como black box testing o gray box testing; de
hecho, un estudio de la NASA encontró que el code review detecta más del doble de defectos por
hora que las pruebas funcionales. El Code Review facilita reconocer vulnerabilidades, y puede
identificar la variable contaminada que origina el problema, de esta forma se determina la raíz de
la vulnerabilidad y su propagación hasta el resultado de las funciones, haciendo evidente cada
instancia de la vulnerabilidad, para así tener un panorama claro de la naturaleza del problema y
encontrar más fácilmente la solución.
La auditoría de código fuente debe ser una tarea regular durante todo el ciclo del proyecto de
desarrollo, esto permite ahorrar costos innecesarios al evitar que se manifiesten problemas de
seguridad durante el desarrollo y no esperar a que se detecten en la implementación del programa
o los ciclos de mantenimiento. Es decir, se asegura la calidad del producto antes de que comience
la fase de prueba.

LISTA DE FALLOS
FALLOS DE DATOS:

 ¿Las variables se inicializan antes que de que se utilicen los valores?


 ¿Todas las constantes tienen nombre?
 ¿El límite superior de los arrays es igual al tamaño de los mismos?
 Las cadenas de caracteres tienen delimitadores explícitos.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
 ¿Existe posibilidad que el buffer se desborde?

FALLOS DE CONTROL:

 Para cada instrucción condicional ¿Es correcta la condición?


 ¿Todos los ciclos terminan?
 ¿Los bloques están delimitados correctamente?
 En las instrucciones case ¿Se han tomado en cuenta todos los casos?
 Si se requiere un break ¿Se ha incluido?
 ¿Existe código no alcanzable?
FALLOS DE ENTRADA/SALIDA:

 ¿Se utilizan todas las variables de entrada?


 Antes de que salgan ¿Se les han asignado valores a las variables de salida?
 ¿Provocan corrupción de los datos las entradas no esperadas?
FALLOS DE GESTIÓN DE LAS EXCEPCIONES:

 ¿Se toman en cuenta todas las condiciones de errores posibles?


FALLOS DE LA INTERFAZ:

 ¿Las llamadas a funciones y métodos tienen el número correcto de parámetros?


 ¿Concuerdan los tipos de los parámetros formales y reales?
 ¿Están los parámetros en el orden adecuado?
 ¿Se utilizan los resultados de las funciones?
 ¿Existen funciones o procedimientos no invocados?

INSPECCIÓN DEL CÓDIGO FUENTE: ANÁLISIS ESTÁTICO AUTOMATIZADO


Los analizadores estáticos de programas son herramientas de software que rastrean el texto fuente
de un programa, en busca de errores no detectados por el compilador.
Aspectos habitualmente analizados son:

 Análisis de flujo de control: Identifica y señala los bucles con múltiples puntos de salida
y las secciones de código no alcanzable.
 Análisis de utilización de datos: Señala como se utilizan las variables del programa:
Variables sin utilización previa, que se declaran dos veces, declaradas y nunca utilizadas.
Condiciones lógicas con valor invariante, etc.
 Análisis de interfaces: Verifica la declaración de las operaciones y su invocación. Esto es
inútil en lenguajes con tipado fuerte (Java, Ada) pero si en los restantes (C no comprueba
los parámetros de una operación).
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
 Análisis de la trayectoria: Identifica todas las posibles trayectorias del programa y
presenta las sentencias ejecutadas en cada trayectoria.
Las pruebas se realizan en cuatro etapas:

 Prueba de unidades (prueba de métodos y clases): se prueba cada método y clase de forma
independiente
 Prueba de integración o de subsistemas: se prueban agrupaciones de clases relacionadas
 Prueba de sistema: se prueba el sistema como un todo
 Prueba de validación (o de aceptación): prueba del sistema en el entorno real de trabajo
con intervención del usuario final.

PRUEBAS DEL SOFTWARE


Las pruebas se realizan en cuatro etapas:
Prueba de unidades (prueba de métodos y clases): se prueba cada método y clase de forma
independiente.
Prueba de integración o de subsistemas: se prueban agrupaciones de clases relacionadas.
Prueba de sistema: se prueba el sistema como un todo.
Prueba de validación (o de aceptación): prueba del sistema en el entorno real de trabajo con
intervención del usuario final.

TIPOS DE PRUEBAS DEL SOFTWARE


LAS PRUEBAS DE DEFECTOS:

 Buscan las inconsistencias entre un programa y su especificación.


 Las pruebas se diseñan para buscar los errores en el código.
 Demuestran la presencia, y no la ausencia, de defectos
 El objetivo de las pruebas de defecto es detectar los defectos latentes de un sistema
software antes de entregar el producto.

Proceso de Pruebas de defectos


LAS PRUEBAS ESTADÍSTICAS:
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
 Buscan demostrar que satisface la especificación operacional y su fiabilidad.
 Se diseñan para reflejar la carga de trabajo habitual.
 Sus resultados se procesan estadísticamente para estimar su fiabilidad (contando el
número de caídas del sistema) y sus tiempos de respuesta.
PRUEBAS FUNCIONALES (“CAJA NEGRA”)
Las pruebas funcionales o de caja negras es una política de selección de casos de pruebas basado
en la especificación del componente o programa.

Pruebas estructurales (“Caja blanca”)

 En las pruebas estructurales las pruebas se seleccionan en función del conocimiento que
se tiene de la implementación del módulo.
 Se suelen aplicar a módulos pequeños.
 El probador analiza el código y deduce cuántos y qué conjuntos de valores de entrada han
de probarse para que al menos se ejecute una vez cada sentencia del código.
PRUEBAS DE INTEGRACIÓN

 Se prueban la respuesta de grupos de módulos interconectados a fin de detectar fallos


resultantes de la interacción entre los componentes.
 Las pruebas de integración se realizan con referencia a las especificaciones del
programa.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
 La principal dificultad de las pruebas de integración es la localización de los fallos. [1]

Pruebas de integración incremental

Niveles de pruebas en sistemas orientados a objetos


En orientación a objetos, la separación entre pruebas de unidades y pruebas de integración no está
muy clara, debido a las dependencias entre clases.
Las pruebas de integración han sido, hasta ahora, las menos estudiadas y comprendidas y las más
evitadas. Aún en empresas que dan poco valor a las pruebas, los desarrolladores realizan pruebas
de unidad, aun cuando sean informales. También se efectúan algunas pruebas de sistema, al menos
poco antes de entregar el software. Sin embargo, las pruebas de integración no se ven como
necesarias.
Según Binder, las pruebas de integración pueden determinar problemas de los tipos siguientes:
a) Problemas de configuración: se producen fallas debido a que las versiones de los diferentes
elementos pueden resultar incompatibles, por mal control de versiones, o por usar una versión
equivocada.
b) Funciones faltantes, traslapadas o que tienen conflictos: Una clase puede invocar un método
de otra que aún no está implementado o que fue olvidado; también puede suceder que la función
invocada no realice lo que se deseaba.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
c) Uso incorrecto o inconsistente de archivos y bases de datos: Los archivos y bases de datos son
elementos importantes al integrar un sistema, pero pueden estar ausentes o tener claves
imprevistas o restricción en el número de usuarios concurrentes o formatos diferentes al previsto.
d) Violaciones a la integridad de los datos: Al manejar bases de datos, si no se respetan las
restricciones de integridad, se producirán errores que quizá no se anticiparon al crear las clases.
e) Llamadas a método equivocado, debido a errores de codificación o a liga inesperada al tiempo
de ejecución: Como los objetos usan liga dinámica y a veces los nombres de los métodos no dicen
su función, es posible invocar métodos equivocados; el polimorfismo lo agrava, ya que no se sabe
con exactitud qué objeto será el que interactúe en un momento dado.
f) Una unidad cliente envía un mensaje que viola las precondiciones del servidor: por ignorancia
o descuido, es posible que una clase solicite un Guía mínima de prueba de software orientado a
objetos Juan Manuel Fernández Peña 2 servicio, pero no cumpla las reglas debidas en los
parámetros que se envía y eso provoca el rechazo de la clase que debe proporcionar el servicio;
por ejemplo, esperaba un número positivo y recibe uno negativo.
g) Objeto equivocado como destinatario en caso de polimorfismo: se esperaba un objeto (por
ejemplo, un cuadrado) y llegó otro (por ejemplo, un triángulo o una elipse) y no se sabe qué hacer
con él.
h) Parámetros erróneos o valores equivocados: los parámetros esperados no corresponden a los
enviados; por ejemplo, esperaban un entero y llegó un real; otro caso sería que falten parámetros;
también puede suceder que el valor no corresponda al rango permitido. Algunos de estos
problemas no se notan al compilar debido a la liga dinámica.
i) Problema de precisión en parámetros: similar al anterior, pero con tipos parecidos; puede
suceder que esperaba un entero de 16 bits y recibe uno de 32 o viceversa.
j) Fallas causadas por mal manejo de memoria: en ocasiones una clase crea y destruye objetos de
otra clase y puede originar problemas si no lo hace correctamente (en lenguajes como Java esto
es poco frecuente).
k) Uso incorrecto de servicios del S.O., ORB1 o de máquina virtual (como la de Java): similares
a los anteriores, pero referidos a invocaciones de servicios del sistema operativo o software
intermedio, en vez de clases del usuario.
l) Conflictos entre componentes: puede ocurrir una falla en una clase cuando otra está corriendo,
debido a mal manejo de concurrencia (ya sea a nivel de hilo o de proceso).
m) Recursos insuficientes: el destinatario no asigna recursos necesarios la creación de objetos va
disminuyendo los recursos del sistema y puede suceder que se excedan las capacidades asignadas
a una aplicación. Por ejemplo, Delphi no destruye automáticamente las ventanas en desuso, sólo
las oculta; el usuario debe cuidar de no dejar demasiadas.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
REFACTORIZACIÓN
¿QUÉ ES LA REFACTORIZACIÓN?
La refactorización podría compararse con la corrección de un libro: el producto final de la
corrección no es un nuevo libro, sino el mismo texto, pero más comprensible. Así, al igual que en
la corrección de un libro se usan procedimientos como la reformulación y la reestructuración o
eliminación de frases, en la refactorización de código se aplican métodos como la encapsulación,
el reformateo o la extracción para optimizar el código sin cambiar su contenido.
La refactorización desempeña un papel especialmente importante en el desarrollo iterativo e
incremental, así como en el desarrollo ágil de software, ya que este modelo cíclico lleva a los
programadores a modificar el software una y otra vez. En este proceso, la refactorización es un
paso clave.
¿CUÁNDO ES RECOMENDABLE APLICAR LA REFACTORIZACIÓN?

 Para corregir errores (código innecesario, duplicado, listas extensas de parámetros…) [5]
 En escenarios de código espagueti: código erosionado, confuso y de difícil lectura que
está poniendo freno a su funcionalidad. Este tipo de códigos suele contener elementos
que complican su estructura (órdenes de salto, bucles for/while, comandos if…) que
pueden derivar de los conocidos como code smells al code rot (literalmente, “putrefacción
del código”), que puede terminar por complicar el código hasta el punto en que no es
posible aplicar actualizaciones. ¨
Frente a esto, la refactorización mejora el código y lo vuelve más efectivo, pudiendo integrar
nuevos elementos de forma más sencilla, también por programadores que accedan por primera
vez al código.

¿CUÁL ES EL OBJETIVO DE LA REFACTORIZACIÓN?


 La refactorización siempre tiene el sencillo y claro propósito de mejorar el código, con
un código más efectivo, puede facilitarse la integración de nuevos elementos sin incurrir
en errores nuevos.
 Otro objetivo de la refactorización es mejorar el análisis de errores y la necesidad de
mantenimiento del software. Poner a prueba el código ahorra esfuerzo a los
programadores.

¿QUÉ FUENTES DE ERROR CORRIGE LA REFACTORIZACIÓN?


Algunas de las fuentes de error que pueden corregirse mediante refactoring son las siguientes:

 Estructuras complicadas o demasiado largas: cadenas y bloques de comandos tan largos


que la lógica interna del software se vuelve incomprensible para lectores externos.
 Redundancias en el código: los códigos poco claros suelen contener repeticiones que han
de corregirse una a una durante el mantenimiento, por lo que consumen mucho tiempo y
recursos.
 Listas de parámetros demasiado largas: los objetos no se asignan directamente a un
método, sino que se indican sus atributos en una lista de parámetros.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
 Clases con demasiadas funciones: clases con demasiadas funciones definidas como
método, también llamadas god objects, que hacen que adaptar el software se vuelva casi
imposible.
 Clases con funciones insuficientes: clases con tan pocas funciones definidas como
método que se vuelven innecesarias.
 Código demasiado general con casos especiales: funciones con casos especiales
demasiado específicos que apenas se usan y que, por lo tanto, dificultan la incorporación
de ampliaciones necesarias.
 Middle man: una clase separada actúa como intermediaria entre los métodos y las
distintas clases, en lugar de direccionar las solicitudes de los métodos directamente a una
clase.

VENTAJAS DESVENTAJAS
Una mejor comprensión facilita el Una refactorización imprecisa podría
mantenimiento y la ampliación del generar nuevos bugs y errores en el código.
software.
La reestructuración del código fuente puedeNo existe una definición clara de qué es un
realizarse sin cambiar la funcionalidad. código limpio o bien estructurado.
La mejora en la legibilidad del código Los clientes no suelen percatarse de las
facilita que otros programadores lo mejoras en el código, ya que la
comprendan. funcionalidad no varía, de forma que la
utilidad de la refactorización no es siempre
obvia.
La eliminación de las redundancias aumenta Cuando la refactorización es realizada por
la eficiencia del código. equipos grandes, llegar a acuerdos podría
suponer más trabajo del esperado.
Los métodos cerrados en sí mismos impiden
que los cambios locales afecten a otras
partes del código.
Un código bien estructurado, con métodos y
clases más cortas y cerradas en sí mismos,
puede ponerse a prueba más fácilmente.
LAS VENTAJAS Y DESVENTAJAS
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
CLASE 12: ¿QUÉ ES USABILIDAD?
Más allá del concepto antes referido, si buscamos la palabra “usabilidad” en Google veremos, no
solo que no está contemplada por la RAE (al tratarse de un neologismo, del inglés, “usability”),
sino que, desde las primeras entradas, su definición hace referencia al entorno digital. Se entiende
usabilidad como “la facilidad con que un usuario puede utilizar una herramienta fabricada por
otras personas con el fin de alcanzar un cierto objetivo”. Se dice que una página web o una
aplicación es usable cuándo es sencilla de utilizar porque facilita la lectura de los textos,
descarga rápidamente la información y presenta funciones y menús sencillos e intuitivos de
manera que resulta cómoda de usar.
• Definición coloquial: Facilidad de uso, ya sea de una página web, una aplicación
informática o cualquier otro sistema que interactúe con un usuario.
• ISO 9126: “La usabilidad se refiere a la capacidad de un software de ser comprendido,
aprendido, usado y ser atractivo para el usuario, en condiciones específicas de uso”.

Esta característica se subdivide a su vez en las siguientes su característica:


 Reconocibilidad de la adecuación. Capacidad del producto que permite al usuario
entender si el software es adecuado para sus necesidades.
 Aprendizabilidad. Capacidad del producto que permite al usuario aprender su
aplicación.
 Operabilidad. Capacidad del producto que permite al usuario operarlo y controlarlo
con facilidad.
 Protección contra errores de usuario. Capacidad del sistema para proteger a los
usuarios de hacer errores.
 Estética de la interfaz de usuario. Capacidad de la interfaz de usuario de agradar y
satisfacer la interacción con el usuario.
 Accesibilidad. Capacidad del producto que permite que sea utilizado por usuarios
con determinadas características y discapacidades.

• ISO 9241: "Usabilidad es la efectividad, eficiencia y satisfacción con la que un producto


permite alcanzar objetivos específicos a usuarios específicos en un contexto de uso
específico".
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información

¿Qué es Usabilidad?
Un sistema usable es:
• Funcionalmente correcto (efectividad)
• Eficiente de usar (eficiencia)
• Fácil de aprender
• Fácil de recordar
• Tolerante a los errores
• Subjetivamente agradable (satisfacción).

OBJETIVOS DE LA USABILIDAD
La accesibilidad de cualquier sistema debe constituir un objetivo primordial que no puede
descuidarse ni dejarse de la mano de la improvisación.
Igual que en el caso de la definición de los objetivos de usabilidad en este apartado no vamos a
enumerar ninguna lista de objetivos a definir, pues se trata de un tema particular de cada
aplicación. El aspecto realmente importante es definir los objetivos de manera clara y precisa
acorde con las discapacidades que pretendamos cubrir, para lo cual nos basaremos en los
estándares y en las normativas vigentes.
De todas formas, en esta definición de objetivos, debemos ser conscientes de que nunca seremos
capaces de ofrecer total funcionalidad para todos los tipos de discapacidades, como tampoco
podremos solucionar todos los problemas relativos a una misma tipología. Por tanto, seamos
ambiciosos, pero no nos marquemos objetivos imposibles.

Tiempo aprendizaje o de tarea: Usar el sitio por primera vez, encontrar un tema por primera vez
en menos de 2 minutos. Usuarios Expertos (5 visitas) menos de 30 segundos.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
Facilidad de aprendizaje: Medible por el tiempo que se tarda en la consecución de las tareas
habituales y recordarlas en futuros usos.
Numero de errores
• No visitar más de tres páginas erróneas para visitar una página.
• No hacer errores fatales menos del 99% del tiempo.
Impresión subjetiva: En una escala de 1 a 10 en cuanto a que el sitio sea atractivo como mínimo
de 7 (medible con una encuesta).
Tareas realizadas: Como mínimo un 75% de los usuarios serán capaces de realizar una consulta.
(en el caso de una web de compra Online).
OTROS OBJETIVOS DE LA USABILIDAD:
1. Optimizar resultados y la experiencia de los usuarios de un sitio web o app.
2. Definir, planificar y ejecutar mejoras continuas para los usuarios.
3. Optimizar la conversión y la experiencia de usuario (UX).
4. Utilizar la analítica web para impulsar el cambio en los negocios online.
5. Elaborar factores clave KPIs.
6. Implementar y explotar un sistema de analítica web de forma eficiente.
7. Poseer elementos contribuyen con los resultados del sitio o marca.
8. Dominar herramientas que optimizarán la experiencia y satisfacción de los usuarios
9. Desarrollar las ventajas competitivas que beneficiarán tu posición ante la clientela.
10. Enriquecer las experiencias de los usuarios que se desempeñan en los distintos ámbitos
productivos.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
CLASE 13: PRINCIPIOS DE LA USABILIDAD
Principios de usabilidad de Jakob Nielsen
En 1990, Jakob Nielsen y Rolf Molich propusieron diez directrices para ayudar en el desarrollo
de interfaces de usuario (UI).
Las heurísticas de Nielsen son principios generales, lo que significa que no establecen reglas
específicas de usabilidad. En lugar de eso, las heurísticas son pautas básicas que puedes seguir
para ayudar a crear productos digitales más accesibles, fáciles de usar e intuitivos. [2]
Estas heurísticas se crearon a partir de observaciones y de la experiencia adquirida durante sus
años de trabajo en el campo.
Desde la amplia experiencia de Dazzet, con dos décadas en el ámbito del marketing digital y
habiendo analizado múltiples tendencias internacionales, se destaca la importancia de ofrecer una
experiencia de usuario óptima en cualquier plataforma digital. Estos son algunos consejos
fundamentales.
Estos son los diez principios de usabilidad confeccionados por Jakob Nielsen:
1. Visibilidad del estado del sistema El sistema (web, app o cualquier otro producto digital)
debe siempre mantener informado al usuario de lo que está ocurriendo. Ejemplo: al subir
un archivo a Google Drive, el sistema nos indica que se está cargando y el tiempo restante.

Este principio de usabilidad web nos indica que siempre tenemos que tener informado al
usuario de lo que está pasando en nuestra web y ofrecerle una respuesta en el menor
tiempo posible.

2. Relación entre el sistema y el mundo real El sitio web o aplicación tiene que utilizar el
lenguaje del usuario, con expresiones y palabras que le resulten familiares. Además, la
información debe aparecer en un orden lógico y natural.

La información tiene que mostrarse con un orden lógico y las imágenes o iconos usados
tienen que ser claros, sin darle la posibilidad al usuario de equivocarse. Con esto,
conseguimos que la interacción con el lector sea natural y no le cueste moverse por la
web.

3. Control y libertad del usuario En caso de elegir alguna opción del sitio web por error, el
usuario agradecerá disponer de una “salida de emergencia” para abandonar el estado no
deseado en que se halla. Debe poder deshacer o repetir una acción previamente realizada.

A veces, un usuario se equivoca, es normal, está dentro de la naturaleza humana el


equivocarse. Tenemos que darle al usuario la posibilidad de subsanar el error y no
sentirse frustrado por no poder realizar algo.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información

4. Consistencia y estándares Es importante establecer convenciones lógicas y mantenerlas


siempre. El usuario no tiene por qué saber que diferentes palabras, situaciones o acciones
significan lo mismo.

Otro punto que tenemos que tener en cuenta es seguir los convenios establecidos para
ciertos iconos. Con el auge de los dispositivos móviles han aparecido nuevos gestos e
iconos que ya hemos asumido como normales.

5. Prevención de errores Ayuda al usuario a que no caiga en un error.

Tenemos, en todo lo posible, que prevenir cualquier error que pueda cometer el usuario.
Y dado el caso de que este cometa uno, tenemos que poner a su alcance todas las opciones
posibles para poder corregirlo.

6. Reconocimiento antes que recuerdo Debemos hacer visibles acciones y opciones para
que el usuario no tenga que recordar información entre distintas secciones o partes del
sitio web o aplicación.

Siempre es mejor reconocer que obligar al usuario a memorizar acciones u objetos para
que pueda cumplir su objetivo. Hacernos una idea de cómo es si nos muestra una pre
visualización de la fuente es más fácil que acordarnos del nombre de cada una de las
fuentes que se han instalado.

7. Flexibilidad y eficiencia de uso Los aceleradores o atajos de teclado, por ejemplo, pueden
hacer más rápida la interacción para usuarios expertos, de tal forma que el sitio web o
aplicación sea útil tanto para usuarios básicos como avanzados.

Tenemos que tener un sitio web preparado para todo tipo de usuario, desde los más
novatos hasta los más experimentados. Si conseguimos que cualquiera pueda navegar por
nuestra web logramos flexibilidad.

8. Estética y diseño minimalista Las páginas no deben contener información innecesaria.


Cada información extra compite con la información relevante y disminuye su visibilidad.

No recargues el diseño de tu página web. El usuario busca sites limpios y que carguen
rápido. Elimina todo lo que consideres innecesario y que no aporta nada a lo que quieres
decir. La mejor forma de recordar este principio básico de usabilidad web es con el
acrónimo KISS, Keep It Simple Stupid.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
9. Ayudar a los usuarios a reconocer, diagnosticar y recuperarse de errores Los mensajes
de error se deben entregar en un lenguaje claro y simple, indicando en forma precisa el
problema y sugerir una solución constructiva al problema.

La mayoría conocemos qué es un error 404, pero hay gente que no sabe lo que es.
Es por esto, por lo que tenemos que cambiarlo para que en vez de que aparezca error 404,
diga algo más amigable como: Lo siento, página no encontrada y darle una posible salida
añadiendo páginas relacionadas o un buscador interno para que pueda buscar y no se vaya
de la web.

10. Ayuda y documentación, Aunque es mejor que el sitio web o aplicación pueda ser usado
sin ayuda, puede ser necesario proveer cierto tipo de ayuda.

Existen numerosos ejemplos de este principio general de usabilidad web:


 FAQs, Frequently Asked Questions, preguntas frecuentes
 El icono de la interrogación cerca de algunas opciones
 Minitours nada más abrir una aplicación donde se muestra lo esencial

¿QUÉ ES LA INGENIERÍA DE LA USABILIDAD?


Beneficios de la usabilidad en la ingeniería
De acuerdo con el estándar ISO 9241, la usabilidad tiene que ver con el grado en que un producto
puede ser utilizado por usuarios determinados, a fin de conseguir resultados muy específicos, con
eficiencia, efectividad y satisfacción.
Al desarrollar sistemas informáticos, es muy común que exista un alto nivel de preocupación para
que el sistema no presente errores a los usuarios; sin embargo, en muy pocas ocasiones se toma
el tiempo necesario para verificar la usabilidad del sistema, punto de suma importancia para un
usuario final de un sistema.
En ocasiones, incluso ni se conoce el término usabilidad y se puede confundir con otros términos
relacionados. La usabilidad es la disciplina que estudia la forma de diseñar sitios web para que
los usuarios puedan interactuar con ellos de la forma más fácil, cómoda e intuitiva posible.
La palabra usabilidad deriva del inglés usability, cuya traducción más acertada es "facilidad y
simplicidad de uso de un artículo u objeto".
Sus atributos o beneficios son los siguientes:

 Facilidad de aprendizaje: Es decir que señala que tan fácil es aprender la funcionalidad
básica del sistema, con la idea de que sea capaz de efectuar las tareas que desee en usuario.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
La facilidad de aprender la funcionalidad y comportamiento del sistema. define en cuánto
tiempo un usuario, que nunca ha visto una interfaz, puede aprender a usarla bien y realizar
operaciones básicas. ¿Cuánto le toma al usuario típico de una comunidad aprender la
manera en cómo se usan los comandos relevantes a un conjunto de tareas?

 Eficiencia: Esta se determina por el número de transacciones por unidad de tiempo que
el usuario es capaz de realizar mediante el sistema.

Involucra alcanzar el nivel de productividad requerido, una vez que el usuario ha


aprendido a usar el sistema. Determina la rapidez con que se pueden desarrollar las tareas.
¿Cuánto le toma a un usuario completar un grupo de tareas específicas (benchmark
tasks)?

 Presentación visual apropiada: Esta se determina mediante el diseño de la interfaz


gráfica de usuario y es recomendable tener en consideración una serie de normativas que
provienen del campo de diseño gráfico, en relación con cómo elegir los colores, el tipo
de letra y la disposición de los elementos.
 Manejo de errores: Este indica cómo el sistema puede prevenir los errores que el usuario
puede cometer en tanto se encuentra en la operación del programa.

La capacidad del sistema para ofrecer una tasa baja de errores, apoyar a los usuarios a
cometer pocos errores durante el uso del sistema, y en caso de que cometan errores
ayudarles a recuperarse fácilmente. ¿Cuántos y qué errores hace la gente al ejecutar un
grupo de tareas específicas?

 Satisfacción: Este indica la impresión subjetiva que el operador de determinado sistema


logra obtener de este. Para ello, se utilizan encuestas, cuestionarios y entrevistas.

Se refiere a la impresión subjetiva del usuario respecto al sistema. ¿Qué tanto les gustaron
a los usuarios los distintos atributos del sistema?

 Nivel de Seguridad: Es bueno destacar que la calidad no es posible que exista sin
seguridad y constituye un factor importante en la usabilidad de una aplicación, por cuanto
genera mayor confianza a los usuarios.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
CLASE 14: CICLO DE VIDA DE LA INGENIERÍA DE LA USABILIDAD
ASPECTOS AFECTIVOS DE LA INTERACCIÓN HUMANO SOFTWARE
Ciclo de vida de la ingeniería de la usabilidad:
• Análisis del perfil del usuario.
• Análisis de tareas.
• Definición de los objetivos de la usabilidad.
• Diseño del sistema.
• Implementación de prototipos.
• Realización del test.

ETAPAS DE LA USABILIDAD DE UN PRODUCTO


El objetivo es orientar el proceso de desarrollo, aun cuando para fijarlas es necesario reconocer a
los usuarios previamente, así como las tareas que deben realizar con el sistema.
1. Especificaciones
Esta etapa se da antes de comenzar con el proyecto, cuando se desarrolla una lista de
especificaciones de usabilidad, con la idea de plasmar los intereses que se pretenden
alcanzar.

Distinción de usuario: Esta se efectúa con la finalidad de conocer tanto a los usuarios
como a las tareas que desempeñan y cómo las ejecutan.
• Es preciso hacer un análisis de mercado, en caso de que se trate de un producto
software comercial.
• Es necesario utilizar los métodos de indagación, entre los que están la
observación de campo, encuestas, entrevistas y cuestionarios, a fin de identificar
los requerimientos del usuario y, por ende, los del producto.

Identificación de tareas: Consiste en un grupo de técnicas que se emplean para precisar


cómo los usuarios realizan una tarea muy determinada.

Especificaciones de usabilidad: Siempre es indispensable contar con una serie de


especificaciones de usabilidad, las cuales puedan ser revisadas a fin de que de esta manera
se pueda medir la usabilidad del producto software que está en proceso de desarrollo.

2. El Diseño
Luego de la identificación de las tareas, se da comienzo a las etapas que contemplan el
diseño.
Para ello se comienza con el diseño de la interacción con el sistema, el cual se irá
evaluando y mejorando en forma interactiva.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
En la mencionada etapa se utilizarán técnicas de prototipado, así como se considerarán
principios de diseño que relacionan al usuario en diferente grado.

Diseño de la interacción: El citado esquema es posible que sea dividido en dos fases:
diseño visual de la interacción y diseño conceptual del sistema.

El prototipado: Normalmente, los usuarios no comprenden el modelo técnico de un


sistema, razón por la cual no pueden formular una opinión sobre el mismo. Frente a ello,
lo recomendable es usar prototipos precisos del sistema, a fin de que el usuario pueda
comprenderlo más fácilmente.

Participación del usuario: La participación del usuario puede variar en esta etapa del
proceso, de acuerdo con el grado de involucramiento, lo cual constituye un Diseño
Centrado en el Usuario o Diseño Participativo.

tres pasos previos al proceso de evaluación: concepción, documentación y ejecución:


 En la primera etapa se identifican y jerarquizan los objetivos; se determinan los
usuarios, qué se quiere saber y cómo se piensa hacerlo.
 En la segunda etapa se efectúa la documentación de todo lo que el servicio (sitio,
portal, etc.) persigue; incluso, se llega a realizar, en formato impreso, una
maqueta con lo que poseerá y se efectúan todas las interconexiones posibles,
mientras se busca toda la información necesaria para la ejecución del proceso de
evaluación.
 En la tercera de estas etapas se combinan las propuestas de diseño independientes
con el fin de interrelacionarlas; se crean y evalúan los prototipos; se efectúan
consideraciones en función del diseño deseado; se jerarquizan las categorías; se
reduce el número de tareas que debe realizar el usuario; se realiza un diseño
consistente y confiable; se realizan los arreglos de contenido y forma, así como
los gráficos significativos; se establecen las condiciones de accesibilidad y se
desarrollan las vías de retroalimentación para los usuarios.

3. LA EVALUACIÓN
La evaluación es una parte del proceso mediante la cual se precisa el nivel de usabilidad
que alcanza el prototipo actual del sistema, con el fin de identificar sus defectos de
usabilidad.

Test de usabilidad: Este test representa la prueba de usabilidad más utilizada y se


fundamenta el hecho de que es imposible precisar el grado de usabilidad de un sistema, a
menos que sea probado con usuarios de verdad.

Evaluación Heurística: La evaluación heurística es realizada por expertos en usabilidad o


también en la llamada interacción hombre-computadora, fundamentándose en su
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
experiencia de diseño o en guías de diseño de usabilidad para señalar críticas sobre el
sistema. [1]

ASPECTOS AFECTIVOS DE LA INTERACCIÓN HUMANO


SOFTWARE
LAS INTERFACES EN LA ERA DE LA COMPUTACIÓN AFECTIVA INNOVACIÓN

 Innovación: artefactos aún no diseñados o artefactos mejorados.

“La creación de una cultura de propósito en torno a la tecnología no solo alienta a los
líderes a ser más intencionales en la gestión de sus empresas, sino que también aprovecha
los beneficios que ofrece la tecnología. Tener una cultura tecnológica propositiva
fomenta y multiplica las competencias. Eso significa menos riesgo, mayor flexibilidad y
agilidad, junto con mayor velocidad y menores costos”, mencionan nuestros líderes Hays
en Brasil, Chile, Colombia y México.

 Las nuevas tecnologías son una herramienta, se incorporan a nuestra vida diaria
 Las emociones deben ser incluidas en el diseño de las nuevas tecnologías.

LAS NUEVAS TECNOLOGÍAS Y LAS EMOCIONES

 Incluirlas implica una mejora en la interacción con los usuarios.


 Lo que redunda en una interacción más rica y satisfactoria.

INTELIGENCIA ARTIFICIAL

La inteligencia artificial (IA) está ganando cada vez más espacio en nuestras rutinas personales y
profesionales dado su amplio abanico de posibilidades de aplicación, como la creación de
contenidos e imágenes, la organización de datos e incluso el desarrollo de sistemas completos.
Esta tecnología continúa revolucionando varios sectores con diferentes tipos de uso, lo que llevará
a una tasa de crecimiento promedio anual esperada del 37,3% entre los años 2023 a 2030, según
datos presentados por Grand View Research en un análisis de mercado. Su amplia adhesión se
explica por la constante actualización de sus bases de conocimiento.
Es un campo excitante donde:

 Durante años nos hemos preguntado, que caracteriza al homo sapiens, nuestras
capacidades mentales son importantes para nosotros.
 Tratamos de comprender como pensamos, esto es, como percibimos, entendemos y
predecimos, cómo somos capaces de manipular el entorno en el que nos movemos (es tan
complejo).
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
EL ESTUDIO DE LAS EMOCIONES Y EL COMPORTAMIENTO

 La computación afectiva es aquella que relaciona, las excitaciones provocadas de forma


deliberada para influenciar en las emociones del usuario.
 Este campo esta estudiado por la psicología y la importancia de las emociones en el
comportamiento humano.
 Sin emociones no pude existir inteligencia durante una interacción.
EL HOMBRE ¿ES RACIONAL O EMOCIONAL?
Recientes estudios neurológicos indican el papel esencial que desempeña la emoción en la
cognición humana:

 Toma de decisiones.
 Percepción.
 Interacción humana.
 Inteligencia.
Este hecho combinado con las computadoras hábiles en el reconocimiento de expresiones y
emociones abren nuevas áreas para la investigación como: computación afectiva y diseño
emocional.
¿QUÉ SON LAS EMOCIONES?
Las emociones son estados de ánimo caracterizados por sentimientos, sensaciones,
pensamientos... Son universales, es decir, todo el mundo sabe que cuando una persona está riendo
y pasándoselo bien, muestra la emoción de la alegría; cuando una persona llora, la emoción que
muestra es la tristeza, por ejemplo. Las emociones nos sirven para comunicarnos con los demás,
ya que a través de los gestos expresamos muchos de nuestros pensamientos.
A continuación, se presenta un video titulado "¿Para qué sirven las emociones?", donde unos
personajes nos enseñan qué sienten y qué le pasa a su cuerpo cuando realizan diferentes acciones.
También expresan mediante gestos en sus caras las emociones de la felicidad, miedo,
tristeza, tranquilidad y enojo. ¿Serás capaz de identificar las emociones de estos personajes?

 Por qué cuando te piden o dan información con amabilidad te sientes mejor…
 Por qué muchas veces prefieres saber que hay alguien del otro lado…
 Por qué te agrada pensar que alguien te acompaña en tu tarea ...
 Las Interfaces inteligentes son una necesidad de nuestro tiempo, en que los sistemas de
software son más y más poderosos y están en todos lados, como los bancos o internet.
EMOCIONES
El sentimiento puede clasificarse como:
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
 Estado sentimental: un sentimiento duradero y estable.
 Emoción: sentimiento breve, de aparición normalmente abrupta, que provoca alteraciones
físicas perceptibles: agitación, palidez, palpitaciones, rubor, etc.
 Pasión: sentimiento intenso, vehemente, que ejerce un influjo poderoso sobre el
comportamiento.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
TALLER CLASE 1 FUNDAMENTOS INGENIERÍA
SOFTWARE
Quinto
Nombres y Apellidos: Freddy Jefferson Cedillo Rivera Curso:
“A”
Fecha: 13/11/2023 Calificación

Seleccionar de entre las opciones cual es la afirmación correcta.

La ingeniería de software es:

A. Una disciplina formada por un conjunto de métodos, herramientas y técnicas que se utilizan
en el desarrollo de los programas informáticos.
B. Se encarga de toda la gestión del proyecto para que éste se pueda desarrollar en un plazo
determinado y con el presupuesto previsto.
C. Es el conjunto de instrucciones o programas que le dicen a una computadora qué hacer.
El ingeniero de software:

A. Una disciplina formada por un conjunto de métodos, herramientas y técnicas que se utilizan
en el desarrollo de los programas informáticos.
B. Se encarga de toda la gestión del proyecto para que éste se pueda desarrollar en un plazo
determinado y con el presupuesto previsto.
C. Es el conjunto de instrucciones o programas que le dicen a una computadora qué hacer.
El software:

A. Una disciplina formada por un conjunto de métodos, herramientas y técnicas que se utilizan
en el desarrollo de los programas informáticos.
B. Se encarga de toda la gestión del proyecto para que éste se pueda desarrollar en un plazo
determinado y con el presupuesto previsto.
C. Es el conjunto de instrucciones o programas que le dicen a una computadora qué hacer.

Software del sistema:

A. Para proporcionar funciones básicas como sistemas operativos, administración de discos,


servicios, administración de hardware y otras necesidades operacionales.
B. Para brindar a los programadores herramientas como editores de texto, compiladores,
enlazadores, depuradores y otras herramientas para crear código.
C. Para ayudar a los usuarios a realizar tareas.
D. El software de sistemas integrado se utiliza para controlar máquinas y dispositivos que
normalmente no se consideran computadoras, como redes de telecomunicaciones,
automóviles, robots industriales y más.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
Software de programación

A. Para proporcionar funciones básicas como sistemas operativos, administración de discos,


servicios, administración de hardware y otras necesidades operacionales.
B. Para brindar a los programadores herramientas como editores de texto, compiladores,
enlazadores, depuradores y otras herramientas para crear código.
C. Para ayudar a los usuarios a realizar tareas.
D. El software de sistemas integrado se utiliza para controlar máquinas y dispositivos que
normalmente no se consideran computadoras, como redes de telecomunicaciones,
automóviles, robots industriales y más.
Software de aplicación

A. Para proporcionar funciones básicas como sistemas operativos, administración de discos,


servicios, administración de hardware y otras necesidades operacionales.
B. Para brindar a los programadores herramientas como editores de texto, compiladores,
enlazadores, depuradores y otras herramientas para crear código.
C. Es para ayudar a los usuarios a realizar tareas.
D. El software de sistemas integrado se utiliza para controlar máquinas y dispositivos que
normalmente no se consideran computadoras, como redes de telecomunicaciones,
automóviles, robots industriales y más.

Software integrado.

A. Para proporcionar funciones básicas como sistemas operativos, administración de discos,


servicios, administración de hardware y otras necesidades operacionales.
B. Para brindar a los programadores herramientas como editores de texto, compiladores,
enlazadores, depuradores y otras herramientas para crear código.
C. Para ayudar a los usuarios a realizar tareas.
D. El software de sistemas integrado se utiliza para controlar máquinas y dispositivos que
normalmente no se consideran computadoras, como redes de telecomunicaciones,
automóviles, robots industriales y más.
¿La ingeniería del software es? Una disciplina que implica el uso de estructuras, herramientas y
técnicas para construir programas informáticos.

A. VERDADERO
B. FALSO

La ingeniería del software:

A. Incluye el análisis previo de la situación la redacción del proyecto, la creación del software.
B. borda solo fases específicas del ciclo de vida del software.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
C. Incluye el desarrollo previo de la situación la redacción del proyecto, la creación del
software.
D. Aborda todas las fases del ciclo de vida del software.
Etapas de la ingeniería de software:

A. Concepción.
B. Freeware.
C. Elaboración.
D. De pago.
E. Construcción.
Etapas de la ingeniería de software:

A. Adware.
B. Transición.
C. Shareware.
D. Mantenimiento.
E. Software libre.
Tipos de software dependiendo de la distribución

A. Concepción.
B. Freeware.
C. Elaboración.
D. De pago.
E. Construcción.
Tipos de software dependiendo de la distribución

A. Adware.
B. Transición.
C. Shareware.
D. Mantenimiento.
E. Software libre.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
TALLER CLASE 2 PROCESO DEL SOFTWARE - MODELO
PROCESO SOFTWARE
Quinto
Nombres y Apellidos: Freddy Jefferson Cedillo Rivera Curso:
“A”

Fecha: 15/11/2023 Calificación

De los siguientes escoja la opción(es) correctas

¿Qué es un proceso del software?


A. La meta de la ingeniería de software es construir productos de software, o mejorar los
existentes; en ingeniería de procesos, la meta es desarrollar o mejorar procesos.
B. Es un conjunto de personas, estructuras de organización, reglas, políticas, actividades y
sus procedimientos, componentes de software, metodologías, y herramientas.

¿Qué es Un proceso de desarrollo de software?


A. La meta de la ingeniería de software es construir productos de software, o mejorar los
existentes; en ingeniería de procesos, la meta es desarrollar o mejorar procesos.
B. Es un conjunto de personas, estructuras de organización, reglas, políticas, actividades y
sus procedimientos, componentes de software, metodologías, y herramientas.

Un proceso de software efectivo habilita a la organización a incrementar su productividad al


desarrollar software:
A. Permite estandarizar esfuerzos, promover re-uso, repetición y consistencia entre
proyectos; provee la oportunidad de introducir mejores prácticas de la industria.
B. Define cómo manejar los cambios y liberaciones a sistemas de software existentes.

Un proceso de software mejora los esfuerzos de mantenimiento y soporte:


A. Permite estandarizar esfuerzos, promover re-uso, repetición y consistencia entre
proyectos; provee la oportunidad de introducir mejores prácticas de la industria.
B. Define cómo manejar los cambios y liberaciones a sistemas de software existentes.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información

Actividades del proceso de software que son fundamentales: Especificación del software
A. Tienen que definirse tanto la funcionalidad del software como las restricciones de su
operación.
B. Debe desarrollarse el software para cumplir con las especificaciones.
C. Hay que validar el software para asegurarse de que cumple lo que el cliente quiere.
D. El software tiene que evolucionar para satisfacer las necesidades cambiantes del
cliente.

Actividades del proceso de software que son fundamentales: Diseño e implementación del
software
A. Tienen que definirse tanto la funcionalidad del software como las restricciones de su
operación.
B. Debe desarrollarse el software para cumplir con las especificaciones.
C. Hay que validar el software para asegurarse de que cumple lo que el cliente quiere.
D. El software tiene que evolucionar para satisfacer las necesidades cambiantes del
cliente.

Actividades del proceso de software que son fundamentales: Validación del software
A. Tienen que definirse tanto la funcionalidad del software como las restricciones de su
operación.
B. Debe desarrollarse el software para cumplir con las especificaciones.
C. Hay que validar el software para asegurarse de que cumple lo que el cliente quiere.
D. El software tiene que evolucionar para satisfacer las necesidades cambiantes del
cliente.

Actividades del proceso de software que son fundamentales: Evolución del software
A. Tienen que definirse tanto la funcionalidad del software como las restricciones de su
operación.
B. Debe desarrollarse el software para cumplir con las especificaciones.
C. Hay que validar el software para asegurarse de que cumple lo que el cliente quiere.
D. El software tiene que evolucionar para satisfacer las necesidades cambiantes del
cliente.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información

¿Descripción del proceso del software? Productos


A. Que son los resultados de una actividad del proceso.
B. Que reflejan las responsabilidades de la gente que interviene en el proceso.
C. Que son declaraciones válidas antes y después de que se realice una actividad del
proceso o se cree un producto.

¿Descripción del proceso del software? Roles


A. Que son los resultados de una actividad del proceso.
B. Que reflejan las responsabilidades de la gente que interviene en el proceso.
C. Que son declaraciones válidas antes y después de que se realice una actividad del
proceso o se cree un producto.

¿Descripción del proceso del software? Precondiciones y postcondiciones


A. Que son los resultados de una actividad del proceso.
B. Que reflejan las responsabilidades de la gente que interviene en el proceso.
C. Que son declaraciones válidas antes y después de que se realice una actividad del
proceso o se cree un producto.

Principales roles o involucrados en el proceso de desarrollo de software: Gerente de proyecto


A. Tiene por misión cumplir los plazos previstos del desarrollo, ofrecer las soluciones
mitigadoras de riesgos o correcciones de las desviaciones en la planificación.
B. Su objetivo es recopilar, analizar y verificar las necesidades del cliente para un sistema.
C. Es el responsable del diseño y desarrollo del software, escribe el código fuente, prueba
lo que programa.
D. Se encarga de diseñar y ejecutar las pruebas necesarias para validar las diferentes
rutinas del código fuente, en busca de errores críticos y no críticos.
E. Se encarga de estudiar y determinar las estructuras de la aplicación y las tecnologías
con las que se construirá el software.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información

Principales roles o involucrados en el proceso de desarrollo de software: Analista de


requerimientos
A. Tiene por misión cumplir los plazos previstos del desarrollo, ofrecer las soluciones
mitigadoras de riesgos o correcciones de las desviaciones en la planificación.
B. Su objetivo es recopilar, analizar y verificar las necesidades del cliente para un sistema.
C. Es el responsable del diseño y desarrollo del software, escribe el código fuente, prueba
lo que programa.
D. Se encarga de diseñar y ejecutar las pruebas necesarias para validar las diferentes
rutinas del código fuente, en busca de errores críticos y no críticos.
E. Se encarga de estudiar y determinar las estructuras de la aplicación y las tecnologías
con las que se construirá el software.

Principales roles o involucrados en el proceso de desarrollo de software: Desarrollador de


software o programador
A. Tiene por misión cumplir los plazos previstos del desarrollo, ofrecer las soluciones
mitigadoras de riesgos o correcciones de las desviaciones en la planificación.
B. Su objetivo es recopilar, analizar y verificar las necesidades del cliente para un sistema.
C. Es el responsable del diseño y desarrollo del software, escribe el código fuente, prueba
lo que programa.
D. Se encarga de diseñar y ejecutar las pruebas necesarias para validar las diferentes
rutinas del código fuente, en busca de errores críticos y no críticos.
E. Se encarga de estudiar y determinar las estructuras de la aplicación y las tecnologías
con las que se construirá el software.

Principales roles o involucrados en el proceso de desarrollo de software: Testeador


A. Tiene por misión cumplir los plazos previstos del desarrollo, ofrecer las soluciones
mitigadoras de riesgos o correcciones de las desviaciones en la planificación.
B. Su objetivo es recopilar, analizar y verificar las necesidades del cliente para un sistema.
C. Es el responsable del diseño y desarrollo del software, escribe el código fuente, prueba
lo que programa.
D. Se encarga de diseñar y ejecutar las pruebas necesarias para validar las diferentes
rutinas del código fuente, en busca de errores críticos y no críticos.
E. Se encarga de estudiar y determinar las estructuras de la aplicación y las tecnologías
con las que se construirá el software.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información

Principales roles o involucrados en el proceso de desarrollo de software: Arquitecto de


software
A. Tiene por misión cumplir los plazos previstos del desarrollo, ofrecer las soluciones
mitigadoras de riesgos o correcciones de las desviaciones en la planificación.
B. Su objetivo es recopilar, analizar y verificar las necesidades del cliente para un sistema.
C. Es el responsable del diseño y desarrollo del software, escribe el código fuente, prueba
lo que programa.
D. Se encarga de diseñar y ejecutar las pruebas necesarias para validar las diferentes
rutinas del código fuente, en busca de errores críticos y no críticos.
E. Se encarga de estudiar y determinar las estructuras de la aplicación y las tecnologías
con las que se construirá el software.

Un modelo de procesos del software


A. Es una descripción simplificada de una configuración del software que presenta una
visión de ese proceso.
B. Es una descripción simplificada de un proceso del software que presenta una visión de
ese proceso.
C. Es una descripción masificada de un proceso del software que presenta una visión de
ese proceso.

Modelo de procesos: Un modelo de flujo de trabajo.


A. Muestra la secuencia de actividades en el proceso junto con sus entradas, salidas y
dependencias.
B. Representa el proceso como un conjunto de actividades, cada una de las cuales realiza
alguna transformación en los datos.
C. Representa los roles de las personas involucrada en el proceso del software y las
actividades de las que son responsables.

Modelo de procesos: Un modelo de flujo de datos o de actividad.


A. Muestra la secuencia de actividades en el proceso junto con sus entradas, salidas y
dependencias.
B. Representa el proceso como un conjunto de actividades, cada una de las cuales realiza
alguna transformación en los datos.
C. Representa los roles de las personas involucrada en el proceso del software y las
actividades de las que son responsables.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información

Modelo de procesos: Un modelo de rol/acción.


A. Muestra la secuencia de actividades en el proceso junto con sus entradas, salidas y
dependencias.
B. Representa el proceso como un conjunto de actividades, cada una de las cuales realiza
alguna transformación en los datos.
C. Representa los roles de las personas involucrada en el proceso del software y las
actividades de las que son responsables.

Modelos de proceso de software: Enfoque en cascada.


A. Considera las actividades anteriores y las representa como fases de procesos
separados, tales como la especificación de requerimientos, el diseño del software, la
implementación, las pruebas, etcétera.
B. Este enfoque entrelaza las actividades de especificación, desarrollo y validación. Un
sistema inicial se desarrolla rápidamente a partir de especificaciones muy abstractas.
C. Esta técnica supone que las partes del sistema existen; El proceso de desarrollo del
sistema se enfoca en la integración de estas partes más que desarrollarlas desde el
principio.
D. El sistema es entregado en partes; El cliente debe de clasificar las partes de acuerdo a
su importancia; El incremento de más alta prioridad se entrega primero; Cada
incremento se pone en producción.

Modelos de proceso de software: Desarrollo iterativo.


A. Considera las actividades anteriores y las representa como fases de procesos
separados, tales como la especificación de requerimientos, el diseño del software, la
implementación, las pruebas, etcétera.
B. Este enfoque entrelaza las actividades de especificación, desarrollo y validación. Un
sistema inicial se desarrolla rápidamente a partir de especificaciones muy abstractas.
C. Esta técnica supone que las partes del sistema existen; El proceso de desarrollo del
sistema se enfoca en la integración de estas partes más que desarrollarlas desde el
principio.
D. El sistema es entregado en partes; El cliente debe de clasificar las partes de acuerdo a
su importancia; El incremento de más alta prioridad se entrega primero; Cada
incremento se pone en producción.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información

Modelos de proceso de software: Ingeniería del software basada en componentes (CBSE).


A. Considera las actividades anteriores y las representa como fases de procesos
separados, tales como la especificación de requerimientos, el diseño del software, la
implementación, las pruebas, etcétera.
B. Este enfoque entrelaza las actividades de especificación, desarrollo y validación. Un
sistema inicial se desarrolla rápidamente a partir de especificaciones muy abstractas.
C. Esta técnica supone que las partes del sistema existen; El proceso de desarrollo del
sistema se enfoca en la integración de estas partes más que desarrollarlas desde el
principio.
D. El sistema es entregado en partes; El cliente debe de clasificar las partes de acuerdo a
su importancia; El incremento de más alta prioridad se entrega primero; Cada
incremento se pone en producción.

Modelos de proceso de software: Desarrollo Incremental


A. Considera las actividades anteriores y las representa como fases de procesos
separados, tales como la especificación de requerimientos, el diseño del software, la
implementación, las pruebas, etcétera.
B. Este enfoque entrelaza las actividades de especificación, desarrollo y validación. Un
sistema inicial se desarrolla rápidamente a partir de especificaciones muy abstractas.
C. Esta técnica supone que las partes del sistema existen; El proceso de desarrollo del
sistema se enfoca en la integración de estas partes más que desarrollarlas desde el
principio.
D. El sistema es entregado en partes; El cliente debe de clasificar las partes de acuerdo a
su importancia; El incremento de más alta prioridad se entrega primero; Cada
incremento se pone en producción.

Tipos de componentes de software que pueden usarse en un proceso orientado a la


reutilización: Servicios Web
A. Que se desarrollan en concordancia para atender servicios estándares y que están
disponibles para la invocación remota.
B. Que se desarrollan como un paquete para su integración con un marco de
componentes como .NET o J2EE.
C. Que se configuran para usar en un entorno particular.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información

Tipos de componentes de software que pueden usarse en un proceso orientado a la


reutilización: Colecciones de objetos
A. Que se desarrollan en concordancia para atender servicios estándares y que están
disponibles para la invocación remota.
B. Que se desarrollan como un paquete para su integración con un marco de
componentes como .NET o J2EE.
C. Que se configuran para usar en un entorno particular.

Tipos de componentes de software que pueden usarse en un proceso orientado a la


reutilización: Sistemas de software independientes
A. Que se desarrollan en concordancia para atender servicios estándares y que están
disponibles para la invocación remota.
B. Que se desarrollan como un paquete para su integración con un marco de
componentes como .NET o J2EE.
C. Que se configuran para usar en un entorno particular.

Modelo en Cascada: El enfoque en cascada. Actividades fundamentales del desarrollo:


A. Análisis y definición de requerimientos.
B. Se precisan las tareas e iteraciones.
C. Diseño del sistema y del software.
D. Diseño de los incrementos.
E. Implementación y prueba de unidad.

Modelo en Cascada: El enfoque en cascada. Actividades fundamentales del desarrollo:


A. Validación de los incrementos.
B. Integración y prueba de sistema.
C. Entrega del producto.
D. Operación y mantenimiento.

Modelo de Diseño incremental: Actividades fundamentales del desarrollo:


A. Requerimientos.
B. Análisis.
C. Se precisan las tareas e iteraciones.
D. Diseño del sistema y del software.
E. Diseño de los incrementos.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
F. Implementación y prueba de unidad.

Modelo de Diseño incremental: Actividades fundamentales del desarrollo:


A. Desarrollo del incremento.
B. Integración y prueba de sistema.
C. Validación de los incrementos.
D. Operación.
E. Integración de los incrementos.
F. Mantenimiento.
G. Entrega del producto.
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
TALLER CLASE 3: COSTOS Y METODOS INGENIERIA DE
SOFTWARE
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
TALLER CLASE 4: HERRAMIENTAS CASE
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
TALLER CLASE 5: ATRIBUTOS DE UN BUEN SOFTWARE
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
TALLER CLASE 6: RETOS FUNDAMENTALES INGENIERÍA
SOFTWARE
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información
UNIVERSIDAD TÉCNICA DE MACHALA
D. L. No. 69-04 DE 14 DE ABRIL DE 1969
Calidad, Pertinencia y Calidez
UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
Sección / Carrera: Tecnologías de la Información

También podría gustarte