ANTOLOGA

MATERIA: Fundamentos de desarrollo de sistemas

CARRERA: Ingeniera en sistemas computacionales

CLAVE DE LA ASIGNATURA: SCM - 0413

CLAVE DEL PLAN: ISIC - 2004 - 296

Compilacin hecha por: M.A. Vernica Amezcua Magalln

UNIDAD 4-. Modelos de proceso de software

Objetivo Educacional

Identificar los diferentes modelos de proceso que se aplican en el desarrollo de software.

4. Modelos de proceso de software

4.1. Modelo de cascada.

Modelo en Cascada:

El ms conocido, esta basado en el ciclo convencional de una ingeniera, el paradigma del ciclo de vida abarca las siguientes actividades:

Ingeniera y Anlisis del SistemaAnlisis de los RequisitosDiseoCodificacinPruebaMantenimiento

Figura 23: Modelo en cascada

Ingeniera y Anlisis del Sistema: Debido a que el software es siempre parte de un sistema mayor el trabajo comienza estableciendo los requisitos de todos los elementos del sistema y luego asignando algn subconjunto de estos requisitos al software.

Anlisis de los requisitos del software: el proceso de recopilacin de los requisitos se centra e intensifica especialmente en el software. El ingeniero de software (analista) debe comprender el mbito de la informacin del software, as como la funcin, el rendimiento y las interfaces requeridas.

Diseo: el diseo del software se enfoca en cuatro atributos distintos del programa: la estructura de los datos, la arquitectura del software, el detalle procedimental y la caracterizacin de la interfaz. El proceso de diseo traduce los requisitos en una representacin del software con la calidad requerida antes de que comience la codificacin. Codificacin: el diseo debe traducirse en una forma legible para la maquina. El paso de codificacin realiza esta tarea. Si el diseo se realiza de una manera detallada la codificacin puede realizarse mecnicamente.

Prueba: comienza una vez que se ha generado el cdigo del programa. sta se centra en la lgica interna del software, y en las funciones externas, realizando pruebas que aseguren que la entrada definida produce los resultados que realmente se requieren.

Mantenimiento: el software sufrir cambios despus de que se entrega al cliente. Los cambios ocurrirn debido a que hayan encontrado errores, a que el software deba adaptarse a cambios del entorno externo (sistema operativo o dispositivos perifricos), o debido a que el cliente requiera ampliaciones funcionales o del rendimiento.

Desventajas:

Los proyectos reales raramente siguen el flujo secuencial que propone el modelo, siempre hay iteraciones y se crean problemas en la aplicacin del paradigma. Normalmente, es difcil para el cliente establecer explcitamente al principio todos los requisitos. El ciclo de vida clsico lo requiere y tiene dificultades en acomodar posibles incertidumbres que pueden existir al comienzo de muchos productos. El cliente debe tener paciencia. Hasta llegar a las etapas finales del proyecto, no estar disponible una versin operativa del programa. Un error importante no detectado hasta que el programa este funcionando puede ser desastroso.

La ventaja de este mtodo radica en su sencillez ya que sigue los pasos intuitivos necesarios a la hora de desarrollar el software.

4.2. Modelo espiral.

Es un modelo de proceso de software evolutivo. En el modelo espiral, el software se desarrolla en una serie de versiones incremntales. 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 mas completas de ingeniera del sistema.

Caractersticas:

Es tambin al igual que el anterior un modelo evolutivo que combina el modelo clsico con el diseo de prototipos. Incluye la etapa de anlisis de riesgos, no incluida anteriormente. Es ideal para crear productos con diferentes versiones mejoradas como se hace con los software modernos de microcomputadoras. La ingeniera puede desarrollarse a travs del ciclo de vida clsico o el de construccin de prototipos. Este es el enfoque ms realista actualmente. El modelo en espiral se divide en un nmero de actividades estructurales, tambin llamadas regiones de tareas. Generalmente, existen entre tres y seis regiones de tareas.

