Ingenieria de Software

1. INGENIERÍA DE SOFTWARE
Ing. Jorge Hernando Mongui Naranjo
Esp. Gerencia Informática
Esp. Soluciones cableadas e inalámbricas
Jorge.mongui2008@gmail.com

2. HISTORIA
 Este término fue introducido a finales de los 60 a raíz de
la crisis del software.
 Esta crisis fue el resultado de la introducción de la
tercera generación del hardware.
 El hardware dejo de ser un impedimento para el
desarrollo de la informática; redujo los costos y mejoro
la calidad y eficiencia en el software producido
La crisis se caracterizo por los siguientes problemas:
 Imprecisión en la planificación del proyecto y estimación
de los costos.

3. HISTORIA
 Baja calidad del software.
 Dificultad de mantenimiento de programas con un
diseño poco estructurado, etc.
 Por otra parte se exige que el software sea eficaz y
barato tanto en el desarrollo como en la compra.
 También se requiere una serie de características
como fiabilidad, facilidad de mantenimiento y de
uso, eficiencia, etc.

4. Ingeniería de software es la disciplina o área de
la informática que ofrece métodos y técnicas
para desarrollar y mantener software de calidad.

6. INGENIERÍA DE SOFTWARE
Ingeniería del Software, término utilizado por primera vez
por Fritz Bauer en la primera conferencia sobre
desarrollo de software patrocinada por el Comité de
Ciencia de la OTAN celebrada en Garmisch, Alemania,
en octubre de 1968.

7. INGENIERÍA DE SOFTWARE
Una definición precisa aún no ha sido contemplada en los
diccionarios, sin embargo se pueden citar las enunciadas
por algunos de los más prestigiosos autores:

8. AUTORES
1 - Ingeniería de Software es el estudio de los
principios y metodologías para el desarrollo y
mantenimiento de sistemas software (Zelkovitz,
1978).
2 - Ingeniería de software es la aplicación práctica del
conocimiento científico al diseño y construcción de
programas de computadora y a la documentación
asociada requerida para desarrollar, operar y
mantenerlos. Se conoce también como Desarrollo
de Software o Producción de Software (Bohem,
1976).

9. 3 - Ingeniería de Software trata del establecimiento de los
principios y métodos de la ingeniería a fin de obtener
software de modo rentable, que sea fiable y trabaje en
máquinas reales (Bauer, 1972).
4 - Es la aplicación de un enfoque sistemático, disciplinado
y cuantificable al desarrollo, operación y mantenimiento
del software; es decir, la aplicación de la ingeniería al
software (IEEE, 1993).

10. OBJETIVOS DE LA INGENIERÍA
DE SOFTWARE
 En la construcción y desarrollo de proyectos se aplican
métodos y técnicas para resolver los problemas, la
informática aporta herramientas y procedimientos sobre
los que se apoya la ingeniería de software.

11.  Mejorar la calidad de los productos de software
 Aumentar la productividad y trabajo de los ingenieros del
software.
 Facilitar el control del proceso de desarrollo de software.
 Suministrar a los desarrolladores las bases para
construir software de alta calidad en una forma eficiente.

12. OBJETIVOS
Para que los objetivos se cumplan las empresas
emprenden proyectos por las siguientes razones: "Las
cinco C”.

13. RAZONES
 Capacidad
 Costo
 Control
 Comunicación
 Competitividad

14. CAPACIDAD
Las actividades de la organización están influenciadas por
la capacidad de ésta para procesar transacciones con
rapidez y eficiencia.

15. COSTO
Vigilancia de los costos:
Para determinar si la compañía evoluciona en la
forma esperada, de acuerdo con lo presupuestado,
se debe llevar a cabo el seguimiento de los costos
de mano de obra, bienes y gastos generales.

16. CONTROL
Llevar una estadística que permita darle al usuario
tranquilidad es muy difícil sin contar con la ayuda de una
computadora.

17. COMUNICACIÓN
La falta de comunicación es una fuente común de
dificultades que afectan tanto a cliente como a
empleados. Sin embargo, los sistemas de información
bien desarrollados amplían la comunicación y facilitan la
integración de funciones individuales.

