El documento presenta las credenciales y experiencia de Michael Rojas R. en ingeniería de software, incluyendo una maestría en ciencias de la computación y certificaciones en Microsoft, Java, Spring Framework y Android. También describe sus habilidades en el diseño de soluciones de tecnologías de la información y comunicación, así como conceptos clave de ingeniería de software como los modelos de proceso de software.

1. Ingeniería de Software
EGEL
M. en C. Michael Rojas R.
Correo: mrojas.unitec@gmail.com

2. Presentación
• Maestro en Ciencias en Informática, egresado de
la UPIICSA- IPN.
• Certificaciones Microsoft MCPD / VS2010.
• Certificación Java, Oracle Java Programmer (OJP)
• Spring Framework 3.5.
• Hibernate 4.
• Android Framework.
• Correo: mrojas.unitec@gmail.com

3. Diseño de soluciones de Tecnologías
de la Información y Comunicación
• D 1. Análisis de modelos tecnológicos:
– Identificación de las características del modelo
tecnológico
– Selección del modelo tecnológicos
• D 2. Definición de modelos tecnológicos:
– Identificación de objetivos y resultados de un modelo
tecnológico
– Elección de modelos tecnológicos acordes a las
políticas de la organización
– Evaluación de la utilidad de modelos tecnológicos

4. • D 3. Evaluación de modelos tecnológicos:
– Evaluación de alternativas de modelos
tecnológicos viables
– Elección de modelos tecnológicos con base a las
necesidades de la organización
• D 4. Validación de modelos tecnológicos:
– Seguimiento del cumplimiento de los
requerimientos del cliente
– Refinamiento del modelo tecnológico
Diseño de soluciones de Tecnologías
de la Información y Comunicación

5. • Conjunto de actividades que conducen a la creación de un
producto software.
• Dependen de personas que toman decisiones y juicios.
No existe proceso ideal.
• Para los sistemas críticos, se requiere un proceso de
desarrollo muy estructurado.
• Para sistemas de negocio con requerimientos rápidamente
cambiantes, un proceso flexible y ágil probablemente sea
más efectivo.
Proceso de Software

6. Especificación del software
• Se debe definir la funcionalidad del software y las
restricciones en su operación.
• Es una etapa crítica ya que los errores de esta
etapa originan problemas en las demás.
• Se produce un documento de requerimientos.
Fases de proceso de software

7. Diseño e implementación del software
• Se debe producir software que cumpla su
especificación.
• Proceso de convertir una especificación del sistema en
un sistema ejecutable.
• Es una descripción de la estructura del software, datos
del sistema, interfaces entre los componentes y
algoritmos utilizados.
Fases de proceso de software

8. Validación del software
• Se debe validar el software para asegurarse que hace lo
que el cliente desea.
• Se utiliza para mostrar que el sistema se ajusta a su
especificación.
• Deben aprobar un proceso de pruebas.
• Etapas: pruebas de componentes, prueba del sistema,
prueba de aceptación.
Fases de proceso de software

9. Evolución del software
• El software debe evolucionar para cubrir las necesidades
cambiantes del cliente.
• En hardware es muy costoso hacer cambios en su diseño.
• En software se pueden hacer cambios en cualquier
momento.
• El software se cambia continuamente durante su periodo
de vida
Fases de proceso de software

10. • Representación abstracta de un proceso del software.
• Proceso desde perspectiva particular.
• Proporciona sólo información parcial no son
descripciones definitivas de los procesos del software.
• Pueden ser extendidos y adaptados para crear procesos
más específicos de ingeniería del software.
– Modelos:
• El modelo en cascada
• Desarrollo evolutivo
• Ingeniería del software basada en componentes
Modelos del Proceso de Software

11. Modelos del Proceso de Software
• Se utilizan para resolver los problemas reales de
una industria, un ingeniero del software o un
equipo de ingenieros debe incorporar una
estrategia de desarrollo que acompañe al
proceso, métodos y capas de herramientas.
• Se selecciona un modelo de proceso para la
ingeniería del software según la naturaleza del
proyecto y de la aplicación, los métodos y las
herramientas a utilizarse, los controles y entregas
que se requieren.

12. • Todo el
desarrollo del
software se
puede
caracterizar
como bucle de
resolución de
problemas en el
que se
encuentran
cuatro etapas
distintas:
Modelos del Proceso de Software
DEFINICION DE
PROBLEMAS
DESARROLLO
TECNICO
INTEGRACION DE
SOLUCIONES
ESTADO
ACTUAL

