Este documento presenta los objetivos de la unidad 1 de ingeniería de software, los cuales incluyen: definir ingeniería de software y explicar su importancia, presentar modelos de proceso de software, definir requerimientos de software, describir actividades de análisis de requerimientos, describir componentes de SRS, discutir métricas de software, definir actividades de análisis de riesgo, discutir planeamiento de proyectos de software, describir términos de control y aseguramiento de calidad, presentar niveles de prue

1. Objetivos de la unidad 1
– Definir qué es la ingeniería de software y explicar su
importancia
– Presentar los diferentes modelos de proceso de
software
– Definir el concepto de requerimientos del software
– Enumerar las actividades de análisis de
requerimientos
– Describir las funciones y componentes de una SRS
– Discutir algunos tipos de métricas de software, tales
como, métricas orientadas al tamaño, métricas
orientadas a función
– Definir las diferentes actividades para llevar a cabo el
análisis de riesgo

2. Objetivos
– Discutir el planeamiento y cronograma de un proyecto de
software
– Describir los términos de control de calidad y
aseguramiento de calidad, en el contexto del software
– Presentar los diferentes niveles de prueba
– Explicar los métodos involucrados en el proceso de prueba
unitaria
– Establecer los enfoques involucrados en la prueba de
integración
– Presentar los deferentes componentes de la prueba del
sistema

3. Unidad 1:
Fundamentos de Ingeniería de Software

4. Objetivos de Aprendizaje
• Explicar el software como un producto y proceso
• Definir la ingeniería de software y explicar su
importancia
• Discutir las ventajas y desventajas de diversos
modelos de proceso de software
• Discutir acerca de los Modelos Evolutivos y
Secuenciales

5. Introducción
• La ingeniería de software provee metodologías y
técnicas que ayudan a desarrollar sistemas de
software a tiempo
• La ingeniería de software asegura que el
desarrollador cumpla con las expectativas de
calidad y presupuesto
• Las metodologías de la ingeniería de software
fomentan un enfoque sistemático a lo largo del
ciclo de vida del software

6. Características
del SoftwareRobusto
Reutilizable
Eficiente
Utilizable
Mantenible
Evolutivo
Confiable Portable
Características del Software

7. Tipos de
Aplicaciones
de Software
Ingeniería y
Científicas
Negocio
Incorporadas
Sistema
Computadoras
Personales e
Individuales
Tiempo
Real
Tipos de Aplicaciones de Software

8. Proceso de Software
Un proceso se define como:
• Una serie de operaciones usadas en la creación de
un producto
• El conjunto de tareas, que tienen que ser realizadas
para generar un producto de software de alta calidad
• Aquello que se sigue para construir el producto de
software
ACTIVIDAD 1
TAREA 1TAREA 1 TAREA X• • •
PROCESO
ACTIVIDAD n• • •

9. Características
del Proceso de
Software
Facilidad de
Mantenimiento
Robustez
Rapidez
Comprensión
Facilidad de
Verificación
Confiabilidad
Facilidad de
Soporte
Facilidad de
Aceptación
Visibilidad
Facilidad de
Adaptación
Características del Proceso de Software

10. Fases del Proceso de Desarrollo de Software
• Fase de Definición:
- Ingeniería de información
- Planeamiento del proyecto de Software
- Análisis de requerimientos
• Fase de Desarrollo:
- Diseño de Software
- Codificación
- Prueba
• Fase de Mantenimiento

11. Categorías de Modelos de Procesos de Software
• Modelo Secuencial Lineal
• Modelo de Creación de un Prototipo
• Modelo Evolutivo
• Modelo de Métodos Formales
• Sistema Ensamblado de Componentes Reutilizables

12. Modelo de Cascada
Ingeniería de
Sistema
Análisis de
Requerimientos
Diseño
Codificación
Prueba
Mantenimiento