18. COMPETITIVIDAD
Los sistemas de información computacionales son un
arma estratégica, capaz de cambiar la forma en
que la compañía compite en el mercado, en
consecuencia éstos sistemas mejoran la
organización y la ayudan a ganar "ventaja
competitiva", sin embargo, si los competidores de
la compañía tienen capacidades mas avanzadas
para el procesamiento de información, entonces los
sistemas de información pueden convertirse en una
"desventaja competitiva".

19. ETAPAS DEL PROCESO
La ingeniería de software requiere llevar a cabo
numerosas tareas, dentro de etapas como las
siguientes:

20. ANÁLISIS DE REQUISITOS
Extraer los requisitos de un producto de software es la
primera etapa para crearlo. Mientras que los clientes
piensan que ellos saben lo que el software tiene que
hacer, se requiere de habilidad y experiencia en la
ingeniería de software para reconocer requisitos
incompletos, ambiguos o contradictorios. El resultado
del análisis de requisitos con el cliente se plasma en el
documento ERS, Especificación de Requerimientos del
Sistema, cuya estructura puede venir definida por varios
estándares, tales como CMM-I Asimismo, se define un
diagrama de entidad, en el que se plasman las
principales entidades que participarán en el desarrollo
del software.

21. ESPECIFICACIÓN
Es la tarea de describir detalladamente el software a
ser escrito, en una forma matemáticamente
rigurosa. En la realidad, la mayoría de las buenas
especificaciones han sido escritas para entender y
afinar aplicaciones que ya estaban desarrolladas.
Las especificaciones son más importantes para las
interfaces externas, que deben permanecer
estables.

22. DISEÑO Y ARQUITECTURA
Se refiere a determinar como funcionará de forma
general sin entrar en detalles. Consiste en
incorporar consideraciones de la implementación
tecnológica, como el hardware, la red, etc. Se
definen los casos de uso para cubrir las funciones
que realizará el sistema, y se transforman las
entidades definidas en el análisis de requisitos en
clases de diseño, obteniendo un modelo cercano a
la programación orientada a objetos.

23. PROGRAMACIÓN
Reducir un diseño a código puede ser la parte más
obvia del trabajo de ingeniería de software, pero no
necesariamente es la que demanda mayor trabajo
y ni la más complicada. La complejidad y la
duración de esta etapa está íntimamente
relacionada al o a los lenguajes de programación
utilizados, así como al diseño previamente
realizado.

24. DOCUMENTACIÓN
Todo lo concerniente a la documentación del propio
desarrollo del software y de la gestión del proyecto,
pasando por modelaciones (UML), diagramas,
pruebas, manuales de usuario, manuales técnicos,
etc.; todo con el propósito de eventuales
correcciones, usabilidad, mantenimiento futuro y
ampliaciones al sistema.

25. MANTENIMIENTO
Mantener y mejorar el software para enfrentar errores
descubiertos y nuevos requisitos. Esto puede llevar
más tiempo incluso que el desarrollo inicial del
software. Alrededor de 2/3 de toda la ingeniería de
software tiene que ver con dar mantenimiento. Una
pequeña parte de este trabajo consiste en arreglar
errores, o Bugs. La mayor parte consiste en
extender el sistema para hacer nuevas cosas. De
manera similar, alrededor de 2/3 de toda la
ingeniería civil, arquitectura y trabajo de
construcción es dar mantenimiento.

26. EL PROCESO UNIFICADO
El Proceso Unificado "es un proceso de desarrollo de
software configurable que se adapta a través de los
proyectos variados en tamaños y complejidad. Se
basa en muchos años de experiencia en el uso de
la tecnología orientada a objetos en el desarrollo de
software de misión crítica en una variedad de
industrias por la compañía Rational", donde
confluyen 'los tres amigos' como se llaman a sí
mismos o los tres grandes: Grady Booch, James
Rumbaugh e Ivar Jacobson.

