SlideShare una empresa de Scribd logo
1 de 65
Ingeniería de Software
EGEL
M. en C. Michael Rojas R.
Correo: mrojas.unitec@gmail.com
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
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
• 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
• 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
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
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
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
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
• 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
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.
• 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
• 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
• 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
• 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
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.
• 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)
Modelo en Cascada (Lineal-Secuencial)
• 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)
• 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)
• 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)
• 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)
• 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)
• 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)
• 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)
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.
Modelo de Construcción de Prototipos
• 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
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
• 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
• 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
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
• 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
• 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
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.
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)
• 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
• 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
• 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
• 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
• 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
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.
• 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
• 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
• 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
• 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
– 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
– 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
• 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
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.
Iterativo
Incremental
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.
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.
Modelo Basado en Componentes
• 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
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.
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.
Sin metodología Con metodología
Metodologías: Aplicación a la
Ingeniería de Software
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.
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.
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
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
– 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
MUCHAS GRACIAS
• Para descargar esta presentación ingresa la
siguiente liga en tu explorador:
http://goo.gl/DemhcY

Más contenido relacionado

La actualidad más candente

Presentación Unidad 3: Análisis de las Necesidades del Sistema
Presentación Unidad 3: Análisis de las Necesidades del SistemaPresentación Unidad 3: Análisis de las Necesidades del Sistema
Presentación Unidad 3: Análisis de las Necesidades del SistemaMariana Marabay Alba
 
IDR Unidad 4: Validación y gestión de requisitos
IDR Unidad 4: Validación y gestión de requisitosIDR Unidad 4: Validación y gestión de requisitos
IDR Unidad 4: Validación y gestión de requisitosFranklin Parrales Bravo
 
Modelo de casos de uso 2ª versión
Modelo de casos de uso 2ª versiónModelo de casos de uso 2ª versión
Modelo de casos de uso 2ª versiónJose Torres Gonzales
 
Principios de diseño de la arquitectura del software
Principios de diseño de la arquitectura del softwarePrincipios de diseño de la arquitectura del software
Principios de diseño de la arquitectura del softwareJose Patricio Bovet Derpich
 
Preparacion de la Propuesta de Sistemas
Preparacion de la Propuesta de SistemasPreparacion de la Propuesta de Sistemas
Preparacion de la Propuesta de Sistemasakrios
 
Cuadro comparativo analisis estructurado y orientado a objeto
Cuadro comparativo analisis estructurado y orientado a objeto Cuadro comparativo analisis estructurado y orientado a objeto
Cuadro comparativo analisis estructurado y orientado a objeto Freddy Rosales
 
Arquitectura de Bases de Datos Oracle
Arquitectura de Bases de Datos OracleArquitectura de Bases de Datos Oracle
Arquitectura de Bases de Datos Oraclevinivaldivieso
 
Metodologia Kendall y Kendall (1.997)
Metodologia Kendall y Kendall (1.997)Metodologia Kendall y Kendall (1.997)
Metodologia Kendall y Kendall (1.997)RobertoCaniza
 
1.2REQUERIMIENTOS DE LOS USUARIOS (ACTORES INVOLUCRADOS)
1.2REQUERIMIENTOS DE LOS USUARIOS (ACTORES INVOLUCRADOS)1.2REQUERIMIENTOS DE LOS USUARIOS (ACTORES INVOLUCRADOS)
1.2REQUERIMIENTOS DE LOS USUARIOS (ACTORES INVOLUCRADOS)mataditoxd
 
Auditoria en un Centro de Computo
Auditoria en un Centro de ComputoAuditoria en un Centro de Computo
Auditoria en un Centro de Computo1416nb
 
Auditoria en desarrollo de sistemas diapo[1]
Auditoria en desarrollo de sistemas diapo[1]Auditoria en desarrollo de sistemas diapo[1]
Auditoria en desarrollo de sistemas diapo[1]caramelomix
 
Gestion de la configuracion del software
Gestion de la configuracion del softwareGestion de la configuracion del software
Gestion de la configuracion del softwareJohan Prevot R
 
