4) Procesos del software

No existe posibilidad alguna de automatizar mas que con herramientas CASE el diseo del software. Un sistema critico requiere un proceso muy estructurado. Sistema de negocio requiere un proceso flexible y agil Especificacion: Funcionalidad del software y restricciones de operacion Diseo e implementacin: P+roducir software Validacion: Hace lo que el cliente desea? Evolucion: Cubrir necesidades cambiantes del cliente Los procesos se pueden mejorar por la estandarizacin, que reduce el tiempo de formacin, y mas economico

4.1 Modelos del software:

Un modelo es una representacin abstracta del software y proporciona informacin parcial del proceso. Son marcos de trabajo del proceso, que pueden ser extendidos y adaptados. Los modelos de procesos son: 1)Modelo en cascada 2)Desarrollo Evolutivo 3)Ingenieria del software basada en componentes 4*) Modelo formal: Se crea un modelo matemtico. No se utiliza en general A menudo se utilizan juntos los distintos modelos. Los subsistemas pueden ser desarrollados utilizando enfoques distintos. 1)Modelo en cascada: Deriva de procesos de ingeniera generales. Analisis y def requerimientos: Consultas con usuarios Diseo sistema y software: Arquitectura del sistema Implementacion y prueba unidades: Integracion y prueba sistema: Se integran unidades individuales y prueban Funcionamiento y mantenimiento Errores no descubiertos No se debe pasar de una etapa a la otra sin anter terminarla. Luego se debe iterar.Es normal que se congelen etapas(como especificacin), esto puede hacer que el sistema no haga lo que el usuario quiere o sistemas mal estructurados. Ventajas: Documentacion muy completa Desventaja: No se puede dividir el proyecto Solo debe usarse cuando se comprenden los requerimientos y estos no cambian. 2)Desarrollo Evolutivo: Implementacion inicial y exponerla al usuario e ir mejorndola. Especificacion, desarrollo y validacin se entrelazan en vez de separarse. Dos tipos: a) Desarrollo exploratorio: Explorar los requerimientos y entregar sistema final, se empieza con los requerimientos que se entienden y se va mejorando.

b) Prototipos Desechables: Experimentar con los requerimientos que no se comprenden del todo para comprenderlos y mejorarlos. Desventajas: No es rentable producir documentos que reflejen cada versin, Se producen sistemas con una estructura deficiente Funciona bien en sistemas medianos y pequeos. Para sistemas grandes modelo en cascada y evolutivo mezclado. Reutilizacion indispensable pero informal. 3)Ingenieria del software basada en componentes: Se basa en la reutilizacin, algunas veces los componentes son sistemas por si mismos que se pueden usar para proporcionar una funcionalidad especifica. Etapas intermedias son distintas: Analisis de componentes: Se buscan los componentes para implementar, estos proporcionan solo parte de la funcionalidad Modificacion de requerimientos: Si las modificaciones no son posibles el anlisis de lleva a cabo nuevamente Diseo del sistema con reutilizacin: Se disea un marco de trabajo para el sistema Desarrollo e Integracion: Se integran los sistemas Ventajas: Reduce la cantidad de software a desarrollar y reduce costos y riesgos. Desventajas: Puede no cumplir totalmente los requerimientos, y si el software usado no es de control de la empresa, puede perderse el control sobre la evolucin del sistema.

4.2 Iteracion de procesos