27. PROCESO UNIFICADO Y MSF; COMPLEMENTOS
TECNOLÓGICOS
Según "más que una metodología, Microsoft Solutions
Framework MSF. Es una serie de modelos flexibles
interrelacionados que guían a una organización sobre
como ensamblar los recursos, el personal y las técnicas
necesaria para asegurar que su infraestructura
tecnológica y sus soluciones cumplan los objetivos de
negocio. MSF mantiene una relación clara entre los
objetivos de negocio y las implementaciones
tecnológicas".

28. "MSF se puede utilizar por sí mismo o con otras
herramientas y técnicas como el Proceso Rational
[Proceso Unificado] para planear, construir y administrar
el desarrollo de soluciones de negocio a la medida“
"El proceso Unificado es un proceso de desarrollo de
software configurable que se adapta a proyectos que
varían en tamaño y complejidad. Se basa en muchos
años de experiencia en el uso de la tecnología de
objetos en el desarrollo de software de misión crítica en
una variedad de industrias. Uno de los componentes
clave es el UML"

29. EL PROCESO UNIFICADO HA ADOPTADO UN
ENFOQUE QUE SE CARACTERIZA POR:
 Interacción con el usuario continua desde un inicio
 Mitigación de riesgos antes de que ocurran
 Liberaciones frecuentes
 Aseguramiento de la calidad
 Involucramiento del equipo en todas las decisiones
del proyecto
 Anticiparse al cambio de requerimientos

30. El Proceso Unificado y MSF se enfocan en la
arquitectura como el centro del desarrollo para
asegurar que el desarrollo basado en componentes
sea clave para un alto nivel de reuso. MSF
considera que hay cuatro perspectivas de
arquitectura que cumplen los requerimientos de
una empresa

31.  Arquitectura de Negocios - Describe como opera
un negocio. Desarrolla una imagen clara de los
procesos de flujo de trabajo de la organización y de
cómo son apoyados por una infraestructura
tecnológica basada en servicios.

32.  Arquitectura de Aplicación – Adopta un modelo
de aplicación de toda la empresa para diseñar y
desarrollar sistemas de negocios que puedan
compartir un conjunto de componentes back-end
de alto valor.

33.  Arquitectura de Información – Define qué
información es necesaria para apoyar el proceso
de negocios, cómo poner esa información
eficientemente en manos de quienes la necesitan
sin crear islas de datos inaccesibles ni sistemas
redundantes.

34.  Arquitectura Tecnológica – Define los estándares
y guías para la adquisición y despliegue de
herramientas, bloques de construcción de
aplicaciones, servicios de infraestructura,
componentes de conectividad de red y plataformas
cliente servidor.

35. MODELOS DE DESARROLLO DE SOFTWARE
La ingeniería de software tiene varios modelos o
paradigmas de desarrollo en los cuales se puede
apoyar para la realización de software, de los cuales
podemos destacar a éstos por ser los más utilizados y
los más completos:
 Modelo en cascada o Clásico (modelo tradicional)
 Modelo en espiral (modelo evolutivo)
 Modelo de prototipos
 Desarrollo por etapas
 Desarrollo iterativo y creciente o Iterativo Incremental
 RAD (Rapid Application Development)

36. MODELO EN CASCADA O CLÁSICO (MODELO
TRADICIONAL)
 es el enfoque metodológico que ordena
rigurosamente las etapas del ciclo de vida del
software, de forma tal que el inicio de cada etapa
debe esperar a la finalización de la inmediatamente
anterior.

37. MODELO EN CASCADA O CLÁSICO
Un ejemplo de una metodología de desarrollo en
cascada es:
 Análisis de requisitos
 Diseño del Sistema
 Diseño del Programa
 Codificación
 Pruebas
 Implantación
 Mantenimiento

38.  De esta forma, cualquier error de diseño detectado en la
etapa de prueba conduce necesariamente al rediseño y
nueva programación del código afectado, aumentando
los costes del desarrollo. La palabra cascada sugiere,
mediante la metáfora de la fuerza de la gravedad, el
esfuerzo necesario para introducir un cambio en las
fases más avanzadas de un proyecto.
 Si bien ha sido ampliamente criticado desde el ámbito