Informe final de Auditoria Informatica
Informe final de Auditoria InformaticaInforme final de Auditoria Informatica
Informe final de Auditoria InformaticaAmd Cdmas
 

La actualidad más candente (20)

Presentación Unidad 3: Análisis de las Necesidades del Sistema
Presentación Unidad 3: Análisis de las Necesidades del SistemaPresentación Unidad 3: Análisis de las Necesidades del Sistema
Presentación Unidad 3: Análisis de las Necesidades del Sistema
 
Iso 12207
Iso 12207Iso 12207
Iso 12207
 
IDR Unidad 4: Validación y gestión de requisitos
IDR Unidad 4: Validación y gestión de requisitosIDR Unidad 4: Validación y gestión de requisitos
IDR Unidad 4: Validación y gestión de requisitos
 
Gestion de redes
Gestion de redesGestion de redes
Gestion de redes
 
Modelo de casos de uso 2ª versión
Modelo de casos de uso 2ª versiónModelo de casos de uso 2ª versión
Modelo de casos de uso 2ª versión
 
tecnicas de revisión del software
tecnicas de revisión del softwaretecnicas de revisión del software
tecnicas de revisión del software
 
Principios de diseño de la arquitectura del software
Principios de diseño de la arquitectura del softwarePrincipios de diseño de la arquitectura del software
Principios de diseño de la arquitectura del software
 
Modelo evolutivo
Modelo evolutivoModelo evolutivo
Modelo evolutivo
 
Preparacion de la Propuesta de Sistemas
Preparacion de la Propuesta de SistemasPreparacion de la Propuesta de Sistemas
Preparacion de la Propuesta de Sistemas
 
Cuadro comparativo analisis estructurado y orientado a objeto
Cuadro comparativo analisis estructurado y orientado a objeto Cuadro comparativo analisis estructurado y orientado a objeto
Cuadro comparativo analisis estructurado y orientado a objeto
 
Arquitectura de Bases de Datos Oracle
Arquitectura de Bases de Datos OracleArquitectura de Bases de Datos Oracle
Arquitectura de Bases de Datos Oracle
 
Metodologia Kendall y Kendall (1.997)
Metodologia Kendall y Kendall (1.997)Metodologia Kendall y Kendall (1.997)
Metodologia Kendall y Kendall (1.997)
 
1.2REQUERIMIENTOS DE LOS USUARIOS (ACTORES INVOLUCRADOS)
1.2REQUERIMIENTOS DE LOS USUARIOS (ACTORES INVOLUCRADOS)1.2REQUERIMIENTOS DE LOS USUARIOS (ACTORES INVOLUCRADOS)
1.2REQUERIMIENTOS DE LOS USUARIOS (ACTORES INVOLUCRADOS)
 
Ejemplo rup
Ejemplo rupEjemplo rup
Ejemplo rup
 
Metodologia kendall y Kendall
Metodologia kendall y KendallMetodologia kendall y Kendall
Metodologia kendall y Kendall
 
Auditoria en un Centro de Computo
Auditoria en un Centro de ComputoAuditoria en un Centro de Computo
Auditoria en un Centro de Computo
 
Auditoria en desarrollo de sistemas diapo[1]
Auditoria en desarrollo de sistemas diapo[1]Auditoria en desarrollo de sistemas diapo[1]
Auditoria en desarrollo de sistemas diapo[1]
 
Atam
AtamAtam
Atam
 
Gestion de la configuracion del software
Gestion de la configuracion del softwareGestion de la configuracion del software
Gestion de la configuracion del software
 
Informe final de Auditoria Informatica
Informe final de Auditoria InformaticaInforme final de Auditoria Informatica
Informe final de Auditoria Informatica
 

Destacado

Archivos.ceneval.edu.mx archivos portal_17353_guiadel_egel-info
Archivos.ceneval.edu.mx archivos portal_17353_guiadel_egel-infoArchivos.ceneval.edu.mx archivos portal_17353_guiadel_egel-info
Archivos.ceneval.edu.mx archivos portal_17353_guiadel_egel-infoMario Chávez Morales
 