Comunicacin con el cliente: las tareas requeridas para establecer comunicacin entre el desarrollador y el cliente.Planificacin: las tareas requeridas para definir recursos, el tiempo y otras informaciones relacionadas con el proyecto. Son todos los requerimientos.Anlisis de riesgos: las tareas requeridas para evaluar riesgos tcnicos y otras informaciones relacionadas con el proyecto.Ingeniera: las tareas requeridas para construir una o ms representaciones de la aplicacin.Construccin y adaptacin: las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario.Evaluacin el cliente: las tareas requeridas para obtener la reaccin del cliente segn la evaluacin de las representaciones del software creadas durante la etapa de ingeniera e implementacin durante la etapa de instalacin.

Figura 24: Modelo en espiral

Cuando empieza el proceso evolutivo, el equipo de ingeniera del software gira alrededor de la espiral en la direccin de las agujas del reloj, comenzando por el centro. El primer circuito de la espiral produce el desarrollo de una especificacin de productos; los pasos siguientes en la espiral se podran utilizar para desarrollar un prototipo y progresivamente versiones mas sofisticadas del software. Cada paso de la regin de planificacin produce ajustes en el plan del proyecto. El coste y la planificacin se ajustan segn la reaccin ante la evolucin del cliente.

VENTAJAS:

El modelado en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora, no termina cuando se entrega el software. Como el software evoluciona, a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los niveles evolutivos. Permite a quien lo desarrolla aplicar el enfoque de construccin de prototipos en cualquier etapa de evolucin del producto. Demanda una consideracin directa de los riesgos tcnicos en todas las etapas del proyecto. Reduce los riesgos antes de que se conviertan en problemticos. Pero al igual que otros paradigmas puede resultar difcil convencer a grandes clientes de que el enfoque evolutivo es controlable. Si un riesgo importante no es descubierto y gestionado, indudablemente surgirn problemas. El modelo en s mismo no se ha utilizado tanto como los paradigmas lineales secuenciales o de construccin de prototipos. Todava tendrn que pasar muchos aos antes de que se determine con absoluta certeza la eficacia de este nuevo e importante paradigma.

PROBLEMAS:

Demostrar al cliente "exigente" (bajo contrato) que el enfoque evolutivo es controlable. Requiere gran habilidad y experiencia para valorar el riesgo y saber cuando detener la evolucin

4.3. Modelo incremental.

El modelo incremental combina elementos del modelo del ciclo de vida clsico con la filosofa interactiva de construccin de prototipos.Cada secuencia lineal produce un incremento.

A diferencia de la construccin de prototipos, el modelo incremental se centra en la entrega de un producto operacional con cada incremento.

Figura 25: Ejemplo del modelo incremental

Los primeros incrementos son versiones desmontadas del producto final, pero proporcionan la capacidad que sirve al usuario y tambin proporciona una plataforma para la evaluacin por parte del usuario.Como resultado de la utilizacin y/o evaluacin, se desarrolla un plan para el incremento a fin de cumplir con:

1. las necesidades del usuario2. la entrega de funciones, y caractersticas adicionales.

Ejemplo:

Registro acadmico:Captura del expedienteacadmicoSe entrega al clienteEl cliente puede solicitar mejoras y/o incorporar nuevo (s) requerimiento (s)

Figura 26: 1er. incremento

Captura planes de estudioSe entrega al clienteEl cliente puede solicitar mejoras y/o incorporar nuevo (s) requerimiento (s)Se incorporan las mejoras y/o nuevos requerimiento (si las hay). Y se agrega una nueva funcin.Figura 27: 2do. incremento

Integracin de los expedientes de los alumnos y los planes de estudios.

Captura del expediente acadmicoCaptura de planes de estudiosFigura 28: 3er. incremento

(Pressman 4 y 6 ed.)

4.4. Proceso de desarrollo unificado.

El Proceso Unificado de Desarrollo Software o simplemente Proceso Unificado es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura y por ser iterativo e incremental. El refinamiento ms conocido y documentado del Proceso Unificado es el Proceso Unificado de Rational o simplemente RUP.

