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

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 enCiencias 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 solucionesde 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 deactividades 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óndel 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 abstractade 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 Procesode 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 desarrollodel 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 DESOLUCIONES: 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 delmodelo 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: – Esel 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 delos 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. – secentra 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. – Unavez 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: – Norefleja 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 menudoes 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: – Nose 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 – Cualquiersoftware 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ónde 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.
  • 28.
    • No modificael 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 PARAQUE 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ñorá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ónocurre 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 clienteve 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 – Cualquieraplicació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 • ElDesarrollo 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 • Sise 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 deGestió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 dedatos. 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 deaplicaciones. – 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 yentrega. – 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: – Aplicacionesen 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 demejorar 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 cicloempieza 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 usaen 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 modeloen 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 deriesgos- 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 delcliente- 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 – Proyectosen 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 unarepetició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.
  • 52.
  • 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 enComponentes • 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 enComponentes
  • 56.
    • EJEMPLO – Softwarereutilizable 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 conjuntode 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 ala 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 Conmetodología Metodologías: Aplicación a la Ingeniería de Software
  • 60.
    Metodologías: Elementos Define unaestrategia 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 losMetodologí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 puntode 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 puntode 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 lasfases 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 • Paradescargar esta presentación ingresa la siguiente liga en tu explorador: http://goo.gl/DemhcY