académico y la industria, sigue siendo el paradigma más
seguido al día de hoy.

39. DESVENTAJAS
 En la vida real, un proyecto rara vez sigue una secuencia
lineal, esto crea una mala implementación del modelo, lo cual
hace que lo lleve al fracaso. Difícilmente un cliente va a
establecer al principio todos los requerimientos necesarios,
por lo que provoca un gran atraso trabajando en este modelo,
ya que este es muy restrictivo y no permite movilizarse entre
fases. Los resultados y/o mejoras no son visibles, el producto
se ve recién cuando este esté finalizado, lo cual provoca una
gran inseguridad por parte del cliente que anda ansioso de ver
avances en el producto. Esto también implica toparse con
requerimientos que no se habían tomado en cuenta, y que
surgieron al momento de la implementación, lo cual provocara
que se regrese nuevamente a la fase de requerimientos.

40. VENTAJAS
 Se tiene todo bien organizado y no se mezclan las
fases.
Es perfecto para proyectos que son rígidos, y
además donde se especifiquen muy bien los
requerimientos y se conozca muy bien la
herramienta a utilizar

41. DESARROLLO EN ESPIRAL
 El Desarrollo en Espiral es un modelo de ciclo de
vida desarrollado por Barry Boehm en 1985,
utilizado generalmente en la Ingeniería de software.
Las actividades de este modelo se conforman en
una espiral, cada bucle representa un conjunto de
actividades. Las actividades no están fijadas a
priori, sino que las siguientes se eligen en función
del análisis de riesgo, comenzando por el bucle
interior.

42. El modelo de desarrollo en espiral es un generador de
modelo de proceso guiado por el riesgo que se emplea
para conducir sistemas intensivos de ingeniería de
software concurrente y a la vez con muchos usuarios.
Se caracteriza principalmente por:
 Un enfoque cíclico para el crecimiento incremental del
grado de definición e implementación de un sistema,
mientras que disminuye su grado de riesgo.
 Un conjunto de puntos de fijación para asegurar el
compromiso del usuario con soluciones de sistema que
sean factibles y mutuamente satisfactorias.

43. EN CADA VUELTA O ITERACIÓN HAY QUE
TENER EN CUENTA
 Los Objetivos: Que necesidad debe cubrir el producto.
 Alternativas: Las diferentes formas de conseguir los
objetivos de forma exitosa, desde diferentes puntos de
vista como pueden ser:
 Características: experiencia del personal, requisitos a
cumplir, etc.
 Formas de gestión del sistema.
 Riesgo asumido con cada alternativa.
 Desarrollar y Verificar: Programar y probar el software.

45. PRINCIPIOS BÁSICOS:
 El modelo espiral captura algunos principios
básicos:
 Decidir qué problema se quiere resolver antes de
viajar a resolverlo.
 Examinar tus múltiples alternativas de acción y
elegir una de las más convenientes.
 Evaluar qué tienes hecho y qué tienes que haber
aprendido después de hacer algo.

46.  Modelo en espiral se divide en un número de
actividades estructurales, también llamadas
regiones de tareas. Generalmente, existen entre
tres y seis regiones de tareas.

47.  Comunicación con el cliente: las tareas requeridas para
establecer comunicación entre el desarrollador y el cliente.
 Planificación: las tareas requeridas para definir recursos, el
tiempo y otras informaciones relacionadas con el proyecto.
Son todos los requerimientos.
 Análisis de riesgos: las tareas requeridas para evaluar
riesgos técnicos y otras informaciones relacionadas con el
proyecto.
 Ingeniería: las tareas requeridas para construir una o más
representaciones de la aplicación.
 Construcción y adaptación: las tareas requeridas para
construir, probar, instalar y proporcionar soporte al usuario.
 Evaluación el cliente: las tareas requeridas para obtener la
reacción del cliente según la evaluación de las
representaciones del software creadas durante la etapa de
ingeniería e implementación durante la etapa de instalación.

