You are on page 1of 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
Diseño de soluciones de Tecnologías
de la Información y Comunicación
• 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
Proceso de Software
• 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.
Fases de 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
Modelos del 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
• 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.
Modelos del Proceso de Software
• Todo el DEFINICION DE
desarrollo del PROBLEMAS
software se
puede
caracterizar
como bucle de ESTADO DESARROLLO
ACTUAL TECNICO
resolución de
problemas en el
que se
encuentran
INTEGRACION DE
cuatro etapas SOLUCIONES
distintas:
Modelos del Proceso de Software
• 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.
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.
Modelo en Cascada (Lineal-Secuencial)
• 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 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
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 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)
Modelo DRA
• 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 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.
Modelo en Espiral
• 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.
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
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.
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.
Metodologías: Aplicación a la
Ingeniería de Software

Sin metodología Con metodología


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.
Ventajas de los Metodologías
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 utilizar 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.
MUCHAS GRACIAS
• Para descargar esta presentación ingresa la
siguiente liga en tu explorador:

http://goo.gl/DemhcY

You might also like