Los requerimientos cambian cuando el negocio responde a presiones externas. Las actividades del proceso de software se repiten regularmente Entrega Incremental: especificacin, diseo e implementacin se desarrollan por turnos. Combina ventajas de desarrollo cascada (sistemas bien documentados) con las de desarrollo evolutivo (permite que los requerimientos se retrasen) Los clientes identifican a grandes rasgos los servicios del sistema y ordena por prioridad. Los requerimientos del servicio que se va a entregar en el primer incremento se definen en detalle y se desarrolla. Ventajas: No hay que esperar que este completo para utilizarlo, Se pueden usar incrementos iniciales como prototipos, Bajo riesgo de fallo total, Es menos probable que los modulos mas importantes tengan errores graves Desventajas: Incrementos pequeos, difcil adaptar requerimientos del clientea incrementos apropiados. Desarrollo Espiral: Esbozo inicial y termina con el desarrollo final del mismo. Definicion objetivos: identifican los riegos del proyecto y definen objetivos Evaluacion y reduccin riegos: Analisis de los riegos Desarrollo y validacin: Se elige un modelo para el desarrollo Planificacion: Se revisa y se ve si se debe continuar con un ciclo mas de la espiral. El modelo en espiral considera explcitamente el riesgo(algo que puede ir mal)

4.3 Actividades del proceso

Especificacion del software: Comprension de servicios que se requieren del sistema. Etapa critica en el desarrollo. Hay dos niveles de detalle: Nivel cliente(bsico) y desarrollador(avanzado) Estudio vialidad: ver si la necesidad se puede satisfacer con software Analisis y obtencin: obtener requerimientos de sistemas existentes. prototipos Especificacion: Se crea un documento que recopila los requerimientos Validacion: comprobar la veracidad etc. Diseo e implementacin del software: Convertir una especificacin en un sistema ejecutable. El diseo convella agregar formalidad y detalles. Las actividades del diseo se entrelazan. El resultado final del proceso son especificaciones precisas de los algoritmos y estructuras de datos a implementar. Con Mtodos agiles no hay documentos de especificacin separados, sino que es representada en el cdigo del programa Con mtodos estructurados se basan en modelos graficos del sistema. Algunos sistemas crticos se disean en detalle antes de cualquier implementacin. Para esto se pueden usar herramientas CASE. Validacin del software: Utiliza para mostrar que el sistema se ajusta a su especificacin y que cumple las expectativas del usuario que lo comprar. La mayora de los costos de validacin aparecen despus de la implementacin, cuando se prueba el sistema. El proceso es iterativo y se retroalimenta Etapas: Prueba de componentes Prueba del sistema Prueba de aceptacin(alfa): se prueba con datos proporcionados por el cliente. Continua hasta que el cliente y desarrollador concuerdan que es estable Si se utiliza enfoque incremental, cada incremento debe ser probado cuando se desarrolla. Prueba beta se utiliza en software comerciales Evolucion del software: El hardware es costoso por lo que es mas fcil hacer cambios en el software. Los costos de mantenimiento son a por lo general varias veces los costos iniciales, pero el mantenimiento es menos problemtico. El Proceso Unificado de Rational: Ejemplo de un modelo de proceso hibrido. Reune elementos de todos los modelos de procesos genricos, iteraciones de apoyo. Tiene 3 perspectivas: Dinamica: fases del modelo sobre el tiempo Estatica: actividades del proceso que se representan Practica: buenas prcticas a utilizar durante el proceso Fases del RUP estn mas relacionadas con modelos de negocios que tcnicos

Fases: Inicio: establecer un curso de negocio para el sistema. Evalua la aportacin que hace el sistema al negocio Elaboracion: desarrollar una compresin del dominio del problema. Casos de uso UML Construccion: diseo del sistema, programacin y pruebas. Al terminar debe haber un sistema software operativo Transicin: mover el sistema desde la comunidad de desarrollo a la comunidad del usuario y hacerlo trabajar en un entorno real. Cada fase se puede representar de un modo iterativo con resultados incrementales. El conjunto entero puede verse de forma incremental buenas practicas: Desarrollar software de forma iterativa Gestionar los requerimientos arquitectura basada en componentes Verificar calidad software Controlar cambios software El RUP no es apropiado para todo tipo desarrollo. Innovaciones mas importantes son separacin en fases y flujos de trabajo. Fases dinamicas y flujos estaticos 4.5 Ingenieria asistida por computador CASE Incluye editores texto, diseo, direcc datos compiladores etc. Ejemplos Modelos graficos, comprensin del diseo con un diccionario de datos, generacin interfaces, depuracin etc CASE automatiza tareas rutinarias, ya que no ha tenido xito la inteligencia artificial Clasificacion Funcional: que hacen Proceso: a que ayudan Integracion: En la practica los limites son borrosos