13. Modelo de Cascada
Ventajas:
– Posibilita un orden máximo en el proceso de implementación
– Proporción una plantilla estructurada para la ingeniería de
software
Desventajas:
– El cliente debe proporcionar todos los requerimientos de una
sola vez
– Es difícil para los usuarios anticipar si el sistema final va a
satisfacer sus requerimientos
– Cualquier cambio que se haga durante la implementación
puede causar confusión.
– La versión de trabajo puede verse sólo en una etapa
posterior.

14. Modelo de Desarrollo Rápido de Aplicación
Período Corto de Tiempo
Equipo 3
Especificaciones
Parciales
Diseño Codificación Pruebas Lanzamiento
Equipo 3
Equipo 1
Equipo 2
Especificaciones
Parciales
Diseño Codificación Pruebas Lanzamiento
Especificaciones
Parciales
Diseño Codificación Pruebas Lanzamiento
Especificaciones
Parciales
Diseño Codificación Pruebas Lanzamiento
Uso de 4GT y
componentes
reutilizables
Modelar el
Negocio

15. Modelo de Creación de un Prototipo
Obtener
Requerimientos
Diseño
Rápido
Prototipo
Evaluar
Prototipo
Refinar
Requerimientos
Lanzamiento e
Ingeniería

16. Modelo de Creación de un Prototipo
• Ventajas:
– Ocurre un desarrollo rápido sin detalles de la entrada y
salida
– Los clientes pueden ver muy pronto la salida de alguna
forma
– Hay la oportunidad de modificar los requerimientos
tempranamente en el proceso de desarrollo
• Desventajas:
– El cliente puede tomar el prototipo como el producto final.
– Puede resultar que el proceso de desarrollo del producto
tome mucho tiempo
– Los desarrolladores no están seguros de qué hacer con
el prototipo

17. Modelo Incremental
PruebasCodificación
Diseño
Incremental
Análisis
Incremental
Análisis
Parcial
Retroalimentación del Incremento
Anterior
Inicio del
proyecto
Inicio del
mantenimiento
Fin del
lanzamient
o del
producto
Lanzamiento
del 1er
incremento
Estudio del
Sistema y
Análisis de
Requerimientos
Ingeniería de
Sistemas e
Información
Diseño
Restringido
Codificación Pruebas
Lanzamiento
del 2do
incremento
Diseño
Incremental
Análisis
Incremental
Codificación Pruebas
Lanzamiento
del 3er
incremento
Retroalimentación
Retroalimentación
Diseño
Incremental
Análisis
Incremental
Codificación Pruebas
Lanzamiento
incremento
final
Retroalimen-
tación de
todos los
Usuarios

18. Modelo Espiral
Análisis de
Riesgo
Ingeniería del
Software
Codificación, Prueba y
Lanzamiento
Evaluación y
Retroalimentació
n del Cliente
Comunicación
con el Cliente
Planificación
del Proyecto

19. Modelo Espiral
Ventajas:
– Las últimas iteraciones tienen más probabilidad de tener
una versión final rápidamente
– Este modelo se puede usar aún después de que el
software es entregado
– Usa el prototipo como un mecanismo de reducción de
riesgo
Desventajas:
– Demanda una experiencia considerable de valoración del
riesgo por parte del cliente
– Los clientes son generalmente aprensivos de si el enfoque
evolutivo puede ser controlado o no.

20. Modelo de Ensamblado de Componentes
• Considerar el diseño e identificar los componentes que
pueden ser reutilizados
• Seleccionar los componentes requeridos de la librería o
repositorio
• Retocar los componentes seleccionados de ser necesario
• Construir componentes adicionales para ayudar a realizar el
diseño en la etapa de la iteración
• Ensamblar los componentes para ayudar a la entrega del
producto en la etapa de iteración
• Adicionar los nuevos componentes creados en la librería o
repositorio
• Completar la iteración actual del componente ensamblador

21. Técnicas de Cuarta Generación (4GTs)
• Involucran las características del software en un alto
nivel de abstracción
• Diversas herramientas se utilizan para generar el
código fuente
• Se denominan también 'generadores de aplicaciones’
• Existen varios entornos de desarrollo de software que
soportan 4GT