El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos especficos. De la misma forma, el Proceso Unificado de Rational, tambin es un marco de trabajo extensible, por lo que muchas veces resulta imposible decir si un refinamiento particular del proceso ha sido derivado del Proceso Unificado o del RUP. Por dicho motivo, los dos nombres suelen utilizarse para referirse a un mismo concepto.El nombre Proceso Unificado se usa para describir el proceso genrico que incluye aquellos elementos que son comunes a la mayora de los refinamientos existentes. Tambin permite evitar problemas legales ya que Proceso Unificado de Rational o RUP son marcas registradas por IBM (desde su compra de Rational Software Corporation en 2003). El primer libro sobre el tema se denomin, en su versin espaola, El Proceso Unificado de Desarrollo de Software (ISBN 84-7829-036-2) y fue publicado en 1999 por Ivar Jacobson, Grady Booch y James Rumbaugh, conocidos tambin por ser los desarrolladores del UML, el Lenguaje Unificado de Modelado. Desde entonces los autores que publican libros sobre el tema y que no estn afiliados a Rational utilizan el trmino Proceso Unificado, mientras que los autores que pertenecen a Rational favorecen el nombre de Proceso Unificado de Rational.

Iterativo e Incremental

El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto de cuatro fases denominadas Inicio, Elaboracin, Construccin y Transicin. Cada una de estas fases es a su vez dividida en una serie de iteraciones (la de inicio slo consta de varias iteraciones en proyectos grandes). Estas iteraciones ofrecen como resultado un incremento del producto desarrollado que aade o mejora las funcionalidades del sistema en desarrollo.

Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que recuerdan a las definidas en el ciclo de vida clsico o en cascada: Anlisis de requisitos, Diseo, Implementacin y Prueba. Aunque todas las iteraciones suelen incluir trabajo en casi todas las disciplinas, el grado de esfuerzo dentro de cada una de ellas vara a lo largo del proyecto.

Dirigido por los casos de uso

En el Proceso Unificado los casos de uso se utilizan para capturar los requisitos funcionales y para definir los contenidos de las iteraciones. La idea es que cada iteracin tome un conjunto de casos de uso o escenarios y desarrolle todo el camino a travs de las distintas disciplinas: diseo, implementacin, prueba, etc. el proceso dirigido por casos de uso es el RUP.

Centrado en la arquitectura

El Proceso Unificado asume que no existe un modelo nico que cubra todos los aspectos del sistema. Por dicho motivo existen mltiples modelos y vistas que definen la arquitectura de software de un sistema. La analoga con la construccin es clara, cuando construyes un edificio existen diversos planos que incluyen los distintos servicios del mismo: electricidad, fontanera, etc.

Enfocado en los riesgos

El Proceso Unificado requiere que el equipo del proyecto se centre en identificar los riesgos crticos en una etapa temprana del ciclo de vida. Los resultados de cada iteracin, en especial los de la fase de Elaboracin, deben ser seleccionados en un orden que asegure que los riesgos principales son considerados primero.

"http://es.wikipedia.org/wiki/Proceso_Unificado"

Fases del proceso unificado

La fase de inicio de PU abarca la comunicacin con el cliente y las actividades de planeacin. Al colaborar con los clientes y usuarios finales se identifican los requerimientos de negocios del software, se propone una arquitectura aproximada para el sistema y se desarrolla un plan para la naturaleza iteractiva e incremental del sistema subsiguiente. Los requisitos fundamentales de negocios se describen a travs de un conjunto preliminar de casos de uso que describen cules caractersticas y funciones son deseables para cada clase importante de usuarios. En general un caso de uso describe una secuencia de acciones que desarrolla un actor (por ejemplo una persona, una mquina, otro sistema) cuando ste interacta con el software. Los casos de uso ayudan a identificar al mbito del proyecto y proporcionan una base para la planeacin de ste.

En este punto, la arquitectura no es ms que un esquema tentativo de los subsistemas ms importantes y de las funciones y caractersticas que lo forman. Despus la arquitectura se refinar y expandir en un conjunto de modelos que representan visiones diferentes del sistema. La planeacin identifica los recursos, evala los riesgos importantes, define un itinerario y establece una base para las fases que se aplicarn conforme se desarrolle el incremento del software.

La fase de elaboracin abarca la comunicacin con el cliente y las actividades de modelado del modelo genrico del proceso. La elaboracin refina y expande los casos de uso preliminares que se desarrollan como parte de la fase de inicio; adems, expande la representacin arquitectnica para incluir cinco visiones diferentes del software: el modelo de caso de uso, el modelo de anlisis, el modelo de diseo, el modelo de implantacin y el modelo de despliegue.

