Analisis Proceso Ciclo Vida Software

Analisis Proceso Ciclo Vida Software

!! Proceso.

Cuando se construye un producto o se presta un servicio se siguen una serie de pasos para lograr cumplir las tareas necesarias en un cierto orden. Un proceso es una serie de pasos que involucran actividades, restricciones y recursos que producen una salida determinada (producto o servicio) utilizando para ello un conjunto de herramientas y técnicas.

Todos los procesos tienen estas características:

• establecen las principales actividades del proceso.

• utilizan recursos (horas hombre, equipos, dinero, …).

• están sujetos a restricciones (calendario, presupuesto, …).

• genera productos intermedios y finales.

• puede constituirse como una cadena de subprocesos, cada uno con su propio modelo. • cada actividad tiene criterios de entradas y salidas; puede saberse cuando comienza y cuando termina una actividad.

• las actividades se organizan en secuencia; resulta claro el orden relativo de una actividad respecto a las demás.

• tiene un conjunto de principios orientadores que describen las metas de cada actividad.

• las restricciones pueden aplicarse a una actividad, recurso o producto.

Un proceso es más que un procedimiento. Un procedimiento es una manera estructurada de combinar herramientas y técnicas para generar un producto. Un proceso es un conjunto de procedimientos organizados de tal modo que los productos construidos satisfagan un conjunto de metas o estándares.

Proceso de desarrollo o ciclo de vida del software.

El proceso que nos interesa es el proceso de desarrollo del software. Cuando un proceso implica construcción de algún producto suele denominarse al proceso ciclo de vida. En particular, el ciclo de vida del software describe la vida de un producto de software desde su concepción hasta su implementación, entrega, utilización y mantenimiento.

Modelos de procesos en ingeniería de software.

Es posible concebir diferentes modelos de proceso para arribar a un mismo producto; las diferencias estarán en las actividades priorizadas, su importancia relativa, la secuencia de realización, los principios orientadores, las herramientas y técnicas elegidas. Entre los modelos más comunes experimentados por la ingeniería de software se cuentan:

• modelo en cascada (~1970).

• modelo de prototipos (~1975).

• modelo de transformaciones (~1981)

• modelo en espiral (~1988).

• desarrollo por fases: incrementos e iteraciones (~1996).

• proceso unificado (~1999).

• programación extrema (~2000).

Nota: las fechas son aproximadas, generalmente de alguna publicación donde por primera vez se propone el modelo o a partir de la cual cobra vigencia. Una fecha lejana no significa necesariamente inutilidad u obsolescencia; los procesos modernos incorporan muchos principios de modelos más viejos. Además, cada proyecto puede responder mejor a un modelo que a otro, independientemente de la edad del modelo.

Para un proceso de desarrollo de software son de interés las siguientes características:

• el proceso debe describirse de manera flexible, que permita a las personas diseñar y construir el software con algún grado de libertad en la elección de las herramientas y técnicas preferidas o más adecuadas.

• el proceso debe guiar las acciones permitiendo examinar, comprender, controlar y mejorar las actividades que abarca.

• los procesos deben permitir capturar la experiencia y transferirla a los demás.

• cada etapa de un proceso de desarrollo de software es en sí misma un proceso o colección de procesos capaz de ser descrito como un conjunto de actividades, cada actividad con sus propias entradas, salidas, restricciones y recursos.

• la descripción de un proceso puede hacerse de muchas formas, textuales, gráficas o combinadas.

Elementos del proceso.

El producto logrado a a través de la realización de un proyecto es el resultado de la intervención de muchas personas. El proceso de desarrollo guía los esfuerzos de esas personas, marcando los pasos necesarios para lograr culminar el proyecto. El proceso puede ayudarse de herramientas con las cuales se busca facilitar o automatizar algunas tareas.

Producto.

El producto resultante de un proyecto de desarrollo de software incluye todos los elementos (artefactos) creados durante la realización del proyecto: modelo, código fuente, ejecutables, documentación.

Un sistema de software es el conjunto de todos los artefactos necesarios para representarlo en forma comprensible por máquinas u hombres, destinado a las máquinas, los trabajadores y los 2 de 5 interesados en el proyecto. Las máquinas son las herramientas, compiladores y computadores

donde se instalará el software. Los trabajadores son directores, arquitectos de software, diseñadores, programadores, personal de gestión, administración y apoyo. Los interesados son inversores, usuarios, personal de comercialización, agentes de regulación, otros. Las personas y máquinas involucradas en el desarrollo de un sistema de software son llamados a veces trabajadores del proyecto [Jacobson2000, cap. 2].

