Fundamentos de Ingenieria de Software.pdf

Fundamentos de Ingenierıa de Software [Modelos]

M. en C. Sergio Luis Perez Perez

UAM CUAJIMALPA, MEXICO, D. F.Trimestre 13-I

Sergio Luis Perez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 1 / 59

Modelos de proceso de software

Modelos de proceso de software I

Un proceso de software es una secuencia de actividades queconducen a la elaboracion de un producto de software.

El desarrollo puede ser desde cero o extendiendo y modificandosoftware ya existente.

Actividades basicas de un proceso de software.Especificacion del software. Definir el alcance del proyecto.Clientes ↔ Ingenieros.

Desarrollo del software. Diseno y Programacion. Ingenieros.

Validacion del software. Pruebas. Ingenieros + Clientes.

Evolucion del software. Estar al dıa con las necesidades del cliente.Ingenieros + Clientes.


Modelos de proceso de software

Modelos de proceso de software II

Las descripciones de los procesos deben considerar:El producto final. Diseno de software → arquitectura del software.

Roles/Funciones. Responsabilidades y funciones de losinvolucrados en el proyecto.

Precondiciones y postcondiciones. Declaraciones validas deactividades/modulos del proceso.

Se analizaran los siguientes modelos de proceso de software:En cascada. Royce 1970.

En espiral. Barry Bohem 1988.

Incremental.

Orientado a la reutilizacion.


Modelos de proceso de software Modelo en cascada

Modelo en cascada I

Se denomina modelo en cascada por que cada fase del modeloconduce a otra.

Tambien se conoce como ciclo de vida del software.

Consiste de cinco fases.Analisis y definicion de requerimientos.

Diseno del sistema y del software.

Implementacion y pruebas de unidad.

Integracion y pruebas del sistema.

Operacion y mantenimiento.



Modelo en cascada II

Analisis y definicion de requerimientosSe debe definir el alcance del proyecto -servicios, restricciones,metas- mediante consultas/entrevistas con el cliente y usuariosdel sistema.

Se debe establecer un documento de especificacion de requisitosque servira como referencia de lo que se debe hacer.



Modelo en cascada III

Diseno del sistema y del softwareSe establecen los requerimientos hardware y/o software delsistema global.

Se deben describir a detalle los componentes principales delsoftware y las relaciones entre ellos.

Lo anterior debe quedar plasmado en un documento del disenodel software.



Modelo en cascada IV

Implementacion y pruebas de unidad

Se lleva a cabo la programacion del diseno del sistema.

Se deben realizar prototipos y pruebas sobre estos, que permitandetectar y corregir errores.

La pruebas consisten en verificar que cada componente cumplacon su especificacion.



Modelo en cascada V

Integracion y pruebas del sistemaLos componentes se integran a fin de formar el sistema global.

Se debe verificar el funcionamiento del nuevo sistema acorde alos requerimientos establecidos.

Se libera la nueva version al cliente para sus usuarios tambienrealicen pruebas.



Modelo en cascada VI

Operacion y mantenimiento

Una version final del sistema queda instalada y puesta enpractica.

Los errores que resulten deben ser corregidos.

Las mejoras requeridas deben ser realizadas.

El sistema debe ser flexible para adecuarse a nuevosrequerimientos.



Modelo en cascada VII

Ventajas

La organizacion y actividades de las fases se encuentran biendefinidas.

Funciona bien para proyectos donde se encuentran bien definidoslos requerimientos y el software que se desea.

La planificacion es sencilla pues existe una secuencia biendefinida de los pasos del proceso de software.

La calidad del producto final es alta.



Modelo en cascada VIII

DesventajasLas iteraciones pueden ser costosas.

Lleva demasiado tiempo atravesar por todo el ciclo.

Algunas fases pueden quedar pendientes.

Las actualizaciones pueden ser costosas.

Si el proyecto es muy grande, su revision completa puede implicarmucho tiempo.


Modelos de proceso de software Modelo en espiral

Modelo en espiral I

Es un modelo evolutivo.

El modelo se puede visualizar como una espiral donde cadaiteracion es un conjunto de actividades.

Las nuevas actividades se eligen en funcion de la iteracionanterior.

Cada giro se puede visualizar como una nueva version delsistema.

Es un enfoque mas practico.

Existen diversas variantes de este modelo: Bohem, seis regiones,ganar-ganar.



Modelo en espiral II

Modelo de BohemPlanificacion. En la primera iteracion se realizan la recoleccionde requisitos y la planificacion del proyecto. Despues, laplanificacion puede ir cambiando en base a los comentarios delcliente.