22. Resumen
• Se explicó el software como un producto y un proceso
• Se definió qué es la ingeniería de software y explicar su
importancia
• Se discutieron las ventajas y desventajas de los
diversos modelos de procesamiento de software
• Se presentaron los Modelos Evolutivos
• Se discutieron las Técnicas de Cuarta Generación

23. Unidad 2:
Especificación de los Requerimientos de
Software

24. Objetivos de Aprendizaje
• Discutir la naturaleza y la importancia de los requerimientos
• Definir los requerimientos de software y el término SRS
• Describir las actividades del análisis de requerimientos
• Describir el proceso del análisis de requerimientos
• Describir las funciones y componentes de una SRS
• Discutir los diferentes atributos de una SRS bien redactada

25. Requerimientos del Software
• Requerimiento es una “condición o capacidad requerida
por un usuario para resolver un problema o para
alcanzar un objetivo”
• La fase de requerimientos inicia cuando:
- Un problema existe y quizás requiere una solución
basada en software
- Hay un alcance para crear un software basado en una
idea

26. Análisis del Problema y Descripción del Producto
• El análisis del problema busca una comprensión
completa del problema y comprende:
- Tormenta de ideas
- Dirigir entrevistas con los involucrados con el sistema
- Obtener información de las personas familiarizadas con el
entorno del sistema
• La descripción del producto, describe la conducta externa
del software en un documento

27. Pasos de la Ingeniería de Requerimientos
Levantamiento de Requerimientos
Análisis de Requerimientos
Refinamiento de Requerimientos
Negociación de Requerimientos
Especificación de Requerimientos
Modelado de Sistema
Validación de Requerimientos
Administración de Requerimientos

28. Levantamiento de Requerimientos
• Proceso de recibir un conjunto de requerimientos
de:
- el cliente
- el usuario
- la gerencia
• Las preguntas a responder en este proceso son:
¿Cuáles son los objetivos del sistema o producto?
¿Qué debe ser alcanzado por el producto o sistema?
¿Cómo ayuda el sistema o producto en las necesidades
del negocio?
¿Cómo se usará el sistema o producto en el día a día?

29. Problemas en el Levantamiento de Requerimientos
Límites del Sistema
Indefinidos
Problema de
Alcance
Detalles
Innecesarios
Problemas en el
Levantamiento de
Requerimientos
Mala apreciación
del entorno de
trabajo
Mala
comunicación
Problema de
Volatilidad
Problema de
Comprensión
Clientes
Inseguros de
sus Necesidades
Pobre Dominio
del
Conocimiento
Cambia en el
Tiempo Número
de
Requerimientos
Requerimientos
Volatiles en sí
Mismos

30. Análisis de Requerimientos
• Los requerimientos se analizan para ser categorizados y
organizados.
• Como una guía se tienen preguntas tales como:
1. ¿Cada requerimiento es consistente?
2. ¿Existen suficientes detalles para cada uno de los
requerimientos?
3. ¿Hay un alcance bien definido que proporciona un límite a
cada requerimiento?
4. ¿Está el conjunto de todos los requerimientos completo y
libre de ambigüedad?

31. Especificación de Requerimientos
Una Especificación de Requerimiento puede involucrar
uno de los siguientes:
• Documento escrito
• Modelo gráfico
• Modelo formal (base matemática)
• Casos de uso
• Prototipos

32. Modelar el Sistema
• Modelar el sistema es un paso recomendado para lograr
un buen entendimiento del sistema
• Para sistemas que están siendo abordados por primera
vez, se recomienda que sean modelados
• Modelar el sistema es un análisis más profundo del
mismo

33. Validación de Requerimientos
Completitud
Consistencia
Correspondencia a
ciertos estándares
No-ambigüedad
Aspectos que
Aseguran la
Validación de
Requerimientos

34. Administración de Requerimientos
• Trata de un conjunto de actividades conectadas con el
control, identificación y rastreo de requerimientos durante
la implementación
• Se ocupa de los cambios en los requerimientos
• Se estudia también bajo el tópico de Administración de la
Configuración

