Modelos de Proceso del Software
Yüklə 202,89 Kb.
|
1 2
|
4  . Modelos de Proceso del Software
El proceso es el conocimiento incorporado, y puesto que el conocimiento esta inicialmente disperso, el desarrollo de software implícito, latente e incompleto en gran medida es un proceso social de aprendizaje. El proceso es un dialogo en el que se reúne el conocimiento y se incluye en el software para convertirse en software. El proceso proporciona una iteración entre los usuarios y los diseñadores, entre los usuarios y las herramientas de desarrollo, y entre los diseñadores y las herramientas de desarrollo (tecnología). Es un proceso interactivo donde la herramienta de desarrollo se usa como medio de comunicación, con cada iteración del dialogo se obtiene mayor conocimiento. Howard Baetjer Desde un punto de vista técnico se puede decir que el proceso de software es un marco de trabajo de las tareas que se requieren para construir software de alta calidad. Aun más importante es que la Ingeniería del Software la realizan personas creativas, con conocimiento, que deberían trabajar dentro de un proceso del software definido y avanzado que es apropiado para los productos que construyen y para las demandas de su mercado. 4  .1 Modelo de cascada [4]
Modelo de Cascada (Bennington 1956, Modificado por Royce en 1970, Pressman lo presenta como ciclo de vida clásico). Se denomina modelo en cascada porque su característica principal es que no se comienza con un paso hasta que no se ha terminado el anterior. El modelo en Cascada establece que el software debe ser construido, rigurosamente, a través de una transformación sucesiva de documentos, siguiendo una estrategia lineal de desarrollo. Primero saber qué se quiere y después, cuando se conozca todo lo que se quiere, empezar a construirlo. El modelo de cascada también conocido como 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. A grandes rasgos el primer paso es conseguir un documento con la especificación completa, exacta, no ambigua de los requisitos del sistema software que debe ser desarrollado. Este documento inicial es transformado en un documento de análisis, supuestamente alejado de la máquina. Después, a partir del análisis, se obtiene otro documento, el diseño. Y por último, del diseño se obtiene el documento final: el código. Para asegurar que no se introducen equivocaciones al transformar un documento (modelo) en otro, se hacen pruebas, al terminar cada uno. Las pruebas son planificadas desde el principio y se documentan como se vayan realizando. Antes de la entrega del sistema software, se valida que satisface los requisitos definidos en el documento inicial. Está basado en el ciclo convencional de una ingeniería, tiene las siguientes actividades que se muestran en la figura 4.1 del modelo de cascada: 
4.1.1 Actividades 
Ingeniería y Análisis 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 algún subconjunto de estos requisitos al software. Análisis de los requisitos del software Análisis: Se analizan las necesidades de los usuarios finales del software para determinar qué objetivos debe cubrir. De esta fase surge una memoria llamada SRD (Documento de Especificación de Requisitos), que contiene la especificación completa de lo que debe hacer el sistema sin entrar en detalles internos (debe comprender el ámbito de la información del software, así como la función, el rendimiento y las interfaces requeridas). [4] Diseño El diseño del software se enfoca en cuatro atributos distintos del programa: la estructura de los datos, la arquitectura del software, el detalle procedimental y la caracterización de la interfaz. El proceso de diseño traduce los requisitos en una representación del software con la calidad requerida antes de que comience la codificación. Como resultado surge el SDD (Documento de Diseño del Software), que contiene la descripción de la estructura global del sistema y la especificación de lo que debe hacer cada una de sus partes, así como la manera en que se combinan unas con otras. [4] Codificación Es la fase de programación. Aquí se desarrolla el código fuente, el diseño debe traducirse en una forma legible para la maquina, haciendo uso de prototipos así como pruebas y ensayos para corregir errores. El paso de codificación realiza esta tarea. Si el diseño se realiza de una manera detallada la codificación puede realizarse mecánicamente. [4] Prueba Una vez que se ha generado el código comienza la prueba del programa. La prueba se centra en la lógica interna del software, y en las funciones externas, realizando pruebas que aseguren que la entrada definida produce los resultados que realmente se requieren. Se comprueba que funciona correctamente antes de ser puesto en explotación. [4] Mantenimiento El software sufrirá cambios después de que se entrega al cliente. Los cambios ocurrirán cuando se hayan encontrado errores, esto en lugar de que el software deba adaptarse a cambios del entorno externo (sistema operativo o dispositivos periféricos), o debido a que el cliente requiera ampliaciones funcionales o del rendimiento. [4] Desventajas
Se tiene un Alto riesgo en sistemas nuevos debido a problemas en las especificaciones y en el diseño. Bajo riesgo para desarrollos bien comprendidos utilizando tecnología conocida Este modelo, que se lleva a cabo de forma descendente, exige que para pasar a la siguiente fase hay que concluir correctamente la anterior, de manera que los posibles errores sean fácilmente detectables. Así, la salida de una fase es la entrada de la siguiente. La Ventaja de este método radica en su sencillez ya que sigue los pasos intuitivos necesarios a la hora de desarrollar el software. 4 .2 Modelo de espiral
El modelo espiral propuesto originalmente por Boehm en 1988, es un modelo de proceso de software evolutivo ha sido desarrollado para cubrir las mejores características tanto del ciclo de vida clásico, como de la creación de prototipos, añadiendo al mismo tiempo un nuevo elemento: el análisis de riesgo. Proporciona el potencial para el desarrollo rápido de versiones incrementales del software. En este modelo el software 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. En las últimas iteraciones, se producen versiones cada vez mas completas del sistema diseñado. El modelo representado mediante la espiral de la figura 4.2 define cuatro actividades principales, también llamadas regiones de tareas o sectores:
Con cada iteración alrededor de la espiral (comenzando en el centro y siguiendo hacia el exterior), se construyen sucesivas versiones del software, cada vez más completas y, al final, el propio sistema operacional. De acuerdo con Sommerville Un ciclo en espiral inicia con la elaboración de objetivos, como el rendimiento y la funcionalidad. Después se enumeran formas alternativas de alcanzar estos objetivos y las restricciones impuestas en cada una de ellas. Cada alternativa se evalúa contra cada objetivo y se identifican las fuentes de riesgo del proyecto. Lo siguiente es resolver los riesgos mediante actividades de recopilación de información como la de detallar más el análisis, la construcción de prototipos y la simulación. Ya que se evaluaron los riesgos, se lleva a cabo cierto desarrollo, seguido de una actividad de planificación para la siguiente fase. El paradigma del modelo en espiral para la Ingeniería de Software es actualmente el enfoque más realista para el desarrollo de software y de sistemas a gran escala. Utiliza un enfoque evolutivo, permitiendo al desarrollador y al cliente entender y reaccionar a los riesgos en cada nivel. Utiliza la creación de prototipos como un mecanismo de reducción de riesgo, pero, lo que es más importante permite a quien lo desarrolla aplicar el enfoque de creación de prototipos en cualquier etapa de la evolución de prototipos. 
4.3 Modelo incremental [2]
El modelo incremental aplica secuencias lineales de forma escalonada mientras avanza el tiempo. Corrige la necesidad de una secuencia no lineal de pasos de desarrollo. Cada secuencia lineal produce un incremento del software. Por ejemplo, el software de tratamiento de textos desarrollado con el paradigma incremental podría extraer funciones de gestión de archivos básicos y de producción de documentos en el primer incremento; funciones de edición mas sofisticadas y de producción de documentos en el segundo incremento; corrección ortográfica y gramatical en el tercero; y una función avanzada de esquema de pagina en el cuarto. Se debería tener en cuenta que el flujo del proceso de cualquier incremento pude incorporar el paradigma de construcción de prototipos. El modelo incremental entrega el software en partes pequeñas, pero utilizables, llamadas “incrementos”. En general, cada incremento se construye sobre aquel que ya ha sido entregado. [2] Cuando se utiliza un modelo incremental, el primer incremento a menudo es un producto esencial. Es decir, se afrontan requisitos básicos, pero muchas funciones suplementarias (algunas conocidas, otras no) quedan sin extraer. El cliente utiliza el producto central (o sufre la revisión detalla). Como un resultado de utilización y/o de evaluación, se desarrolla un plan para el incremento siguiente. El plan afronta la modificación del producto central a fin de cumplir mejor las necesidades del cliente y la entrega de funciones, y características adicionales. Este proceso se repite siguiendo la entrega de cada incremento. Hasta que se elabore el producto completo. El modelo de proceso incremental, como la construcción de prototipos y otros enfoques evolutivos, es iterativo por naturaleza. Pero a diferencia de la construcción de prototipos, el modelo incremental se centra en la entrega de un producto operacional con cada incremento. Los primero incrementos son versiones “incompletas” del producto final, pero proporcionan al usuario la funcionalidad que precisa y también una plataforma para la evaluación. El desarrollo incremental es particularmente útil cuando el personal no esta disponible para una implementación completa en la fecha límite que se haya establecido para el proyecto. Los primeros incrementos se pueden implementar con menos personas. Este modelo constituyo un avance sobre el modelo en cascada pero también presenta problemas. Aunque permite el cambio continuo de requisitos, aun existe el problema de determinar si los requisitos propuestos son validos. Los errores en los requisitos se presentan tarde y su corrección resulta tan costosa como en el modelo en cascada. 4.4 Proceso de desarrollo unificado [18]
Es un modelo complejo con mucha terminología propia, pensado principalmente para el desarrollo de grandes proyectos. Es un proceso que puede adaptarse y extenderse en función de las necesidades de cada empresa. Es el resultado de esfuerzo de las tres últimas décadas en desarrollo de software y de la experiencia de sus creadores Ivar Jacobson, Grady Booch y James Rumbaugh. 4 .4.1 Orígenes
El antecedente más importante lo ubicamos en 1967 con la Metodología Ericsson (Ericsson Approach), ésta es una aproximación de desarrollo basada en componentes, que introdujo el concepto de caso de uso; entre los años de 1987 a 1995 Jacobson funda la compañía “Objectory AB” y lanza el proceso de desarrollo Objectory (abreviación de Object Factory), posteriormente en 1995 “Rational Software Corporation” adquiere “Objectory AB” y es entre 1995 y 1997 que se desarrolla “Rational Objectory Process (ROP)” fruto del encuentro y evolución de Objectory 3.8 y la Metodología Rational (Rational Approach) que adopta por primera vez UML como lenguaje de modelamiento. [16] A principios de los noventas, la guerra de los métodos hizo evidente la necesidad de unificar criterios, es así como Grady Booch autor del método Booch y James Rumbaugh (desarrollador para General Electric) se unieron en Rational en 1994, después en 1995 se une Jacobson y gracias al esfuerzo de varias compañías y metodologistas evolucionó UML hasta ser un estándar en 1997, el cual es adoptado en todos los modelos del ROP. Desde ese entonces y a la cabeza de Booch, Jacobson y Rumbaugh, Rational ha desarrollado e incorporado diversos elementos para expandir el ROP, destacándose especialmente el flujo de trabajo conocido como modelamiento del negocio, es así como en junio del 1998 se lanza Rational Unified Process 5.0. La evolución y orígenes de este proceso de desarrollo se puede visualizar mejor en la figura 2.1 [16] 4 .4.2 Características del Proceso Unificado de Desarrollo
El Proceso Unificado guía a los equipos de proyecto en cómo administrar el desarrollo iterativo de un modo controlado mientras se balancean los requerimientos del negocio, el tiempo al mercado y los riesgos del proyecto. El proceso describe los diversos pasos involucrados en la captura de los requerimientos y en el establecimiento de una guía arquitectónica, para diseñar y probar el sistema hecho de acuerdo a los requerimientos y a la arquitectura. El proceso describe qué producto se debe producir, cómo desarrollar lo que vamos a entregar y también provee patrones. El proceso unificado es soportado por herramientas que automatizan entre otras cosas, el modelado visual, la administración de cambios y las pruebas. El Proceso Unificado está basado en componentes, lo cual quiere decir que el sistema software en construcción está formado por componentes de software interconectados a través de interfaces bien definidas. Además, el Proceso Unificado utiliza el UML para expresar gráficamente todos los esquemas de un sistema de software. Pero, realmente, las características que definen este Proceso Unificado son tres: Iterativo e Incremental, Dirigido por casos de uso y Centrado en la Arquitectura. 4 .4.2.1 Dirigido por casos de uso
Un caso de uso es un fragmento de funcionalidad del sistema que proporciona un resultado de valor a un usuario. Los casos de uso modelan los requerimientos funcionales del sistema. [17] Basándose en los casos de uso, los desarrolladores crean una serie de modelos de diseño e implementación que llevan a cabo. Además, estos modelos se validan para que sean conforme a los casos de uso. Finalmente, los casos de uso se usan para realizar los casos de pruebas sobre los componentes desarrollados. Los casos de uso no solo inician el proceso, sino que también proporcionan un hilo conductor en todo el ciclo de vida del desarrollo de software. En conclusión los casos de uso son utilizados para:
4.4.2.2 Centrado en la arquitectura
La arquitectura de un sistema software se describe mediante diferentes vistas del sistema en construcción. Arquitectura: Conjunto de decisiones significativas acerca de la organización de un sistema software, la selección de los elementos estructurales a partir de los cuales se compone el sistema, las interfaces entre ellos, su comportamiento, sus colaboraciones, y su composición. [17] El concepto de arquitectura software incluye los aspectos estáticos y dinámicos más significativos del sistema. La arquitectura es una vista del diseño completo con las características más importantes resaltadas, dejando los detalles de lado. Los casos de uso y la arquitectura están profundamente relacionados. Los casos de uso deben encajar en la arquitectura, y a su vez la arquitectura debe permitir el desarrollo de todos los casos de uso requeridos, actualmente y a futuro. El arquitecto desarrolla la forma o arquitectura a partir de la comprensión de un conjunto reducido de casos de uso fundamentales o críticos (usualmente no mas del 10 % del total). El arquitecto:
Este proceso continúa hasta que se considere que la arquitectura es estable. 4.4.2.3 Iterativo e incremental
Todo sistema complejo supone un gran esfuerzo que puede durar desde varios meses hasta años. Por lo tanto, lo más práctico es dividir un proyecto en varias fases o mini proyectos. Una iteración es un bucle de desarrollo completo, es una secuencia de actividades con un plan establecido y criterios de evaluación. Acaba en la edición de un producto ejecutable, subconjunto del producto final bajo desarrollo. Se suele hablar de ciclos de vida en los que se realizan varios recorridos por todas las fases. Cada recorrido por las fases se denomina Iteración en el proyecto en la que se realizan varios tipos de trabajo (denominados flujos). Cada iteración parte de la anterior incrementado (crece el producto) o revisando la funcionalidad implementada. Los desarrolladores basan la selección de lo que implementarán en cada iteración en dos cosas: el conjunto de casos de uso que amplían la funcionalidad, y en los riesgos más importantes que deben mitigarse. Las iteraciones deben estar controladas. Esto significa que deben seleccionarse y ejecutarse de una forma planificada. Los beneficios de este enfoque iterativo son:
4 .4.2.4 Basado en componentes
La creación de sistemas intensivos en software requiere dividir el sistema en componentes con interfaces bien definidas, que posteriormente serán ensamblados para generar el sistema. Esta característica en un proceso de desarrollo, permite que el sistema se vaya creando a medida que se obtienen o que se desarrolla y maduran sus componentes. Un componente, es una parte del sistema, física y reemplazable, que está sujeto á, y proporciona la implementación de un conjunto de interfaces. El desarrollo basado en componentes consiste en la creación e implantación de sistemas de software complejos, ensamblados a partir de componentes, y que ponen a la vez nuevos componentes a disposición de otros sistemas. Puede automatizarse mediante herramientas y procesos, que permiten aumentar la productividad, calidad y tiempo de desarrollo. 4.4.3 Ciclo de vida
El Proceso Unificado se repite a lo largo de una serie de ciclos que constituyen la vida de un sistema. Cada ciclo constituye una versión del sistema. 4.4.3.1 Fases
Cada ciclo consta de cuatro fases: inicio, elaboración, construcción, y transición:
Iteraciones dentro del ciclo de vida. Cada fase se subdivide en iteraciones. En cada iteración se desarrolla en secuencia un conjunto de disciplinas o flujos de trabajos.  4.4.3.2 Disciplinas
Cada disciplina es un conjunto de actividades relacionadas (flujos de trabajo) vinculadas a un área específica dentro del proyecto total. Las más importantes son: Requerimientos, Análisis, Diseño, Codificación, y Prueba. El agrupamiento de actividades en disciplinas es principalmente una ayuda para comprender el proyecto desde la visión tradicional en cascada. Cada disciplina está asociada con un conjunto de modelos que se desarrollan. Estos modelos están compuestos por artefactos. Los artefactos más importantes son los modelos que cada disciplina realiza: modelo de casos de uso, modelo de diseño, modelo de implementación, y modelo de prueba. El Proceso Unificado consiste en una serie de disciplinas o flujos de trabajo que van desde los requisitos hasta las pruebas. Los flujos de trabajo desarrollan modelos desde el modelo de casos de uso hasta el modelo de pruebas. 4 .4.3.3 Hitos
Cada fase finaliza con un hito. Cada hito se determina por la disponibilidad de un conjunto de artefactos (RUP llama artefactos a un subproducto), es decir un conjunto de modelos o documentos que han sido desarrollados hasta alcanzar un estado predefinido. Los hitos tienen muchos objetivos. El más crítico es que los encargados del proyecto deben tomar ciertas decisiones antes de que el trabajo continúe con la siguiente fase. Los hitos también permiten controlar la dirección y progreso del trabajo. Al final se obtiene un conjunto de datos a partir del seguimiento del tiempo y esfuerzo consumidos en cada fase. Estos datos son útiles para la estimación en futuros proyectos. 4 .4.3.4 Artefactos
Dentro del Proceso de Desarrollo Unificado se denomina artefacto a todo producto o subproducto resultante del proceso. Dentro de esto se encuentra desde el propio código fuente hasta la documentación aportada por el cliente y la entregada al completarse cada hito dentro del proyecto. Para su mejor comprensión hemos agrupado todos los artefactos posibles del proceso en tres grandes grupos: Artefactos entregados por el cliente, Artefactos internos del proceso y Artefactos entregables al cliente. No siempre en todo proyecto se crean los mismos artefactos, esto dependerá de las características del proyecto y los requisitos del cliente, siendo tarea de la gestión de la configuración el definir qué artefactos específicos y con qué nivel de formalidad se crearán para el proyecto en cuestión. 4.4.3.4.1 Artefactos entregados por el cliente
4.4.3.4.2 Artefactos Internos del Proceso
4 .4.3.4.3 Artefactos entregables al cliente
4.4.3.5 Inicio
Su meta principal es lograr el consenso de todos los involucrados acerca de los objetivos del ciclo de vida del proyecto. Es muy importante especialmente en proyectos nuevos en que existen riesgos significativos en el negocio o la implementación de los requisitos, y deben ser solucionados para que el proyecto proceda. Para los proyectos que se enfocan en mejorar sistemas existentes, esta fase es más breve, pero aún así centrada en asegurar que el proyecto vale la pena y se puede realizar. Objetivos
Actividades
Hito Establecer el ámbito del producto, la identificación de los principales riesgos y la viabilidad del proyecto. 4  .4.3.6 Elaboración
El propósito de la etapa de Elaboración es crear la línea base de la arquitectura del software para así disponer de unos cimientos sólidos sobre los que se basará el grueso del esfuerzo de diseño e implementación durante la siguiente fase de Construcción. En la definición de la línea base de la arquitectura se incluyen los requisitos más significativos (aquéllos que tienen un mayor impacto sobre la arquitectura del sistema), y los componentes de mayor riesgo para el sistema. Para evaluar la estabilidad de la arquitectura se emplean prototipos evolutivos de la arquitectura. Objetivos
Actividades
Hito Obtener una línea base de la arquitectura del sistema, capturar la mayoría de los requisitos y reducir los riesgos principales así como permitir la escalabilidad del equipo del proyecto durante la fase de construcción. 4 .4.3.7 Construcción
En esta fase se documentan los requisitos restantes y se completa el desarrollo del sistema basándose en la arquitectura que se ha sido añadida a la línea base. La Construcción es un proceso de fabricación donde se hace énfasis en la administración de los recursos y el control de operaciones para optimizar costos, el tiempo dedicado, y la calidad del producto. En este sentido la administración experimenta una transición del desarrollo de propiedad intelectual durante las fases de Inicio y Elaboración, al desarrollo de productos instalables durante la Construcción y Transición. Objetivos
Actividades
Hito Podemos decir que se alcanza el hito principal de la fase cuando hemos conseguido desarrollar el sistema con calidad de producción, y puede entonces prepararse para la entrega al equipo de transición. En esta fase, toda la funcionalidad ha sido implementada, y completadas las pruebas para el estado alfa de la aplicación. 4 .4.3.8 Transición
En esta fase la atención se enfoca en asegurar que el software está disponible para los usuarios finales. Puede extenderse a varias iteraciones, e incluye las pruebas del producto como parte de su preparación para ser entregado, y la realización de ajustes menores en respuesta a la retroalimentación recibida de los usuarios. En este punto del ciclo de vida la retroalimentación de los usuarios debe enfocarse fundamentalmente a ajustes específicos y de corto alcance al producto, junto a otros temas como configuración, instalación, y usabilidad. Referencias a otros ajustes estructurales mayores habrán sido solucionadas anteriormente en el ciclo de vida y serán documentadas para futuras generaciones del software. Al final de la fase de Transición los objetivos del ciclo de vida se han cumplido, y el proyecto está listo para cerrarse. En algunos casos el final de este ciclo coincide con el inicio de otro ciclo en el mismo proyecto, encaminándose a la siguiente generación o versión del producto. Para otros proyectos el final de esta fase puede coincidir con la entrega completa de los productos (aplicaciones) y subproductos (documentación) a terceros que pudieran ser responsables de la operación, mantenimientos, y mejoras al sistema entregado. Esta fase de transición puede variar de muy sencilla a extremadamente compleja, dependiendo del tipo de producto. Esta etapa comienza cuando la línea base está lo suficientemente madura como para realizar una entrega al dominio de los usuarios finales. Esto por lo general requiere que se haya completado un subconjunto usable del sistema con un nivel de calidad aceptable y documentación de usuario de modo que la transición produzca resultados positivos para todas las partes. Objetivos
Actividades
Hito Al finalizar esta fase se decide si los objetivos se cumplieron y si debe comenzarse otro ciclo de desarrollo. Es el resultado de la revisión y aceptación por parte del cliente de los productos y subproductos que le han sido entregados. 4 .5 Proceso Software Personal.
El Proceso Personal del Software (PSP) es un sistema estructurado de descripciones, de medidas, y de los métodos de proceso que pueden ayudar a ingenieros a mejorar su actividad personal. El PSP fue definido por Watts S. Humphrey del Software Engineering Institute (SEI) en la Carnegie Mellon University. 4 .5.1 Principios del Proceso de Software Personal [15]
El PSP Cubre los siguientes aspectos como:
Es un acercamiento general que se puede utilizar en casi cualquier parte del proceso del software. El costo personal de un PSP, es el tiempo que se requiere para aprender y para usarlo, el costo emocional de tener una disciplina necesaria y el riesgo potencial a su ego.
4.5.2 PSP0 Línea Base [15]
Establece una línea de medida del progreso y para definir un fundamento para mejorar. EL PSP0 provee una estructura muy conveniente para hacer tareas a pequeña escala, un marco de trabajo para medir las tareas y un fundamento de mejora del proceso Las tareas incluyen lo siguiente:
4.5.2.1 PSP0 Proceso Actual [15]
Se debe identificar el proceso actual del desarrollo de software. En caso de que no se tenga un proceso regular se puede utilizar el siguiente:
El proceso incluye las siguientes tareas:
4.5.2.2 PSP0 Tiempo de Registro [15]
El tiempo de registro incluye:
4.5.2.3 PSP0 Registro de fallas [15]
El registro de una falla se usa para tener los defectos encontrados y corregidos. El objetivo de esto es determinar donde se pierde mucho tiempo y ser lo mas minucioso posible con los datos. El registro de fallas debe incluir lo siguiente:
4.5.2.4 PSP0 Estándar de fallas [15]
Estos pueden se algunas de las fallas que se registran y que se pueden tomar como un estándar:
Yüklə 202,89 Kb. Dostları ilə paylaş:
|
nstituto Tecnológico 1 2