48. MODELO DE PROTOTIPOS
 En Ingeniería de software el desarrollo con
prototipación, también llamado modelo de
prototipos que pertenece a los modelos de
desarrollo evolutivo, se inicia con la definición de
los objetivos globales para el software, luego se
identifican los requisitos conocidos y las áreas del
esquema en donde es necesaria más definición.
Entonces se plantea con rapidez una iteración de
construcción de prototipos y se presenta el
modelado (en forma de un diseño rápido).

49. El diseño rápido se centra en una representación de
aquellos aspectos del software que serán visibles
para el cliente o el usuario final (por ejemplo, la
configuración de la interfaz con el usuario y el
formato de los despliegues de salida). El diseño
rápido conduce a la construcción de un prototipo, el
cual es evaluado por el cliente o el usuario para
una retroalimentación; gracias a ésta se refinan los
requisitos del software que se desarrollará. La
iteración ocurre cuando el prototipo se ajusta para
satisfacer las necesidades del cliente. Esto permite
que al mismo tiempo el desarrollador entienda
mejor lo que se debe hacer y el cliente vea
resultados a corto plazo.

50. VENTAJAS
 Este modelo es útil cuando el cliente conoce los
objetivos generales para el software, pero no
identifica los requisitos detallados de entrada,
procesamiento o salida.
 También ofrece un mejor enfoque cuando el
responsable del desarrollo del software está
inseguro de la eficacia de un algoritmo, de la
adaptabilidad de un sistema operativo o de la forma
que debería tomar la interacción humano-máquina.

51. INCONVENIENTES
 El usuario tiende a crearse unas expectativas
cuando ve el prototipo de cara al sistema final. A
causa de la intención de crear un prototipo de
forma rápida, se suelen desatender aspectos
importantes, tales como la calidad y el
mantenimiento a largo plazo, lo que obliga en la
mayor parte de los casos a reconstruirlo una vez
que el prototipo ha cumplido su función. Es
frecuente que el usuario se muestre reacio a ello y
pida que sobre ese prototipo se construya el
sistema final, lo que lo convertiría en un prototipo
evolutivo, pero partiendo de un estado poco
recomendado.

52. INCONVENIENTES
 En aras de desarrollar rápidamente el prototipo, el
desarrollador suele tomar algunas decisiones de
implementación poco convenientes (por ejemplo,
elegir un lenguaje de programación incorrecto
porque proporcione un desarrollo más rápido). Con
el paso del tiempo, el desarrollador puede olvidarse
de la razón que le llevó a tomar tales decisiones,
con lo que se corre el riesgo de que dichas
elecciones pasen a formar parte del sistema final.

53. DESARROLLO RÁPIDO DE APLICACIONES
 Rapid application development (RAD) es un
proceso de desarrollo de software (en inglés,
software development process), desarrollado
inicialmente por James Martin en 1980. El método
comprende el desarrollo iterativo, la construcción
de prototipos y el uso de utilidades CASE
(Computer Aided Software Engineering).
Tradicionalmente, el desarrollo rápido de
aplicaciones tiende a englobar también la
usabilidad, utilidad y la rapidez de ejecución.

54. VENTAJAS Y DESVENTAJAS
El desarrollo rápido tiene dos ventajas primarias:
 Velocidad del desarrollo: Los aumentos de la
velocidad son debido al uso de la herramienta
CASE.
 Calidad: según lo definido por el RAD, es el grado
al cual un uso entregado resuelve las necesidades
de usuarios así como el grado al cual un sistema
entregado tiene costes de mantenimiento bajos. El
RAD aumenta calidad con la implicación del
usuario en las etapas del análisis y del diseño.

55. VENTAJAS Y DESVENTAJAS
El RAD tiene dos desventajas primarias:
 Características reducidas.
 Escalabilidad reducida: debido a que el RAD se
desarrolló como prototipo

56. PROCESO UNIFICADO
 El nombre Proceso Unificado se usa para describir el