35. Aplicaciones del SRS
Una SRS (Especificación de Requerimientos de
Software) es un documento que contiene una descripción
completa de la conducta externa de un producto
La SRS la escribe la organización de desarrollo, su propósito
es:
• Proporcionar medios de comunicación entre clientes,
usuarios, analistas y diseñadores
• Constituir una base para las actividades de prueba y
verificación del sistema
• Controlar la evolución del sistema

36. Contenido de la SRS
• Una SRS debe incluir una descripción concisa, de la
totalidad de la interfaz externa del sistema con su
ambiente, incluyendo otros software, puertos de
comunicación , hardware y usuarios
• Incluye dos tipos de requerimientos:
• De comportamiento
• De no comportamiento

37. Atributos de
un SRS de
Alta Calidad
Rastreable
Integra
Comentada
No Ambigua
Comprensible
Consistente
Correcta Verificable
Atributos de un SRS de Alta Calidad

38. Resumen
• Se discutió la naturaleza e importancia de los
requerimientos
• Se definieron los requerimientos de software y el término
SRS
• Se describieron las actividades para el análisis de los
requerimientos
• Se describió el proceso de análisis de requerimientos
• Se describieron las funciones y componentes de una SRS
• Se explicaron los diferentes atributos de una SRS bien
redactada

39. Unidad 4:
Diseño de Software

40. Objetivos de Aprendizaje
• Explicar brevemente el proceso de diseño
• Explicar los enfoques top-down y bottom-up
• Discutir los principios y objetivos del diseño
• Discutir los conceptos de cohesión y acoplamiento

41. Introducción
• El diseño de software busca planear una solución para
un problema especificado en la SRS
• Es el primer paso para avanzar del dominio del
problema al dominio de la solución
• Es la primera de tres actividades técnicas en el proceso
de ingeniería de software
• Comienza poco tiempo después del análisis y la
especificación de requerimientos

42. Resultados del Proceso de Diseño
• Diseño de datos
• Diseño arquitectónico
• Diseño de interfaz
• Diseño de componentes

43. Características de un Buen Diseño
• El diseño debe implementar todos los requerimientos de la
SRS
• Para los desarrolladores y ´testers´ debe ser fácil entender
el diseño
• El diseño debe cubrir todos los aspectos de
implementación del software (funcional, comportamiento y
flujo de datos)

44. Enfoques de Diseño Top-Down y Bottom-Up
Top Down:
- Enfoque orientado en niveles, comienza con una descripción de alto
nivel
- Refina su visión paso a paso
- El sistema se fragmenta en módulos más pequeños y de más bajo
nivel
Bottom Up:
- Enfoque que identifica un conjunto básico de módulos y sus
interrelaciones
- El beneficio principal es permitir la evaluación de sub-módulos
durante el desarrollo

45. Conceptos
Básicos de
Diseño
Modularidad
Refinamiento
Arquitectura
Abstracción
Conceptos Básicos de Diseño

46. Abstracción
 Es el proceso mediante el cual el diseñador se concentra
sólo en aquellos aspectos que son relevantes, e ignora los
detalles irrelevantes
 Los niveles más altos de abstracción esconden los
detalles que no son importantes en ese nivel
 Los niveles más bajo revelan mayores detalles
 En los niveles más bajo de abstracción, una solución se
presenta de tal manera que puede ser implementada
directamente

47. Refinamiento
 Es básicamente una forma de elaboración
 El refinamiento ayuda al diseñador a revelar detalles
de bajo nivel a medida que progresa su diseño de
niveles simple a complejos
Modularidad
 El software puede ser dividido en componentes
individuales llamados módulos.
 Dividir un programa en muchos módulos diferentes lo
simplifica

48. Arquitectura del Software
Diferentes modelos para representar la arquitectura
del software:
• Modelos estructurales
• Modelos de marcos de trabajo
• Modelos dinámicos
• Modelos de proceso
• Modelos funcionales

49. Diseño Modular
• El diseño modular es una de las metodologías de diseño
más usadas
• La implementación del diseño modular ayuda a:
 Reducir la complejidad en el proceso de diseño
 A ejecutar el cambio
 Permitir una implementación más sencilla