52165998 deteccion-de-las-necesidades-informaticas-en-las-organizaciones
52165998 deteccion-de-las-necesidades-informaticas-en-las-organizaciones52165998 deteccion-de-las-necesidades-informaticas-en-las-organizaciones
52165998 deteccion-de-las-necesidades-informaticas-en-las-organizacionesJare Muñoz
 
Evaluacion de proyectos tecnologicos
Evaluacion de proyectos tecnologicosEvaluacion de proyectos tecnologicos
Evaluacion de proyectos tecnologicosMonica Barrera
 
Examen General de Licenciatura
Examen General de LicenciaturaExamen General de Licenciatura
Examen General de LicenciaturaChristhiam Cabrera
 
Gestion informatica guia
Gestion informatica guiaGestion informatica guia
Gestion informatica guiaPlukis Sanchez
 
15059526 guia-del-examen-egel-para-informatica
15059526 guia-del-examen-egel-para-informatica15059526 guia-del-examen-egel-para-informatica
15059526 guia-del-examen-egel-para-informaticaJoVaz Lukaz Glez
 
Gestión de Proyectos Tecnológicos
Gestión de Proyectos TecnológicosGestión de Proyectos Tecnológicos
Gestión de Proyectos TecnológicosMariaFontalvo
 
Manual reactivos ceneval.
Manual reactivos ceneval.Manual reactivos ceneval.
Manual reactivos ceneval.zakuvmupn
 
EXAMEN CENEVAL CONTESTADO
EXAMEN CENEVAL CONTESTADOEXAMEN CENEVAL CONTESTADO
EXAMEN CENEVAL CONTESTADOMedi Educa
 
Gua egel ico
Gua egel icoGua egel ico
Gua egel icoCECYTEM
 
Analisis y diseño de un modelo informatico para la gestion del proyecto educa...
Analisis y diseño de un modelo informatico para la gestion del proyecto educa...Analisis y diseño de un modelo informatico para la gestion del proyecto educa...
Analisis y diseño de un modelo informatico para la gestion del proyecto educa...gerenciaproy
 
Guia ceneval contestada (2009)
Guia ceneval contestada (2009)Guia ceneval contestada (2009)
Guia ceneval contestada (2009)armacar
 
Introducción a Swing
Introducción a SwingIntroducción a Swing
Introducción a Swingmrojas_unitec
 
1.1 Nuevas Tecnologias de la Informacion.
1.1 Nuevas Tecnologias de la Informacion.1.1 Nuevas Tecnologias de la Informacion.
1.1 Nuevas Tecnologias de la Informacion.adark
 

Destacado (20)

Archivos.ceneval.edu.mx archivos portal_17353_guiadel_egel-info
Archivos.ceneval.edu.mx archivos portal_17353_guiadel_egel-infoArchivos.ceneval.edu.mx archivos portal_17353_guiadel_egel-info
Archivos.ceneval.edu.mx archivos portal_17353_guiadel_egel-info
 
Guia informática 2 contestada
Guia informática 2   contestadaGuia informática 2   contestada
Guia informática 2 contestada
 
52165998 deteccion-de-las-necesidades-informaticas-en-las-organizaciones
52165998 deteccion-de-las-necesidades-informaticas-en-las-organizaciones52165998 deteccion-de-las-necesidades-informaticas-en-las-organizaciones
52165998 deteccion-de-las-necesidades-informaticas-en-las-organizaciones
 
Evaluacion de proyectos tecnologicos
Evaluacion de proyectos tecnologicosEvaluacion de proyectos tecnologicos
Evaluacion de proyectos tecnologicos
 
Examen General de Licenciatura
Examen General de LicenciaturaExamen General de Licenciatura
Examen General de Licenciatura
 
Gestion informatica guia
Gestion informatica guiaGestion informatica guia
Gestion informatica guia
 
15059526 guia-del-examen-egel-para-informatica
15059526 guia-del-examen-egel-para-informatica15059526 guia-del-examen-egel-para-informatica
15059526 guia-del-examen-egel-para-informatica
 