13. • ESTADO ACTUAL (STATUS QUO):
«representa el estado actual de sucesos».
• DEFINICIÓN DE PROBLEMAS:
identifica el problema específico a resolverse;
• DESARROLLO TÉCNICO :
resuelve el problema a través de la aplicación de
alguna tecnología
Modelos del Proceso de Software

14. • INTEGRACIÓN DE SOLUCIONES:
ofrece los resultados (por ejemplo:
documentos, programas, datos, nueva función
comercial, nuevo producto) a los que solicitan
la solución en primer lugar.
Modelos del Proceso de Software

15. • Independientemente del modelo de proceso
que se seleccione para un proyecto de
software, todas las etapas podrian coexisten
simultáneamente en algún nivel de detalle.
• Las etapas tratadas anteriormente se aplican
igualmente al análisis de una aplicación
completa y a la generación de un pequeño
segmento de código.
Modelos del Proceso de Software

16. Modelo en Cascada (Lineal-Secuencial)
• Llamado algunas veces «ciclo de vida básico»
el modelo lineal secuencial sugiere un
enfoque sistemático, secuencial, para el
desarrollo del software que comienza en un
nivel de sistemas y progresa con el análisis,
diseño, codificación, pruebas y
mantenimiento.

17. • Características:
– Es el más utilizado.
– Es una visión del proceso de desarrollo de software como una
sucesión de etapas que producen productos intermedios.
– Para que el proyecto tenga éxito deben desarrollarse todas las fases.
– Las fases continúan hasta que los objetivos se han cumplido.
– Si se cambia el orden de las fases, el producto final será de inferior
calidad.
Modelo en Cascada (Lineal-Secuencial)

18. Modelo en Cascada (Lineal-Secuencial)

19. • Análisis de los requisitos del software.
– Para comprender la naturaleza del (los)
programa(s) a construirse, el ingeniero
(«analista») del software debe comprender el
dominio de
– información del software, así como la función
requerida, comportamiento, rendimiento de
interconexión.
Modelo en Cascada (Lineal-Secuencial)

20. • Diseño.
– se centra en cuatro atributos distintos de programa:
estructura de datos, arquitectura de software,
representaciones de interfaz y detalle
– procedimental (algoritmo).
• Generación de código.
– El diseño se debe traducir en una forma legible por la
máquina.
– El paso de generación de código lleva a cabo esta tarea.
– Si se lleva a cabo el diseño de una forma detallada, la
generación de código se realiza mecánicamente.
Modelo en Cascada (Lineal-Secuencial)

21. • Pruebas.
– Una vez que se ha generado el código, comienzan las pruebas
del programa.
– detección de errores y asegurar que la entrada definida produce
resultados reales de acuerdo con los resultados requeridos.
• Mantenimiento.
– Una vez terminado el sistema se le debe dar mantenimiento
para adaptarlo a las cuestiones cambiantes de la empresa.
– Suelen haber proyectos que una vez terminados no se les da
mantenimiento a estos su vida en producción es mas corta.
– El mantenimiento también pueden ser implementación de
nuevas funciones o corrección de errores que no se detectan en
la fase de pruebas.
Modelo en Cascada (Lineal-Secuencial)

22. • Criticas:
– No refleja realmente el proceso de desarrollo del software.
– Se tarda mucho tiempo en pasar por todo el ciclo.
– Perpetua el fracaso de la industria del software en su comunicación
con el usuario final.
– El mantenimiento se realiza en el código fuente.
– Las revisiones de proyectos de gran complejidad son muy difíciles.
– Impone una estructura de gestión de proyectos
Modelo en Cascada (Lineal-Secuencial)

23. • A menudo es difícil que el cliente exponga
explícitamente todos los requisitos.
• El modelo lineal secuencial lo requiere y tiene
dificultades a la hora de acomodar la
incertidumbre natural al comienzo de muchos
proyectos.
• El cliente debe tener paciencia. Una versión de
trabajo del (los) programa(s) no estará disponible
hasta que el proyecto esté muy avanzado.
Modelo en Cascada (Lineal-Secuencial)

