Procesos de Software EGEL-UNITEC

Ingeniería de SoftwareEGEL

M. en C. Michael Rojas R.Correo: [email protected]

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: [email protected]

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.


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.


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


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

• Todo el desarrollo del software se puede caracterizar como bucle de resolución de problemas en el que se encuentran cuatro etapas distintas:


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 dealguna tecnología


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


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

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



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


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


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


• 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


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


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


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


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


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”


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


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


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.


• 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


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

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


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

Sin metodología Con metodología

Metodologías: Aplicación a la Ingeniería de Software

Metodologías: ElementosDefine 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.


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.


– 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

http://goo.gl/DemhcY

Education

Procesos de Software EGEL-UNITEC