Gestión de Proyectos Tecnológicos
Gestión de Proyectos TecnológicosGestión de Proyectos Tecnológicos
Gestión de Proyectos Tecnológicos
 
Manual reactivos ceneval.
Manual reactivos ceneval.Manual reactivos ceneval.
Manual reactivos ceneval.
 
EXAMEN CENEVAL CONTESTADO
EXAMEN CENEVAL CONTESTADOEXAMEN CENEVAL CONTESTADO
EXAMEN CENEVAL CONTESTADO
 
Gua egel ico
Gua egel icoGua egel ico
Gua egel ico
 
Guiadel egel info-ng
Guiadel egel info-ngGuiadel egel info-ng
Guiadel egel info-ng
 
Egel
EgelEgel
Egel
 
Guiadel egel isoft
Guiadel egel isoftGuiadel egel isoft
Guiadel egel isoft
 
Analisis y diseño de un modelo informatico para la gestion del proyecto educa...
Analisis y diseño de un modelo informatico para la gestion del proyecto educa...Analisis y diseño de un modelo informatico para la gestion del proyecto educa...
Analisis y diseño de un modelo informatico para la gestion del proyecto educa...
 
Gestion De Proyectos Tecnologicos
Gestion De Proyectos TecnologicosGestion De Proyectos Tecnologicos
Gestion De Proyectos Tecnologicos
 
Guia ceneval contestada (2009)
Guia ceneval contestada (2009)Guia ceneval contestada (2009)
Guia ceneval contestada (2009)
 
Introducción a Swing
Introducción a SwingIntroducción a Swing
Introducción a Swing
 
Presentacin1[1]
Presentacin1[1]Presentacin1[1]
Presentacin1[1]
 
1.1 Nuevas Tecnologias de la Informacion.
1.1 Nuevas Tecnologias de la Informacion.1.1 Nuevas Tecnologias de la Informacion.
1.1 Nuevas Tecnologias de la Informacion.
 

Similar a Procesos de Software EGEL-UNITEC

02 proceso ciclodevida
02 proceso ciclodevida02 proceso ciclodevida
02 proceso ciclodevidaclaudiappaez
 
Ingeniería de software
Ingeniería de softwareIngeniería de software
Ingeniería de softwaremat3matik
 
Ingeniería%20de%20 software[1], maryy
Ingeniería%20de%20 software[1], maryyIngeniería%20de%20 software[1], maryy
Ingeniería%20de%20 software[1], maryynelly
 
Ingeniería de software16
Ingeniería de software16Ingeniería de software16
Ingeniería de software16Ramon
 
Ingenier%c3%ada de software
Ingenier%c3%ada de softwareIngenier%c3%ada de software
Ingenier%c3%ada de softwareMarilupe
 
Ingen de software
Ingen de softwareIngen de software
Ingen de softwareerikapoh
 
Ingeniería de software
Ingeniería de softwareIngeniería de software
Ingeniería de softwaresamantha
 
Ingeniería de software
Ingeniería de softwareIngeniería de software
Ingeniería de software142918
 
Investigación de modelos
Investigación de modelos Investigación de modelos
Investigación de modelos bren1995
 
METODOLOGIA RUP.pptx
METODOLOGIA RUP.pptxMETODOLOGIA RUP.pptx
METODOLOGIA RUP.pptxjuan gonzalez
 

Similar a Procesos de Software EGEL-UNITEC (20)

02 proceso ciclodevida
02 proceso ciclodevida02 proceso ciclodevida
02 proceso ciclodevida
 
Ingeniería de software
Ingeniería de softwareIngeniería de software
Ingeniería de software
 
Ingeniería%20de%20 software[1], maryy
Ingeniería%20de%20 software[1], maryyIngeniería%20de%20 software[1], maryy
Ingeniería%20de%20 software[1], maryy
 
Ingeniería de software16
Ingeniería de software16Ingeniería de software16
Ingeniería de software16
 
