INS-ES
REV00

INGENIERÍA EN INFORMÁTICA
INGENIERÍA DE
SOFTWARE

DIRECTORIO
Mtro. Alonso Lujambio Irazábal
Secretario de Educación Pública
Dr. Rodolfo Tuirán Gutiérrez
Subsecretario de Educación Superior
Mtra. Sayonara Vargas Rodríguez
Coordinadora de Universidades Politécnicas

II

PÁGINA LEGAL
Participantes
Mtra. Rebeca Rodríguez Huesca – Universidad Politécnica de Puebla
Mtro. Pedro Vargas García – Universidad Politécnica de Puebla

Primera Edición: 2011
DR  2011 Coordinación de Universidades Politécnicas.
Número de registro:
México, D.F.
ISBN-----------------

III

ÍNDICE

INTRODUCCIÓN ............................................................................................................................................ 1
PROGRAMA DE ESTUDIOS .......................................................................................................................... 3
FICHA TÉCNICA ............................................................................................................................................. 4
DESARROLLO DE LA ACTIVIDAD DE APRENDIZAJE .................................................................................. 6
INSTRUMENTOS DE EVALUACIÓN............................................................................................................. 16
GLOSARIO ................................................................................................................................................... 25
BIBLIOGRAFÍA ............................................................................................................................................ 32

IV

INTRODUCCIÓN
La Ingeniería de Software es la rama de la ingeniería que aplica los principios de la ciencia
de la computación y las matemáticas para lograr soluciones costo-efectivas (eficaces en
costo o económicas) a los problemas de desarrollo de software", es decir, "permite elaborar
consistentemente productos correctos, utilizables y costo-efectivos"1.
El proceso de ingeniería de software se define como "un conjunto de etapas parcialmente
ordenadas con la intención de lograr un objetivo"2, en este caso, la obtención de un
producto de software de calidad.
El proceso de desarrollo de software "es aquel en que las necesidades del usuario son
traducidas en requerimientos de software, estos requerimientos transformados en diseño y
el diseño implementado en código, el código es probado, documentado y certificado para su
uso operativo". Concretamente "define quién está haciendo qué, cuándo hacerlo y cómo
alcanzar un cierto objetivo"3.
El proceso de desarrollo de software requiere por un lado un conjunto de conceptos, una
metodología y un lenguaje propio. A este proceso también se le llama el ciclo de vida del
software que comprende cuatro grandes fases: concepción, elaboración, construcción y
transición. La concepción define el alcance del proyecto y desarrolla un caso de negocio. La
elaboración define un plan del proyecto, especifica las características y fundamenta la
arquitectura. La construcción crea el producto y la transición transfiere el producto a los
usuarios.
Las metodologías de desarrollo de software son un conjunto de procedimientos, técnicas y
ayudas a la documentación para el desarrollo de productos software
Las técnicas indican cómo debe ser realizada una actividad técnica determinada
identificada en la metodología. Combina el empleo de unos modelos o representaciones
1

Cota A. 1994 "Ingeniería de Software". Soluciones Avanzadas. Julio de 1994. pp. 5-13.
Jacobson, I. 1998. "Applying UML in The Unified Process" Presentación. Rational Software
3
Jacobson, I. 1998. "Applying UML in The Unified Process" Presentación. Rational Software
2

1

gráficas junto con el empleo de unos procedimientos detallados. Se debe tener en
consideración que una técnica determinada puede ser utilizada en una o más actividades
de la metodología de desarrollo de software.
De esta manera, la asignatura enseña de forma ordenada los pasos a seguir para el
desarrollo de un sistema de información, desde su concepción hasta su diseño. Los
métodos y técnicas necesarios en cada fase se introducen mediante la realización de casos
prácticos, basados en escenarios reales que serán planteados por el propio alumno.

El propósito de este curso es que el alumno realice proyectos de software implementando
metodologías y herramientas de calidad para garantizar el desarrollo de aplicaciones que
cumplan con los requerimientos del cliente, para lo cual se tomará como base dos
asignaturas previas: el análisis y el diseño de sistemas, en donde ya se obtuvieron los
requisitos y se eligió un modelo de diseño.

2

PROGRAMA DE ESTUDIOS
NOMBRE DEL PROGRAMA EDUCATIVO:
OBJETIVO DEL PROGRAMA EDUCATIVO:
NOMBRE DE LA ASIGNATURA:
CLAVE DE LA ASIGNATURA:
OBJETIVO DE LA ASIGNATURA:
TOTAL HRS. DEL CUATRIMESTRE:
FECHA DE EMISIÓN:
UNIVERSIDADES PARTICIPANTES:

PROGRAMA DE ESTUDIO
DATOS GENERALES
Ingeniería en Informática
Formar ingenieros competentes en la implementación y administración de soluciones de negocios o para la investigación basadas en computadora, con una amplia visión de la ciencia y las nuevas tecnologías de la información, bajo el modelo de educación basado en competencias.
Ingeniería de software
INS-ES
El alumno será capaz de realizar proyectos de software implementando metodologías y herramientas de calidad para garantizar el desarrollo de aplicaciones que cumplan con los requerimientos del cliente.
105
31 de mayo de 2011
UPEMOR,UPPuebla, UPSIN, UPVM, UPVT

CONTENIDOS PARA LA FORMACIÓN

ESTRATEGIA DE APRENDIZAJE
TECNICAS SUGERIDAS

UNIDADES DE APRENDIZAJE

1. Desarrollo rápido de software

2. Documentación del software

3. Técnicas de verificación y validación

4. Evolución del software

RESULTADOS DE APRENDIZAJE

Al completar la unidad, el alumno será
capaz de:
*Realizar códigos ejecutables para el
desarrollo de un sistema de información o
un software rápido.

EVIDENCIAS

EC1. Cuestionario sobre
desarrollo rápido de
software.
EP1: Reporte de práctica
para realizar código
ejecutable para el
desarrollo de sistemas de
información.

EP1: Realiza el manual
técnico del sistema de
Al completar la unidad, el alumno será
información desarrollado.
capaz de:
* Elaborar la documentación técnica
EP2. Realiza el manual de
asociada a cada una de las fases del sistema
usuario del sistema de
de información y el manual de usuario.
información desarrollado.

Al completar la unidad, el alumno será
capaz de:
* Realizar pruebas a los códigos de un
sistema para verificar y validar el software.

Al completar la unidad, el alumno será
capaz de:
* Elaborar un plan de gestión de la
configuración del software, que contenga los
diferentes tipos de mantenimiento y los
factores que afectan en el costo para
implementarlo.