En algunos casos, la elaboracin crea un lnea de base arquitectnica ejecutable que representa un sistema ejecutable en su primer corte. La lnea de base arquitectnica demuestra la viabilidad de la arquitectura, pero no proporciona todas las caractersticas y funciones necesarias para utilizar el sistema. Adems, el plan se revisa de manera cuidadosa al trmino de la fase de elaboracin para asegurar que el mbito, los riesgos y los datos entregados an son razonables. Las modificaciones a plan se deben hacer en este momento.

La fase de construccin del PU es idntica a la actividad de construccin definida para el proceso genrico del software. Si se utiliza el modelo arquitectnico como entrada, la fase de construccin desarrolla o adquiere los componentes del software que harn que cada caso de uso sea operativo para los usuarios finales. Lograr esto requiere que los modelos de anlisis y diseo iniciados durante la fase de elaboracin se completen para reflejar la versin final del incremento del software.

Todas las caractersticas y funciones necesarias y requeridas del incremento del software (por ejemplo, la entrega) se implementan en cdigo fuente. Conforme los componentes estn en proceso de implementacin, se disean y ejecutan pruebas de unidad para cada uno de ellos. Adems, se realizan las actividades de integracin (ensamblaje de componentes y pruebas de integracin). Los casos de uso se utilizan para derivar un conjunto de pruebas de aceptacin que se ejecutan antes del inicio de la siguiente fase del PU.

La fase de transicin del PU abarca la ltima actividad genrica de construccin y la primera parte de la actividad genrica de despliegue. El software se entrega a los usuarios finales para realizar pruebas beta (accin de prueba controlada), la retroalimentacin del usuario reporta tanto defectos como cambios necesarios. Adems, el equipo de software crea la informacin de soporte necesaria (por ejemplo, manuales del usuario, guas de resolucin de problemas, procedimientos de instalacin) para el lanzamiento. Al final de la fase de transicin, el incremento de software se convierte en un lanzamiento de software utilizable.

La fase de produccin del PU coincide con la actividad de despliegue del proceso genrico. Durante esta fase se monitorea el uso subsiguiente del software, se proporciona el soporte para el ambiente operativo (infraestructura), y se reciben y evalan los informes de defectos y los requerimientos de cambios.

Es probable que mientras se realizan las fases de construccin, transicin y produccin ya se hayan iniciado los trabajos para el siguiente incremento del software. Esto significa que las cinco fases de PU no suceden en una secuencia, sino en una concurrencia de etapas.

(Presuma 6 ed.)4.5. Proceso software personal

Cada desarrollador utiliza algn proceso para construir un software de computadora. El proceso puede ser fortuito o ad hoc, puede cambiar a diario, puede no ser eficiente, efectivo o hasta exitoso, pero existe un proceso. El PSP resalta la medida personal del producto de trabajo que se produce y la calidad resultante del producto de trabajo. Adems responsabiliza al profesional encargado de la planeacin del proyecto (por ejemplo, la estimacin y la planificacin) y le confiere el poder de controlar la calidad de todos los productos de trabajo del software que se desarrollan.

El modelo PSP define cinco actividades del marco de trabajo: planeacin, diseo de alto nivel, revisin del diseo de alto nivel, desarrollo y anlisis de resultados.

Planeacin: Esta actividad selecciona requisitos y, con base en stos, desarrolla el tamao y la estimacin de los recursos. Adems, se estiman los defectos (el nmero de defectos proyectado en el trabajo). Todas las mediciones se registran en hojas de trabajo o en plantillas. Al final, se identifican las tareas de desarrollo y se crea un programa del proyecto.

Diseo de alto nivel: Se elaboran las especificaciones externas para que cada componente sea construido y se crea un diseo del componente. Se construyen prototipos cuando existe incertidumbre. Todos los elementos se registran y se rastrean.

Revisin del diseo de alto nivel: Los mtodos formales de verificacin se aplican a errores descubiertos en el diseo. Las mediciones se mantienen para todas las tareas importantes y los resultados de trabajo.