Un artefacto designa cualquier tipo de información creada, producida, cambiada o utilizada por los trabajadores (hombres o máquinas) durante el desarrollo del sistema. Los artefactos pueden ser tanto de ingeniería como de gestión. Más formalmente, un artefacto es una pieza de información tangible 1) creada, modificada y usada por los trabajadores al realizar actividades; 2) donde se representa un área de responsabilidad; 3) candidata a ser tenida en cuenta al realizar el control de configuración. Un artefacto puede ser un modelo, un elemento de un modelo o un documento. La construcción de un sistema es la construcción de modelos. Diferentes modelos pueden describir diferentes perspectivas del sistema. Un modelo es una abstracción del sistema, especificando el sistema modelado desde un cierto punto de vista y en determinado nivel de abstracción. Más formalmente, un modelo es una abstracción semánticamente cerrada del sistema. Es una vista autocontenida del sistema: un usuario del modelo no necesita recurrir a información fuera del propio modelo, ni a otros modelos [Jacobson2000, cap. 2].

Personas.

Las constructores del proyecto son arquitectos de software, desarrolladores, encargados de pruebas, personal de gestión; usuarios, clientes, inversores y otros interesados también participan en la construcción. Las personas se verán afectadas por diversos aspectos organizativos y de gestión del proyecto:

• viabilidad del proyecto: el proyecto debe ser posible; una evaluación temprana de la viabilidad puede detener un proyecto imposible.

• gestión del riesgo: identificación de los riesgos mayores, definición de políticas de aversión al riesgo (como evitar o manejar el riesgo) contribuyen a la confianza y tranquilidad de todos los involucrados.

• estructura de los equipos: las personas trabajan mejor en grupos reducidos, de seis a ocho personas. La división en subsistemas con interfaces claras permite trabajar con varios equipos manteniendo su coordinación.

• plan de proyecto: una estimación realista de tiempos y recursos permite armar un plan de trabajo fundamentado y posible, eliminando la desalentadora sensación de no terminar nunca.

• facilidad de comprensión del proyecto: la visión global del proyecto provista por la descripción de la arquitectura permite a todos los implicados conocer qué se está haciendo y para qué; la comprensión de lo que se está haciendo permite a la gente trabajar mejor. • cumplimiento: la conclusión exitosa de cada etapa, hecha posible por un plan realista, evita la frustración del atraso o el incumplimiento.

Las tareas y responsabilidades de las personas intervinientes en el proyecto irán cambiando a lo largo del mismo, o aún pueden desempeñarse en diferentes conjuntos de tareas y especialidades al mismo tiempo; el papel de las personas como trabajadores cambiará, o se desempeñarán como diferentes tipos de trabajadores. El término trabajador designa un conjunto de tareas y responsabilidades asumidas por una persona o un grupo [Jacobson2000, cap. 2].

Proyecto.

El proyecto es un elemento organizativo a través del cual se gestiona el desarrollo de software. El resultado de un proyecto es una versión de un producto. Se parte de un proyecto inicial con el cual se evalúa la viabilidad, se identifican los riesgos y se define el plan de proyecto. La construcción se realizará en una serie de iteraciones; cada iteración constituye un mini proyecto con requisitos, diseño, implementación y prueba. 3 de 5

Proceso.

Un proceso de desarrollo de software es una definición del conjunto completo de actividades necesarias para transformar los requerimientos del usuario en un producto. Un proceso es un patrón o plantilla sobre la cual se definen los proyectos. Puede decirse que un proyecto es una instancia de un proceso, una aplicación concreta a un emprendimiento particular de los principios, forma de trabajo y recomendaciones de un proceso.

Un proceso de desarrollo de software consiste en la definición del conjunto completo de actividades necesarias para convertir los requerimientos del usuario en un conjunto consistente de artefactos que conforman el producto de software, así como para convertir los cambios surgidos en los requerimientos en un nuevo conjunto consistente de artefactos de software [Jacobson2000, cap. 2].

Modelo.

Un modelo es una simplificación de la realidad. Se construyen modelos para comprender mejor el sistema en desarrollo. El modelado persigue estos objetivos:

• visualizar cómo será el sistema deseado;

• especificar la estructura o el comportamiento del sistema;

• proveer plantillas descriptivas para usar como guía en la construcción del sistema;