Analisis de riesgo. En la primera iteracion se realiza el analisisde riesgo basado en los requisitos iniciales. Despues, este seadecua a la reaccion del cliente.

Ingenierıa. Una nueva version del sistema es liberada.

Evaluacion del cliente. El cliente pone a prueba el sistemaincluso puede poner la version en produccion.



Modelo en espiral III

Modelo de seis regiones

Comunicacion con el cliente. Se realiza la recoleccion derequisitos.

Planificacion. Planificacion del proyecto -recursos, tiempo, etc.-.

Analisis de riesgo. Analisis de riesgo basado en los requisitos.Tareas donde se ponen en claro los riesgos tecnicos y todo lorelacionado al proyecto.

Ingenierıa. Construir toda la arquitectura del sistema.

Construccion y adaptacion. Programar, probar, instalar y darsoporte al usuario.

Evaluacion del cliente. Obtencion de la reaccion del cliente.



Modelo en espiral IV

Modelo ganar-ganar o teorıa W [Boehm y Ross, 1989]

Conjunto de precondiciones.Comprender la forma en que las personas quieren ganar.Establecer expectativas por parte de los implicados.Adecuar las tareas.

Proceso de software.Establecer un plan realista.Planificar el proyecto.Identificar y gestionar los riesgos donde todos pierden o unospierden y otros ganan.Mantener implicadas a las personas.

Producto software.Adecuar el producto a las condiciones de exito de los usuarios.Considerar a las personas que daran mantenimiento y soporte.



Modelo en espiral V

Ventajas

Es un enfoque mas realista en el desarrollo de sistemas.

Es un modelo adaptativo.

Existe mayor comunicacion entre el desarrollador y el cliente.

Durante la evolucion del software se tienen diferentes prototipos.

Se eliminan errores y al final se queda la mejor version.

Son mejores desarrollar con base en orientacion a objetos.



Modelo en espiral VI

DesventajasEs difıcil sostener y programar las interecciones con el cliente.

Se requiere de gran habilidad para la evaluacion de riesgos.


Modelos de proceso de software Modelo incremental

Modelo incremental I

Como el modelo en espiral, este tambien es un modelo evolutivo.

La idea es disenar una implementacion inicial y exponerla a loscomentarios del usuario.

La implementacion pasa a traves de varias versiones hasta llegara un sistema final.

Cada incremento o version incorpora algunas de lasfuncionalidades que requiere el cliente.

Las pimeras versiones incluyen las funciones mas importantes.

El cliente puede desde el inicio si lo que se desarrolla es lo querealmente requiere.



Modelo incremental II

Bosquejo de descripcionSe realiza un documento informal que contiene las principalesfuncionalidades deseables en el sistema.

Este documento servira como base para la especificacion enforma.

EspecificacionContiene todos los requerimientos del cliente.

El documento va evolucionando conforme avanza el proyecto y seadecua a los nuevos requerimientos por parte del cliente.



Modelo incremental III

DesarrolloSe realiza la implementacion con base en los requerimientos decada iteracion.

Los errores encontrados en la iteracion anterior son corregidos yse agrega la nueva funcionalidad.

ValidacionEl cliente evalua la version actual del sistema y proporciona lasnuevas prioridades a los desarrolladores.

Los desarrolladores obtienen retroalimentacion constante porparte del cliente a traves de las multiples demostraciones delsoftware.



Modelo incremental IV



Modelo incremental V

Ventajas

Menor costo de desarrollo, pues la documentacion es revisada yactualizada mas frecuentemente.

Es mas facil obtener retroalimentacion del cliente.

Para el cliente son mas palpables los avances realizados a travesde las demostraciones de software.

La entrega de un software util - aunque posiblemente noterminado- hacia el cliente se realiza en menor tiempo.



Modelo incremental VI

DesventajasLas entregas deben ser frecuentes con el objetivo de poder medirel avance.

Si no se cuenta con el suficiente personal trabajando sobre elproyecto puede resultar contraproducente.

Si el software no tiene bases flexibles los cambios puedendegradar el sistema.

La incorporacion de demasiados cambios puede resultar masdifıcil y costoso.


Modelos de proceso de software Modelo orientado a la reutilizacion

Modelo orientado a la reutilizacion I

Algunos productos de software son desarrollados reutilizandodisenos y/o componentes.

Es una estrategia propuesta por Douglas McIlroy (LaboratoriosBell - AT&T Bell Laboratories and Bell Telephone Laboratories-)en 1968.

Este modelo puede ir de la mano con otros modelos de software.