24. • Limitaciones:
– No se permiten las iteraciones.
– Los requisitos se congelan al principio del
proyecto.
– No existe un proyecto “enseñable” hasta el final
del proyecto.
Modelo en Cascada (Lineal-Secuencial)

25. • EJEMPLO
– Cualquier software en el que la version se cierra, es
decir, se empaqueta y se entrega al cliente final. En el
que una actualización implica una nueva versión.
• Tutorial e-learning (en flash).
• Software de aplicación como Word, excel, etc.
• Videojuego.
• Apps de uso general.
– Alarmas.
– Contabilidad.
– Fotografía.
Modelo en Cascada (Lineal-Secuencial)

26. Modelo de Construcción de Prototipos
• El paradigma de construcción de prototipos
comienza con la recolección de requisitos.
• El desarrollador y el cliente encuentran y
definen los objetivos globales para el
software, identifican los requisitos conocidos y
las áreas del esquema en donde es obligatoria
más definición.

27. Modelo de Construcción de Prototipos

28. • No modifica el flujo del ciclo de vida
• Reduce el riesgo de construir productos que no
satisfagan las necesidades de los usuarios
• Reduce costos y aumenta la probabilidad de éxito
• Exige disponer de las herramientas adecuadas
• No presenta calidad ni robustez
• Una vez identificados todos los requisitos
mediante el prototipo, se construye el producto
de ingeniería.
Modelo de Construcción de Prototipos

29. EL PROTOTIPADO PARA QUE SEA EFECTIVO:
• Debe ser un sistema con el que se pueda experimentar
• Debe ser comparativamente barato (< 10%)
• Debe desarrollarse rápidamente
• Énfasis en la interfaz de usuario
• Equipo de desarrollo reducido
• Herramientas y lenguajes adecuados
• “El prototipado es un medio excelente para recoger el
‘feedback’ (realimentación) del usuario final”
Modelo de Construcción de Prototipos

30. • El diseño rápido se centra en una representación de
aspectos del software que serán visibles para el
usuario/cliente (enfoques de entrada y formatos de
salida).
• El diseño rápido lleva a la construcción de un prototipo.
• En la mayoría de los proyectos, el primer sistema
construido apenas se puede utilizar y se tiene que tirar,
porque incluso la mejor planificación no es
omnisciente como para que esté perfecta la primera
vez.
Modelo de Construcción de Prototipos

31. • La iteración ocurre cuando el prototipo se
pone a punto para satisfacer las necesidades
del cliente, permitiendo al mismo tiempo que
el desarrollador comprenda mejor lo que se
necesita hacer.
Modelo de Construcción de Prototipos

32. PELIGROS DEL PROTOTIPO
• El cliente ve funcionando lo que para el es la primera
versión del prototipo que ha sido construido con
“plastilina y alambres”, y puede desilusionarse al
decirle que el sistema aun no ha sido construido.
• El desarrollador puede caer en la tentación de ampliar
el prototipo para construir el sistema final sin tener en
cuenta los compromisos de calidad y de
mantenimiento que tiene con el cliente.
Modelo de Construcción de Prototipos

33. • El cliente ve una versión de trabajo del
software, sin saber que con la prisa de hacer
que funcione no se ha tenido en cuenta la
calidad del software global o la facilidad de
mantenimiento a largo plazo.
• Se puede utilizar un sistema operativo o
lenguaje de programación inadecuado
simplemente porque está disponible
Modelo de Construcción de Prototipos

34. • EJEMPLO
– Cualquier aplicación en la que el cliente desea ver
tener idea de cómo quedaría la versión final, se
van tomando los requerimiento con base a lo que
el cliente retroalimente. Aplicaciones muy visuales
y cuando las ideas son frescas.
• Pagina web informativa.
• Apps de un negocio.
• Aplicaciones con realidad aumentada.
Modelo de Construcción de Prototipos

35. Modelo DRA
• El Desarrollo Rápido de Aplicaciones (DRA)es
un modelo de proceso del desarrollo del
software lineal secuencial que enfatiza un
ciclo de desarrollo extremadamente corto.
• Es una adaptación a «alta velocidad» del
modelo lineal secuencial en el que se logra el
desarrollo rápido utilizando una construcción
basada en componentes.

36. Modelo DRA
• Si se comprenden
bien los requisitos y
se limita el ámbito
del proyecto, el
proceso DRA permite
al equipo de
desarrollo crear un
«sistema
completamente
funcional» dentro de
períodos cortos de
tiempo (por ejemplo:
de 60 a 90 días)