50. Tipos de Módulos
• Módulo secuencial
• Modulo incremental
• Módulo paralelo

51. Independencia Funcional
• Desarrollar módulos con funciones singulares
• Desarrollar módulos que no tengan una tendencia hacia
una interacción extra con otros módulos
• En el software cada módulo se debe ocupar de una
sub-función específica de requerimientos
• La interfaz de cada módulo debe verse simple, desde
otras partes del la estructura del programa

52. •Es la propiedad por la cual las cosas que son similares
se mantienen juntas
•Un módulo se considera completamente cohesivo sólo si
realiza una única función o tarea
•Se debe aspirar un alto grado de cohesión
•Bajos niveles de cohesión son contraproducentes para
propósitos de diseño
Cohesión

53. Acoplamiento
• El acoplamiento es la medida de interconexión entre
diferentes módulos dentro de una estructura de
software
• Depende de:
- La complejidad de la interfaz entre dos módulos
diferentes
- La manera en que se hace una referencia al módulo
- La manera en que los datos se pasan a través de la
interfaz

54. Resumen
• Se explicó el proceso de diseño en pocas palabras
• Se explicaron los enfoques top-down y bottom-up
• Se discutieron los principios y objetivos del diseño
• Se discutieron los conceptos cruciales de cohesión
y acoplamiento

55. Unidad 5:
Planeamiento del Software

56. Objetivos de Aprendizaje
• Describir los diferentes pasos que tiene el planeamiento
de un proyecto
• Discutir las diferentes actividades que abarca el análisis
de riesgos
• Explicar la administración del riesgo
• Discutir el planeamiento y cronograma de un proyecto de
software
• Describir el planeamiento organizacional

57. Introducción
• La administración de un proyecto tiene tres fases:
 Planeamiento
 Monitoreo y control
 Análisis de culminación
• El planeamiento del proyecto es la responsabilidad más
grande de la administración del proyecto
• Para desarrollar un plan para desarrollar software, los
objetivos de un proyecto deben ser cumplidos
exitosamente y eficientemente

58. Planeamiento de un Proyecto
Estimación
Análisis de Riesgo
Cronograma
Decisiones de adquisición
Reingeniería
Planeamiento Organizacional

59. Administración del Riesgo
Administración
del Riesgo
Análisis del
Riesgo
Identificación
del Riesgo
Proyección del
Riesgo
Evaluación
del Riesgo

60. Análisis de Riesgo
• Riesgo se refiere a las posibilidades que pudieran afectar
el costo, la calidad o el cronograma de un desarrollo de
software
• Factores como el método de implementación u operación
de un programa/aplicación, el tipo de herramientas
usadas, el número de personal involucrado, etc.

61. Identificación del Riesgo
Los riesgos se agrupan generalmente bajo varias categorías
como:
• Riesgos de proyecto
• Riesgos técnicos
• Riesgos de negocio

62. Proyección del Riesgo
• Medir la probabilidad de ocurrencia del riesgo
• Listar el conjunto de problemas que se necesita manejar
si el riesgo ocurre
• Hacer un estimado del impacto del riesgo en el proyecto
en cuestión
• Evaluar el nivel de confiabilidad con el cual se ha
proyectado el riesgo

63. Evaluación del Riesgo
• Definir niveles de referencia de riesgo para un proyecto
• Construir una relación entre los factores individuales,
versus riesgo, probabilidad de riesgo, e impacto de
riesgo y niveles de referencia individuales
• Tener un conjunto de puntos de quiebre que definirá la
región de culminación
• Entender la manera en la que las combinaciones de
riesgos afectarán un nivel de referencia

64. Administración y Monitoreo de Riesgos
Identificación
del Riesgo
Análisis
del Riesgo
Planificación
del Riesgo
Monitoreo
del Riesgo
Lista de Riesgos
potenciales
Lista de Riesgos
con prioridades
Plan de contingencia
y prevención del
Riesgo
Evaluación del
Riesgo

65. Cronograma del Proyecto de Software
• El cronograma de un proyecto de software puede hacerse de
dos maneras
 La fecha límite para la publicación del producto / programa ya