• documentar las decisiones adoptadas.

Se construyen modelos de los sistemas complejos porque resulta muy difícil comprender el sistema en su totalidad.

La elección de modelos tiene una profunda influencia sobre la forma de enfrentar un problema y como se llega a la solución. Es preciso elegir bien los modelos. Los mejores modelos reflejan la realidad en todos y sólo aquellos aspectos importantes para el sistema en desarrollo. Un modelo puede ser presentado en diferentes niveles de detalle, desde diferentes perspectivas, a través de un conjunto de modelos casi independientes pero coordinados entre sí [Booch1999, cap. 1].

Arquitectura.

El diseño de arquitectura de un sistema ofrece una visión global del sistema. Más formalmente, la arquitectura de un sistema de software es un conjunto de decisiones significativas acerca de la organización de ese sistema, la selección de elementos estructurales e interfaces componentes del sistema junto con su comportamiento, la composición de esos elementos estructurales en subsistemas, y el estilo que orienta esa organización. Incluye no sólo la funcionalidad (lo que hace) sino también restricciones (limitantes), compromisos sobre uso, rendimiento, comprensión, flexibilidad, reutilización, economía, tecnología y estética [Jacobson2000, cap. 2].

No es posible comprender la arquitectura de un sistema medianamente complejo si no se la expresa a través de diversas vistas complementarias:

• una vista de casos de uso para mostrar los requerimientos del sistema;

• una vista de diseño para capturar el vocabulario del dominio del problema tal como lo conocen los usuarios y del dominio de la solución tal como la imaginan los desarrolladores.

• una visión de procesos, donde se modelan los procesos e hilos de ejecución mediante los cuales el sistema realizará sus tareas.

• una vista de implementación, donde se consigna la relación entre los distintos componentes de software que colaboran entre sí para cumplir los cometidos del sistema;

• una vista de despliegue donde se muestra la distribución física de los componentes en diferentes equipos y ubicaciones.

Cada una de estas vistas comprende aspectos estructurales (estáticos, cómo es) y de comportamiento (dinámicos, cómo funciona). En conjunto, estas vistas son los “planos del software”, análogos a los planos de un edificio, un puente, una máquina o un diagrama de circuitos [Booch1999, cap. 1].

Herramientas.

Las herramientas usadas en la realización de un proyecto de desarrollo de software es el software usado para automatizar o facilitar las tareas del personal interviniente en el proyecto. Puede incluir procesadores de palabras, programas de diagramación, ambientes integrados de desarrollo o software específico para ingeniería de software (herramientas CASE, “Computer Aided Software Engineering”, ingeniería de software asistida por computador). El proceso y las herramientas están estrechamente relacionados; se eligen o construyen las herramientas de acuerdo con el proceso de desarrollo a seguir.

Referencias y lecturas recomendadas.

El contenido de este documento está basado en las fuentes citadas a continuación, cuya lectura o consulta no pretenden sustituir.

Lecturas recomendadas.

• [Larman2003] Larman, Craig. UML y patrones. Una introducción al análisis y diseño orientado a objetos y al Proceso Unificado, 2a. edición. Madrid, 2003. ISBN 8420534382.

• [Fowler1997] Fowler, Martin y Scott, Kendall. UML distilled. Applying the Standard Object Modelling Language. Addison Wesley Longman, Inc., 1997. ISBN 0201325632.

• [Pfleeger2002] PFLEEGER, SHARI LAWRENCE. Ingeniería de software, teoría y práctica, 1a. edición. Buenos Aires, Pearson educación, 2002. ISBN: 9879460715.

Referencias.

• [Jacobson2000] Jacobson, Ivar; Booch, Grady; Rumbaugh, James. El proceso unificado de desarrollo de software. Pearson Educación, Madrid, 2000. ISBN: 8478290362.

• [Booch1999] Booch, Grady; Jacobson, Ivar; Rumbaugh, James. El lenguaje unificado de modelado. Pearson Educación, Madrid, 2000. ISBN: 8478290281.

Errores, omisiones, comentarios: Víctor González Barbone, vagonbar en fing.edu.uy Desarrollo de Software para Ingeniería Eléctrica Curso 2006 Página del curso:

http://iie.fing.edu.uy/ense/asign/desasoft Instituto de Ingeniería Eléctrica Facultad de Ingeniería UDELAR, Montevideo, Uruguay.


Mis sitios nuevos:
Emprendedores
Politica de Privacidad