37. • Modelado de Gestión. El flujo de información
entre las funciones de gestión se modela de
forma que responda a las siguientes
preguntas:
– ¿Qué información conduce el proceso de gestión?
– ¿Qué información se genera?
– ¿Quién la genera?
– ¿A dónde va la información?
– ¿Quién la procesa?
Modelo DRA

38. • Modelado de datos. Se definen las características
(llamadas atributos) de cada uno de los objetos y
las relaciones entre estos objetos.
• Modelado del proceso.
– Los objetos de datos definidos en la fase de modelado
de datos quedan transformados para lograr el flujo de
información necesario para implementar una función
de gestión.
– Las descripciones del proceso se crean para añadir,
modificar, suprimir, o recuperar un objeto de datos.
Modelo DRA

39. • Generación de aplicaciones.
– En lugar de crear software con lenguajes de
programación, trabaja para volver a utilizar
componentes de programas ya existentes (cuando
es posible) o a crear componentes reutilizables
(cuando sea necesario).
– Se utilizan herramientas para facilitar la
construcción del software.
Modelo DRA

40. • Pruebas y entrega.
– Como el proceso DRA enfatiza la reutilización, ya
se han comprobado muchos de los componentes
de los programas.
– Esto reduce tiempo de pruebas. Sin embargo, se
deben probar todos los componentes nuevos y se
deben ejercitar todas las interfaces a fondo.
Modelo DRA

41. • EJMEPLO:
– Aplicaciones en donde se desarrollen proyectos
simultáneos con un mismo fin o que sean parte de
la mismo software. Desarrollo Orientado a
Objetos.
• Punto de Venta tipo OXXO.
• Cajero Automático.
Modelo DRA

42. Modelo en Espiral
• Es un modelo de proceso de software evolutivo que
conjuga la naturaleza iterativa de construcción de
prototipos con los aspectos controlados y sistemáticos del
modelo lineal secuencial.
• Se desarrolla en una serie de versiones incrementales.
• Durante las primeras iteraciones, la versión incremental
podría ser un modelo en papel o un prototipo.
• Durante las últimas iteraciones, se producen versiones cada
vez más completas del sistema diseñado.

43. • Trata de mejorar los ciclos de vida
clásicos y prototipos.
• Permite acomodar otros modelos
• Incorpora objetivos de calidad y gestión
de riesgos
• Elimina errores y alternativas no
atractivas al comienzo
• Permite iteraciones, vuelta atrás y
finalizaciones rápidas
Modelo en Espiral

44. • Cada ciclo empieza identificando:
– Los objetivos de la porción correspondiente
– Las alternativas
– Restricciones
• Cada ciclo se completa con una revisión que
incluye todo el ciclo anterior y el plan para el
siguiente
Modelo en Espiral

45. • Se usa en proyectos en los que se prevén riesgos.
• Representa un enfoque dirigido por el riesgo para el análisis y
estructuración del proceso software.
• Ventajas:
– Utiliza las fases de modelos tradicionales. Se centra en la eliminación
de errores y alternativas poco atractivas.
– Su orientación a detectar y prevenir el riesgo evita muchas
dificultades.
• Desventajas:
– Complicado: Consume muchos recursos.
– Las etapas y sus E/S no están claramente definidas.
Modelo en Espiral

46. • En modelo en espiral que contiene seis
regiones de tareas:
– 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 otra información
relacionadas con el proyecto.
Modelo en Espiral

47. – análisis de riesgos- las tareas requeridas para
evaluar riesgos técnicos y de gestión.
– ingeniería- las tareas requeridas para construir
una o más representaciones de la aplicación.
– construcción y acción- las tareas requeridas para
construir, probar, instalar y proporcionar soporte
al usuario (por ejemplo: documentación y
práctica)
Modelo en Espiral

48. – evaluación del 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 implementada
durante la etapa de instalación.
Modelo en Espiral

49. • EJEMPLO
– Proyectos en los que hace falta una revisión
exhaustiva, proyectos en los que una vez
terminados se deben hacer pilotos para poder
liberarlos al resto de los clientes.
• Aplicaciones bancarias y de procesamiento de pagos.
• Aplicaciones con cero tolerancia a fallos como
detección de fraudes.
Modelo en Espiral

50. Iterativo
• Es una repetición de varios ciclos de vida en cascada.
• Al final de cada ciclo se entrega una versión completa del software
mejorada respecto a la anterior.
• Los ciclos se repiten hasta obtener un producto satisfactorio.
• Los usuarios deben evaluar el producto en cada iteración y
proponer mejoras.
• Se suele aplicar en desarrollos en los que los requisitos no están
claros, las primeras versiones pueden ser prototipos que se
desechan posteriormente.

51. Iterativo

52. Incremental

53. Iterativo e Incremental
• EJEMPLO (INCREMENTAL E ITERATIVO)
– Software que requiere liberaciones previas a la
productiva como pilotaje.
• Aplicaciones con muchos usuarios que requieren ser
revisadas antes de ponerse en producción.
• Servicios de correo electrónico.
• Software financiero.
• Software que implique revisiones previas.

54. Modelo Basado en Componentes
• Enfatiza la creación de clases que encapsulan
tanto los datos como los algoritmos que se
utilizan para manejar los datos.
• Si se diseñan y se implementan
adecuadamente, las clases orientadas a
objetos son reutilizables por las diferentes
aplicaciones y arquitecturas de sistemas
basados en computadora.

55. Modelo Basado en Componentes

56. • EJEMPLO
– Software reutilizable y modular donde componentes
de código pueden utilizarse n veces o adaptarse con
base a los requerimientos.
– Son utilizados por empresas que tienen alta vision de
proyectos. Todo se puede ocupar de nuevo.
• Aplicaciones en donde hay muchos servicos adjuntos y que
los dueños de los servicios venden en varios lados.
– Servicios de tiempo aire.
– Software integrables.
– Módulos de lectura de tarjetas bancarias.
– Módulos de cifrados de datos.
Modelo Basado en Componentes

57. Metodologías
• El conjunto de métodos que se utilizan en
una determinada actividad con el fin de
formalizarla y optimizarla.
• Determina los pasos a seguir y cómo
realizarlos para finalizar una tarea.

58. Metodologías: Aplicación a la
Ingeniería de Software
• Optimiza el proceso y el producto software.
• Metodologías que guían en la planificación y
en el desarrollo del software.
• Define qué hacer, cómo y cuándo durante
todo el desarrollo y mantenimiento de un
proyecto.

59. Sin metodología Con metodología
Metodologías: Aplicación a la
Ingeniería de Software

60. Metodologías: Elementos
Define una estrategia global para enfrentarse con el
proyecto:
Fases.
Tareas a realizar en cada fase.
Productos (final e intermedios).
E/S de cada fase, documentos.
Procedimientos y herramientas.
Apoyo a la realización de cada tarea.
Criterios de evaluación.
Del proceso y producto. Saber si se han logrado los
objetivos.

61. Ventajas de los Metodologías
• Desde el punto de vista de gestión:
– Facilitar la tarea de planificación.
– Facilitar la tarea de control y seguimiento de un proyecto.
– Mejorar la relación coste/beneficio.
– Optimizar el uso de recursos disponibles.
– Facilitar la evaluación de resultados y cumplimiento de los
objetivos.
– Facilitar la comunicación efectiva entre usuarios y
desarrolladores.
– Ayuda a la gestión del proyecto.

62. Desde el punto de vista de los ingenieros del
software:
– Ayudar a la comprensión del problema.
– Optimizar el conjunto y cada una de las fases del proceso
de desarrollo.
– Facilitar el mantenimiento del producto final.
– Permitir la reutilización de partes del producto.
Ventajas de los Metodologías

63. Desde el punto de vista del cliente o usuario final:
– Garantía de un determinado nivel de calidad en el
producto final.
– Confianza en los plazos de tiempo fijados en la definición
del proyecto.
– Definir el ciclo de vida que más se adecue a las condiciones
y características del desarrollo.
Ventajas de los Metodologías

64. – Determinar las fases dentro del ciclo de vida
especificando su orden de ejecución.
– Definir los resultados intermedios y finales.
– Proporcionar un conjunto de métodos,
herramientas y técnicas para facilitar la tarea del
ingeniero del software y aumentar
suproductividad.
Ventajas de utilizar Metodologías

65. MUCHAS GRACIAS
• Para descargar esta presentación ingresa la
siguiente liga en tu explorador:
http://goo.gl/DemhcY