Los componentes basados en reutilizacion pueden sermodificados para expander su funcionalidad.

Componentes tıpicos a reutilizarse:Servicios Web. Disponibles de forma remota.



Modelo orientado a la reutilizacion II

Colecciones de objetos. Que se agregan como parte de un marcode componentes (NET, J2EE, Compuware).

Sistemas de software indipendientes. De uso especıfico.

Consiste de seis etapas:Especificacion de requerimientos.

Analisis de componentes.

Modificacion de requerimientos.

Diseno del sistema con reutilizacion.

Desarrollo e integracion.

Validacion del sistema.



Modelo orientado a la reutilizacion III

Hewlett-Packard ha tenido exito utilizando esta filosofıa.

Libro: Software reuse: Architecture process and organization forbusiness success. Ivar Jacobson, Martin Griss, Patrik Jonsson,ACM Press, 1997.

Martin Gris de Hewlett-Packard, Ivar Jacobso de Ericsson, PatrikJonsson de Rational Software Corporation (Suecia).



Modelo orientado a la reutilizacion IV

Analisis de componentes

Se realiza una busqueda de los componentes mas adecuadospara cumplir con los requerimientos.

Pocas veces la coincidencia es exacta.

Modificacion de requerimientosSe replican los componentes y se modifican para adecuarse a losrequerimientos.

La modificacion puede consistir en ligeros cambios o extension dela funcionalidad.



Modelo orientado a la reutilizacion V

Diseno del sistema con reutilizacionSe disena el marco conceptual o se modifica uno existente.

Se debe denotar la diferencia entre los componentes reciclados ylos nuevos.

Desarrollo e integracion

Se hacen la implementaciones necesarias.

Se realiza la integracion de los componentes para la creacion delproducto final.



Modelo orientado a la reutilizacion VI



Modelo orientado a la reutilizacion VII

VentajasConfiabilidad creciente. El software reutilizable ha sido probadomas veces.

Reduccion de riesgo de proceso. Se conoce ya el costo delsoftware existente.

Intervencion de especialistas. No se “reinventa la rueda” y loscomponentes encapsulan el conocimiento de varios expertos.

Cumplimiento de estandares. Las aplicaciones presentan losmismos formatos de menus para los usuarios.

Desarrollo acelerado. El software llega mas rapido al mercado.



Modelo orientado a la reutilizacion VIII

DesventajasCostos crecientes de mantenimiento. Si no se tiene acceso alcodigo fuente no se podran resolver incompatibilidades con elsistema.

Falta de herramientas. Puede ser que los componentes no seanflexibles.

No aceptacion del software existente. No se tiene confianza sobreel software ya existente y siempre se desea rescribir con laintencion de mejorar.

Difıcil comprension y adaptacion de los componentes a reutilizar.Los desarrolladores deben conocer todos los componentes y susrequerimientos.


Actividades del proceso de software

Actividades del proceso de software I

Un proceso de software debe considerar la relacion entre lasactividades tecnicas, colaborativas y administrativas con elobjetivo de especificar, disenar, implementar y probar un productode software.

Los desarrolladores de software se apoyan de multiplesherramientas para la creacion de software.

Editores de diseno.

Diccionarios de datos.

Compiladores.

Depuradores. (Debugger)

Software para la construccion del sistema.



Actividades del proceso de software II

La combinacion de estas herramientas se conoce como Ambientede Desarrollo Interactivo -Integrated Development EnvironmentIDE-.

Eclipse. Ver. 4.2. C, C++, Java, http://www.eclipse.org/.

ActiveState Komodo. Ver. 7.http://www.activestate.com/komodo-ide.

IntelliJ IDEA. Ver. 12. http://www.jetbrains.com/idea/.

Oracle JDeveloper. Ver. 11g. http://www.oracle.com/.

NetBeans. Ver 7.2. http://netbeans.org.

Microsoft Visual Studio. Ver. 2012.http://www.microsoft.com/visualstudio/esn.

MyEclipse. Ver. 10. http://www.myeclipseide.com/



Actividades del proceso de software IIIWinDev y WebDev. Ver. 17. http://www.windev.com/

Uniface. Ver. 11.http://www.compuware.com/rapid-application-development/

Actividades que automatizan los IDE’s:Modelos de sistemas graficos.

Generacion de codigo a partir de los modelos de sistemas graficos.

Produccion de interfaces de usuario a partir de descripciones delusuario.

Depuracion del programa.

Traduccion automatizada de programas escritos.

Estudiaremos las 4 principales actividades del proceso.


Actividades del proceso de software Especificacion del software

Especificacion del software I