proceso genérico que incluye aquellos elementos que
son comunes a la mayoría de los refinamientos
existentes. También permite evitar problemas legales ya
que Proceso Unificado de Rational o RUP son marcas
registradas por IBM (desde su compra de Rational
Software Corporation en 2003). El Proceso Unificado es
un marco de desarrollo iterativo e incremental
compuesto de cuatro fases denominadas Inicio,
Elaboración, Construcción y Transición. Cada una de
estas fases es a su vez dividida en una serie de
iteraciones (la de inicio sólo consta de varias iteraciones
en proyectos grandes). Estas iteraciones ofrecen como
resultado un incremento del producto desarrollado que
añade o mejora las funcionalidades del sistema en
desarrollo

57. CARACTERÍSTICAS
 Es un conjunto de actividades necesarias para
transformar los requerimientos de un usuario en un
sistema de software.
 Proceso Unificado es un marco de trabajo de proceso
genérico que puede especializarse para cada clase de
sistemas de software, para diferentes áreas de
aplicación, tipo de organizaciones, niveles de
competencia y tamaños de proyecto.
 Proceso de Desarrollo de Software --- requerimientos----
Sistema de Software
 Basado en componentes, significa que está hecho de
componentes de software interconectados con
interfaces.
 Usa el Lenguaje de Modelado Unificado (UML)

58. CENTRADO EN LA ARQUITECTURA
 Concepto similar a la arquitectura de un edificio
 Varios planos con diferentes aspectos del edificio
 Tener una imagen completa del edificio antes que
comience la construcción
 Arquitectura en software
 Diferentes vistas del sistema: estructural, funcional,
dinámico, etc.
 Plataforma en la que va a operar
 Determina la forma del sistema
 Arquitectura: determina la forma del sistema
 Casos de uso:
 Determinan la función del sistema

59. ASPECTOS QUE DISTINGUEN AL PU
 Manejado por Caso de Uso
 Centrado en Arquitectura
 Iterativo e Incremental

60. PU ES MANEJADO POR CASO DE USO
 Un usuario representa a alguien o algo que
Interactúa con el sistema
 En respuesta, el sistema realiza una secuencia
de Acciones que proporcionan al usuario un
 Resultado de valor una interacción de este tipo
es un caso de uso

61. INTERACTIVO E INCREMENTAL
 Descomposición de un proyecto grande en mini-
proyectos
 Cada mini-proyecto es una iteración
 Las iteraciones deben estar controladas
 Cada iteración trata un conjunto de casos de uso

62. VENTAJAS DEL ENFOQUE ITERATIVO
 Detección temprana de riesgos
 Administración adecuada del cambio
 Mayor grado de reutilización
 Mayor experiencia para el grupo de desarrollo

63. CASO DE USO

64. HISTORIA
 En 1986, Ivar Jacobson, importante contribuyente
al desarrollo de los modelos de UML y proceso
unificado, creó el concepto de caso de uso.

65.  Un caso de uso es una secuencia de interacciones
que se desarrollarán entre un sistema y sus actores
en respuesta a un evento que inicia un actor
principal sobre el propio sistema. Cada caso de uso
proporciona uno o más escenarios que indican
cómo debería interactuar el sistema con el usuario
o con otro sistema para conseguir un objetivo
específico. Un diagrama muestra la relación entre
los actores y los casos de uso en un sistema. Una
relación es una conexión entre los elementos del
modelo, por ejemplo la especialización y la
generalización son relaciones. Los diagramas de
casos de uso se utilizan para ilustrar los
requerimientos del sistema al mostrar como
reacciona una respuesta a eventos que se
producen en el mismo.

66. Una metodología de desarrollo de software es
dirigida por casos de uso, si cada una de las
actividades o disciplinas de su proceso (análisis
de requerimientos, diseño, implementación y
prueba) es dirigida en su ejecución por los
casos de uso. Esto quiere decir que el ingeniero
de software especifica los requerimientos por
medio del modelo de casos de uso, el cual sirve
como referente principal para la construcción
del modelo de diseño, representado
básicamente por medio de los diagramas de
clase y de secuencia