Desarrollo: El diseo al nivel de componentes se refina y revisa. Se genera, revisa, compila y prueba el cdigo. Las mediciones se mantienen para todas las tareas importantes y los resultados de trabajo.

Anlisis de resultados: Mediante las mediciones y medidas recolectadas (una cantidad sustancial de datos debe analizarse de manera estadstica) se determina la efectividad del proceso. Las mediciones y medidas deben ofrecer una gua para modificar el proceso y as mejorar su efectividad.

El PSP destaca la necesidad que tiene cada ingeniero de software de identificar los errores desde el principio y la importancia de entender los tipos de errores suele cometer. Esto se lleva a cabo mediante una actividad de evaluacin rigurosa aplicada en todos los productos de trabajo que genere el ingeniero de software.

El PSP representa un enfoque disciplinado, basado en mediciones, de la ingeniera de software que puede conducir a un choque de culturas de muchos profesionales. Sin embargo, cuando el PSP se presenta de un modo adecuado a los ingenieros de software, la mejora resultante en la productividad y calidad de peste son significativas. No obstante, la industria no ha adoptado con amplitud el PSP. Las razones, tristemente, tiene ms relacin con la naturaleza humana y la inercia organizacional que con las fuerzas y debilidades del enfoque del PSP. Este ltimo es un reto intelectual y demanda un grado de compromiso que no siempre es posible obtener. La capacitacin es relativamente larga y sus costos son altos.

(Pressman 6 ed.)

Unidad 4: Modelos de proceso de software

Unidad 4: Modelos de proceso de software

ndice

1.Conceptos Introductorios.11.1.Introduccin a los Sistemas11.1.1Descripcin general de sistemas21.1.2Tipos de Sistemas41.1.3Clasificacin de Sistemas51.2. Ciclo de vida de un proyecto de software.81.2.1.Planificacin y gestin del proyecto.81.2.2. Determinacin de requerimientos.81.2.3. Anlisis y diseo.91.2.4.Programacin.101.2.5.Pruebas e implantacin.102.Introduccin a la ingeniera de software112.1.Definicin de ingeniera de software.132.2.Historia de la ingeniera de software.142.3.Caractersticas del software.162.4.Mitos del software.172.5.Capas de la ingeniera de software.182.6.El proceso de software.192.7.Software de calidad.212.8.Factores de calidad y productividad.263.Paradigmas de la ingeniera de software.353.1.El enfoque estructurado.363.1.1.Diagramas de flujos de datos.363.1.2.Diccionarios de datos.463.1.3.Diseo de mdulos.483.1.4.Descomposicin de procesos.523.2.El enfoque orientado a objetos.613.2.1.Anlisis.613.2.2.Diseo.654.Modelos de proceso de software674.1.Modelo de cascada.674.2.Modelo espiral.694.3.Modelo incremental.714.4.Proceso de desarrollo unificado.744.5. Proceso software personal775.Tcnicas, herramientas y estudios previos.805.1.Tcnicas de recopilacin de informacin.805.1.1 Entrevista.805.1.2 Cuestionario.845.1.3 Recopilacin y anlisis de documentos.865.1.4 Observacin y tcnica STROBE.885.2. Herramientas CASE.905.2.1 Estructuradas.925.2.2 Orientadas a Objetos.935.3. Desarrollo de prototipos.966. Diseo y arquitectura de productos de software.1056.1. Descomposicin modular.1056.2. Arquitecturas de dominio especfico.1086.2.1 Diseo de software de arquitectura multiprocesador.1086.2.2 Diseo de software de Arquitectura Cliente/Servidor1096.2.3 Diseo de software distribuido1176.2.4 Diseo de software de tiempo real.121Bibliografa:129Webgrafa:129http://www.monografas.com/trabajos11/teosis/teosis.shtml/129http://www.rosenblueth.mx/InterFAR/Vol1Num3/doc/Vol1Num3-49.htm129http://exa.unne.edu.ar/depar/areas/informatica/anasistem2/public_html/apuntes/maf/anexos/flujo.htm129http://exa.unne.edu.ar/depar/areas/informatica/anasistem2/public_html/apuntes/maf/cap2.htm#DE129Anexos:130Anexo 1: Datos de la asignatura (programa y retcula)130