La especificacion del software -requerimientosconsiste encomprender y definir los servicios que requiere el sistema.

Ademas se deben identificar las restricciones sobre la operacion yel desarrollo del sistema.

Los errores en esta etapa conducen a problemas en el futuro.

El objetivo es elaborar el documento de requerimientos quecumplira el sistema.

Tal documento puede presentar dos niveles de abstraccion:detallado del sistema y de usuario.



Especificacion del software II

Estudio de factibilidad¿Las necesidades del usuario se cubren con las tecnologıasactuales?.

Costo-beneficio → sujeto a restricciones presupuestales y detiempo.

Se decidira si se continua o no con un analisis mas detallado.

Obtencion y analisis de requerimientosConsiste en derivar los requerimientos en base a sistemasexistentes, necesidades de los usuarios, analisis de las tareas,entre otros.

Desarrollar prototipos puede ayudar a entender lo requerido.



Especificacion del software III

Especificacion de requerimientos

Consiste en plasmar en un documento la informacion recopilada.

Se contemplan los requerimientos del usuario y los del sistema.

Validacion de requerimientosSe verifica que los requerimientos sean realistas, coherentes ycompletos.

Se corrigen los posibles errores encontrados en el documento.



Especificacion del software IV


Actividades del proceso de software Desarrollo e implementacion

Desarrollo e implementacion I

Esta estapa consiste en convertir las especificaciones en unsistema real.

Un diseno de software implica describir la estructura del softwarea implementar, los componentes, las estructuras de datos autilizar, las interfaces y los algoritmos.

A los que realizan esta labor se le conoce como Arquitectos deSoftware -Software Architect-.

Se parte de un diseno inicial que puede ser modificado oincrementado.



Desarrollo e implementacion II

Se debe considerar que el software puede interactuar con otrossistemas.

Sistema operativo Bases de datosMiddleware Aplicaciones

Si el sistema procesa ciertos datos entonces en el diseno delsistema se deben describir tales datos.

Las herramientas de software permiten generar esqueletos apartir de disenos.

Cada programador sigue su propia filosofıa de desarrollo.Facıl → DfifıcilDifıcil → Facil



Desarrollo e implementacion III

Cada programador debe desarrollar pruebas del codigo quedesarrollo y en su caso depurarlo.

Es importante considerar multiples casos de prueba.

Diseno arquitectonicoSe identifica la estructura global del sistema, los principalescomponentes y sus relaciones.

Diseno de la base de datosSe crea el modelo -ER- de la base de datos y como sera surepresentacion fısica.



Desarrollo e implementacion IV

Diseno de interfazSe definen la interfaces entre los componentes.

Los componentes deben ser como cajas negras para otroscomponentes.

Si ya se cuenta con las especificaciones de la interfaz, loscomponentes se pueden desarrollar de forma concurrente.

Diseno de componentesSe disena el funcionamiento de cada componente.

Cada programador se encarga del como teniendo siempre encuenta el que.



Desarrollo e implementacion V


Actividades del proceso de software Validacion de software

Validacion de software I

La validacion del software consiste en probar que un sistemacumple tanto con sus especificaciones como con las espectativasdel cliente.

La principal tecnica de validacion consiste en utilizar datosficticios para probar el sistema.

Generalmente las pruebas van de lo particular a lo general.

Defectos a un nivel global puede implicar el volver a verificarcomponentes ya revisados.

Este es un proceso totalmente iterativo.



Validacion de software II

Prueba de desarrolloEs un proceso realizado por los programadores.

Cada componente se prueba de forma independiente.

Existen herramientas que automatizan este proceso o bienpueden ser creadas las propias.

JUnit in Action, Petar Tahchiev, Felipe Leme, Vincent Massol andGary Gregory, 2nd Ed. 2010.



Validacion de software III

Pruebas del sistemaEl objetivo es descubrir errores de las interacciones entre loscomponentes.

Tambien se busca verificar que el sistema cumple con losrequerimientos funcionales.

Puede consistir de varias etapas.

Pruebas de aceptacionEl sistema se pone a prueba con datos reales.

Los datos reales suelen revelar problemas no detectados con losdatos ficticios.

Permiten observar el rendimiento global del sistema.



Validacion de software IV


Actividades del proceso de software Evolucion del software

Evolucion del software I

El software, a diferencia del hardware, puede ser modificado masfacilmente.

Es necesario que el software se adapte a las condicionesactuales:

Avances tecnologicos.

Cambios en el proceso de negocio.

Cambios en los sistemas operativos o incluso el hardware.

Nuevas necesidades del cliente.