EC1. Cuestionario sobre
técnicas de verificación y
validación.
ED1: Práctica sobre
pruebas del código del
sistema a diferentes
niveles con los enfoques
de caja blanca y caja
negra.
EP1: Elabora reporte de
práctica sobre el plan de
gestión de la
configuración del
software de acuerdo al
tipo de mantenimiento
que se puede
implementar.
ED1. Presentación del
plan de gestión.

PARA LA
ENSEÑANZA
(PROFESOR)

PARA EL
APRENDIZAJE
(ALUMNO)

Estudio de caso,
Resolver
situaciones
problemáticas,
Ensayo, foro

Aprendizaje basado en
problemas, dinámica de
grupos

Estudio de caso,
Resolver
situaciones
problemáticas,
Ensayo, foro

Estudio de caso,
Resolver
situaciones
problemáticas,
Ensayo, foro

Estudio de caso,
Resolver
situaciones
problemáticas,
Ensayo, foro

Aprendizaje basado en
problemas, dinámica de
grupos

Aprendizaje basado en
problemas, dinámica de
grupos

Aprendizaje basado en
problemas, dinámica de
grupos

ESPACIO EDUCATIVO

AULA

X

X

X

X

LABORATORIO

X

X

X

X

EVALUACIÓN

MOVILIDAD FORMATIVA

OTRO

X

X

X

X

PROYECTO

PRÁCTICA

TOTAL DE HORAS
MATERIALES
REQUERIDOS

EQUIPOS
REQUERIDOS

OBSERVACIÓN
TEÓRICA
Presencial

X

X

X

X

Código
ejecutable para
el desarrollo de
sistemas de
información.

Material
bibliográfico e
impreso,
Computadora,
marcadores,
proyector, pizarrón
lapiceros, plumas,
interactivo, pizarrón.
borrador, lápices,
hojas, cuaderno,
carpetas.

Manual técnico
y del usuario

Material
bibliográfico e
impreso,
Computadora,
marcadores,
proyector, pizarrón
lapiceros, plumas,
interactivo, pizarrón.
borrador, lápices,
hojas, cuaderno,
carpetas.

Casos de
prueba bajo los
enfoques de
caja blanca y
caja negra

Material
bibliográfico e
impreso,
Computadora,
marcadores,
proyector, pizarrón
lapiceros, plumas,
interactivo, pizarrón.
borrador, lápices,
hojas, cuaderno,
carpetas, software

Plan de gestión
de la
configuración
del software

Material
bibliográfico e
impreso,
Computadora,
marcadores,
proyector, pizarrón
lapiceros, plumas,
interactivo, pizarrón.
borrador, lápices,
hojas, cuaderno,
carpetas, software

8

PRÁCTICA

NO
Presencial

4

Presencial

8

NO
Presencial

8

TÉCNICA

INSTRUMENTO

Documental

*Cuestionario guía sobre
desarrollo rápido de software.
*Lista de cotejo para reporte
de práctica donde realiza un
código ejecutable para el
desarrollo de sistemas de
información.

Documental
8

4

8

Elegir el entorno de
desarrollo del acuerdo
con la solución
planteada

*Lista de cotejo para la
elaboración de manual
técnico del sistema de
información desarrollado.

8

N/A
*Lista de cotejo para la
elaboración de manual de
usuario del sistema de
información desarrollado.

8

6

4

3

8

6

8

6

Documental y de
campo

Documental y de
campo

*Cuestionario guía sobre
técnicas de verificación y
validación.
*Guía de observación para
práctica sobre pruebas del
código del sistema a
diferentes niveles con los
enfoques de caja blanca y
caja negra.
*Lista de cotejo para reporte
de práctica sobre el plan de
gestión de la configuración
del software de acuerdo al
tipo de mantenimiento que se
puede implementar.

Se sugieren las pruebas
de Camino básico,
Dataflow, Sintax y Finite
state Machine testing

N/A

*Guía de observación para
presentación del plan de
gestión.

3

FICHA TÉCNICA
INGENIERÍA DE SOFTWARE
Nombre:

Ingeniería de software

Clave:

INS – ES

Justificación:

El proceso de desarrollo de software requiere de una gestión que permita una
pertinencia entre los recursos invertidos y los beneficios a obtener, además de
garantizar que los resultados se obtengan con la oportunidad, forma y calidad
requeridas por la empresa. Es por ello que un Ingeniero en Informática utilice
métodos, técnicas y herramientas que faciliten medir, estimar, controlar la
calidad, realizar pruebas y documentar proyectos de software.

Objetivo:

El alumno será capaz de realizar proyectos de software implementando
metodologías y herramientas de calidad para garantizar el desarrollo de
aplicaciones que cumplan con los requerimientos del cliente.


Habilidades:







Competencias
genéricas a
desarrollar:

Utilizar sistemas de información mediante tecnologías locales y/o web para
eficientar los procesos de la organización.
Realizar análisis detallado de sistemas.
Diseñar el modelado del sistema requerido.
Elaborar programas de computadora usando algún lenguaje de
programación.
Implantar sistemas de información.
Creatividad, confidencialidad, administración de recursos, orden, limpieza,
puntualidad, empatía, responsabilidad, trabajo en equipo, liderazgo,
honestidad, analítico, comunicación oral y escrita, comprensión del idioma
inglés.

Análisis y síntesis para: aprender, resolver problemas, aplicar los conocimientos
en la práctica y trabajar en forma autónoma y en equipo.

Competencias a las que contribuye la
asignatura

Capacidades a desarrollar en la asignatura







Especificar requerimientos del sistema
mediante el análisis de procesos de la
organización para detectar necesidades y
áreas de oportunidad en el desarrollo de la
aplicación de software.
Diseñar sistemas de información a través de
técnicas de modelado para especificar las
características del sistema a desarrollar.
Especificar requerimientos del sistema
mediante el análisis de procesos para
detectar áreas de oportunidad en el desarrollo
de aplicaciones Web
Diseñar sistemas de información a través de
técnicas de modelado para especificar las
características del sistema Web a desarrollar.





Desarrollar aplicaciones de software mediante
lenguajes especializados para eficientar los
procesos de las organizaciones.
Desarrollar aplicaciones web mediante
lenguajes especializados para eficientar los
procesos de las organizaciones
Diseñar la función informática mediante
estándares para el aprovechamiento de las
TIC

4




Especificar la situación actual de la empresa
mediante el análisis de la función informática
usando estándares de calidad
Diseñar el modelo de la función informática
mediante estándares para aprovechar los
recursos informáticos de manera eficiente.