Ingenier%c3%ada de software
Ingenier%c3%ada de softwareIngenier%c3%ada de software
Ingenier%c3%ada de software
 
Ingen de software
Ingen de softwareIngen de software
Ingen de software
 
Ingeniería de software
Ingeniería de softwareIngeniería de software
Ingeniería de software
 
Clase 11
Clase 11Clase 11
Clase 11
 
Ingeniería de software
Ingeniería de softwareIngeniería de software
Ingeniería de software
 
Rup
RupRup
Rup
 
Espoch
EspochEspoch
Espoch
 
Clase1
Clase1Clase1
Clase1
 
Software sao
Software saoSoftware sao
Software sao
 
Software
SoftwareSoftware
Software
 
Investigación de modelos
Investigación de modelos Investigación de modelos
Investigación de modelos
 
Presentacion grupo9
Presentacion grupo9Presentacion grupo9
Presentacion grupo9
 
Clase 11
Clase 11Clase 11
Clase 11
 
Modelos
ModelosModelos
Modelos
 
2 modelos de la ingenieria de software
2  modelos de la ingenieria de software2  modelos de la ingenieria de software
2 modelos de la ingenieria de software
 
METODOLOGIA RUP.pptx
METODOLOGIA RUP.pptxMETODOLOGIA RUP.pptx
METODOLOGIA RUP.pptx
 

Último

Presentación Bloque 3 Actividad 2 transversal.pptx
Presentación Bloque 3 Actividad 2 transversal.pptxPresentación Bloque 3 Actividad 2 transversal.pptx
Presentación Bloque 3 Actividad 2 transversal.pptxRosabel UA
 
3. Pedagogía de la Educación: Como objeto de la didáctica.ppsx
3. Pedagogía de la Educación: Como objeto de la didáctica.ppsx3. Pedagogía de la Educación: Como objeto de la didáctica.ppsx
3. Pedagogía de la Educación: Como objeto de la didáctica.ppsxJuanpm27
 
Técnicas de grabado y estampación : procesos y materiales
Técnicas de grabado y estampación : procesos y materialesTécnicas de grabado y estampación : procesos y materiales
Técnicas de grabado y estampación : procesos y materialesRaquel Martín Contreras
 
SIMULACROS Y SIMULACIONES DE SISMO 2024.docx
SIMULACROS Y SIMULACIONES DE SISMO 2024.docxSIMULACROS Y SIMULACIONES DE SISMO 2024.docx
SIMULACROS Y SIMULACIONES DE SISMO 2024.docxLudy Ventocilla Napanga
 
Fichas de matemática DE PRIMERO DE SECUNDARIA.pdf
Fichas de matemática DE PRIMERO DE SECUNDARIA.pdfFichas de matemática DE PRIMERO DE SECUNDARIA.pdf
Fichas de matemática DE PRIMERO DE SECUNDARIA.pdfssuser50d1252
 
05 Fenomenos fisicos y quimicos de la materia.pdf
05 Fenomenos fisicos y quimicos de la materia.pdf05 Fenomenos fisicos y quimicos de la materia.pdf
05 Fenomenos fisicos y quimicos de la materia.pdfRAMON EUSTAQUIO CARO BAYONA
 
Fichas de Matemática DE SEGUNDO DE SECUNDARIA.pdf
Fichas de Matemática DE SEGUNDO DE SECUNDARIA.pdfFichas de Matemática DE SEGUNDO DE SECUNDARIA.pdf
Fichas de Matemática DE SEGUNDO DE SECUNDARIA.pdfssuser50d1252
 
Presentacion minimalista aesthetic simple beige_20240415_224856_0000.pdf
Presentacion minimalista aesthetic simple beige_20240415_224856_0000.pdfPresentacion minimalista aesthetic simple beige_20240415_224856_0000.pdf
Presentacion minimalista aesthetic simple beige_20240415_224856_0000.pdfSarayLuciaSnchezFigu
 
