INSTITUTO TECNOLGICO DE TOLUCA INGENIERA EN SISTEMAS COMPUTACIONALES

Materia: Fundamentos de desarrollo de sistemas

Trabajo de: Reporte de investigacin de Modelos del proceso de software

Alumno (a): Esmeralda Vargas Peralta

Profesora: Rosa Elvira Moreno Ramirez

QU ES UN MDELO? Con origen en el trmino italiano modello, el concepto de modelo tiene diversos usos y significados. Por ejemplo, un modelo es un arquetipo o punto de referencia para imitarlo o reproducirlo. En las acciones morales y en las obras de ingenio, un modelo es un ejemplar que se debe seguir e imitar por su perfeccin. QU ES UN PROCESO? Un proceso es un conjunto de actividades o eventos (coordinados u organizados) que se realizan o suceden (alternativa o simultneamente) bajo ciertas circunstancias con un fin determinado. Este trmino tiene significados diferentes segn la rama de la ciencia o la tcnica en que se utilice. En la informtica, un proceso es un concepto manejado por los sistemas operativos, que est compuesto por las instrucciones de un programa destinadas a ser ejecutadas por el microprocesador, su estado de ejecucin en un momento dado, su memoria de trabajo y otras informaciones. MODELOS DE PROCESOS DEL SOFTWARE Los estndares establecen los diferentes procesos implicados a la hora de desarrollar y mantener un sistema desde que surge la idea o necesidad de desarrollar las aplicaciones hasta que stas se retiran de explotacin. Sin embargo, ninguno impone un modelo de procesos concreto (modelo de ciclo de vida) ni cmo realizar las diferentes actividades incluidas en cada proceso, por lo que cada empresa deber utilizar los mtodos, tcnicas y herramientas que considere oportuno. Por su naturaleza, los modelos son simplificaciones; por lo tanto, un modelo de procesos del software es una simplificacin o abstraccin de un proceso real. Podemos definir un modelo de procesos del software como una representacin abstracta de alto nivel de un proceso software. Cada modelo es una descripcin de un proceso software que se presenta desde una perspectiva particular. Alternativamente, a veces se usan los trminos ciclo de vida y Modelo de ciclo de vida. Cada modelo describe una sucesin de fases y un encadenamiento entre ellas. Segn las fases y el modo en que se produzca este encadenamiento, tenemos diferentes modelos de proceso. Un modelo es ms adecuado que otro para desarrollar un proyecto dependiendo de un conjunto de caractersticas de ste. Todo el desarrollo del software se puede caracterizar como bucle de resolucin de problemas en el que se encuentran cuatro etapas distintas: statusquo, definicin de problemas, desarrollo tcnico e integracin de soluciones. Status quo representa el estado actual de sucesos; la definicin de problemas identifica el problema especfico a resolverse; el desarrollo tcnico resuelve el problema a

travs de la aplicacin de alguna tecnologa y la integracin de soluciones ofrece los resultados (por ejemplo: documentos, programas, datos, nueva funcin comercial, nuevo producto) a los que solicitan la solucin en primer lugar. Existe una gran variedad de modelos diferentes entre los que tenemos los que se describen a continuacin: MODELO EN CASCADA O LINEAL SECUENCIAL Llamado algunas veces ciclo de vida bsico o cmodelo en cascada, el modelo lineal secuencial sugiere un enfoque5 sistemtico, secuencial, para el desarrollo del software que comienza en un nivel de sistemas y progresa con el anlisis, diseo, codificacin, pruebas y mantenimiento. CARACTERSTICAS DEL MODELO: Primer modelo empleado (Royce, 1970), tambin denominado ciclo de vida clsico y modelo lineal secuencial. Consiste en la ejecucin secuencial de una serie de fases que se suceden, lo que da nombre al modelo. Cada fase genera documentacin para la siguiente. Esta documentacin debe ser aprobada. Una fase no comienza hasta que la anterior ha terminado. Requiere disponer de unos requisitos completos y precisos al principio del desarrollo. PRESENTA UNA SERIE DE VENTAJAS: -Se debe tener en cuenta que fue el primer modelo empleado, y por lo tanto es mejor que ninguno. -Facilita la gestin del desarrollo. AS COMO UNA SERIE DE INCONVENIENTES: En general, establecer todos los requisitos al principio del proceso de desarrollo es un mito inalcanzable: -Los usuarios no pueden imaginarse lo que quieren hasta que no ven un sistema funcionando. -Los requisitos no se pueden congelar mientras dura el desarrollo. El mercado cambia, todo cambia. -El usuario debe esperar mucho tiempo hasta ver los resultados: Se tarda mucho tiempo en pasar por todo el ciclo (hasta que no termina una fase no empieza la siguiente) y el sistema en funcionamiento no estar disponible hasta el final del proceso, eso s, ser el sistema completo. -Los errores de anlisis y diseo son costosos de eliminar, y se propagan a las fases siguientes con un efecto conocido como bola de nieve. -Se genera mucho mantenimiento inicial debido al perodo de congelacin de requisitos y ste recae, en su mayor parte, sobre el cdigo fuente, que en consecuencia se va deteriorando y resultando cada vez ms difcil de mantener. El modelo lineal secuencial comprende las siguientes actividades:

Ingeniera y modelado de Sistemas/Informacin. Como el software siempre forma parte de un sistema ms grande (o empresa), el trabajo comienza estableciendo requisitos de todos los elementos del sistema y asignando al software algn subgrupo de estos requisitos. Esta visin del sistema es esencial cuando el software se debe interconectar con otros elementos como hardware, personas y bases de datos. La ingeniera y el anlisis de sistemas comprende los requisitos que se recogen en el nivel del sistema con una pequea parte de anlisis y de diseo. La ingeniera de informacin abarca los requisitos que se recogen en el nivel de empresa estratgico y en el nivel del rea de negocio. Anlisis de los requisitos del software. El proceso de reunin de requisitos se intensifica y se centra especialmente en el software. Para comprender la naturaleza del (los) programa(s) a construirse, el ingeniero (arialista) del software debe comprender el dominio de informacin del software, as como la funcin requerida, comportamiento, rendimiento e interconexin. Diseo. El diseo del software es realmente un proceso de muchos pasos que se centra en cuatro atributos distintos de programa: estructura de datos, arquitectura de software, representaciones de interfaz y detalle procedimental (algoritmo). El proceso del diseo traduce requisitos en una representacin del software donde se pueda evaluar su calidad antes de que comience la codificacin. Generacin de cdigo. El diseo se debe traducir en una forma legible por la mquina. El paso de generacin de cdigo lleva a cabo esta tarea. Si se lleva a cabo el diseo de una forma detallada, la generacin de cdigo se realiza mecnicamente. Pruebas. Una vez que se ha generado el cdigo, comienzan las pruebas del programa. El proceso de pruebas se centra en los procesos lgicos internos del software, asegurando que todas las sentencias se han comprobado, y en los procesos externos funcionales; es decir, realizar las pruebas para la deteccin de errores y asegurar que la entrada definida produce resultados reales de acuerdo con los resultados requeridos. Mantenimiento. El software indudablemente sufrir cambios despus de ser entregado al cliente (una excepcin posible es el software empotrado). Se producirn cambios porque se han encontrado errores, porque el software debe adaptarse para acoplarse a

los cambios de su entorno externo (por ejemplo: se requiere un cambio debido a un sistema operativo o dispositivo perifrico nuevo), o porque el cliente requiere mejoras funcionales o de rendimiento. El soporte y mantenimiento del software vuelve a aplicar cada una de las fases precedentes a un programa ya existente y no a uno nuevo. El modelo lineal secuencial es el paradigma ms antiguo y ms extensamente utilizado en la ingeniera del software. Sin embargo, la crtica del paradigma ha puesto en duda su eficacia. Entre los problemas que se encuentran algunas veces en el modelo lineal secuencial se incluyen: 1.- Los proyectos reales raras veces siguen el modelo secuencial que propone el modelo. Aunque el modelo lineal puede acoplar interaccin, lo hace indirectamente. Como resultado, los cambios pueden causar confusin cuando el equipo del proyecto comienza. 2.- A menudo es difcil que el cliente exponga explcitamente 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. 3.- El cliente debe tener paciencia. Una versin de trabajo del (los) programa(s) no estar disponible hasta que el proyecto est muy avanzado. Un grave error puede ser desastroso si no se detecta hasta que se revisa el programa.

Figura 1: Ejemplo de modelo en cascada o secuencia lineal MODELO DE CONSTRUCCIN DE PROTOTIPOS El paradigma de construccin de prototipos comienza con la recoleccin 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 ms definicin. Entonces aparece un diseo rpido. El diseo rpido se centra en una representacin de esos aspectos del software que sern visibles para el usuario/cliente (por ejemplo: enfoques de entrada y formatos de salida). El diseo rpido lleva a la construccin de un prototipo. El prototipo lo

evala el cliente/usuario y se utiliza para refinar los requisitos del software a desarrollar. La iteracin 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. Sin embargo, la construccin de prototipos tambin puede ser problemtica por las siguientes razones: 1. El cliente ve lo que parece ser una versin de trabajo del software, sin tener conocimiento de que el prototipo tambin est junto con el chicle y el cable de embalar, 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. 2. El desarrollador, a menudo, hace compromisos de implementacin para hacer que el prototipo funcione rpidamente. Se puede utilizar un sistema operativo o lenguaje de programacin inadecuado simplemente porque est disponible y porque es conocido; un algoritmo eficiente se puede implementar simplemente para demostrar la capacidad. Despus de algn tiempo, el desarrollador debe familiarizarse con estas selecciones, y olvidarse de las razones por las que son inadecuadas.

Figura 2: Modelo de construccin de prototipos

MODELO DRA