ha sido fijada y la compañía desarrolladora tiene que distribuir
el esfuerzo en un espacio de tiempo específico
 Los períodos de tiempo aproximado han sido dados, pero la
compañía desarrolladora fija la fecha de finalización
• La certeza en el cronograma algunas veces juega un rol más
importante que la certeza en los costos

66. Relación Trabajo-Personas
• A medida que el tamaño del proyecto se incrementa, más
se necesitará más personas para alcanzar el resultado
final en un periodo de tiempo dado
• Si el proyecto esta retrasado, incrementar el número de
programadores seguramente acelerará el proceso
• Incrementar en el número de desarrolladores también
incrementará los canales de comunicación dentro del
sistema, y por lo tanto incrementa la complejidad de los
procesos de comunicación

67. Paralelismo y Definición de Tareas
• Los proyectos de desarrollo de software son usualmente
tomados en paralelo cuando más de una persona está
involucrada en el proceso de desarrollo
• La base para tareas paralelas es el análisis,
especificación y la revisión resultante de los
requerimientos
• Una vez que los requerimientos han sido identificados y
revisados, las actividades de diseño y planeamiento de
pruebas se llevan en paralelo

68. Distribución de Esfuerzo
• El esfuerzo de distribución de un proyecto está dirigido
sólo por las características de ese proyecto particular
• Generalmente el análisis de requerimiento constituye
sólo un 10 a 25 % del esfuerzo del proyecto
• El esfuerzo del planeamiento del proyecto es usualmente
sólo 2 a 3 % del total de esfuerzo del proyecto
• El esfuerzo gastado en prototipo o análisis usualmente
se incrementa en proporción directa al tamaño y
complejidad del proyecto

69. Diferentes Modelos para Cronogramas
• Los dos métodos más comúnmente usados para los
cronogramas de desarrollo de software son:
Evaluación del Programa y Técnica de Revisión (PERT)
Método de la Ruta Crítica (CPM)

70. Decisiones de Adquisición
• El software puede ser comprado o licenciado
• El software puede ser comprado y luego personalizado a
las necesidades
• El software puede ser también hecho a la medida dando el
desarrollo a un contratista externo

71. Re-ingeniería
• Ciertas aplicaciones de software pueden haber sido
desarrolladas con un diseño en particular
• Las diferentes adiciones y actividades de mantenimiento
podrían haber afectado el diseño original
• Tales aplicaciones son difíciles y costosas de mantener
• Es posible rediseñar tal sistema de software y desarrollarlo
de nuevo

72. Plan del proyecto del software
• Estimación del costo
• Cronogramas e hitos
• Plan del personal
• Aseguramiento de la calidad de software
• Plan de la administración de configuración
• Plan de monitoreo del proyecto
• Administración del riesgo

73. Administración de Configuración
Controlar los cambios y documentación relacionada
Documentar las características funcionales y
físicas de los elementos de configuración
Guardar y reportar la información requerida para la
administración efectiva de elementos de configuración
Auditar elementos para verificar la conformidad con
las especificaciones, diagramas, documentos de
control de interfaces y requerimientos contractuales

74. Herramientas de Administración de la Configuración
• Administración de la configuración del software basada en
archivo
• Administración de la configuración del Software basada en
repositorio del proyecto
• Administración de Configuración del Software basada en
transparencia del archivo

75. Ventajas de la Administración de la Configuración
• Implementar un buen proceso y sistema de SCM, usado
correctamente ahorrará dinero
• Muchas compañías adoptan prácticas de SCM porque
desean poder controlar y dirigir el proceso complejo lo mejor
que pueden
• Los gastos incluyen gastos en eliminar errores, rediseño,
correcciones

76. Resumen
• Se describieron los diferentes pasos que tiene el
planeamiento de un proyecto
• Se discutió acerca de las diferentes actividades que
abarca el análisis de riesgos
• Se explicó la administración del riesgo
• Se discutió acerca del planeamiento y cronograma de un
proyecto de software
• Se describió el planeamiento organizacional
• Se explicó la administración de la configuración