Fisiologia.Articular. 3 Kapandji.6a.Ed.pdf
Fisiologia.Articular. 3 Kapandji.6a.Ed.pdfFisiologia.Articular. 3 Kapandji.6a.Ed.pdf
Fisiologia.Articular. 3 Kapandji.6a.Ed.pdfcoloncopias5
 
IV SES LUN 15 TUTO CUIDO MI MENTE CUIDANDO MI CUERPO YESSENIA 933623393 NUEV...
IV SES LUN 15 TUTO CUIDO MI MENTE CUIDANDO MI CUERPO  YESSENIA 933623393 NUEV...IV SES LUN 15 TUTO CUIDO MI MENTE CUIDANDO MI CUERPO  YESSENIA 933623393 NUEV...
IV SES LUN 15 TUTO CUIDO MI MENTE CUIDANDO MI CUERPO YESSENIA 933623393 NUEV...YobanaZevallosSantil1
 
Presentación de Estrategias de Enseñanza-Aprendizaje Virtual.pptx
Presentación de Estrategias de Enseñanza-Aprendizaje Virtual.pptxPresentación de Estrategias de Enseñanza-Aprendizaje Virtual.pptx
Presentación de Estrategias de Enseñanza-Aprendizaje Virtual.pptxYeseniaRivera50
 
Estas son las escuelas y colegios que tendrán modalidad no presencial este lu...
Estas son las escuelas y colegios que tendrán modalidad no presencial este lu...Estas son las escuelas y colegios que tendrán modalidad no presencial este lu...
Estas son las escuelas y colegios que tendrán modalidad no presencial este lu...fcastellanos3
 
CUADERNILLO DE EJERCICIOS PARA EL TERCER TRIMESTRE, SEXTO GRADO
CUADERNILLO DE EJERCICIOS PARA EL TERCER TRIMESTRE, SEXTO GRADOCUADERNILLO DE EJERCICIOS PARA EL TERCER TRIMESTRE, SEXTO GRADO
CUADERNILLO DE EJERCICIOS PARA EL TERCER TRIMESTRE, SEXTO GRADOEveliaHernandez8
 

Último (20)

Aedes aegypti + Intro to Coquies EE.pptx
Aedes aegypti + Intro to Coquies EE.pptxAedes aegypti + Intro to Coquies EE.pptx
Aedes aegypti + Intro to Coquies EE.pptx
 
Presentación Bloque 3 Actividad 2 transversal.pptx
Presentación Bloque 3 Actividad 2 transversal.pptxPresentación Bloque 3 Actividad 2 transversal.pptx
Presentación Bloque 3 Actividad 2 transversal.pptx
 
3. Pedagogía de la Educación: Como objeto de la didáctica.ppsx
3. Pedagogía de la Educación: Como objeto de la didáctica.ppsx3. Pedagogía de la Educación: Como objeto de la didáctica.ppsx
3. Pedagogía de la Educación: Como objeto de la didáctica.ppsx
 
Técnicas de grabado y estampación : procesos y materiales
Técnicas de grabado y estampación : procesos y materialesTécnicas de grabado y estampación : procesos y materiales
Técnicas de grabado y estampación : procesos y materiales
 
SIMULACROS Y SIMULACIONES DE SISMO 2024.docx
SIMULACROS Y SIMULACIONES DE SISMO 2024.docxSIMULACROS Y SIMULACIONES DE SISMO 2024.docx
SIMULACROS Y SIMULACIONES DE SISMO 2024.docx
 
Fichas de matemática DE PRIMERO DE SECUNDARIA.pdf
Fichas de matemática DE PRIMERO DE SECUNDARIA.pdfFichas de matemática DE PRIMERO DE SECUNDARIA.pdf
Fichas de matemática DE PRIMERO DE SECUNDARIA.pdf
 
Sesión La luz brilla en la oscuridad.pdf
Sesión  La luz brilla en la oscuridad.pdfSesión  La luz brilla en la oscuridad.pdf
Sesión La luz brilla en la oscuridad.pdf
 