Unidades de aprendizaje
Estimación de
tiempo (horas)
necesario para
transmitir el
aprendizaje al
alumno, por
Unidad de
Aprendizaje:

HORAS TEORÍA
HORAS PRÁCTICA
No
No
Presencial presencial Presencial presencial

Desarrollo rápido de
software

8

4

8

8

Documentación del
software

8

4

8

8

Técnicas de verificación
y validación

8

4

8

8

Evolución del software

6

3

6

6

Total de horas por cuatrimestre:
Total de horas por semana:
Créditos:

105
7
6

5

DESARROLLO DE LA ACTIVIDAD DE APRENDIZAJE
CÓDIGO EJECUTABLE

Nombre de la asignatura:
Nombre de la Unidad de
Aprendizaje:
Nombre de la actividad
de aprendizaje:

Ingeniería de software

I.

Código ejecutable bajos ciertas especificaciones

Número:
Resultado de aprendizaje:
Requerimientos (Material
o equipo):

Desarrollo rápido de software

1/2
-

Duración (horas) :

2

Realizar códigos ejecutables para el desarrollo de un sistema de
información o un software rápido

Computadora, material bibliográfico impreso, software para desarrollar.

Actividades a desarrollar:
Implementar el diseño de un sistema de información basado en computadora, para lo cual, utiliza el
lenguaje de programación que se ajuste a las necesidades del proyecto:
1. Crear la base de datos de acuerdo con el modelo físico previamente construido.
2. Implementar el diseño arquitectónico, para lo cual se recomienda usar uno de los siguientes
modelos:
 Métodos ágiles
 Programación extrema
 Desarrollo rápido de aplicaciones
 Prototipado del software
Para la implementación se deben retomar los productos que se habían generado en la etapa de
diseño como:
a) Diagrama de clases
b) Casos de uso
c) Diagrama de actividades
d) Diagrama de componentes
e) Diagrama de secuencias
Evidencias a las que contribuye el desarrollo de la práctica:
EP1: Reporte de práctica para realizar código ejecutable para el desarrollo de sistemas de información.

6

DESARROLLO DE LA ACTIVIDAD DE APRENDIZAJE
CUESTIONARIO SOBRE DESARROLLO RÁPIDO DE SOFTWARE

Nombre de la asignatura:
Nombre de la Unidad de
Aprendizaje:
Nombre de la actividad
de aprendizaje:
Número:

Ingeniería de software

I.

Desarrollo rápido de software

Cuestionario sobre desarrollo rápido de software
2/2

Duración (horas) :

4

Resultado de
aprendizaje:

Realizar códigos ejecutables para el desarrollo de un sistema de
información o un software rápido

Requerimientos (Material
o equipo):

Computadora, proyector, pizarrón interactivo, material impreso o
bibliográfico.

Actividades a desarrollar:
Una vez que se hayan analizado las ventajas y posibilidades que brindan los modelos de desarrollo
rápido que se pueden utilizar en elimplementación del sistema de información, resolver el cuestionario
relacionado a esos aspectos.
Evidencias a las que contribuye el desarrollo de la práctica:
EC1. Cuestionario sobre desarrollo rápido de software.

7

DESARROLLO DE LA ACTIVIDAD DE APRENDIZAJE
MANUAL TÉCNICO DEL SISTEMA DESARROLLADO

Nombre de la asignatura:
Nombre de la Unidad de
Aprendizaje:
Nombre de la actividad
de aprendizaje:
Número:
Resultado de
aprendizaje:
Requerimientos (Material
o equipo):

Ingeniería de software

II.

Documentación del software

Manual técnico del sistema desarrollado.
1/2

Duración (horas) :

9

Elaborar la documentación técnica asociada a cada una de las fases del
sistema de información desarrollado, además del manual de usuario.
Computadora, material impreso o bibliográfico.

Actividades a desarrollar:
Este es uno de los documentos más importantes que se generan durante el desarrollo de un proyecto,
debido a que contiene toda la información respecto al mismo, cómo es que se llegó a la solución,
metodología seguida para el mismo. Es por eso que es necesario prestar especial atención en el
desarrollo del mismo, ya que de esto dependerá que se pueda dar mantenimiento al mismo una vez
concluida la fase de desarrollo en la cual se encuentre el sistema.
Las consideraciones generales para su elaboración son:
 Logotipo de la empresa.
 Nombre oficial de la empresa
 Departamento o área responsable
 Lugar y fecha de elaboración.
 Número de revisión (en su caso).
 Personas responsables de su elaboración, revisión y/o autorización.
El documento debe estructurarse en las siguientes secciones:
1. Índice
2. Introducción: una breve descripción del sistema desarrollado, que contemple el ámbito
abarcado, cuál es su función principal y un detalle de las funciones macros o partes que lo
componen.
3. Objetivo general y específicos del sistema
4. Contenido técnico, formado a su vez por:
 Análisis de requerimientos, el cual debe mostrar las reglas del negocio implementadas en
el sistema desarrollado.
 Modelado del diseño, que debe contener diseño de la arquitectura, de datos y de la
interfaz
 Controles de auditoría implementados en el sistema.
5. Plataforma de usuario. Aquí se describen los requerimientos mínimos que se deben tener
tanto de hardware como de software para que el sistema se pueda instalar y ejecutar

8

correctamente (en caso de que se considere necesario).
6. Áreas de aplicación y/o alcance de los procedimientos. Esfera de acción que cubren las
implementadas
Evidencias a las que contribuye el desarrollo de la práctica:
EP1: Realiza el manual técnico del sistema de información desarrollado.

9

DESARROLLO DE LA ACTIVIDAD DE APRENDIZAJE
MANUAL DE USUARIO DEL SISTEMA DESARROLLADO

Nombre de la asignatura:

Ingeniería de software

Nombre de la Unidad de
Aprendizaje:
Nombre de la actividad
de aprendizaje:
Número:
Resultado de
aprendizaje:
Requerimientos (Material
o equipo):

II.

Documentación del software

Manual de usuario del sistema desarrollado
2/2

Duración (horas) :

6

Elaborar la documentación técnica asociada a cada una de las fases del
sistema de información desarrollado, además del manual de usuario.
Computadora, material impreso o bibliográfico.

Actividades a desarrollar:
El manual de usuario no es menos importante que el manual técnico, pues en este caso éste permitirá
a las personas que utilizarán el sistema aprovechar al máximo su funcionalidad.
Las secciones recomendadas para su elaboración son:
1. Introducción
2. Objetivo del manual
3. Personas a las que está dirigido
4. Organización del manual y convenciones que se utilizarán en el mismo
5. Requerimientos técnicos para su instalación en cuanto a hardware y software
6. Proceso de instalación
7. Acceso al sistema
8. Operación del sistema, donde se incluirá toda la funcionalidad del mismo
Evidencias a las que contribuye el desarrollo de la práctica:
EP1: Realiza el manual de usuario del sistema de información desarrollado