Raras veces el software creado es invariante a lo largo de su ciclode vida.


Actividades del proceso de software Evolucion del software

Evolucion del software II


El Proceso Unificado

El Proceso Unificado

El Proceso Unificado Racional -Rational Unified Process RUP-fue creado por Philippe Kruchten en 2003.

Su antecesor es fue el Rational Objectory Process de 1998.

Este es un modelo hıbrido que considera la buena practica enespecificacion y diseno y esta de acuerdo con la entrega deprototipos y entrega incremental.

Este modelo puede ser utilizado segun tres enfoques:Dinamico. Resalta las fases del modelo en el tiempo. Cliente.

Estatico. Presenta las actividades que se establecen para elproceso. Desarrolladores.

Practico. Sugiere buenas practicas a utilizar durante el proceso.Desarrolladores.


El Proceso Unificado Fases del Proceso Unificado

Fases del Proceso Unificado I

InicioConsiste en modelar el problema del cliente/empresa.

Se deben identificar todas las entidades externas (personas ysistemas) que interactuaran con el sistema.

Se deben identificar los requisitos necesarios para resolver elproblema.

Se valora la aportacion del sistema al cliente/empresa.

Se establece el alcance del proyecto.

Pueden generarse algunas estimaciones imprecisas.



Fases del Proceso Unificado II

ElaboracionSe desarrolla la comprension del problema.

Se resuelven los altos riesgos.

Puede que se encuentren mas requisitos y se redefina el alcance.

Las estimaciones se vuelven mas realistas.

Se establece un marco conceptual arquitectonico del sistema.

Se establecen los casos de uso UML, el diseno arquitectonico y laplanificacion del proyecto.



Fases del Proceso Unificado III

ConstruccionConsiste en el diseno, programacion y pruebas del sistema.

Al finalizar esta etapa debe entregarse un software funcionando yla documentacion asociada.

TransicionConsiste en liberar la version a los usuarios para que la usen enel entorno real.

Es una fase costosa y problematica.

La documentacion del sistema debe ir completamente acorde aeste.


El Proceso Unificado Actividades de ingenierıa del Proceso Unificado

Actividades de ingenierıa del Proceso Unificado I

Modelado del negocio

Se modelan los procesos del negocio utilizando los casos de uso de laempresa.

RequerimientosSe identifican los actores del sistema y se desarrollan los propioscasos de uso.

Analisis y diseno

Se crea y documenta el diseno del sistema mediante modelosarquitectonicos, de componentes, de objetos y de secuencias.



Actividades de ingenierıa del Proceso Unificado II

Administracion del proyecto

Debe existir una planificacion que cumpla con las restricciones decosto y tiempo. Ademas se deben cubrir las necesidades yexpectativas del cliente.

EntornoSe porporcionan al equipo de desarrollo las herramientas adecuadasal producto que se desea crear.

ImplementacionSe implementan y estructuran los componentes del sistema. Lageneracion automatica de codigo puede acelerar esta actividad.



Actividades de ingenierıa del Proceso Unificado III

PruebasSon un proceso iterativo que va de la mano con la implementacion.

Administracion de la configuracion

Consiste de varias actividades:Se realiza el ensamblaje de los componentes, librerıas, datos y lacompilacion para crear el ejecutable del sistema.Se realiza la administracion de los cambios ası como de lasversiones.

Despliegue

Se libera el producto hacia los usuarios.



Actividades de ingenierıa del Proceso Unificado IV

Tomado de http://es.wikipedia.org/wiki/Proceso Unificado


El Proceso Unificado Buenas practicas del Proceso Unificado

Buenas practicas del Proceso Unificado I

Desarrollo de software de manera interactivaRealizar el desarrollo en base a las prioridades del cliente.

Gestion de requerimientosDocumentar explıcitamente los requerimientos y realizar los cambiosnecesarios sobre estos. Evaluar el impacto de cambios en el sistemaantes de aceptarlos.

Usar arquitecturas basadas en componentesEstructurar la arquitectura del sistema en base a componentes.


El Proceso Unificado Buenas practicas del Proceso Unificado

Buenas practicas del Proceso Unificado II

Software modelado visualmenteUtilizar modelos UML para refresentar procesos en la fases yactividades de ingenierıa del Proceso Unificado.

Verificar la calidad del softwareAsegurar que el software cumple con los estandares de calidadestablecidos en la empresa.

Controlar los cambios al softwareGestionar los cambios mediante un controlador de versiones. Ademasse deben documentar los procedimientos y todo lo necesario para laconfiguracion del sistema.


Documents

Fundamentos de Ingenieria de Software.pdf