DIA INTERNACIONAL DAS FLORESTAS .
DIA INTERNACIONAL DAS FLORESTAS         .DIA INTERNACIONAL DAS FLORESTAS         .
DIA INTERNACIONAL DAS FLORESTAS .
 
05 Fenomenos fisicos y quimicos de la materia.pdf
05 Fenomenos fisicos y quimicos de la materia.pdf05 Fenomenos fisicos y quimicos de la materia.pdf
05 Fenomenos fisicos y quimicos de la materia.pdf
 
Fichas de Matemática DE SEGUNDO DE SECUNDARIA.pdf
Fichas de Matemática DE SEGUNDO DE SECUNDARIA.pdfFichas de Matemática DE SEGUNDO DE SECUNDARIA.pdf
Fichas de Matemática DE SEGUNDO DE SECUNDARIA.pdf
 
Presentacion minimalista aesthetic simple beige_20240415_224856_0000.pdf
Presentacion minimalista aesthetic simple beige_20240415_224856_0000.pdfPresentacion minimalista aesthetic simple beige_20240415_224856_0000.pdf
Presentacion minimalista aesthetic simple beige_20240415_224856_0000.pdf
 
La luz brilla en la oscuridad. Necesitamos luz
La luz brilla en la oscuridad. Necesitamos luzLa luz brilla en la oscuridad. Necesitamos luz
La luz brilla en la oscuridad. Necesitamos luz
 
Fisiologia.Articular. 3 Kapandji.6a.Ed.pdf
Fisiologia.Articular. 3 Kapandji.6a.Ed.pdfFisiologia.Articular. 3 Kapandji.6a.Ed.pdf
Fisiologia.Articular. 3 Kapandji.6a.Ed.pdf
 
Aedes aegypti + Intro to Coquies EE.pptx
Aedes aegypti + Intro to Coquies EE.pptxAedes aegypti + Intro to Coquies EE.pptx
Aedes aegypti + Intro to Coquies EE.pptx
 
IV SES LUN 15 TUTO CUIDO MI MENTE CUIDANDO MI CUERPO YESSENIA 933623393 NUEV...
IV SES LUN 15 TUTO CUIDO MI MENTE CUIDANDO MI CUERPO  YESSENIA 933623393 NUEV...IV SES LUN 15 TUTO CUIDO MI MENTE CUIDANDO MI CUERPO  YESSENIA 933623393 NUEV...
IV SES LUN 15 TUTO CUIDO MI MENTE CUIDANDO MI CUERPO YESSENIA 933623393 NUEV...
 
Presentación de Estrategias de Enseñanza-Aprendizaje Virtual.pptx
Presentación de Estrategias de Enseñanza-Aprendizaje Virtual.pptxPresentación de Estrategias de Enseñanza-Aprendizaje Virtual.pptx
Presentación de Estrategias de Enseñanza-Aprendizaje Virtual.pptx
 
Estas son las escuelas y colegios que tendrán modalidad no presencial este lu...
Estas son las escuelas y colegios que tendrán modalidad no presencial este lu...Estas son las escuelas y colegios que tendrán modalidad no presencial este lu...
Estas son las escuelas y colegios que tendrán modalidad no presencial este lu...
 
VISITA À PROTEÇÃO CIVIL _
VISITA À PROTEÇÃO CIVIL                  _VISITA À PROTEÇÃO CIVIL                  _
VISITA À PROTEÇÃO CIVIL _
 
CUADERNILLO DE EJERCICIOS PARA EL TERCER TRIMESTRE, SEXTO GRADO
CUADERNILLO DE EJERCICIOS PARA EL TERCER TRIMESTRE, SEXTO GRADOCUADERNILLO DE EJERCICIOS PARA EL TERCER TRIMESTRE, SEXTO GRADO
CUADERNILLO DE EJERCICIOS PARA EL TERCER TRIMESTRE, SEXTO GRADO
 
TL/CNL – 2.ª FASE .
TL/CNL – 2.ª FASE                       .TL/CNL – 2.ª FASE                       .
TL/CNL – 2.ª FASE .
 

Procesos de Software EGEL-UNITEC

  • 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.
  • 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