10

DESARROLLO DE LA ACTIVIDAD DE APRENDIZAJE
CASOS DE PRUEBA BAJO LOS ENFOQUES DE CAJA BLANCA Y CAJA NEGRA

Nombre de la asignatura:
Nombre de la Unidad de
Aprendizaje:
Nombre de la actividad
de aprendizaje:

Ingeniería de software

III.

Técnicas de verificación y validación

Casos de prueba bajo los enfoques de caja blanca y caja negra

Número:

1/2

Resultado de
aprendizaje:
Requerimientos (Material
o equipo):
Actividades a desarrollar:

Duración (horas) :

6

Realizar pruebas a los códigos de un sistema para verificar y validar el
software.
Computadora, material impreso o bibliográfico.

El proceso de pruebas es un proceso complejo que comprende varios niveles:
1. Pruebas de unidad, las cuales se centran en la lógica de procesamiento interno y en las

estructuras de datos dentro de los límites de un componente. Dentro de este tipo se deberán:
 Desarrollar y aplicar técnicas de prueba de caja blanca, como son:
 Prueba del camino básico
 Data flowtesting
 Desarrollar y aplicar técnicas de prueba de caja negra, como son:
 Prueba de sintáxis
 Prueba de transición de estados
2. Pruebas de integración, en este caso se puede utilizar alguno de los siguientes métodos:


Top-down integration and testing



Botton-up testing and integration

 Prueba de humo
3. Pruebas de validación, para lo cual se pueden emplear las pruebas alfa o beta
4. Pruebas del sistema, se recomienda aplicar uno o más de las siguientes:


Prueba de recuperación



Prueba de seguridad



Prueba de resistencia



Prueba de desempeño

La aplicación de las pruebas en los diferentes niveles permitirá garantizar la calidad del sistema.
Evidencias a las que contribuye el desarrollo de la práctica:
ED1: Práctica sobre pruebas del código del sistema a diferentes niveles con los enfoques de caja blanca
y caja negra.

11

DESARROLLO DE LA ACTIVIDAD DE APRENDIZAJE
CUESTIONARIO SOBRE TÉCNICAS DE VERIFICACIÓN Y VALIDACIÓN

Nombre de la asignatura:
Nombre de la Unidad de
Aprendizaje:
Nombre de la actividad
de aprendizaje:
Número:
Resultado de
aprendizaje:
Requerimientos (Material
o equipo):

Ingeniería de software

III.

Técnicas de verificación y validación

Cuestionario sobre técnicas de verificación y validación
2/2

Duración (horas) :

3

Realizar pruebas a los códigos de un sistema para verificar y validar el
software.
Computadora, material impreso o bibliográfico

Actividades a desarrollar:
Una vez que se hayan analizado las diferentes técnicas de prueba y los niveles de aplicación, resolver el
cuestionario relacionado a esos aspectos.

Evidencias a las que contribuye el desarrollo de la práctica:
EC1. Cuestionario sobre técnicas de verificación y validación.

12

DESARROLLO DE LA ACTIVIDAD DE APRENDIZAJE
PLAN DE GESTIÓN DE LA CONFIGURACIÓN

Nombre de la asignatura:
Nombre de la Unidad de
Aprendizaje:
Nombre de la actividad
de aprendizaje:
Número:

Ingeniería de software

IV.

Evolución del software

Plan de gestión de la configuración
1/2

Duración (horas) :

3

Resultado de
aprendizaje:

Elaborar un plan de gestión de la configuración del software, que contenga
los diferentes tipos de mantenimiento y los factores que afectan en el costo
para implementarlo.

Requerimientos (Material
o equipo):

Computadora, material impreso o bibliográfico

Actividades a desarrollar:
La Gestión de Configuración es el proceso de identificar y definir los elementos en el sistema, controlando
el cambio de estos elementos a lo largo de su ciclo de vida, registrando y reportando el estado de los
elementos y las solicitudes de cambio, y verificando que los elementos estén completos y que sean los
correctos.
El propósito de la Gestión de Configuración del Software es establecer y mantener la integridad de los
productos de software a través del ciclo de vida del proceso de software.
Algunos de los elementos de Configuración en un proyecto de software son :
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.

El plan de proyecto.
El documento de definición de requerimientos.
Estándares de análisis, diseño, codificación, pruebas, y auditoria.
Documentos de análisis del sistema.
Documentos de diseño del sistema.
Prototipos.
Documentos de diseño de bajo y alto nivel
El plan de pruebas del sistema.
El Código fuente del programa.
Código objeto y ejecutable.
Documentos de diseño de base de datos.
Manuales de usuario.

Los elementos del plan de gestión de la configuración recomendados son:
 Introducción:
Este incluye el propósito, ámbito, definiciones, acrónimos, abreviaciones,
referencias, y un resumen ejecutivo de este documento
 Administración de la configuración: conformada por:
o Organización, Responsabilidades, e Interfaces

13

o Herramientas, Entorno, e Infraestructura
Programa de Administración de la Configuración, que incluye:
o Identificación de la Configuración con líneas base
o Proceso de petición de cambios y aprobación
o políticas de retención, de respaldos, desastres y planes de recuperación
 Fases: debe incluir detalles de actualizaciones del plan.
 Capacitación y Recursos: describir las herramientas de software, personal y capacitación
necesarias para implementar las actividades de gestión de la configuración especificadas
Evidencias a las que contribuye el desarrollo de la práctica:


EP1: Elabora reporte de práctica sobre el plan de gestión de la configuración del software de acuerdo al
tipo de mantenimiento que se puede implementar.

14

DESARROLLO DE LA ACTIVIDAD DE APRENDIZAJE
PRESENTACIÓN DEL PLAN DE GESTIÓN

Nombre de la asignatura:
Nombre de la Unidad de
Aprendizaje:
Nombre de la actividad
de aprendizaje:
Número:

Ingeniería de software

IV.

Evolución del software

Presentación del plan de gestión
2/2

Duración (horas) :

3

Resultado de
aprendizaje:

Elaborar un plan de gestión de la configuración del software, que contenga
los diferentes tipos de mantenimiento y los factores que afectan en el costo
para implementarlo.

Requerimientos (Material
o equipo):

Computadora, material impreso o bibliográfico