Capitulo 17: Desarrollo Rpido de software

Ventajas enfoque incremental: Entrega acelerada de servicios del cliente: aprovecha el sistema desde el principio Compromiso del cliente con el sistema: Con su participacin, es mas probable que cumpla los requerimientos y consiga que llegue a funcionar El mejor enfoque para sistemas de negocio, comercio electrnico Principales problemas enfoque iterativo y des. incremental:

P. administracin: no se puede producir documentacin del sistema. Dificil usar el personal existente P . contractuales: normalmente se basa en la especificacin del sistema, pero aqu debe ser de acuerdo al tiempo invertido. El desarrollador no puede controlar los cambios requeridos P. Validacion: Se intenta minimizar la documentacin, por lo que la validacin independiente es difcil P. mantenimiento: cambios continuos corrompen el sistema por lo k es difcil entender el software

Los sistemas grandes sufren los mismos problemas de req inciertos y cambiantes. Para abordarlos se puede usar un proceso hibrido en donde se experimetan con los requerimientos y diseo. Se utiliza un prototipado , que es un proceso iterativo para desarrollar un sistema experimental que no esta destinada a la utilizacin de los clientes. Tiene obj distintos: Validar u obtener requerimientos. Debe comenzar con aquellos que no se comprenden bien

Metodos Agiles:
Pensados para entregar software funcional de forma rpido a los clientes Metodos: Programacion extrema Scrum Cristal Des software adaptable DsDM des dirigido por caractersticas Problemas de Principios de los mtodos agiles: participacin del cliente: Dificil que el cliente participe con el equipo de desarrollo Los miembros pueden no tener la personalidad para trabajar en equipo Priorizar los cambios puede ser difcil Mantener la simplicidad requiere trabajo extra Redactar un contrato puede ser difcil Son apropiados para sistemas de negocios pequeos y medianos

Programacin Extrema: Usa tcnicas iterativas y participacin del cliente en niveles extremos. Requerimientos se especifican como escenarios y se implementan directamente como una serie de tareas. Los programadores trabajan de a 2 Practicas: Entregas pequeas

Compromiso a tiempo completo del cliente en el equipo de desarrollo No se contempla cambios futuros en el sistema Los requerimientos no se especifican como una lista de funciones requeridas del sistema. Si se requieren cambios en un sistema ya entregado, se desarrllan nuevas tarjetas de historias y el cliente decide la prioridad. Se pueden construir varias veces al dia versiones de software y se entrega cada 2 meses aprox. Se evita pensar en mantenimiento para hacer el software fcil de entender y cambiar. Pruebas: No existe una especificacin del sistma para desarrollar pruebas. Pone nfasis en el proceso de pruebas: Desarrollo previamente probado(1 se crean pruebas, luego el software) pruebas incrementales participacin del usuario en las pruebas uso de bancos de prueba automatizados Al escribir primero las pruebas se define implcitamente una interfaz y una especificacin de funcionamiento Programacion en parejas: Se sientan juntos en la misma estacin, tiene ventajas: Idea de propiedad y responsabilidad comunes Proceso de revisin informal La productividad en pareja parece ser igual que individualmente Desarrollo Rapido de aplicaciones (RAD): Herramientas: lenguaje de prog de base de datos Generador de interfaces Enlaces a aplicaciones de oficina Generador de informes Hacen llamadas a componentes reutilizables, a cdigo de propsito especial o ambos. Permite el desarrollo de aplicaciones relativamente sencillas por un equipo pequeo. Prototipado del software: