Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Facultad de Ingeniería
Ingeniería de Sistemas
OCTAVO SEMESTRE
SYLLABUS DE LA ASIGNATURA
INGENIRÍA DE SOFTWARE
U N I V E R S I D A D D E A Q U I N O B O L I V I A
1
FACULTAD DE INGENIERIA
VISION DE LA UNIVERSIDAD
MISION DE LA UNIVERSIDAD
U N I V E R S I D A D D E A Q U I N O B O L I V I A
2
FACULTAD DE INGENIERIA
U N I V E R S I D A D D E A Q U I N O B O L I V I A
3
FACULTAD DE INGENIERIA
U N I V E R S I D A D D E A Q U I N O B O L I V I A
4
FACULTAD DE INGENIERIA
TEMAS CON
TAREAS LUGAR DE FECHA
LOS QUE SE
PROPUESTAS ACCIÓN PREVISTA
RELACIONA
Desarrollo de un software a medida, aplicando
ingeniería para empresas del medio, en grupo Diferentes
Todo el
de dos estudiantes, proyecto que será Todos empresas
semestre
presentado en la feria de proyectos de la carrera del medio
al final del semestre.
Fechas
Se realizará una participación activa en las Ciudad de
previstas
incursiones al medio planificadas por la 5 Santa Cruz
por la
Universidad. de la Sierra.
universidad
Realizar visitas técnicas a empresas del medio Empresas
Antes del
con el objetivo de conocer la tecnología de de la ciudad
1, 2 primer
software que utilizan y el proceso de desarrollo de Santa
parcial.
que siguen según la institución. Cruz
ACTIVIDADES DE INCURSIÓN actividades planificadas para las Brigadas
MASIVA EN LA COMUNIDAD. UDABOL. Estas evaluaciones tendrán una
calificación entre 0 y 50 puntos.
A lo largo del semestre se realizarán dos
incursiones masivas en la comunidad, PROCESO DE APRENDIZAJE O
comprendida la primera entre el 2 y el 8 de SUMATIVA.
octubre y la segunda entre el 13 y el 19 de
noviembre. Con la finalidad de realizar Se realizarán dos evaluaciones parciales
trabajos ya sean de recojo de información, con contenidos teóricos y prácticos.
extensión o relacionada con los proyectos a
desarrollar en la asignatura o la carrera. En la etapa final se presentará un
proyecto que se desarrollará a lo largo
IV. EVALUACIÓN DE LA ASIGNATURA. de todo el semestre dando aplicación a
los diferentes temas avanzados, y un
PROCESUAL O FORMATIVA. examen final de todo lo avanzado en el
semestre. Estas evaluaciones tendrán
En todo el semestre se realizarán una calificación entre 0 y 50 puntos.
preguntas escritas, trabajos prácticos,
trabajos de investigación además de las V. BIBLIOGRAFIA
U N I V E R S I D A D D E A Q U I N O B O L I V I A
5
FACULTAD DE INGENIERIA
APUNTES
U N I V E R S I D A D D E A Q U I N O B O L I V I A
6
FACULTAD DE INGENIERIA
U N I V E R S I D A D D E A Q U I N O B O L I V I A
7
FACULTAD DE INGENIERIA
WORK PAPER # 1
Los mitos surgieron durante los primeros años ordenada. Además si sacamos a gente de
del desarrollo del software. otros proyectos, en último término
retrasaremos otros proyectos.
• Son actitudes erróneas que causan serios
problemas tanto a gestores como a técnicos. 1.2. Mitos del cliente
• Pueden afectar a: a) Mito: Una declaración general de objetivos
es suficiente para comenzar a escribir los
– Gestores. programas, y podemos dar los detalles más
– Clientes. adelante.
– Programadores. Realidad: Una mala definición inicial conlleva
trabajo inútil.
1. Mitos del software
b) Mito: Los requisitos del proyecto cambian
1.1. Mitos del gestor continuamente, pero los cambios pueden
a) Mito: Tenemos un manual de desarrollo de acomodarse fácilmente porque el software es
software. ¿Qué más necesitamos? flexible.
Realidad. ¿Se entiende? ¿Se utiliza? ¿El Realidad: Es cierto que los requisitos
personal tiene práctica en su aplicación?. cambian, pero el impacto del cambio varía en
función del momento en que se introduzcan
b) Mito: Disponemos de las herramientas de los cambios, mientras más tarde el costo es
desarrollo más avanzadas, ya que mas alto.
compramos siempre los mejores equipos.
1.3. Mitos de los desarrolladores
Realidad: ¿Se invierte en herramientas
CASE? ¿Y en entornos de desarrollo? a) Mito: Una vez que escribamos el programa
y hagamos que funciones, nuestro trabajo ha
c) Mito: Si fallamos en la planificación, terminado.
podemos añadir más programadores y
adelantar el tiempo perdido. Realidad: Entre el cincuenta y el setenta por
ciento de todo el esfuerzo dedicado a un
Realidad: En el proceso de software añadir programa se realiza después de que se
gente puede retrasar más el proyecto. La entregue al cliente por primera vez.
gente debe añadirse de forma planificada y
U N I V E R S I D A D D E A Q U I N O B O L I V I A
8
FACULTAD DE INGENIERIA
WORK PAPER # 2
U N I V E R S I D A D D E A Q U I N O B O L I V I A
9
FACULTAD DE INGENIERIA
ETAPAS: ETAPAS:
c) El modelado de proceso
U N I V E R S I D A D D E A Q U I N O B O L I V I A
10
FACULTAD DE INGENIERIA
Equipo No 2 Equipo No 3
Equipo No 1
Modelado
de gestión
Modelado
Modelado de gestión Modelado
de gestión de datos
Modelado
Modelado de procesos
Modelado de datos
Gener. de
de datos Aplicaciones
Modelado
de procesos
Pruebas
Modelado y entrega
de procesos Generación
de
Aplicaciones
Generación
de Pruebas
Aplicaciones y entrega
Pruebas
y entrega
4. El modelo incremental
Ingeniería de
Sistemas/Información Incremento 1
Entrega del
Análisi Diseño Código Prueba 1er Incremento
Entrega del
Incremento 3 Análisi Diseño Código Prueba 3er Incremento
s
Entrega del
Análisi
Incremento 4 Diseño Código Prueba 4to Incremento
s
Se centra en la entrega de un producto operacional con cada incremento.
U N I V E R S I D A D D E A Q U I N O B O L I V I A
11
FACULTAD DE INGENIERIA
Este método es útil cuando la dotación de personal no está disponible para una implementación
completa en la fecha límite que se haya establecido para el proyecto. Se caracteriza por modularizar
el problema y resolver los módulos uno a uno, poniendo en funcionamiento cada modulo una vez
terminado.
5. Modelo Espiral
a) Planificación
En esta etapa se realiza la determinación de objetivos, alternativas y restricciones.
b) Análisis de riesgo
U N I V E R S I D A D D E A Q U I N O B O L I V I A
12
FACULTAD DE INGENIERIA
U N I V E R S I D A D D E A Q U I N O B O L I V I A
13
FACULTAD DE INGENIERIA
Ninguna
Bajo Desarrollo
Cambios en Bajo
espera revisión
Realizado
Se centra en el estado por el que pasa un continúa con la línea de desarrollo hasta
Sistema de Información, donde inicialmente terminar la tarea, una vez en este punto, es
parte de Ninguna, luego entra a Bajo posible, nuevamente volver a Cambios en
desarrollo, si es un nuevo Sistema pasa a Espera; pero si el propósito es realizar el
Cambios en espera, una vez teniendo un mantenimiento de un, este puede pasar de
avance en el desarrollo pasa a bajo bajo desarrollo a bajo revisión, luego volver a
modificación, donde el cliente tiene la línea base, hasta terminar la tarea.
posibilidad de revisar el avance, luego se
Construir la Buscar
iteración del componentes en
sistema Biblioteca
Poner Extraer
componentes en componentes
la Biblioteca disponibles
Desarrollar
componentes si
no están
disponibles
U N I V E R S I D A D D E A Q U I N O B O L I V I A
14
FACULTAD DE INGENIERIA
U N I V E R S I D A D D E A Q U I N O B O L I V I A
15
FACULTAD DE INGENIERIA
WORK PAPER # 3
U N I V E R S I D A D D E A Q U I N O B O L I V I A
16
FACULTAD DE INGENIERIA
La métrica permite relacionar y comparar 2. ¿Dos razones para medir un proyecto son:
mediciones. Evaluar y predecir?
Las métricas son el fundamento de los V F
indicadores. 3. ¿Qué diferencias existe entre la medida y la
• Un indicador es una métrica o combinación de métrica?
métricas que proporcionan una visión profunda ___________________________________
del proceso del software, del proyecto de
software o del producto en si. ___________________________________
Ejemplo: En el país A no han aumentado los
sueldos en los últimos tres años, pero el índice ___________________________________
King Burger se ha duplicado en ese periodo.
4. Un indicador es una medida que
• Ejemplo: La productividad media de nuestra proporcionan una visión profunda del proceso
empresa es de 500(LDC/mes) y en el último del software, del proyecto de software o del
proyecto ha sido de 250(LDC/mes). producto en si.
CUESTIONARIO WORK PAPER NRO. 3 V F
1. ¿Las métricas sirven para que el 5. La métrica permite relacionar y comparar
desarrollador de software evalúe la calidad mediciones.
de los productos y trabajos técnicos?
V F
V F
WORK PAPER # 4
U N I V E R S I D A D D E A Q U I N O B O L I V I A
17
FACULTAD DE INGENIERIA
U N I V E R S I D A D D E A Q U I N O B O L I V I A
18
FACULTAD DE INGENIERIA
WORK PAPER # 5
U N I V E R S I D A D D E A Q U I N O B O L I V I A
19
FACULTAD DE INGENIERIA
Puesto que es imposible hacer una Intentan garantizar que todos los caminos
prueba de defectos exhaustiva, de ejecución del programa quedan
utilizaremos un subconjunto de casos de probados.
prueba Pruebas de estructura de control:
Probar las capacidades del sistema es
Del camino básico: Diseñar un caso de
más importante que probar sus
prueba por cada camino independiente.
componentes.
De condición: Diseñar casos de prueba
Probar las capacidades anteriores es más
para que todas las condiciones del
importante que probar capacidades
programa se evalúen a cierto/falso
nuevas.
Probar situaciones típicas es más De bucles: Diseñar casos de prueba para
importante que probar los casos límite. que se intente ejecutar un bucle 0,1,…,n-
1,n y n+1 veces (siendo n el número
a) Métodos de caja blanca máximo)
Aseguran que la operación interna del b) Pruebas de caja negra
programa se ajusta a las especificaciones y
que todos los componentes internos se han Considera el sistema como una caja negra,
probado adecuadamente. cuyo comportamiento es determinado
únicamente a partir de sus entradas y salidas
Usa la estructura de control para obtener
Los casos de prueba se basan en la
los casos de prueba.
especificación del sistema
U N I V E R S I D A D D E A Q U I N O B O L I V I A
20
FACULTAD DE INGENIERIA
U N I V E R S I D A D D E A Q U I N O B O L I V I A
21
FACULTAD DE INGENIERIA
Mal uso de la interfaz por ejemplo eventos que provocan que el objeto cambie
parámetros en orden incorrecto o número de estado
de parámetros incorrecto Pruebas de integración
No entendimiento de la interfaz En sistemas orientados a objetos no hay
Se realizan asunciones incorrectas sobre el una distinción clara en niveles(no se
comportamiento del componente al que se pueden aplicar estrategias top-down o
"llama" Errores temporales botton-up)
El componente que realiza la llamada y el Se utilizan las denominadas pruebas de
componente al quese llama operan con "clusters", consistentes en probar grupos
velocidades diferentes y se accede a de objetos que cooperan entre sí
información "no actualizada" Para identificar los clusters se usa el
Guía para pruebas de interfaz conocimiento sobre las operaciones de los
objetos y las características del sistema
Diseñar pruebas para que los parámetros
que son implementadas por dichos clusters
de un procedimiento sean ejercitados en
los valores extremos de sus rangos Pruebas de "clusters"
Si se utilizan punteros, probar siempre con Pruebas basadas en escenarios
punteros nulos Las pruebas se obtienen a partir de las
En interfaces procedurales, diseñar interacciones del usuario con el sistema.
pruebas para ocasionar un fallo en el Tienen la ventaja de que permiten probar
componente Usa rpruebas de "resistencia" las características del sistema tal y como
en sistemas con paso de mensajes las utilizan los usuarios
En sistemas con memoria compartida, Pruebas en "hebras"
variar el orden en el que los componentes Prueban la respuesta del sistema a
son activados Ejercitar el sistema con su eventos de entrada considerando la
carga máxima. secuencia de acciones implicadas para
Pruebas orientadas a objetos tratar dichos eventos
Los componentes a probar son clases, que Pruebas de interacción de objetos
se instanciarán a objetos Se prueban secuencias de interacciones
No son obvios los niveles en la arquitectura entre objetos que terminan cuando una
para poder utilizar estrategias top-down operación de un objeto ya no requiere los
servicios de otro objeto
Niveles de pruebas Probar las operaciones
asociadas con los objetos Probar las clases Pruebas de "WeatherStation"
de objetos Probar grupos de objetos que Hebra de métodos ejecutados
colaboran (clusters) CommsController:request→WeatherStation
Probar el sistema completo :report→WeatherData:summarise Entradas
y salidas
1.3. Pruebas de clases de objetos
Entrada de una petición de informe con la
Las pruebas de clases de objetos implican aceptación asociada y una salida final de
Probar todas las operaciones asociadas dicho informe
con dicho objeto Se puede proba rcreando datos ficticios y
Asignar y consultar valores para todos los asegurándose de que en el informe se
atributos del objeto incluyen dichos datos de forma correcta
Ejercitar el objeto en todos sus posibles Se usarán los mismos datos para probar el
estados: se deben simular todos los objeto WeatherData
Herramientas automáticas
U N I V E R S I D A D D E A Q U I N O B O L I V I A
22
FACULTAD DE INGENIERIA
U N I V E R S I D A D D E A Q U I N O B O L I V I A
23
FACULTAD DE INGENIERIA
WORK PAPER # 6
U N I V E R S I D A D D E A Q U I N O B O L I V I A
24
FACULTAD DE INGENIERIA
de riesgo reactivas. En el mejor de los casos, proyecto se hacen realidad, es probable que la
la estrategia reactiva supervisa el proyecto en planificación temporal del proyecto se retrase y
previsión de posibles riesgos. Los recursos se que los costos aumenten. Los riesgos del
ponen aparte, en caso de que pudieran proyecto identifican los problemas potenciales
convertirse en problemas reales. Pero lo más de presupuesto, planificación temporal,
frecuente es que el equipo de software no personal (asignación y organización), recursos,
haga nada respecto a los riesgos hasta que cliente y requisitos y su impacto en un proyecto
algo va mal. Después el equipo vuela para de software.
corregir el problema rápidamente. éste es el
Los riesgos técnicos amenazan la calidad y
método denominado a menudo "de bomberos".
la planificación temporal del software que hay
Cuando falla, "la gestión de crisis" entra en
que producir. Si un riesgo técnico se convierte
acción y el proyecto se encuentra en peligro
en realidad, la implementación puede llegar a
real.
ser difícil o imposible. Los riesgos técnicos
Una estrategia considerablemente más identifican problemas potenciales de diseño,
inteligente para el control del riesgo es ser implementación, de interfaz. verificación y de
proactivo. La estrategia proactiva empieza mantenimiento. Además. las ambigüedades de
mucho antes de que comiencen los trabajos especificaciones, incertidumbre técnica,
técnicos. Se identifican los riesgos potenciales, técnicas anticuadas y las "tecnologías punta"
se valoran su probabilidad y su impacto y se son también factores de riesgo. Los riesgos
establece una prioridad según su importancia. técnicos ocurren porque el problema es más
Después el equipo de software establece un difícil de resolver de lo que pensábamos.
plan para controlar el riesgo. El primer objetivo Los riesgos del negocio amenazan la
es evitar el riesgo, poco común no se pueden viabilidad del software a construir Los riesgos
evitar todos los riesgos. el equipo trabaja para del negocio a menudo ponen en peligro el
desarrollar un plan de contingencia que le proyecto o el producto. Los candidatos para los
permita responder de una manera eficaz y cinco principales riesgos del negocio son:
controlada. A lo largo de lo que queda de este
1. Construir un producto o sistema excelente
work paper, estudiamos la estrategia proactiva
que no quiere nadie en realidad (riesgo de
para el control de riesgos.
mercado).
2. Riesgos del software
2. Construir un producto que no encaja en la
Se han producido amplios debates sobre la estrategia comercial general de la
definición adecuada para riesgo de software, y compañía (riesgo estratégico).
hay acuerdo común en que el riesgo siempre
3. Construir un producto que ei departamento
implica dos características:
de ventas no sabe cómo vender.
• Incertidumbre: El acontecimiento que
4. Perder el apoyo de una gestión experta
caracteriza al riesgo puede o no puede
debido a cambios de enfoque o a cambios
ocurrir; por ejemplo, no hay riesgos de un
de personal (riesgo de dirección).
100 por ciento de probabilidad.
5. Perder presupuesto o personal asignado
• Pérdida: Si el riesgo se convierte en una
(riesgos de presupuesto).
realidad, ocurrirán consecuencias no
deseadas o pérdidas. Es extremadamente importante recalcar que
no siempre funciona una categorización tan
Cuando se analizan los riesgos es importante
sencilla. Algunos riesgos son simplemente
cuantificar el nivel de incertidumbre y el grado
imposibles de predecir. Otra categorización
de pérdidas asociado con cada riesgo. Para
general de los riesgos ha sido propuesta por
hacerlo, se consideran diferentes categorías
Charette. Los riesgos conocidos son todos
de riesgos.
aquellos que se pueden descubrir después
Los riesgos del proyecto amenazan al plan
de una cuidadosa evaluación del plan del
del proyecto. Es decir, si los riesgos del
U N I V E R S I D A D D E A Q U I N O B O L I V I A
25
FACULTAD DE INGENIERIA
proyecto, del entorno técnico y comercial en Tamaño del producto: riesgos asociados
el que se desarrolla el proyecto y otras fuentes con el tamaño general del software a
de información fíables (por ej.: fechas de construir o a modificar.
entrega poco realistas, falta de especificación
de requisitos o de ámbito del software, o un Impacto en el negocio: riesgos asociados
entorno pobre de desarrollo), los riesgos con las limitaciones impuestas por la
predecibles se extrapolan de la experiencia en gestión o por el mercado.
proyectos anteriores (ej.: cambio de personal, Características del cliente: riesgos
mala comunicación con el cliente. disminución asociados con la sofisticación del cliente y
del esfuerzo del personal a medida que la habilidad del desarrollador para
atienden peticiones de mantenimiento). comunicarse con el cliente en los
Pueden ocurrir pero son extremadamente momentos oportunos.
difíciles de identificar por adelantado.
Definición del proceso: riesgos asociados
2. Identificación del riesgo con el grado de definición del proceso del
La identificación del riesgo es un intento software y su seguimiento por la
sistemático para especificar las amenazas al organización de desarrollo.
plan del proyecto (estimaciones, planificación Entorno de desarrollo: riesgos asociados
temporal, carga de recursos, etc). Identificando con la disponibilidad y calidad de las
los riesgos conocidos y predecibles, el gestor herramientas que se van a emplear en la
del proyecto da un paso adelante para construcción del producto.
evitarlos cuando sea posible y controlarlos
cuando sea necesario. Tecnología a construir: riesgos asociados
con la complejidad del sistema a construir y
Existen dos tipos diferenciados de riesgos para la tecnología punta que contiene el
cada categoría presentada en el apartado sistema.
anterior: genéricos y específicos del producto.
Los riesgos genéricos son una amenaza Tamaño y experiencia de la plantilla:
potencial para todos los proyectos de software. riesgos asociados con la experiencia
Los específicos de producto sólo los pueden técnica y de proyectos de los ingenieros del
identificar los que tienen una clara visión de la software que van a realizar el trabajo.
tecnología, el personal y el entorno específico La lista de comprobación de elementos de
del proyecto en cuestión. Para identificar los riesgo puede organizarse de diferentes
riesgos específicos del producto se examinan maneras. Se pueden responder a cuestiones
el plan del proyecto y la declaración del ámbito relevantes de cada uno de los temas
del software y se desarrolla una respuesta a la apuntados anteriormente para cada proyecto
siguiente pregunta: ¿Qué características de software. Las respuestas a estas
especiales de este producto pueden estar preguntas permiten al planificador del
amenazadas por nuestro plan del proyecto? proyecto estimar el impacto del riesgo. Un
Tanto los riesgos genéricos como los formato diferente de lista de comprobación de
específicos del producto se deberían identificar elementos de riesgo contiene simplemente las
sistemáticamente. Tom Gilb tiene toda la razón características relevantes para cada
cuando dice: "Si no atacas activamente a los subcategoría genérica. Finalmente, se lista un
riesgos, ellos te atacarán activamente a ti", Un conjunto de "componentes y controladores del
método para identificar riesgos es crear una riesgo" junto con sus probabilidades de
lista de comprobación de elementos de riesgo. aparición. Los controladores del rendimiento,
La lista de comprobación se puede utilizar para el soporte, el coste y la planificación temporal
identificar riesgos y se enfoca en un del proyecto se estudian como respuesta a
subconjunto de riesgos conocidos y preguntas posteriores.
predecibles en las siguientes subcategorías CUESTIONARIO WORK PAPER # 6
genéricas:
U N I V E R S I D A D D E A Q U I N O B O L I V I A
26
FACULTAD DE INGENIERIA
WORK PAPER # 7
U N I V E R S I D A D D E A Q U I N O B O L I V I A
27
FACULTAD DE INGENIERIA
U N I V E R S I D A D D E A Q U I N O B O L I V I A
28
FACULTAD DE INGENIERIA
¿Está dispuesto el cliente a ¿Se emplea este proceso del software para
establecer una comunicación fluida otros proyectos?
con el desarrolador?
¿Ha desarrollado o adquirido su
¿Está dispuesto el cliente a participar organización cursos de formación de
en las revisiones? ingeniería del software para jefes de
proyecto y personal técnico?
¿Es sofisticado técnicamente el área
del producto? ¿Se ha proporcionado una copia de los
estándares de ingeniería del software
¿Está dispuesto el cliente a dejar a
publicados a cada desarrollador y gestor de
su personal hacer el trabajo? Es
software?
decir, ¿resistirá la tentación de mirar
por encima del hombro durante el ¿Se han desarrollado diseños de
trabajo técnico? documentos y ejemplos para todas las
entregas definidas como parte del proceso
¿Entiende el cliente el proceso del
del software?
software?
¿Se llevan a cabo regularmente revisiones
Si la respuesta a alguna de estas
técnicas formales de las especificaciones
preguntas es "no", se debería hacer una
de requisitos, diseño y código?
investigación más profunda para valorar
el potencial de riesgo. ¿Se llevan a cabo regularmente: revisiones
7. Riesgos del proceso técnicas de los procedimientos de prueba y
de los casos de prueba?
Si el proceso del software no está bien
definido; si el análisis, diseño y pruebas se ¿Se documentan todos los resultados de
realizan sobre la marcha; si la calidad es un las revisiones técnicas, incluyendo los
concepto que todo el mundo estima errores encontrados y recursos
importante, pero por la que nadie actúa de empleados?
manera tangible para alcanzarla, entonces el ¿Existe algún mecanismo para asegurarse
proyecto está en peligro. Las siguientes de que el trabajo realizado en un proyecto
preguntas se han extraído sobre la evaluación se ajusta a los estándares de ingeniería del
de la ingeniería del software desarrollado por software?
Roger Pressman & Associates. Inc. Las
preguntas se han adaptado del cuestionario de ¿Se emplea una gestión de configuración
evaluación del proceso del software del para mantener la consistencia entre los
Instituto de Ingeniería del Software (IIS). requisitos del sistema/software, diseño,
código y casos de prueba?
Aspectos del proceso
¿Hay algún mecanismo de control de
¿Apoyan sus gestores senior unas normas cambios de los requisitos del cliente que
escritas que hagan hincapié en la impacten en el software?
importancia de un proceso estándar para el
desarrollo del software? ¿Hay alguna declaración de trabajo
documentada, una especificación de
¿Ha desarrollado su organización una requisitos software y un plan de desarrollo
descripción escrita del proceso del software del software para cada subcontratación?
a emplear en este proyecto?
¿Se sigue algún procedimiento para hacer
¿Están de acuerdo los miembros del un seguimiento y revisar el rendimiento de
personal con el proceso del software tal y las subcontraciones?
como está documentado y están
dispuestos a usarlo? Aspectos técnicos
U N I V E R S I D A D D E A Q U I N O B O L I V I A
29
FACULTAD DE INGENIERIA
U N I V E R S I D A D D E A Q U I N O B O L I V I A
30
FACULTAD DE INGENIERIA
U N I V E R S I D A D D E A Q U I N O B O L I V I A
31
FACULTAD DE INGENIERIA
U N I V E R S I D A D D E A Q U I N O B O L I V I A
32
FACULTAD DE INGENIERIA
Revise los siguientes libros de texto y páginas Edición. McGRAW-HILL. 2002. Capítulo
Web, donde usted encontrará información a 32. Perspectivas futuras
cerca de el futuro del software. http://www.microsoft.com/spain/sharedsou
rce/Articles/Future.mspx
PRESSMAN, ROGER. “Ingeniería del http://pulsar.unizar.es/gluz/manual-
Software un enfoque practico”. 5ta. sl/x199.html
U N I V E R S I D A D D E A Q U I N O B O L I V I A
33
FACULTAD DE INGENIERIA
DIF´s # 3
Revise los siguientes libros de texto y páginas Edición. McGRAW-HILL. 2002. Capítulo
Web, donde usted encontrará información a 30. Reingeniería.
cerca de los Diagramas de Colaboración. http://alarcos.inf-
cr.uclm.es/doc/ISOFTWAREI/Tema16.p
PRESSMAN, ROGER. “Ingeniería del df
Software un enfoque practico”. 5ta.
U N I V E R S I D A D D E A Q U I N O B O L I V I A
34
FACULTAD DE INGENIERIA
http://www.tribunalmmm.gob.mx/conferenc http://www.conocimientosweb.net/dcmt/fic
ias/2ReunionInformatica/txtConfeHidalg ha11385.html
o.htm
U N I V E R S I D A D D E A Q U I N O B O L I V I A
35
FACULTAD DE INGENIERIA
U N I V E R S I D A D D E A Q U I N O B O L I V I A
36
FACULTAD DE INGENIERIA
U N I V E R S I D A D D E A Q U I N O B O L I V I A
37