Actividades a desarrollar:
Presentar por equipos su plan de gestión de la configuración, resaltando el tipo de mantenimiento que se
planea utilizar
Evidencias a las que contribuye el desarrollo de la práctica:
ED1. Presentación del plan de gestión.

15

16

CUESTIONARIO GUÍA SOBRE DESARROLLO
RÁPIDO DE SOFTWARE

Logotipo de la
Universidad

DATOS GENERALES DEL PROCESO DE EVALUACIÓN
Nombre de la asignatura:

Código:

Nombre del alumno:

Firma del alumno:

Matricula::

Programa educativo::

Nombre del profesor:

Grupo:

Fecha:

Firma del profesor:

1. ¿Cuáles son las actividades genéricas del modelo de desarrollo rápido de
aplicaciones?
2. ¿A qué se refiere la agilidad en el contexto del trabajo de la ingeniería del software?
3. ¿Cuáles son los aspectos clave que deben existir entre la gente que integra un
equipo de software efectivo?
4. ¿Cuáles son los aspectos que resalta la filosofía ágil?
5. Realiza una tabla comparativa entre 3 modelos de proceso ágil que conozcas

17

LISTA DE COTEJO PARA REPORTE DE
PRÁCTICA PARA CÓDIGO EJECUTABLE PARA EL

Logotipo de la
Universidad

DESARROLLO DE SISTEMAS DE INFORMACIÓN

DATOS GENERALES DEL PROCESO DE EVALUACIÓN

Nombre(s) del alumno(s):

Matrícula:

Firma del alumno(s):

Producto:

Nombre del Proyecto :

Fecha:

Asignatura:

Periodo cuatrimestral:

Nombre del Profesor:

Firma del Profesor:
INSTRUCCIONES

Revisar los documentos o actividades que se solicitan y marque en los apartados “SI” cuando la evidencia a evaluar se cumple; en caso contrario marque “NO”.
En la columna “OBSERVACIONES” ocúpela cuando tenga que hacer comentarios referentes a lo observado.
Valor del
reactivo

CUMPLE

Característica a cumplir (Reactivo)

SI

5%

Desempeño. Entrega la evidencia a tiempo, con orden, limpieza
sin errores de ortografía.

10%

Notación. Utiliza los estructuras de control correctamente

50%

Eficacia: resuelve el problema utilizando las estructuras de
control de manera que el programa obtenga los resultados
esperados

20%

Estructura. Divide los programas en funciones manejables y que
puedan utilizarse en varias secciones del programa

15%

Documentación: Documenta el programa utilizando comentarios
de prólogo y descriptivos por bloques de código.

100%
NOTAS:
-

NO

NA

OBSERVACIONES

CALIFICACIÓN:
Los reactivos sombreados deberán ser cumplidos obligatoriamente para que se considere aprobada la evidencia.

18

LISTA DE COTEJO PARA LA ELABORACIÓN DE
MANUAL TÉCNICO

Logotipo de la
Universidad

DATOS GENERALES DEL PROCESO DE EVALUACIÓN

Nombre(s) del alumno(s):

Matrícula:

Firma del alumno(s):

Producto:

Nombre del Proyecto :

Fecha:

Asignatura:

Periodo cuatrimestral:

Nombre del Profesor:

Firma del Profesor:
INSTRUCCIONES

Revisar los documentos o actividades que se solicitan y marque en los apartados “SI” cuando la evidencia a evaluar se cumple; en caso contrario marque “NO”.
En la columna “OBSERVACIONES” ocúpela cuando tenga que hacer comentarios referentes a lo observado.

CUMPLE

Valor del
reactivo

Característica a cumplir (Reactivo)

5%

Presentación. Entrega la evidencia a tiempo, con orden, limpieza
sin errores de ortografía.

10%

Estructura: Indica el propósito del escrito, el acercamiento al
tema y la organización que seguirá el manual

50%

Contenido temático: presenta todas las secciones recomendadas
para su elaboración y en el orden correcto

20%

Notación: Utiliza los símbolos de acuerdo con la metodología
propuesta para los diagramas presentados

15%

Uso correcto e idiomático del lenguaje: utiliza un lenguaje formal
para expresar sus ideas

100.%
NOTAS:
-

SI

NO

NA

OBSERVACIONES

CALIFICACIÓN:
Los reactivos sombreados deberán ser cumplidos obligatoriamente para que se considere aprobada la evidencia.

19

LISTA DE COTEJO PARA LA ELABORACIÓN DE
MANUAL DE USUARIO

Logotipo de la
Universidad

DATOS GENERALES DEL PROCESO DE EVALUACIÓN

Nombre(s) del alumno(s):

Matrícula:

Firma del alumno(s):

Producto:

Nombre del Proyecto :

Fecha:

Asignatura:

Periodo cuatrimestral:

Nombre del Profesor:

Firma del Profesor:
INSTRUCCIONES

Revisar los documentos o actividades que se solicitan y marque en los apartados “SI” cuando la evidencia a evaluar se cumple; en caso contrario marque “NO”.
En la columna “OBSERVACIONES” ocúpela cuando tenga que hacer comentarios referentes a lo observado.

CUMPLE

Valor del
reactivo

Característica a cumplir (Reactivo)

5%

Presentación. Entrega la evidencia a tiempo, con orden, limpieza
sin errores de ortografía.

10%

Estructura: Indica el propósito del escrito, el acercamiento al
tema y la organización que seguirá el manual

50%

Contenido temático: presenta todas las funciones
implementadas y descritas en el análisis de requerimientos, en
el orden correcto

20%

Facilidad de uso: presenta información breve y concisa, pero que
ayuda a resolver un problema puntual en el uso del sistema

15%

Uso correcto e idiomático del lenguaje: utiliza un lenguaje formal
para expresar sus ideas

100.%
NOTAS:
-

SI

NO

NA

OBSERVACIONES

CALIFICACIÓN:
Los reactivos sombreados deberán ser cumplidos obligatoriamente para que se considere aprobada la evidencia.

20

CUESTIONARIO GUÍA SOBRE TÉCNICAS DE
VERIFICACIÓN Y VALIDACIÓN

Logotipo de la
Universidad

Indica si la sentencia es verdadera o falsa
1. El SQA engloba una estrategia de prueba multiescalada

(

)

2. El objetivo de la garantía de la calidad es proporcionar la gestión
para informar de los datos necesarios sobre la calidad del producto

(

)

3. Pasos de la inspección desarrollada por Fagan en 1972 son Análisis
y Diseño

(

)

4. La visión de la calidad que puede ser reconocida pero no definida
es la del Usuario

(

)

5. Un factor de acuerdo con el Modelo de Calidad de McCall que se
refiere a la Revisión del producto es la Flexibilidad

(

)

6. El término Verificación responde a la pregunta ¿Estamos
construyendo el producto correcto?

(

)

7. Las pruebas facilitan verificar los dominios de E/S del programa,
rendimiento y comportamiento

(

)

8. Un buen caso de prueba es aquel que muestra que no hay errores

(

)

9. Las pruebas de caja negra son aquellas que normalmente se llevan
a cabo sobre la interfaz

(

)

10. Las pruebas de caja blanca también se conocen como
estructurales

(

)

21

GUÍA DE OBSERVACIÓN PARA PRÁCTICA
SOBRE PRUEBAS DEL CÓDIGO DEL SISTEMA

Logotipo de la
Universidad

A DIFERENTES NIVELES CON LOS ENFOQUES
DE CAJA BLANCA Y CAJA NEGRA
DATOS GENERALES DEL PROCESO DE EVALUACIÓN
Nombre(s) del alumno(s):

Matrícula:

Firma del alumno(s):

Asignatura:

Fecha:

Periodo cuatrimestral:

Nombre del profesor:

Firma del profesor:

INSTRUCCIONES
Revisar los documentos o actividades que se solicitan y marque en los apartados “SI” cuando la evidencia a evaluar se cumple; en caso contrario marque “NO”.
En la columna “OBSERVACIONES” realice comentarios referentes a lo observado.
Valor del

CUMPLE

Característica a cumplir (Reactivo)

reactivo

SI

NO

OBSERVACIONES

Técnica
20%

El alumno usa el mínimo de instrucciones necesarias.

40%

El alumno realiza las pruebas del código del sistema a diferentes niveles con enfoque de
caja blanca y caja negra.

10%

El alumno identifica el código.

10%

El alumno maneja la sintaxis de forma adecuada.
Desempeño

10%

El alumno realiza las modificaciones con rapidez suficiente.
Presentación

10%

100%

El alumno da un nombre adecuado a las variables usadas. Además comenta
adecuadamente el programa.
CALIFICACIÓN:

22

LISTA DE COTEJO PARA REPORTE DE
PRÁCTICA SOBRE LA ELABORACIÓN DEL PLAN
DE GESTIÓN DE LA CONFIGURACIÓN DEL

Logotipo de la
Universidad

SOFTWARE

DATOS GENERALES DEL PROCESO DE EVALUACIÓN

Nombre(s) del alumno(s):

Matrícula:

Firma del alumno(s):

Producto:

Nombre del Proyecto :

Fecha:

Asignatura:

Periodo cuatrimestral:

Nombre del Profesor:

Firma del Profesor:
INSTRUCCIONES

Revisar los documentos o actividades que se solicitan y marque en los apartados “SI” cuando la evidencia a evaluar se cumple; en caso contrario marque “NO”.
En la columna “OBSERVACIONES” ocúpela cuando tenga que hacer comentarios referentes a lo observado.

CUMPLE

Valor del
reactivo

Característica a cumplir (Reactivo)

5%

Presentación. Entrega la evidencia a tiempo, con orden, limpieza
sin errores de ortografía.

10%

Estructura: Indica el propósito del escrito, el acercamiento al
tema y la organización que seguirá el plan

50%

Contenido temático: presenta todas las secciones recomendadas
para su elaboración y en el orden correcto

20%

Cobertura: el plan considera todos los productos de trabajo
generados durante el proyecto o al menos los más críticos

15%

Uso correcto e idiomático del lenguaje: utiliza un lenguaje formal
para expresar sus ideas

100.%
NOTAS:
-

SI

NO

NA

OBSERVACIONES

CALIFICACIÓN:
Los reactivos sombreados deberán ser cumplidos obligatoriamente para que se considere aprobada la evidencia.

23

GUÍA DE OBSERVACIÓN PARA PRESENTACIÓN
DEL PLAN DE GESTIÓN.

Logotipo de la
Universidad

INSTRUCCIONES: Anote en el cuadro correspondiente el número que se ajuste a la
percepción que se tiene del trabajo realizado.
1. No competente
2. Básico umbral
3. Básico Avanzado
4. Independiente
5. Competente
No.

Acciones a Evaluar

Ponderación

Observaciones

Presentación
1

El alumno presenta su equipo y/o a sí mismo

2

Presenta el tema y/o ejercicio de su exposición

11

Participación
Los participantes motivan al resto del grupo
generando un ambiente de entusiasmo por el
aprendizaje
Comparten su experiencia concentrándose en el tema
Los participantes responden las preguntas del grupo
enfocando sus comentarios al tema abordado
Los participantes responden las preguntas del
facilitador
Transmiten las ideas de forma clara y concreta
Predomina la participación de un estudiante y no del
grupo
Técnica
Utilizaron información del tema para resolver la
problemática planteada
El desarrollo del problema/ejercicio siguió una
estructura adecuada
La solución del problema fue correcta

12

Presentaron conclusiones de su exposición

3
4
5
6
7
8

9
10

Desempeño
13

Presentaron la solución del problema a tiempo

14

La organización del o los participantes fue adecuada

15

La explicación del tema(s) fue clara

24

GLOSARIO
A
Actor: Un papel específico adoptado por el usuario de una aplicación mientras participa en
un caso de uso.
Administración del proyecto: Proceso de mantener y administrar las diferentes versiones de
los distintos artefactos de un proyecto de software.
Agenda: Lista de todas las tareas asociadas con el proyecto específico.
Agilidad: La ingeniería de software ágil combina una filosofía y un conjunto de directrices de
desarrollo. La filosofía busca la satisfacción del cliente y la entrega temprana del software
incremental, equipos de proyecto pequeños y con alta motivación, métodos informales, un
mínimo de productos de trabajo.
Alcance (de un proyecto): Es la suma total de todos los productos y sus requisitos o
características. Se utiliza a veces para representar la totalidad de trabajo necesitado para
dar por terminado un proyecto.
Análisis de requerimientos: Proceso de obtener una declaración escrita completa de la
funcionalidad, apariencia, desempeño y comportamiento que requiere la aplicación.
Analista de sistemas: Individuo responsable de investigar, planear, coordinar y recomendar
opciones de software y sistemas para cumplir los requerimientos de una empresa de
negocios.
Aplicación: Tipo de programa informático diseñado como herramienta para permitir a un
usuario realizar uno o diversos tipos de trabajo.
Árbol de decisión: Diagrama que representa en forma secuencial las condiciones y acciones
facilitando la comunicación entre los analistas.
Arquitectura del software: Un diseño global de una aplicación que incluye su descomposición
en partes.
Artefacto: Cualquier tipo de datos, código fuente o información producida o usada por un
desarrollador durante el proceso de desarrollo; se usa en particular al describir un proceso
de desarrollo de software unificado.
Atributo: Variable de una clase como un todo.

25

C
Calidad del software: Es el grado en el que un conjunto de características inherentes cumple
con los requisitos
Cascada: Proceso de desarrollo de software en el cual primero se recolectan los
requerimientos, se desarrolla un diseño, el diseño se convierte en código y después se
prueba. Esto se hace en secuencia, con un pequeño traslape entre las etapas sucesivas.
Casos de uso: Secuencia de acciones, algunas realizadas por una aplicación y otras por el usuario,
que son comunes al usar la aplicación; el usuario tiene un papel particular en esta interacción y
recibe el nombre de “actor” respecto al caso de eso.

Ciclo de vida: Describe el desarrollo de software, desde la fase inicial hasta la fase final. El
propósito de este programa es definir las distintas fases intermedias que se requieren para
validar el desarrollo de la aplicación, es decir, para garantizar que el software cumpla los
requisitos para la aplicación y verificación de los procedimientos de desarrollo: se asegura
de que los métodos utilizados son apropiados.
D
Database Management Systems (DBMS): Sistema de administración de base de datos para
organizar y tener acceso a los datos.
Desarrollo de aplicaciones rápido: Proceso de desarrollar con rapidez una aplicación, o parte
de ella, que puede implicar sacrificar la documentación o el diseño adecuados o la
posibilidad de ampliarla.
Desarrollo de software (o sistemas): Significa construir el sistema mediante su descripción.
Está es una muy buena razón para considerar la actividad de desarrollo de software como
una ingeniería. En un nivel más general, la relación existente entre un software y su entorno
es clara ya que el software es introducido en el mundo de modo de provocar ciertos efectos
en el mismo.
Diagrama de actividades: Se usa para mostrar la secuencia de actividades. Los diagramas de

actividades muestran el flujo de trabajo desde el punto de inicio hasta el punto final
detallando muchas de las rutas de decisiones que existen en el progreso de eventos
contenidos en la actividad.
Diagrama de clases: Forma estructural que relaciona los elementos de un sistema
Diagrama de componentes: Describen los elementos físicos del sistema y sus relaciones

26

Diagrama de flujo de datos: Diagrama que muestra cómo fluyen los datos al entrar, dentro y
al salir de una aplicación. Los datos fluyen entre las aplicaciones del usuario, los almacenes
de datos y los elementos de procesamiento interno de la aplicación.
Diagrama de secuencia: Diagrama formado por los objetos de la aplicación que muestra una
secuencia de llamadas de funciones entre los objetos; los diagramas de secuencia suelen
dar detalles de los casos de uso.
Diseño: Proceso de definición de la arquitectura, componentes, interfaces y otras
características de un sistema o componente que resulta de este proceso.
E
Entrevista: Técnica que se utiliza en el Análisis de Sistemas para recabar la información
verbal, a través de una serie de preguntas que propone el analista. Esta a su vez es
imprescindible para obtener información cualitativa, relacionarse con los usuarios y recoger
un conjunto de hechos y/o requerimientos de información necesaria para el estudio.
Especificación de requerimientos de software (ERS): Documento que establece lo que una
aplicación debe lograr.
Estado: El estado de un objeto; la definición formal es el conjunto de valores de las variables
de un objeto.
Estándar de calidad: Son normas y protocolos internacionales que deben cumplir productos
de cualquier índole para su distribución y consumo por el cliente final. Es el que reúne los
requisitos mínimos en busca de la excelencia dentro de una organización institucional.
Estudio de factibilidad: Consiste en descubrir cuáles son los objetivos de una organización, luego
determinar si el proyecto es útil para que la empresa logre sus objetivos. Este estudio se enfoca en 4
aspectos: financiero, tecnológico, recursos y tiempo.

Expectativa: Es lo que los clientes esperan de su proveedor, como: la mejor calidad del
producto o del servicio, al menor costo, entregado a tiempo, que sea flexible para atender
las especiales o urgentes necesidades del cliente.
Evento: Una ocurrencia que afecta un objeto, iniciado desde el exterior del objeto.
F
Fase: Etapa del ciclo de vida de un sistema
Funcionalidad: Conjunto de características que hacen que algo sea práctico y utilitario.
G
Gestión de Configuración: Es el proceso de identificar y definir los elementos en el sistema,
controlando el cambio de estos elementos a lo largo de su ciclo de vida, registrando y reportando el

27

estado de los elementos y las solicitudes de cambio, y verificando que los elementos estén
completos y que sean los correctos.

H
Heurística: Capacidad de un sistema para realizar de forma inmediata innovaciones
positivas para sus fines.
Hito: Fechas límites para las tareas dentro de la agenda de trabajo.
I
Ingeniería de sistemas: Proceso de analizar y diseñar un sistema completo; incluye hardware
y software.
Integración: La fusión de los módulos que forman una aplicación.
Interacción: Es una acción que se ejerce de forma recíproca entre dos o más sujetos,
objetos, agentes, fuerzas o funciones.
Interfaz: Una interfaz para un sistema es una especificación de un conjunto de funciones
que proporciona e, sistema; la especificación incluye los nombres de las funciones, sus tipos
de parámetros, los tipos de resultados y las excepciones.
Interfaz gráfica de usuario (GUI): Despliegue gráfico, a menudo interactivo, mediante el cual
el usuario interactúa con una aplicación.
Intuitivo: Un conocimiento que se adquiere sin la necesidad de emplear un análisis o un
razonamiento anterior. Más bien, la intuición es evidente, por lo que es una consecuencia
directa de la intervención del subconsciente en la solución de conflictos netamente
racionales que se presentan en la cotidianidad.
Involucrados: Persona, grupo u organización que tienen algo que ver en el resultado de una
aplicación en desarrollo.
L
Líder de proyecto: Es el responsable de detectar las necesidades de los usuarios y gestionar
los recursos económicos, materiales y humanos, para obtener los resultados esperados en
los plazos previstos y con la calidad necesaria.
Su misión es la de dirigir y coordinar los proyectos de desarrollo y mantenimiento de las
aplicaciones de un área de la empresa, supervisando las funciones y los recursos de análisis
funcional, técnico y programación, con el fin de satisfacer las necesidades de los usuarios y
asegurando la adecuada explotación de las aplicaciones.
M

28

Manual del usuario: Es un documento técnico de un determinado sistema que intenta
ayudar a los usuarios a utilizarlo, independientemente del nivel de conocimientos del
mismo.
Manual técnico: Este documento contiene toda la información sobre los recursos utilizados
por el proyecto, llevan una descripción muy bien detallada sobre las características físicas y
técnicas de cada elemento. Por ejemplo: características de procesadores, velocidad,
dimensiones del equipo, garantías, soporte, proveedores y equipo adicional.
Mapa conceptual: Lista de actividades que se obtiene para lograr una meta específica.
Metodología (de desarrollo de software): Se refiere a un marco de trabajo que es usado para
estructurar, planear y controlar el proceso de desarrollo en sistemas de información. Este
consiste de una filosofía de desarrollo de sistemas; así como, las herramientas, modelos y
métodos para asistir a dicho proceso.
Métodos formales: Métodos rigurosos para especificar los requerimientos, diseño o la
implementación, de naturaleza matemática o lógica.
Métricas: Especificación para cómo medir un artefacto de ingeniería de software.
Modelo: El modelo de una aplicación es un panorama de su diseño desde una perspectiva
particular, como la combinación de sus clases, o su comportamiento manejado por los
eventos.
Modelización de datos: Técnica utilizada en el Análisis de Sistemas para conseguir
estructuras de datos no redundantes, sin inconsistencias, seguras e íntegras, utilizando
representaciones gráficas.
Modelo de negocios: Es el mecanismo por el cual un negocio trata de generar ingresos y
beneficios. Es un resumen de cómo una compañía planifica servir a sus clientes. Implica
tanto el concepto de estrategia como el de implementación.
Modular: Descomponer en módulos un problema, sistema
N
Normalización: Consiste en aplicar una serie de reglas a las relaciones obtenidas tras el
paso del modelo entidad-relación al modelo relacional.
Notación: Convenciones que se adoptan y utilizan para expresar determinados conceptos de
una disciplina concreta.
O
Orientado a objetos (OO): Organización de los diseños y el código en clases de instancias
(“objetos”), Se asigna un conjunto de funciones especificadas por una clase dada a cada

29

objeto de esa clase; cada objeto tiene su copia de un conjunto de variables especificadas
para la clase.
P
Paradigma: Una manera de pensar, como el paradigma de la orientación a objetos.
Proceso: “Proceso de software” es el orden en que se realizan las actividades del desarrollo.
Programación extrema: Es un enfoque de la ingeniería de software que pone más énfasis en
la adaptabilidad que en la previsibilidad. Es el más destacado de los procesos ágiles de
desarrollo de software.
Programa: Es una colección de instrucciones que indican ala computadora las tareas a
realizar.
Prototipo: Aplicación que ilustra o muestra algunos aspectos de la aplicación que se
construye.
Q
Que se puede probar: Un artefacto (Como un requerimiento) para el cual es posible escribir
una prueba específica para validar que el producto es consistente con el artefacto.
Que se puede rastrear: Requerimiento que se puede rastrear si los fragmentos de diseño y
código que lo implementan se pueden identificar de inmediato; un requerimiento no se
puede rastrear si no está claro qué partes del diseño se ajustan a él y qué partes del código
lo implementan.
R
Requerimiento: Es una característica que debe incluirse en un nuevo sistema.
Requerimientos D: Requerimientos para el desarrollador, una forma de requerimientos
adecuada principalmente para que los desarrolladores trabajen con ella, pero que también
forma parte de los requerimientos de los clientes.
Requerimiento funcional: Requerimiento que, en particular, no es un requerimiento de la
aplicación.
Requerimiento no funcional: Requerimiento colocado sobre una aplicación que no involucra
una funcionalidad específica. Una restricción sobre la memoria por ejemplo.
Requisito: Véase Requerimiento.
Restricción: Limitación específica.
S

30

Sistema: Conjunto de artefactos que interactúan entre sí para lograr un objetivo común.
Sistema abierto: Es aquel que interactúa con su medio ambiente (reciben entradas y
producen salidas).
Sistema cerrado: Es aquel que no interactúa con su medio ambiente
Sistema de información: Es aquel que logra un resultado empresarial. Recopila, manipula,
almacena y crea reportes de información respecto de las actividades de negocios de una
empresa, con el fin de ayudar a la administración de esa empresa en el manejo de
operaciones de negocios.
T
Tabla de decisión: Matriz de renglones y columnas que indican las condiciones y acciones.
Usada en el análisis de funciones de una empresa.
Transición (en un diagrama de estados): Proceso mediante el cual un objeto cambia de un
estado a otro.
TIC: Tecnologías de la información.
U
Unified Modeling Language (UML): Lenguaje de modelado unificado o notación gráfica que
sirve para expresar los diseños orientados a objetos.
Usabilidad: Se define coloquialmente como 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.
Usuario final: Persona que no es especialista en sistemas de información, pero que utilizan
las computadoras para desempeñar su trabajo.
V
Validación: Proceso para asegurar que una aplicación de software realiza las funciones para
las que se creó de la manera especificada.
Verificación: Proceso para asegurar que una aplicación de software se está construyendo de
la manera planeada.

31

BIBLIOGRAFÍA
Título:
Autor:
Año:
Editorial o referencia:
Lugar y año de la edición:
ISBN o registro:

Ingeniería del software
Ian Sommerville
2007
Pearson
Madrid 2005
84-7829-074-5

Título:
Autor:
Año:
Editorial o referencia:
Lugar y año de la edición:
ISBN o registro:

ingeniería del software - un enfoque práctico
Roger S. Pressman
2010
Mc Graw Hill
México 2010 7a. Edición
9786071503145

Título:
Autor:
Año:
Editorial o referencia:
Lugar y año de la edición:
ISBN o registro:

Calidad de sistemas informáticos
Mario G. Piattini, Félix O. García, Ismael Caballero
2007
Alfaomega
México, 2007
978-970-15-1267-8

COMPLEMENTARIA
Título:
Autor:
Año:
Editorial o referencia:
Lugar y año de la edición:
ISBN o registro:

Developping enterprise java applications with j2ee and UML
Khawar Zaman Ahmed, Cary E. Ummrysh
2001
Addison-Wesley
United States of América, 2001
0-201-73929-5

Título:
Autor:
Año:
Editorial o referencia:
Lugar y año de la edición:
ISBN o registro:

Component software -beyond object-oriented programming
Clemens Szyperski, Dominik Grutz, Stephan Murer
2002
Addison-Wesley
Gran Bretaña, 2002
0-201-74572-0

32