El Desarrollo Rpido de Aplicaciones (DRA)es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto. El modelo DRA es una adaptacin a alta velocidad del modelo lineal secuencial en el que se logra el desarrollo rpido utilizando una construccin basada en componentes. 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 perodos cortos. Cuando se utiliza principalmente para aplicaciones de sistemas de informacin, el enfoque DRA comprende las siguientes fases: Modelado de Gestin. El flujo de informacin entre las funciones de gestin se modela de forma que responda a las siguientes preguntas: Qu informacin conduce el proceso de gestin? Qu informacin se genera? Quin la genera? A dnde va la informacin? Quin la procesa? Modelado de datos. El flujo de informacin definido como parte de la fase de modelado de gestin se refina como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las caractersticas (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 informacin necesario para implementar una funcin de gestin. Las descripciones del proceso se crean para aadir, modificar, suprimir, o recuperar un objeto de datos. Generacin de aplicaciones. El DRA asume la utilizacin de tcnicas de cuarta generacin. En lugar de crear software con lenguajes de programacin de tercera generacin, el proceso DRA trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o a crear componentes reutilizables (cuando sea necesario). En todos los casos se utilizan herramientas para facilitar la construccin del software.

Pruebas y entrega. Como el proceso DRA enfatiza la reutilizacin, 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.

Figura 3: Ejemplo de modelo DRA

MODELOS EVOLUTIVOS DEL PROCESO DEL SOFTWARE Se reconoce que el software, al igual que todos los sistemas complejos, evoluciona con el tiempo. Los requisitos de gestin y de productos a menudo cambian conforme a que el desarrollo proceda haciendo que el camino que lleva al producto final no sea real; las estrictas fechas tope del mercado hacen que sea imposible finalizar un producto completo, por lo que se debe introducir una versin limitada para cumplir la presin competitiva y de gestin; se comprende perfectamente el conjunto de requisitos de productos centrales o del sistema, pero todava se tienen que definir los detalles de extensiones del producto o sistema. En estas y en otras situaciones similares, los ingenieros del software necesitan un modelo de proceso que se ha diseado explcitamente para acomodarse a un producto que evolucione con el tiempo. Los modelos evolutivos son iterativos. Se caracterizan por la forma en que permiten a los ingenieros del software desarrollar versiones cada vez ms completas del software. EL MODELO INCREMENTAL

El modelo incrernental combina elementos del modelo lineal secuencial (aplicados repetidamente) con la filosofa interactiva de construccin de prototipos, el modelo incremental aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento del software. Por ejemplo, el software de tratamiento de textos desarrollado con el paradigma incremental podra extraer funciones de gestin de archivos bsicos y de produccin de documentos en el primer incremento; funciones de edicin ms sofisticadas y de produccin de documentos en el segundo incremento; correccin ortogrfica y gramatical en el tercero; y una funcin avanzada de esquema de pgina en el cuarto. Se debera tener en cuenta que el flujo del proceso de cualquier incremento puede incorporar el paradigma de construccin de prototipos.

Figura4: Ejemplo de modelo incremental MODELO EN ESPIRAL El modelo en espiral, propuesto originalmente por Boehm, es un modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de construccin de prototipos con los aspectos controlados y sistemticos del modelo lineal secuencial. Proporciona el potencial para el desarrollo rpido de versiones incrementales del software. En el modelo espiral, el software se desarrolla en una serie de versiones incrementales. Durante las primeras iteraciones, la versin incremental podra ser un modelo en papel o un prototipo. Durante las ltimas iteraciones, se producen versiones cada vez ms completas del sistema diseado.

DESARROLLO BASADO EN COMPONENTES

El modelo de desarrollo basado en componentes conduce a la reutilizacin del software, y la reutilizacin proporciona beneficios a los ingenieros de software.

Figura 5: Ejemplo de modelo en espiral

MODELO DE METODOS FORMALES El modelo de mtodos formales comprende un conjunto de actividades que conducen a la especificacin matemtica del software de computadora. Los mtodos formales permiten que un ingeniero de software especifique, desarrolle y verifique un sistema basado en computadora aplicando una notacin rigurosa y matemtica. Aunque todava no hay un enfoque establecido, los modelos de mtodos formales ofrecen la promesa de un software libre de defectos. Sin embargo, se ha hablado de una gran preocupacin sobre su aplicabilidad en un entorno de gestin: 1. El desarrollo de modelos formales actualmente es bastante caro y lleva mucho tiempo. 2. Se requiere un estudio detallado porque pocos responsables del desarrollo de software tienen los antecedentes necesarios para aplicar mtodos formales. 3. Es difcil utilizar los modelos como un mecanismo de comunicacin con clientes que no tienen muchos conocimientos tcnicos. Bibliografa
http://es.scribd.com/doc/7978336/Ingenieria-de-Software-Un-Enfoque-Practico-Pressman-5th-Ed http://isoft3cv2.wordpress.com/2012/02/08/modelo-en-cascada-o-lineal-secuencial/ http://members.fortunecity.es/odi39/modelo.htm http://tamaraferrufino.blogspot.mx/2010/10/modelos-de-desarrollo-del-software.html