• Author / Uploaded
• todotresde

Citation preview

Unidad 1: Ingeniería de Software 1.1

Ingeniería de Software

1.1.1 Concepto de Ingeniería de Software La Ingeniería de software es una disciplina, como expresa su nombre, de Ingeniería, la cual comprende todos los aspectos de la producción de software, es decir, desde las etapas iniciales de la especificación del sistema, lo que debe hacer, hasta su entrega y mantenimiento. El mantenimiento del software se realiza después de haber sido entregado al cliente y éste lo está utilizando. Otra definición que podemos plantear es la de D. L. Parnas (Programming Methodology, 4th Informatik Symposium, 1974), quien definió a la ingeniería en software como “multi-person construction of multi-version software”, su traducción sería “varias personas en la construcción de multiversión de software”. Es lógico pensar que el software que se produce funciona correctamente y satisface las necesidades del cliente, para que esto sea así es necesario que se cumplan varias etapas del desarrollo del mismo y los recursos humanos involucrados deben ser capaces de hacerlo cumplir. Para ello resulta necesario conocer conceptos fundamentales que hacen a la Ingeniería de software. Los ingenieros son los encargados de hacer que los software funcionen, para ello aplican teorías, métodos y herramientas de forma selectiva, tratando de descubrir soluciones a los problemas existentes o futuros, aún cuando no existan teorías o métodos aplicables a la resolución de dichos problemas. Todo proyecto tiene restricciones de tiempo, organizacionales y de presupuesto, por lo que el ingeniero debe tener en cuenta en la resolución de los problemas estas restricciones. Son entonces los encargados de llevar el proyecto adelante y que éste sea con éxito, para ello deberá realizar la gestión integral del proyecto, el desarrollo de herramientas, teorías y/o métodos que apoyen la producción de software. El trabajo del ingeniero debe ser sistémico y organizado, como lo determina la Ingeniería, si quiere obtener un software de alta calidad, pero a su vez necesita ser flexible a los cambios y tener un enfoque más informal y creativo para algunos casos que lo requieran. Para entender mejor la definición primero tiene que conocer el concepto de software. ¿Qué es software? El software es más que programas; tiene una característica muy importante que hay que atender: es un sistema. Antes de mirar más profundamente el proceso de creación de software, será útil explorar algunos aspectos del software mismo. Como dice el viejo adagio: “para derrotar a tu enemigo hay que conocerlo”. (Freeman). Lo importante es definir qué es software, cómo se piensa en él y qué papel cuenta en un contexto mayor. Si nuestro concepto de software es sólo desde el punto de vista de una computadora, será

Materia: Ingeniería de Software Profesora: Lic. Adriana Pérez

-1-

sólo programas, líneas de código que se producen en un determinado tiempo; esto es un error, ya que nos llevará a tener montañas de códigos que no se integrarán como sistema y que no lograrán satisfacer las necesidades del cliente, aunque técnicamente sean correctos. Software es un conjunto de programas que se ejecutan en un ordenador y la documentación asociada, de este modo los “productos de software” pueden desarrollarse para un cliente en particular o para un mercado particular o general. Existen tres tipos básicos de software:  System software  Utilitarios  Software de Aplicación Cualquiera sea el tipo de software, requiere de información que lo acompañe para su correcto entendimiento y uso para luego mantenerlo, caso contrario lo llevará a tener errores que no podrán ser salvados en el tiempo. El software tiene características que es importante conocer, veamos algunas de ellas. Su Naturaleza y Cualidades:  El software es fácilmente modificable, lo que implica que el código responde a una lógica y normalmente es de quien lo construye, por lo que si cambia el actor es muy posible que cambie el código.  No es tangible, como otros productos. Al ser intangible no es fácil imaginarse el tamaño o la forma del software, muchas veces se cree que realizar una aplicación o una nueva funcionalidad es algo simple, pero la mayoría de las veces implica un gran trabajo difícil de visualizar. Clasificación de las Cualidades:  Externas versus internas, se pueden considerar como externas la usabilidad del software por los usuarios, mientras que la interna es técnica, la ven quienes codifican. Es posible que un software esté muy bien diseñado y codificado pero al usuario le resulte difícil de entender y usar, o totalmente al revés, el usuario solicita algo que mientras lo entienda y sea fácil de usar no importa si técnicamente está bien realizado. Lo óptimo es que cumpla con ambas condiciones.  Cualidades de producto y proceso. El proceso de desarrollo de software dará un producto final que se espera que sea de calidad y satisfaga las necesidades del cliente, para ello el proyecto deberá ser exitoso y el proceso de software también. Cualidades Representativas:  Correctitud, confiabilidad y robustez o Correctitud: un programa es “funcionalmente correcto” si se comporta acorde a la especificación de la función que debería proveer. o Confiabilidad: un programa es confiable si el usuario puede depender de él. El software no debe causar daño físico o económico si falla. o Robustez: un programa es robusto si se comporta “razonablemente”, aún en situaciones que no fueron anticipadas en los requerimientos.  Performance: afecta la usabilidad de un sistema  Confiabilidad: El software no debería malgastar el uso de los recursos del sistema.  Amigabilidad: esto ocurre si los seres humanos lo encuentran fácil de usar  Verificabilidad: esto ocurre si sus propiedades pueden ser verificadas fácilmente

Materia: Ingeniería de Software Profesora: Lic. Adriana Pérez

-2-



      

Mantenibilidad: se refiere a modificaciones que se le hacen al software después de su lanzamiento inicial. Es software debería evolucionar acompañando el cambio que puede ser: o Reparativo. o Evolutivo Reusabilidad: software o componentes de él que permiten evolucionar a otra versión con mínimas modificaciones Portabilidad: si corre en diferentes ambientes, plataformas, entendiendo por plataforma al hardware y sistema operativo. Comprensible: si es fácil de entender por otros Interoperabilidad: si el software es capaz de convivir con otros Productividad: la eficiencia puesta en el proceso Entrega en fecha: entregar un producto en el tiempo previsto Visibilidad: si todos los pasos y su actual estado están documentados claramente.

Si el software es lo que se entrega al cliente, entonces se puede considerar un producto. Software como producto Desde los años ‟60 se comenzó a separar el concepto de software de hardware, fue entonces que comenzó a constituirse como producto. El software es tanto un producto como un objeto técnico, esto es: conocimiento empaquetado. Software como conocimiento Si los programas que se entregan al finalizar el proceso de desarrollo contienen conocimiento, entonces sus primeras versiones también contienen conocimiento, que en el punto de vista de vista de software sólo como programas ejecutables lo perdemos. No perder este conocimiento es uno de los pilares de la característica de “reusabilidad” del software. Este conocimiento es de las personas que intervienen en el proyecto, cada uno aporta algo a un todo, si este conocimiento no queda documentado se pierde en el tiempo, ya sea porque las personas se van del proyecto o por olvido. Como el software es maleable y responde a cambios, es importante pensarlo de otra forma, un cambio en el software atiende a un cambio de diseño más que de código. El proceso de producción de software atiende más al diseño e implementación que a la manufactura del mismo. Las visiones del producto de software atienden a distintos actores, cada uno espera algo distinto de él:  Usuario: que sea confiable, eficiente y fácil de usar.  Productor: que sea verificable, mantenible, portable y extensible.  Administrador del proyecto: productivo y fácil de controlar. Es por ello que el software que se entrega es un producto compuesto por programas ejecutables y documentación que lo acompaña. Veamos las características que tiene el producto de software:

Materia: Ingeniería de Software Profesora: Lic. Adriana Pérez

-3-

   

Es un software más sofisticado Es usado por personas distintas al desarrollador Es extensivamente testeado antes de ser liberado Su costo de desarrollo es 3 veces mayor al de un programa

Recordemos también el concepto y alguitas características de sistema:  Grupo de programas que trabajan juntos  Su desarrollo es complicado debido a la complejidad de sus interfaces entre los componentes  Integración  Su desarrollo cuesta 3 veces lo que cuesta desarrollar un programa Si unimos todos los eslabones de esta cadena de conceptos, podemos identificar qué es un “Sistema producto”:  Tiene el “pulido” de un programa  Múltiples partes de un sistema  Su costo de desarrollo cuesta alrededor de 9 veces más que un simple programa Otras de las diferencias importantes de entender son las relacionadas con la Ingeniería en sistemas. ¿Cual es la diferencia entre Ingeniería en Software y el Profesional en Sistemas? La Ingeniería en Sistema se ocupa de todos los aspectos del desarrollo de un sistema (aspectos humanos, de software, de hardware, de procesos, otros), mientras que la Ingeniería en Software es parte de ese proceso. Así la Ingeniería de software debe cumplir con los siguientes principios, que son indispensables para lograr un producto final de calidad:  Rigor y formalidad  Separación de intereses  Modularidad  Abstracción  Anticipación al cambio  Generalidad  Incrementabilidad El Rol del Ingeniero de Software. A veces se confunden los roles con los ingenieros de otras disciplinas; si bien tienen algunas en común, es bueno identificar aquellas que hacen específicamente al rol del Ingeniero en Software:  Buen programador. Es necesario que reúna las características de un buen programador, no es indispensable que sea en un lenguaje determinado, sino que haya adquirido las herramientas necesarias para resolver un problema a través de la programación.  Enfoques de diseño. Debe ser capaz de realizar buenos diseños de software.  Niveles de abstracción, haber adquirido un nivel de abstracción que le permita ver la solución de forma intangible.  Saber modelar. Realizar un modelo conceptual es indispensable para luego poder plasmarlo en el producto concreto.  Habilidades de comunicación interpersonal. La comunicación y las buenas relaciones con los integrantes del equipo son fundamentales para lograr un ambiente de trabajo productivo.

Materia: Ingeniería de Software Profesora: Lic. Adriana Pérez

-4-

 Ser capaz de planificar su trabajo y el de otros. Con desorganización no se produce software de calidad, por lo que la planificación de las actividades es fundamental. Como en todas las profesiones el Ingeniero de software de tener presente la ética y la responsabilidad profesional:  Responsabilidades que van más allá de la simple aplicación de habilidades técnicas.  Los Ingenieros en Software se deben comportar en forma honesta y éticamente responsables para ser respetados como profesionales.  La conducta ética es más que el simple cumplimiento de la ley. Temas de la responsabilidad profesional:  Confidencialidad  Competencia  Derechos de propiedad Intelectual  Malas practicas Algunos dilemas éticos que se pueden presentar son:  Desacuerdo con las políticas de la dirección.  Su empleador actúa en forma no ética y libera software de características críticas sin terminar las fases de testeo.  Participación en el desarrollo de software militar y armamento nuclear

1.1.2 Problemas de la ingeniería de Software. La crisis de desarrollo de software Las economías de TODAS las naciones desarrolladas son dependientes del software, si atendemos esta afirmación el software debe garantizar buenos negocios y nunca pérdida de dinero. La fabricación industrial, comercial y del sistema financiero está totalmente informatizada, por lo que producir software costeable es fundamental para el funcionamiento de la economía nacional e internacional. Existieron factores que influyeron para que el software no fuese costeable:  La evolución de la tecnología.  El proceso de desarrollo  La administración de proyectos  El mantenimiento del software La noción de Ingeniería del software fue introducida en 1968 en una conferencia para discutir lo que se llamó “Crisis del software”, resultado de la introducción de nuevas tecnologías en hardware basadas en circuitos integrados. Así, el software que se producía implicaba nuevos conocimientos y nuevos lenguajes de programación con software de magnitudes mayores y más complejos que los sistemas previos. Durante años el desarrollo de Software ha sido un arte, una tarea artesanal basada en el conocimiento de los desarrolladores de código y del cliente. Se suponía que el cliente sabía lo que necesitaba y lo solicitaba, generalmente lo hacía directamente a los desarrolladores y en el mejor de los casos al Gerente del área de Investigación y Desarrollo.

Materia: Ingeniería de Software Profesora: Lic. Adriana Pérez

-5-

Este tipo de práctica sólo llevó a vivir “La crisis del software”, clientes insatisfechos y pérdida de dinero para los dueños de las consultoras. Esta forma de trabajar tiene un alto riesgo, cuando se carece de profesionalidad y calidad en el producto final. Para revertir esta situación en un principio se incorporó una persona como intermediario entre el cliente y el desarrollador, el “Comercial” quien tenía la función de comunicar el requerimiento del cliente a desarrollo, pero es evidente que entre lo que el cliente ve, necesita, piensa que ve o piensa que necesita y lo que recepta el intermediario hay diferencias, de más está decir que la diferencia se amplía cuando se transmite, lo que lleva inevitablemente a no cubrir las expectativas del cliente. ¿Cuánto tiempo y dinero se pierde cada vez que se trata de resolver un error? Se cobra por desarrollar un software y por mantenerlo pero no para solucionarlo, donde las horas de recodificación son a cargo del dueño de la consultora de software. Por otro lado: ¿Quién prueba el software? ¿El cliente? La respuesta debería ser no, ya que al cliente le debe llegar el producto final funcionando correctamente, para lo cual se agrega el rol de Tester interno en la empresa. Con estas medidas podríamos solucionar en parte los problemas, es común escuchar expresiones tales como, “El problema es el código”, “los que no saben son los desarrolladores”, pero la verdad no es ésa. Está comprobado que el mayor problema está en la captura del requerimiento, tarea que requiere de conocimiento de negocio, de análisis y diseño de interfaz gráfica, porque es la persona encargada de interpretar correctamente el problema, transmitirlo y documentarlo con la garantía de que éste responde al requerimiento del cliente. Tan importante es esta tarea que hoy es tratada como “Ingeniería de Requerimiento”. La experiencia previa en la construcción de estos sistemas mostró que un enfoque informal para el desarrollo del software no era bueno. Los grandes proyectos no se entregaban en término con retrasos de años, costaban mucho más que lo presupuestado, totalmente irrealizables, difíciles de mantener y con pobre desempeño. Mientras el hardware mostraba avances tecnológicos que lo hacían superior y bajaban los costos, el software sufría una evolución totalmente al revés. Estaba claro que se necesitaba revertir esta situación y para ello había que fijar los lineamientos para que la producción de software se convirtiera en una Ingeniería, nuevas técnicas y métodos para controlar la complejidad inherente a los grandes sistemas. Tomamos la definición de Ingeniería de software de Fairley (“Ingeniería de Software”, 1987): “La Ingeniería de Software es la disciplina tecnológica y de administración que se ocupa de la producción y evolución sistemática de productos de software que son desarrollados y modificados dentro de los tiempos y costos estimados”. En estos tiempos donde las empresas necesitan ser competitivas, responder al dinamismo de los cambios en forma eficiente es sumamente importante, para ello se define un correcto proceso de software, donde el cliente está al inicio y al final, desde el requerimiento hasta la entrega,

Materia: Ingeniería de Software Profesora: Lic. Adriana Pérez

-6-

estableciendo las etapas mínimas que garantizan un producto de calidad y la satisfacción del cliente. Sabemos que no hay un “ideal” de la Ingeniería de software, debido a la gran diversidad de tipos de sistemas y organizaciones que los usan, por lo que necesitamos tener diversos enfoques para el desarrollo de software, no obstante, las nociones fundamentales de procesos y organización del sistema constituyen la base de todas las técnicas y, a su vez, son la esencia de la Ingeniería de software. El desafío es ponerse en movimiento hacia el cambio en post de la mejora continua, acompañando al crecimiento profesional y económico de todos.

1.1.3 Diferencias entre Ingeniería de Software y Ciencia de la Computación. Otra diferencia importante a destacar es el concepto de “Ciencia de la computación” con el de “ingeniería de software”. La Ciencia de la computación comprende la teoría y fundamentos, mientras que la ingeniería de software comprende las formas prácticas para desarrollar y entregar un software requerido y útil para el cliente. La ingeniería de software, al atender el proceso de desarrollo de software, se diferencia de la “ingeniería en sistemas”, ya que esta última se refiere a todos los aspectos del desarrollo de sistemas informáticos, incluye hardware, software e ingeniería de procesos. Concepto de sistema El término Sistema es utilizado universalmente, aplicado a todas las disciplinas, en el caso de la computación hablamos de Sistemas Operativos, sistemas informáticos, sistema educativo, sistemas contables y financieros, entre otros. Si bien difieren unos de otros, todos entienden que un sistema es más que una suma de partes. Definición de Sommerville: “Un sistema es una colección de componentes interrelacionados que trabajan conjuntamente para cumplir algún objetivo”. Esta definición es tan amplia que puede incluir a sistemas tan simples como puede ser un velador o un bolígrafo, hasta los sistemas muy complejos como podría ser un sistema de aviación o de seguridad aérea, entre muchos otros casos posibles que incluyen diversas tecnologías, hardware y software. Los sistemas informáticos que incluyen software se dividen en dos categorías:  Sistemas técnicos informáticos. Estos sistemas incluyen hardware y software pero no incluyen procesos ni procedimientos. Como ejemplo de estos sistemas están los electrodomésticos como lavarropas automáticos, microondas, como también los televisores, los teléfonos móviles y las computadoras con sus componentes internos. Los sistemas como herramientas informáticas tales como los procesadores de texto o las planillas de cálculo también entran en esta categoría.  Sistemas socio-técnicos. Estos sistemas comprenden uno o más sistemas técnicos pero además incluyen el conocimiento necesario para su uso para lograr su funcionalidad.

Materia: Ingeniería de Software Profesora: Lic. Adriana Pérez

-7-

Significa que estos sistemas incluyen los procesos y procedimientos operativos, las personas que lo operan, las reglas internas, de negocio, como también las reglas externas que rigen su uso y funcionamiento. Como ejemplo podemos citar un sistema de facturación que incluye los procesos necesarios, las reglas impositivas que lo rigen y las reglas internas de la organización. Entre las características fundamentales de los sistemas socio-técnicos encontramos las siguientes:  Tienen propiedades emergentes, propiedades del sistema como un todo más que asociadas con las partes del sistema, que dependen tanto de los componentes como de las relaciones entre ellos. Estas propiedades pueden ser evaluadas luego de ser implementado el sistema.  Por lo general no son sistemas determinísticos. No siempre producen la misma salida con una entrada específica, ya que el comportamiento del sistema depende de operadores humanos, de su uso y tratamiento. Además, se debe contemplar la posibilidad de que el sistema pueda proporcionar nuevas relaciones entre sus componentes.  El grado de apoyo a los objetivos organizacionales no depende solamente del sistema. La concreción de los objetivos dependen de la estabilidad de los mismos, conflictos entre cómo son planteados e interpretados por las personas, así dependiendo de las personas un sistema exitoso puede convertirse en un fracaso y no utilizarlo. Teniendo en cuenta lo expresado anteriormente, las propiedades emergentes de un sistema se dan en conjunto cuando el sistema ha sido implementado completamente e interactúan sus componentes de forma integral. Estas propiedades emergentes pueden considerarse como funcionales y no funcionales:  Funcionales, cuando todos los componentes del sistemas trabajan conjuntamente para lograr un objetivo común.  No funcionales, se refieren al comportamiento de los sistemas en su entorno operativo. Entre ellas encontramos, la fiabilidad, el rendimiento, la seguridad y la protección. Entre estas propiedades no funcionales, la fiabilidad es quizás la más importante ya que se puede aplicar a los cinco componentes principales de los sistemas socio-técnicos, fiabilidad del hardware, del software, de las personas que lo operan, de los procesos definidos y de los datos utilizados. ¿Cuáles son las diferencias entre el proceso de la ingeniería de sistemas y el proceso de desarrollo de software? 

El desarrollo de sistemas tiene un alcance limitado para rehacer el trabajo. Cuando se han tomado las decisiones en la Ingeniería del sistema se han planteado las etapas y las acciones de cada una, donde cada etapa verifica con la anterior si el camino es el correcto, por lo que pensar en cambios a la mitad del proceso traería costos y riesgos muy grandes. Las etapas que se identifican en el proceso de Ingeniería de sistemas son las siguientes: o Definición de requerimientos o Diseño del sistema o Desarrollo del subsistema o Integración del sistema o Instalación del sistema o Evolución del sistema o Desmantelamiento del sistema

Materia: Ingeniería de Software Profesora: Lic. Adriana Pérez

-8-



Alcance interdisciplinario. En la Ingeniería de sistemas se conjugan muchas Ingenierías, como puede ser la electrónica con la mecánica y la de software. El proceso de desarrollo de software involucra:  procesos de negocio,  procedimientos operativos que se deben tener en cuenta a la hora de diseñar los procesos informatizados,  las necesidades del cliente que se traducen en requerimientos funcionales para el software,  los requerimientos no funcionales, que hacen a la forma de presentación o performance del software,  los requerimientos candidatos, que son las funcionalidades que no se informatizarán en este momento, pero que se tendrán en cuenta para el futuro,  las etapas de captura de requerimiento, análisis, diseño, codificación, prueba, instalación y mantenimiento.  Las personas, cada una en el rol que se le requiere, tanto las internas como grupo de trabajo del proceso de desarrollo como las externas como clientes y usuarios.  Los cambios organizacionales, de procesos, de personas, tanto internos como externos.

1.2

Ciclo de Vida

1.2.1 Ciclo de Vida: Conceptos de Proceso de Desarrollo de Software. Proceso de desarrollo de software Se entiende por proceso de software al conjunto estructurado de actividades para desarrollar un sistema de software. Estas actividades varían dependiendo de la organización y el tipo de sistema que debe desarrollarse. Debe ser explícitamente modelado si va a ser administrado.

Person as Requerimientos Ideas Tiempo

Materiales

Energía

Equipamiento

Actividades

Procedimiento s Productos y servicios

Características del Proceso  Comprensibilidad: Si el proceso está definido y es comprensible.  Visibilidad: Si el progreso del proceso es visible externamente.  Suportabilidad: Puede soportarse con herramientas CASE (Computer Aided Software Engineering, en castellano Ingeniería de Software Asistida por Computadora)

Materia: Ingeniería de Software Profesora: Lic. Adriana Pérez

-9-

 Aceptabilidad: Si el proceso es aceptable por los que deben utilizarlo  Confiabilidad: Si los errores del proceso son descubiertos antes que resulten errores del producto.  Robustez: Puede el proceso continuar frente a problemas inesperados  Mantenibilidad: Puede el proceso evolucionar para alcanzar las necesidades de cambio, organizacionales.  Rapidez: Cuán rápido puede producir el sistema. Si bien no se puede tratar al proceso de software como una serie de actividades preestablecidas e inmodificables, ya que cada producto de software final es único y atiende a características de organización, cliente, proyecto y factores internos y externos, se identifican 4 actividades fundamentales para todos los procesos, que son:    

Especificación del software. Se trata de definir las funcionalidades que deberá tener el software y las restricciones en su operación. Diseño e implementación del software. Primero se diseña la solución y luego se produce el software que cumpla con la especificación. Validación del software. Se valida con el cliente la funcionalidad del software asegurando que realiza lo que el cliente desea y necesita. Evolución del software. Las organizaciones son sistemas dinámicos que se acomodan a los cambios, el software debe evolucionar para cubrir las necesidades de cambio que plantea el cliente.

Cada empresa adopta el proceso con las etapas que considera mejor según el equipo de gente que dispone, siempre teniendo en cuenta estas 4 actividades fundamentales. Todo proceso de construcción de software lleva un tiempo desde que es requerido por el cliente hasta que se finaliza y se entrega el producto final, luego viene el mantenimiento del mismo. Este tiempo es el “Ciclo de Vida”. Como ciclo de vida, tiene un comienzo y puede tener un fin, de acuerdo al límite que se determine, en ese tiempo es que se dan las actividades fundamentales que vimos anteriormente. Como determinamos que no existe un proceso ideal, es que este proceso ha tomado distintas formas en el tiempo, de acuerdo a la respuesta obtenida y la retroalimentación que se realiza del mismo. Existen modelos de procesos de desarrollo de software que han evolucionado en el tiempo y se identifican con las características de la realidad de cada momento. Dentro de una organización pueden existir sistemas que están funcionando y que quizás no cumplan con todas las necesidades del cliente, pero que no se pueden dejar de usar. Las nuevas funcionalidades tendrán que tener en cuenta estos sistemas para su integración. Estos sistemas se consideran “Sistemas heredados”, en algunos casos no se pueden modificar, sólo utilizar, en otros casos se puede modificar, pero si no poseen documentación es una tarea muy compleja. Las nuevas funcionalidades o los sistemas completos se pueden desarrollar o adquirir, o sea que en una organización pueden coexistir sistemas heredados, sistemas propios y sistemas adquiridos; es necesaria la integración de las partes para alcanzar la funcionalidad, el objetivo y el trabajo como sistema.

Materia: Ingeniería de Software Profesora: Lic. Adriana Pérez

- 10 -

1.2.2 Ciclo de Vida: Modelos ¿Qué es un modelo de procesos del software? Comencemos con la definición de modelo según la Real Academia Española: Modelo: Esquema teórico, generalmente en forma matemática, de un sistema o de una realidad compleja, como la evolución económica de un país, que se elabora para facilitar su comprensión y el estudio de su comportamiento. Esta definición puede aplicarse al proceso de desarrollo de software; el modelo se plantea teórico, para facilitar su comprensión y el estudio de su comportamiento. Definición de modelo de procesos de software planteado por SOMMERVILLE, IAN (“Ingeniería del Software”, pág. 25): “Un modelo de procesos es una descripción simplificada de un proceso del software que presenta una visión de ese proceso.” Esta definición la podemos interpretar como: La serie de pasos a través de los cuales el producto progresa, teniendo en cuenta las personas involucradas en la ingeniería del software. Un ciclo de vida de software es una representación de un proceso. Representa una descripción del proceso desde una perspectiva particular. En todos los casos los modelos especifican:  Las fases de proceso. Por ejemplo: requerimientos, especificación, diseño.  El orden en el cual se llevan a cabo. ¿Cuál es la importancia de los Modelos de Ciclos de Vida? La importancia de los modelos de ciclos de vida es amplia, fundamentalmente ayudan al seguimiento del proceso, organización y planificación. Veamos algunas de ellas: 

Proveer una guía para la administración de proyecto. o ¿Cuáles de las tareas deben ser rastreadas? o ¿Qué tipo de progreso se ha realizado? o ¿Cuáles son las actividades que se deben realizar y en qué orden? o ¿Cuándo interactuamos con el cliente? o ¿Qué tenemos que tener en cuenta?

¿Cuál es la necesidad de modelos de ciclos de vida? Para tener las ventajas descriptas anteriormente son necesarios los modelos de ciclos de vida, así como conocerlos para poder elegir cuál es más conveniente utilizar, de acuerdo al caso a resolver y a la situación. 

La necesidad de modelos de ciclos de vida. o El carácter del desarrollo de software ha cambiado.  Épocas tempranas: los programadores eran los usuarios finales.  Diseños muy modestos, desconocimiento del potencial del software. o Sistemas más complejos

Materia: Ingeniería de Software Profesora: Lic. Adriana Pérez

- 11 -

 

Más funcionalidad, más sofisticación posibilidades de cometer errores. Usuarios heterogéneos.

 mayor complejidad, más

Algunos factores que ayudaron a la necesidad de contar con modelos fueron:  Normalmente, las especificaciones son incompletas y con anomalías.  Muy difusa la distinción entre especificación, diseño y manufactura.  No hay una realización física del sistema en las pruebas.  Software no se consume, el mantenimiento no significa reemplazo. Recordemos que el ciclo de vida de un proyecto comienza cuando el mismo forma parte de una idea hasta la implementación en todos los usuarios que utilizarán el sistema y que un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto de desarrollo de software. Existen muchos modelos, algunos se desprenden de otros, también depende de los autores de las distintas bibliografías. Sommerville Ian (“Ingeniería del Software”, pág. 25), plantea que “la mayoría de los modelos de procesos del software se basan en uno de los tres modelos generales o paradigmas de desarrollo de software”:   

Enfoque en cascada. Totalmente secuencial, una etapa después de terminada la anterior. Se termina, se firma y se sigue con la siguiente. Desarrollo iterativo. Entrelaza las actividades de especificación, desarrollo y validación. Parte de especificaciones muy abstractas, se refina de acuerdo a las peticiones del cliente para finalmente producir un sistema que satisfaga las necesidades de dicho cliente. Ingeniería del software basado en componentes (CBSE). Supone que las partes del sistema existen, por lo tanto, el proceso de desarrollo se enfoca en la integración de las partes más que en su desarrollo desde el principio.

1.2.3 Ciclos de vida secuenciales: El modelo en cascada Modelo en cascada Fue el primer ciclo de vida de software, definido por Winston Royce a fines del 70. Es el más básico de todos los modelos y sirve como bloque de construcción para los demás modelos de ciclo de vida, plantea una visión simple basada en el concepto que el desarrollo de software puede ser a través de una secuencia simple de fases. Cada fase tiene un conjunto de metas bien definidas y las actividades dentro de una fase contribuyen a la satisfacción de metas de esa fase o quizás a una subsecuencia de metas de la fase. Existen fases discontinuas, las cuales no se solapan. Este modelo está orientado a la documentación. El modelo de ciclo de vida cascada, captura algunos principios básicos:  Planear un proyecto antes de embarcarse en él.  Definir el comportamiento externo deseado del sistema antes de diseñar su arquitectura interna.  Documentar los resultados de cada actividad.  Diseñar un sistema antes de codificarlo.  Testear un sistema después de construirlo.

Materia: Ingeniería de Software Profesora: Lic. Adriana Pérez

- 12 -

Se realizan relevamientos de los siguientes aspectos:  Técnicos: equipamiento, capacidad técnica de recursos  Funcionales: extracción completa de los Requerimientos, el 100%.  Del Negocio: los sectores involucrados Su utilización es beneficiosa en:  productos bien definidos  con metodologías técnicas bien entendidas,  una actualización de un mantenimiento existente  el traslado de un producto a una nueva plataforma  en un equipo de trabajo sin experiencia En los primeros años tuvo mucha aceptación, luego se fueron realizando modificaciones tratando de lograr adaptarlo a las necesidades. Encontramos como ventajas sobresalientes, las siguientes:  Provee información a través del ciclo de vida y la documentación de cada fase.  Favorece el seguimiento del proceso ordenándolo, con actividades bien comprendidas pero complejas. A partir de los 90 ha sido sujeto a numerosas críticas, debido a que es restrictivo y rígido, lo cual dificulta el desarrollo de proyectos de software moderno. Algunas de sus desventajas son:  Lleva mucho tiempo finalizarlo por ser tan secuencial  No se puede comenzar hasta tener el total de los requerimientos antes de comenzar con el diseño.  Es rígido, ya que no permite volver hacia etapas anteriores para corregir errores  No es aconsejable para desarrollos cortos porque posee una excesiva cantidad de documentación

Especificación de Requerimiento

Definición

Análisis

Especific. Diseño

Diseño Implementación y Unidad de Testeo

Desarrollo

Integración

Implementación

Mantenimiento

Materia: Ingeniería de Software Profesora: Lic. Adriana Pérez

- 13 -

Debido a las desventajas del modelo, muchos modelos nuevos de ciclo de vida han sido propuestos, incluyendo modelos que pretenden desarrollar software más rápidamente, más incrementalmente, de una forma más evolutiva o precediendo el desarrollo a escala total con algún conjunto de prototipos rápidos. Desarrollo evolutivo El desarrollo evolutivo consiste en desarrollar una implementación inicial, entregada a los usuarios para sus comentarios y refinándola a través de la retroalimentación y las versiones hasta lograr el sistema adecuado. Los requerimientos son cuidadosamente examinados y sólo aquellos que son bien comprendidos son seleccionados para el primer incremento. Los desarrolladores construyen una implementación parcial del sistema que recibe sólo estos requerimientos. El cliente lo usa, basado en la retroalimentación y en los nuevos requerimientos se construye la nueva versión, así el proceso se repite indefinidamente. Note que el desarrollo evolutivo es 100% compatible con el modelo cascada. Todo lo que uno tiene que hacer es construir un subconjunto de requerimientos conocidos (incremental) y comprender que nuevos requerimientos aparecerán cuando el sistema sea desplegado o desarrollado. Las actividades de especificación, de desarrollo y validación se entrelazan en vez de separarse, con una rápida retroalimentación entre éstas. Existen 2 tipos de desarrollo evolutivo:  

Desarrollo exploratorio, donde se trabaja con el cliente para explorar sus requerimientos y entregar un sistema final, comenzando siempre por los requerimientos del sistema que se entienden mejor. El sistema crece, evoluciona con lo que el cliente va proponiendo. Prototipos desechables, en este caso se centra en los requerimientos que no están muy claros, por lo que el objetivo es comprender los requerimientos del cliente para poder desarrollar una definición mejorada del sistema.

Visto desde la ingeniería de gestión, el modelo evolutivo tiene los siguientes problemas:  Carencia de Visibilidad del Proceso  Los sistemas frecuentemente son pobremente estructurados  Puede requerirse habilidades Especiales (Ej. En lenguajes de prototipación rápida) Es factible su aplicación:  Para Sistemas interactivos de tamaño pequeño o mediano.  Para partes de sistemas grandes (Ej. Interfaces de usuario).  Para sistemas de ciclo de vida corto. Veamos el modelo representado en el siguiente gráfico.

Materia: Ingeniería de Software Profesora: Lic. Adriana Pérez

- 14 -

Ingeniería de software basada en componentes Con los avances de la programación orientada a objetos, el conocimiento de sistemas que actúan en forma similar se ha incorporado el concepto de componente reusable. Este enfoque requiere de componentes de software reutilizables (cantidad que va creciendo) y de un marco de trabajo de integración de estos. Es posible que estos componentes sean sistemas por sí mismos, subsistemas o módulos que tienen una funcionalidad específica. Veamos la gráfica de este modelo.

Especificación de Rqs.

Análisis de componentes

Modificación de Rqs.

Diseño de sistemas con reutilización

Desarrollo e integración

Validación del sistema

Si bien las etapas de especificación de requerimientos y la de validación son similares a otros procesos, las etapas intermedias son diferentes. Desarrollemos estas etapas intermedias: Análisis de componentes: teniendo la especificación de requerimientos se buscan los componentes necesarios que cumplan con toda la funcionalidad o con parte de ella. En este caso serán modificados, llevándolos al punto más general posible, para que se constituyan en librerías de componentes capaces de ser reutilizados en más de un proyecto sin tener que modificarlos. Modificación de requerimientos: si los componentes encontrados para los requerimientos no son modificables, se pueden buscar soluciones alternativas, modificando en parte el requerimiento, sin que deje de cumplir con la necesidad del cliente.

Materia: Ingeniería de Software Profesora: Lic. Adriana Pérez

- 15 -

Diseño de sistemas con reutilización: esta etapa se relaciona con el marco de trabajo, son los diseñadores los que tienen en cuenta los componentes que se reutilizan para organizar el marco de trabajo que los satisfaga o bien diseñar nuevos componentes porque no se cuenta con los necesarios. Desarrollo e integración: estas etapas no son independientes, es necesaria su integración ya que es parte del desarrollo tener en cuenta los componentes que existen, los que se adquieren externamente y los que se desarrollan internamente para integrarlos en un todo. Ventajas de la ingeniería de software basada en componentes:  Reducir la cantidad de software a desarrollar  Reducir costos  Reducir riesgos.  Permite una entrega más rápida Riesgos del uso de este modelo:  Si depende totalmente de los componentes a reutilizar puede ser que el producto no cumpla con las necesidades del cliente.  Las nuevas versiones de los componentes pierden la especificidad de la organización, se plantean generales, por lo que requiere de la necesidad de relevar las reglas de negocio de cada cliente. Este modelo tiene mucho en común con el enfoque que está surgiendo en los últimos años para el desarrollo de sistemas que se basan en la integración de servicios Web. Modelo incremental Si el desarrollo de sistema es complejo y es un proyecto a largo plazo, implica que tiene asociado demasiados riesgos, como por ejemplo que no se termine, que no cumpla con las necesidades del cliente que cambiaron desde que lo solicitó, que el costo sea muy elevado, entre otros. Una forma de reducir estos riesgos es construir sólo una parte de sistema, organizando por versiones lo que se incrementa. En el modelo incremental requiere del 100% de los requerimientos al comienzo del ciclo de vida, se toman subconjuntos de requerimientos y se desarrollan en versiones siempre incrementando el producto de software. El documento de requerimientos es escrito al capturar todos los requerimientos necesarios para el sistema completo, es el que sirve de guía para los incrementos. Este modelo es compatible con el modelo cascada, no obstante el modelo incremental provee algunos beneficios significativos para los proyectos:  Construir un sistema pequeño es siempre menos riesgoso que construir un sistema grande.  Al ir desarrollando parte de las funcionalidades, es más fácil determinar si los requerimientos planeados para los niveles subsiguientes son correctos.  Si un error importante es realizado, sólo la última iteración necesita ser descartada.  Reduciendo el tiempo de desarrollo de un sistema, decrecen las probabilidades que esos requerimientos de usuarios puedan cambiar durante el desarrollo.  Si un error importante es realizado, el incremento previo puede ser usado.  Los errores de desarrollo realizados en un incremento, pueden ser arreglados antes del comienzo del próximo incremento.

Materia: Ingeniería de Software Profesora: Lic. Adriana Pérez

- 16 -

Veamos su gráfica de organización de etapas:

Requisitos

Diseño

Requisitos Diseño de Arquitectura Diseño detallado

Desarrollo

Codificación y pruebas unitarias

Pruebas de integración Pruebas de sistema Instalación y capacitación Implementación

Aceptación del cliente

Tanto el modelo de desarrollo incremental como el modelo de desarrollo evolutivo construyen una serie de grandes versiones sucesivas de un producto. La diferencia radica en el conocimiento de los requerimientos, mientras que la aproximación incremental presupone que el conjunto completo de requerimientos es conocido al comenzar, el modelo evolutivo asume que los requerimientos no son completamente conocidos al inicio del proyecto. Modelos que derivan de los anteriores Modelo de Prototipado de Requerimientos El prototipado de requerimientos tiene el propósito explícito de aprender sobre los requerimientos del sistema, para ello se crea una implementación parcial del sistema.

Materia: Ingeniería de Software Profesora: Lic. Adriana Pérez

- 17 -

Por lo general consiste en la entrega de prototipos de interfaz de usuario, construido de una manera tan rápida como sea posible. Esto es dado a los usuarios, clientes o representantes de ellos, quienes serán los que proveen la retroalimentación sobre lo que a ellos les gustó y no les gustó acerca del prototipo proporcionado. En los 90 fue usado frecuentemente, porque la especificación de requerimientos para sistemas complejos tiende a ser relativamente dificultoso de cursar. A diferencia del modelo evolutivo donde los requerimientos mejor entendidos están incorporados, un prototipo generalmente se construye con los requerimientos entendidos más pobremente. Veamos su gráfica:

Modelo Entrega por etapas Es utilizado cuando la arquitectura es conocida. Las ventajas son:  Permite correcciones en el transcurso del proyecto  Permite colocar en producción las funcionalidades de mayor peso  Obtiene un producto en forma rápida Las desventajas son:  Se debe trabajar con una planificación cuidadosa Permite independizar la administración del proyecto de la parte técnica, brindándole al usuario las funcionalidades más significativas. Se debe tener mucho cuidado porque para implementar una fase puede requerir de la finalización de otra.

Materia: Ingeniería de Software Profesora: Lic. Adriana Pérez

- 18 -

Veamos su gráfica:

1.2.4. La naturaleza iterativa de los desarrollos. Modelo Iterativo Este modelo tiene como objetivo obtener un protocolo de desarrollo común para cualquier tipo de aplicación de software, minimizando los procesos que tardan mucho tiempo, para entregar avances o compilados por módulos acompañados de su documentación facilitando la transferencia de conocimientos entre los integrantes del proyecto y del cliente. Se asemeja al modelo de desarrollo por prototipos, la diferencia es que en el modelo iterativo los prototipos son entregables y tienen versión. Veamos su gráfica:

Materia: Ingeniería de Software Profesora: Lic. Adriana Pérez

- 19 -

Modelo de espiral Cada proyecto es organizado y explotado en miniproyectos, es conveniente para modelos del ciclo meta-vida, o sea que transcurren en el tiempo. Es un modelo incremental con versiones, en cada una se respetan las etapas, se documenta y va incluyendo a los productos anteriores. Normalmente es utilizado en:  Sistemas de gran envergadura  Proyectos con un numeroso grupo de integrantes.  Problemas de Performance  Existencia de requerimientos pobres, poco entendibles  Arquitectura pobremente detallada Una vez entendido el problema, continua como un proyecto en cascada Algunas de las ventajas son:  Altos costos significan pocos riesgos  Para desarrollos rápidos  Provee más controles que los sistemas tradicionales  Se pueden „mostrar‟ avances del proyecto  Netamente confiable Las desventajas que se han manifestado son:  La administración de los riesgos  Ante un proyecto complejo, requiere una administración rigurosa (concientizada). Se deben definir hitos de control de pase de una etapa a otra  Difícil de ser construidos con tiempos predeterminados

Materia: Ingeniería de Software Profesora: Lic. Adriana Pérez

- 20 -

Veamos su gráfica:

Modelo Iterativo e incremental Se toman las características de ambos modelos, del iterativo y del incremental para lograr un modelo con mejores aplicaciones. Las ventajas, si bien son muchas y variadas, dependen del contexto en que se implemente el proceso. Algunas de ellas son:  Se divide en fases, workflows centrales e iteraciones.  Resolución de problemas de alto riesgo en menores tiempos del proyecto.  Visión de avance en el desarrollo desde las primeras etapas del desarrollo.  Obtención del feedback del usuario lo antes posible, lo que permite orientar el desarrollo al cumplimiento de sus necesidades y realizar las adaptaciones identificadas y necesarias para cumplir con los objetivos planteados.  Menor porcentaje de fallo del proyecto, mayor productividad del equipo y menor cantidad de defectos.  La complejidad del proyecto se maneja por partes.  El aprendizaje y experiencia del equipo se da iteración tras iteración, mejora exponencialmente el trabajo, aumenta la productividad y permite optimizar el proceso a corto plazo.  El trabajo iterativo deja una experiencia en el equipo que permite ir ajustando y mejorando las planificaciones, logrando menores desvíos en la duración total del proyecto.  Adoptar este modelo no presenta grandes inversiones. Si bien no se han detectado desventajas en el tiempo que lleva implementándose, es importante tener en cuenta algunos aspectos: 

Su uso no garantiza por si solo el éxito del proyecto ni de su uso.

Materia: Ingeniería de Software Profesora: Lic. Adriana Pérez

- 21 -



Existen costos ocultos en su implementación, por la necesidad de la planificación y la necesidad de medir el impacto para no fracasar en el intento.

El modelo iterativo e incremental es utilizado por metodologías modernas y es adoptado por UML (Lenguaje de modelado unificado). Su gráfica es la siguiente (fuente: Book Racional Modeler)

El gráfico del modelo iterativo e incremental presenta una tabla de dos entradas, las columnas representan las “Fases” y las filas representan los “Flujos de trabajo”. Las fases son cuatro: Inicio, Elaboración, Construcción y Transición. Los flujos de trabajo representan las actividades y son 7: Requerimientos, Análisis y Diseño, Implementación, Prueba, Administración de configuración, Administración del proyecto y Entorno. Las tres últimas etapas se toman como acompañamiento de todo el proceso de desarrollo.

1.2.5. Ventajas y desventajas de c/u de los ciclos de vida Hemos planteado hasta ahora cada modelo de ciclo de vida del proceso de desarrollo de software y las ventajas y desventajas de sus usos. Existen dos temas que son generales a todos los modelos, el costo de tiempo por etapas y los riesgos. Costo relativo a las fases Si bien cada modelo tiene su organización y tiempos por fases, hay cálculos promedios que se pueden tener en cuenta para los procesos. Veamos su representación gráfica:

Materia: Ingeniería de Software Profesora: Lic. Adriana Pérez

- 22 -

Integración Test de (8%) Mod.(7%) C od. De Módulos (5%) Mantenimiento (67%)

Diseño (6%) Especificación (5%)

Requerimientos (2%)

Gestión de Riesgos Tal vez la tarea principal del administrador es minimizar el riesgo El riesgo inherente en un activad es una medida de la incertidumbre de la salida de esa actividad. Las actividades de alto riesgo causan excesos en los costos y la planificación. El riesgo está relacionado con la calidad y cantidad de información disponible. Mientras menos información el riesgo es mayor. Problemas de riesgos en los modelos Cascada  Alto riesgo en sistemas nuevos debido a problemas de especificación y diseño.  Bajo riesgo para desarrollos bien conocidos y utilizando tecnología familiar. Evolutivos  Bajo riesgo para nuevas aplicaciones debido a que la especificación y la programación están muy relacionados  Alto riesgo debido a la carencia de visibilidad para el proceso. Transformacional  Alto riesgo debido a la necesidad de tecnología avanzada y habilidades en el personal Vista integral de los modelos Trataremos entonces en conjunto los modelos integrando las características de cada uno para lograr una visión general y particular de ellos, que ayude a la toma de decisiones a la hora de tener que elegir uno a implementar en un proyecto. Ciclo de vida

Trabaja con requerimientos pobremente entendidos Trabaja con arquitectura pobremente entendida Produce un sistema altamente confiable

Cascada Puro

Codificación y Arreglo

Espiral

Cascada Modificado

Prototipación Evolutiva

Entrega por Etapas

Diseño por Fases

Pobre

Pobre

Excelente

Justo a excelente

Excelente

Pobre

Pobre a justo

Pobre

Pobre

Excelente

Justo a excelente

Pobre a Justo

Pobre

Pobre

Excelente

Pobre

Excelente

Excelente

Justo

Excelente

Justo

Materia: Ingeniería de Software Profesora: Lic. Adriana Pérez

- 23 -

Produce sistema con sobre Excelente crecimiento

Pobre a justo

Excelente

Excelente

Excelente

Excelente

Justo a excelente

Administración de riesgos

Pobre

Pobre

Excelente

Justo

Justo

Justo

Justo a excelente

Justo

Pobre

Justo

Justo

Pobre

Justo

Excelente

Pobre

Excelente Pobre a excelente

Justo

Excelente

Justo

Justo

Justo

Justo

Excelente

Pobre

Justo Pobre a justo

Pobre

Justo

Excelente

Justo

Excelente

Justo

Justo

Justo

Pobre

Excelente

Justo a excelente

Justo

Excelente

Excelente

Justo

Excelente

Pobre

Pobre a Justo

Pobre

Justo

Pobre

Puede ajustarse a un calendario predefinido Tiene bajo perfil Permite correcciones de medio curso Provee visibilidad en el progreso (al cliente) Provee visibilidad en el progreso (al administrador) Requiere poca administración o sofisticación de desarrollo

Pobre

Resumen: Los temas tratados en este módulo tienen que ver directamente con la Ingeniería de software y su relación con la Ingeniería de sistemas y la Ciencia de la computación. Dentro de los temas de la Ingeniería de software identificamos los conceptos de software, producto, proceso de desarrollo de software, su ciclo de vida y los distintos modelos de desarrollo de software y su ciclo de vida. Tenga en cuenta los puntos clave que remarcamos a continuación (Sommerville, Ian, capítulo 1 y 3):  La Ingeniería en Software es una Ingeniería que abarca todos los aspectos de la producción de software.  Los productos de Software consisten en el desarrollo de programas y toda la documentación asociada a ellos. Los atributos esenciales son la mantenibilidad, confiabilidad, eficiencia y usabilidad.  El proceso de software consiste en actividades las cuales involucran el desarrollo de productos de software. Las actividades básicas son especificación, desarrollo, validación y evolución.  Los métodos son formas organizadas de producir software. Ellos incluyen sugerencias para el cumplimento del métodos, la notación a ser usada, las reglas de validación de modelos y guías de diseño.  Las herramientas CASE son sistemas de software los cuales son diseñados para auxiliar en actividades de rutina en el proceso de desarrollo de software. Tales como edición de diagramas, verificar la consistencia de diagramas y mantener un registro de los testeos efectuados.  Los ingenieros en Software tienen responsabilidades para con su profesión y para con la sociedad. No están simplemente involucrados en aspectos técnicos En cuanto a los sistemas y las Ingenierías puede destacar los siguientes puntos clave (Sommerville, Ian, capítulo 2):

Materia: Ingeniería de Software Profesora: Lic. Adriana Pérez

- 24 -



Los sistemas socio-técnicos incluyen hardware, software, personas y procesos, se encuentran dentro de las organizaciones y ayudan a cumplir un objetivo.



Las propiedades emergentes de un sistema son las características que actúan como un todo no por partes o componentes del sistema. Incluyen propiedades como el rendimiento, fiabilidad, usabilidad, seguridad y protección. El éxito o fracaso de un sistema socio-técnico dependen de las propiedades en la mayoría de los casos.



Factores humanos y organizacionales influyen en el funcionamiento de los sistemas sociotécnicos.



Dentro de una organización pueden existir más de un tipo de sistemas, los heredados, los propios y los adquiridos. Es posible que se planteen conflictos entre el proceso de adquisición, el proceso de desarrollo y los procesos operativos internos.



Los sistemas heredados son sistemas socio-técnicos.

En cuanto al proceso de software puede destacar lo siguiente: 

Proceso de Software o Un conjunto coherente de actividades para especificar, diseñar, implementar y testear un sistema de software.  Modelos de Ciclo de Vida o Cascada demasiado inflexible  Orientado a documentos o Modelos evolutivos y prototipos  Dependen de las decisiones tomadas antes del entendimiento del problema o Una buena solución es integrar protipado rápido y cascada

Puntos clave a tener en cuenta, Sommerville, Ian, (capítulo 4 – temas 4.1 y 4.2):     

Los procesos de software incluyen las actividades relacionadas con la producción de un sistema de software. Los modelos del proceso del software son representaciones abstractas de estos procesos. Todos los procesos del software incluyen las etapas de especificación, diseño, implementación, validación y evolución del software. Los modelos genéricos del proceso describen la organización de los procesos del software, como son el modelo en cascada, los evolutivos y la Ingeniería basada en componentes. Los modelos de iteración presentan el proceso de software como un ciclo de actividades. El modelo en espiral, es uno de los más utilizados. El modelo iterativo e incremental incluye las mejores prácticas del modelo iterativo y del modelo incremental.

Materia: Ingeniería de Software Profesora: Lic. Adriana Pérez

- 25 -

Scientific American, noviembre, 1994 LA CRISIS CRÓNICA DE LA PROGRAMACIÓN W. Wayt Gibbs1 A pesar de 50 años de progresos, a la industria del software le faltan años -quizás décadas- para convertirse en la disciplina de ingeniería madura que la sociedad de la información requiere. El nuevo aeropuerto internacional de Denver, en los EE.UU., iba a ser la maravilla de la ingeniería moderna, el orgullo de la región. Su enorme tamaño, como diez veces el londinense Heathrow, permite el aterrizaje simultáneo de tres jets, incluso con mal tiempo. Por colosales que sean sus dimensiones, aun es mas impresionante el sistema subterráneo de traslado de equipajes con que cuenta. 4.000 “telecarros” independientes, lanzados a toda velocidad por 33 kilómetros de vía férrea, transportan y distribuyen los equipajes entre lo mostradores, las puerta de acceso y las áreas para retirar de 20 líneas aérea distintas. Un sistema nervioso central 100 computadores conectados entre sí y a 5.000 ojos eléctricos, a 400 receptores de radio y a 56 lectores de código de barras se encarga de orquestar la llegada segura y a tiempo de cada maleta y de cada bolsa e esquí2. Eso, al menos, era lo previsto. Este Gulliver ha estado nueve meses prisionero de los liliputienses, léase, de los errores del software que controla el sistema automático de equipajes. El aeropuerto debía “despegar” el día de Halloween3 del año pasado, pero su gran inauguración hubo de posponerse hasta diciembre, para permitir que los técnicos de la empresa BAE Automated Systems exorcizasen de espíritus malignos su sistema, que había costado 193 millones de dólares. De diciembre hubo que pasar a marzo. Marzo trocóse en mayo. En junio del presente año, las acciones del aeropuerto se cotizaban al precio del papel de embalar y el presupuesto de sus promotores sufría una hemorragia de tinta roja que alcanzaba 1,1 millones de dólares diarios en intereses y gastos operativos, viéndose obligados a admitir que no podían predecir en qué momento el sistema de equipajes adquiriría la estabilidad necesaria para poder abrir el aeropuerto. Para los desarrolladores de software más veteranos, lo único inusual del desastre de Denver es su notoriedad. Hay estudios que señalan que por cada seis nuevos sistemas de software de gran tamaño que entran en servicio, otros dos quedan cancelados. Los proyectos de desarrollo de software de tamaño medio suelen consumir vez y media el tiempo previsto, situación que empeora en los grandes. Y alrededor de tres cuartas partes de todos los sistemas de gran tamaño son “fracasos operativos”, que no funcionan como se quería o no se utilizan para nada. El arte de la programación ha requerido 50 años de incesante perfeccionamiento para alcanzar este estadio. Al cumplir los 25, las dificultades que planteaba la construcción de software grande cobraron tanta importancia que en el otoño4 de 1968 el Comité de Ciencias de la OTAN convocó a un grupo de unas 50 personas, formado por programadores de primera categoría, científicos de la computación y empresarios, para que trazasen un rumbo que permitiera salir de lo que se ha dado en denominar “la crisis del software”.

Aunque no fueron capaces de elaborar una ruta que guiase la nave hacia tierra firme, sí acuñaron un nombre para esa lejana meta: ingeniería de software, ahora definida formalmente como “la aplicación de métodos sistemáticos, disciplinados y cuantificables al desarrollo, funcionamiento y mantenimiento del software”. Otro cuarto de siglo después, la ingeniería de software sigue siendo una aspiración. La mayor parte del código de computadoras se confecciona a mano por artesanos que utilizan lenguajes de programación bastante burdos técnicas que ni se miden ni pueden repetirse con consistencia. Para el profesor universitario Brad J. Cox “Es algo así como la fabricación de arcabuces antes de Eli Whitney”5. Dice Brad J. Cox, un profesor de la Universidad George Mason, “Antes de la revolución industrial no existían métodos especializados de manufactura de productos, lo que entrañaba un máximo de destreza artesanal y un mínimo de intercambiabilidad. Si queremos vencer esta crisis del software ha de acabarse con el secretismo y con los métodos preindustriales, en los que cada programador ha de construirlo todo desde cero”. Pero hay esperanzas. La intuición va cediendo paso lentamente al análisis y los programadores comienzan a utilizar medidas cuantitativas de la calidad del software que producen para mejorar la forma en que los producen. Los fundamentos matemáticos de la programación se están consolidando merced a la investigación de métodos para la expresión algebraica de los diseños de programas, lo que ayuda a evitar la comisión de errores graves. Los académicos de ciencias de la computación empiezan a tratar de remediar su fracaso en la generación de profesionales de software competentes. Y, lo que quizás es más importante, muchas personas de la industria centran su atención hacia la invención de las tecnológicas y estructuras mercantiles necesarias para soportar las partes del software que sean intercambiables y reutilizables. “Lamentablemente, la industria no aplica uniformemente lo que es reconocido como mejor práctica”, lamenta Larry E. Druffel, director de Software Engineering Institute de la Universidad Carnegie Mellon. De hecho, una innovación que genera la investigación requiere 18 años en abrirse paso hasta el repertorio de técnicas standard de programación. es posible que la combinación de esfuerzos de la universidad, las empresas y la administración pública logren elevar el desarrollo de software hasta el nivel de una disciplina ingenieril propia de la era industrial en este decenio. Si no se consigue, la alocada carrera de la sociedad hacia la era de la información se tornará, en el mejor de los casos, espasmódica e impredecible. Arenas movedizas “A lo largo de los próximos años presenciaremos cambios enormes [en el uso de los computadores] que en comparación harán que la revolución inicial causada por el ordenador personal resulte insignificante”, concluían el pasado mes de abril veintidós especialistas en el desarrollo de software, procedentes de la universidad, de las empresas y de los laboratorios de investigación. Estos expertos se reunieron en Hedson Parkn un lugar cerca de Londres para conmemorar la conferencia de la OTAN y para considerar las

direcciones del software en el futuro. “En 1968 sabíamos lo que queríamos construir, pero no podíamos hacerlo”, rememora Cliff Jones, profesor de la universidad de Manchester. “Hoy pisamos arenas movedizas.” Las bases en que se asientan las prácticas tradicionales de programación son erosionadas rápidamente conforme los ingenieros de hardware van lanzando equipos cada vez más rápidos, más pequeños y más baratos. Muchos de los supuestos fundamentales de los programadores (por ejemplo, su aceptación de que sus productos siempre tendrán defectos) deben de cambiar en consecuencia. Como indica la profesora Mary S. Shaw, de Carnegie Mellon, “cuando los interruptores de la luz incorporen computadoras es preciso que el software funcione la primera vez, porque no habrá posibilidades de revisarla”. “La cantidad de código instalada en la mayoría de los productos de consumo se está duplicando cada dos años”, según Remi H. Bourgonjon, director de tecnología de software del Philips Research Laboratory, en Eindhoven. Un televisor actual puede incorporar hasta 500 Kb de software y una afeitadora eléctrica, 2 Kb. Las transmisiones de los nuevos automóviles de General Motors ejecutan de 30.000 líneas de código de computadora. Lograr que el software funcione bien la primera vez les resulta difícil incluso a quienes procurar conseguirlo. El Departamento de Defensa de los Estados Unidos (DoD) aplica normas de ensayo muy estrictas- y costosas- para garantizar la confiabilidad de software del que depende una misión. Esos standards fueron las utilizados en la certificación de Clementine, un satélite que el DoD junto con la NASA, querían situar en órbita lunar la primavera pasada. Un aspecto principal de la misión consistía en ensayar software de selección de blanco, aptos para ser utilizados algún día en un sistema defensivo antimisiles, instalado en el espacio. Pero cuando se hizo girar al satélite para que situara a la Luna en su punto de mira, un bug del programa provocó que, en lugar de lo solicitado, la nave mantuviera ininterrumpidamente encendidos sus motores de maniobra durante 11 minutos. El satélite, agotado su combustible y girando alocadamente sobre sí, mismo no pudo efectuar el encuentro previsto con el asteroide Geographos. La detección de errores en sistemas de tiempo real, como el Clementine, resulta de una dificultad diabólica porque, lo mismo que pasa con ese ruidito sospechoso del motor de nuestro coche, sólo suelen manifestarse en circunstancias muy determinadas [véase “Los riesgos de la programación”, por Bev Littlewood y Lorenzo Strigini; INVESTIGACIÓN Y CIENCIA, enero de 1993]. “No está claro que los métodos utilizados actualmente para la producción de software en los que la seguridad tiene importancia decisiva -caso de los reactores nucleares o de los automóviles- evolucionen y se amplíen en la medida necesaria para satisfacer nuestras expectativas futuras”, advertía Gilles Kahn, director científico del laboratorio de investigación INRIA de Francia, en la reunión de Hedson Park. “Me parece, por el contrario, que en el caso de estos sistemas estamos en un punto de quiebre.” La software sufre también las presiones de la inexorablemente creciente demanda de “sistemas distribuidos”, esto es, programas que operen conjuntamente en muchos computadores integrados en una red. Las empresas están volcando recursos a manos llenas en sistemas de información distribuidos, que confían en poder utilizar como armas

estratégicas. La inconstancia del desarrollo del software pueden hacer de tales proyectos una ruleta rusa. Son muchas las empresas seducidas por metas de apariencia sencilla. Algunas tratan de reencarnar en forma distribuida software obsoleto basado en mainframe. Otros desean conectar entre sí los sistemas de que ya disponen, o conectarlos a sistemas nuevos mediante los que se pueda compartir datos y disponer de una interfaz más amistosa para el usuario. En la jerga técnica, este tipo de interconexión de programas suele denominarse “integración de sistemas”. Pero Brian Randell un científico de la computación de la Universidad de Newcastle en Tyne, sugiere “que hay una palabra más adecuada que integración, del slang de la RAF: nominalmente ‘to graunch’, que significa ‘hacer que algo encaje por aplicación de una fuerza excesiva’.” El asunto es riesgoso, pues aunque el software pueda parecer cosa maleable, la mayoría de los programas son en realidad complicadas redes de estructuras lógicas muy frágiles, a través de los cuales solamente pueden pasar datos de naturaleza específica. Al igual que los arcabuces hachos a mano, diversos programas pueden realizar funciones semejantes y ser, sin embargo, de diseño exclusivo. De aquí que sean difíciles de modificar y de reparar, y de aquí también que las tentativas de embutirlos unos en otros acaben a menudo de mala manera. Por poner un ejemplo. El Departamento de Vehículos Automotor de California decidió en 1987 hacerles la vida más fácil a los conductores, para lo que resolvió fundir en uno los sistemas de permiso de conducción para el personal y de circulación de los vehículos. Tarea sencilla, en apariencia. Los responsables confiaban en que en 1993 tendrían en servicio quioscos donde se efectuasen cómodamente las renovaciones en una sola parada. En vez de ello, lo que vieron era cómo se multiplicaba por 6,5 el costo previsto y se posponía hasta 1998 la fecha de inauguración. El pasado diciembre cerraron el grifo y perdieron la inversión efectuada en los siete años: 44,3 millones de dólares. Hay veces que nada es tan catastrófico como el éxito. En el decenio de 1970, la compañía American Airlines construyó el SABRE, un sistema de reserva de pasajes de autentico virtuosismo, que costo 2000 millones de dólares y llegó a formar parte de la infraestructura de la industria de viajes. “SABRE constituyó el ejemplo más luminoso de sistema estratégico de información, porque hizo que American Airlines se convirtiera en la mayor línea aérea del mundo”, recuerda Bill Curtis, consultor del Software Engineering Institute. Decidida a valerse del software con igual efectividad en este decenio, American Airlines trató de acoplar sus sistema de reserva de pasajes con los de reserva de hotel y de alquiler de automóviles de Marriott, Hilton y Budget. El proyecto colapsó en 1992, en medio de un montón de pleitos. “Fue un fracaso aplastante”, dice Curtis. “American Airlines tuvo que pasar a pérdidas 165 millones de dólares por esta causa”. Mal puede decirse que la compañía aérea se encuentre sola en sus sufrimientos. El Consulting Gropu de IBM hizo públicos en junio los resultados de un estudio efectuado en

24 compañías líderes que habían desarrollado grandes sistemas distribuidos. Las cifras eras inquietantes: el 55 por ciento de los proyectos costó más de lo esperado, el 68 por ciento incumplió los plazos previstos y el 88 por ciento tuvo que rediseñarse a fondo. El informe no mencionaba, empero, un dato estadístico de la mayor importancia: la confiabilidad del funcionamiento de los programas terminados. Los sistemas informáticos suelen estrellarse o quedarse colgados debido a su incapacidad de enfrentar lo inesperado. Las redes amplían el problema, “Los sistemas distribuídos pueden consistir en un conjunto muy grande de puntos individuales interconectados, en lo que cabe que se produzcan fallas y muchos de los cuales no están identificados de antemano”, explica Randell. “La complejidad y la fragilidad de estos sistemas plantean un problema de primera magnitud.” El desafío de la complejidad no sólo es grande sino que va en aumento. Lo que recibe uno por cada unidad monetaria invertida en ordenadores se duplica cada 18 meses, más o menos. Lo que origina, entre otras cosas, “un crecimiento de un orden de magnitud en el tamaño de los sistemas por decenio y, en ciertos sectores, cada cinco años”, según Curtis. Para no verse superados por semejante demanda, los programadores tendrán que cambiar la forma en que trabajan. “No se pueden construir rascacielos con carpinteros”, bromea. Auxilio! !Socorro! Cuando un sistema se vuelve tan complejo que ningún gerente lo comprende individualmente por completo, los procesos tradicionales de desarrollo se vienen abajo. La Administración Federal de Aviación estadounidense (FAA, Federal Aviation Administration) ha tenido que afrontar este problema a lo largo de su intento- que ya dura diez años- de sustituir el sistema de control de tráfico aéreo del país, cada vez más anticuado. En su sustituto, denominado Sistema Avanzado de Automación (AAS, Advanced Automation Systems), se combinan todos los problemas de la computación de nuestro decenio. El programa, cuyo tamaño supera el millón de líneas, está distribuido en cientos de ordenadores y empotrado en aparatos nuevos y muy complejos. Todo el sistema debe responder instantáneamente a acontecimientos impredecibles durante las veinticuatro horas del día. Incluso un ligero bug puede constituir una amenaza para la seguridad pública. Para llevar a la práctica sus sueño tecnológico, la FAA seleccionó a Federal Systems Company, de IBM, entidad de muy buena reputación y líder en el desarrollo de software, posteriormente adquirida por Loral. Los responsables de la FAA esperaban (aunque no lo exigieron) que IBM aplicase las últimas técnicas disponibles para estimar el costo y la duración del proyecto, al igual que dieron por supuesto que revisaría cuidadosamente requerimientos y el diseño del sistema, para detectar los errores cuanto antes, cuando es posible corregirlos en horas y no en días. Y aceptaron - conservadoramente - que tendrían que pagar unos 500 dólares por línea de programa producida, unas cinco veces más que el costo medio normal para procesos de desarrollo bien gestionados.

Según un informe sobre el proyecto AAS, publicado en mayo de este año por el Centro de Análisis Naval estadounidense, “las estimaciones de costos y el seguimiento del proceso de desarrollo” hechos por IBM “se efectuaron con datos inadecuados y se realizaron de forma inconsistente, y fueron rutinariamente ignoradas por los gerentes del proyecto. El resultado es que la FAA ha estado pagando la programación para el sistema AAS a razón de 700 a 900 dólares por línea código. Una de las razones de precio tan exorbitante es que, “por término medio, cada una de dichas líneas ha de volver a escribirse”, según se lamentaba un documento de la FAA. Alarmado por la estratosférica elevación de costos y porque los ensayos efectuados sobre el sistema semiterminado mostraban que no era confiable, David R. Hinson, administrador de la FAA, decidió en junio pasado cancelar dos de las cuatro grandes partes del proyecto y reducir la escala de una tercera. Los 144 millones de dólares dilapidados en estos programas fallidos son sólo una gota de agua frente a los 1400 millones invertidos en la pieza cuarta y central: el nuevo software de las estaciones de trabajo de los controladores de tráfico aéreo. También este proyecto va camino de irse a pique. El programa lleva cinco años de retraso, ha engullido más de 1000 millones de dólares sobre lo presupuestado y está lleno de bugs. Expertos informáticos de la Carnegie Mellon y del Instituto de Tecnología de Massachusetts (MIT, Massachusetts Institute of Technology) están tratando de depurarlo y de averiguar si todavía es posible salvarlo o si debe cancelarse sin más. Los desastres serán una parte crecientemente común y disruptiva del desarrollo de software, a menos que la programación adopte muchas de las características de las ramas de la ingeniería, que están firmemente entroncadas en la ciencia y en las matemáticas (ver el cuadro “Progreso hacia el profesionalismo”). Por fortuna, esa tendencia ha comenzado ya. A lo largo de la última década, empresas líderes de la industria han comprendido bastante sobre cómo medir cuantitativa y consistentemente, el caos de sus procesos de desarrollo, la densidad de errores de sus productos y el estancamiento de la productividad de sus programadores. Los investigadores están dando el paso siguiente: encontrar soluciones prácticas y reproducibles para estos problemas. Los frutos del proceso Así, por ejemplo, el SEI, un vivero de ideas sobre el tema, financiado por los militares, reveló en 1991 su “modelo de capacidad y madurez” (CMM, Capability Maturity Model). “El CMM proporciona una visión de la excelencia de la ingeniería de software y de su gestión”, dice David Zubrov, quien dirige un proyecto sobre métodos empíricos en el Instituto. Al menos el CMM, ha persuadido a muchos programadores de concentrarse en la medición del proceso por el que producen software, un requisito previo en cualquier disciplina de ingeniería industrial. Sirviéndose de entrevistas, de cuestionarios y del CMM como sistema de comparación, puede calificarse la capacidad de un equipo de programación para crear

software predecible y que solucionen las necesidades de sus clientes. El CMM aplica una escala de cinco niveles, que van desde el caos en el nivel 1, hasta el parangón de una buena gestión en el nivel 5. Las organizaciones evaluadas hasta ahora son 261. “La aplastante mayoría- alrededor del 75 por ciento- siguen todavía empantanadas en el nivel 1”, nos cuenta Curtis. “Carecen de procesos formales, no miden lo que hacen y no tienen forma de saber si van por el mal camino o si han descarrilado del todo.” (El Centro de Análisis Naval concluyó que el nivel del proyecto AAS en Federal Systems, de IBM, como “1 bajo”.) El 24 por ciento restante de los proyectos se encuentra entre los niveles 2 y 3. Tan sólo dos grupos de elite han merecido la máxima puntuación CMM, el nivel 5. El equipo de programación que Motorola tiene en Bangalore, India, ostenta uno de esos títulos. El otro ha sido el proyecto de software de a bordo para el transbordador espacial, realizado por Loral (que antes pertenecía a IBM). Tan perfectamente ha aprendido el equipo de Loral a controlar los errores, que es capaz de pronosticar correctamente cuántos van a descubrirse en cada nueva versión del software. Se trata de una a hazaña notable, habida cuenta de que la mayoría de los programadores ni siquiera llevan la cuenta de los bugs que descubren, de acuerdo a Capers Jones, Chairman de Software Productivity Research. Y entre quienes lo hacen, dice, son pocos quienes detectan más de la tercera parte de los existentes. El director del proyecto de software para el transbordador espacial, Tom Peterson, atribuye su éxito a “una cultura que se esfuerza por enmendar no sólo los errores del programa sino también las fallas del proceso de comprobación, que permitieron que los primeros pasaran desapercibidos”. No obstante, siempre se cuela alguno. El primer lanzamiento del transbordador espacial en 1981 tuvo que interrumpirse y posponerse dos días debido a que una señal errónea impidió que los cinco ordenadores de a bordo quedaran debidamente sincronizados. Otro fallo, esta vez en el programa de rendezvous del transbordador, puso en peligro la misión de rescate del satélite Intelsat-6, en 1992. Aunque el modelo CMM no es la panacea, la promoción que de él ha realizado el SEI ha persuadido a algunas de las principales empresas de software de que, a largo plazo, el control cuantitativo de la calidad puede resultar rentable. Así, por ejemplo, la división de equipos de Raytheon elaboró en 1988 un “iniciativa de ingeniería de software” tras haber fallado en una evaluación del CMM. Empezaron a invertir un millón de dólares anuales para refinar las guías de inspección y de verificación rigurosa y para formar a sus 400 programadores para que las siguieran. En el plazo de tres años ya habían escalado dos niveles. El mes de junio pasado casi todos los proyectos, entre ellos complejos sistema de radar y de control de tráfico aéreo, se estaban concluyendo antes de plazo y a costo inferior del presupuestado. La productividad se ha duplicado con holgura. Los análisis de costos de retrabajo han indicado ahorros de 7,80 dólares por cada dólar invertido en la iniciativa. Impresionada por semejantes éxitos, la Fuerza Aérea de los Estados Unidos ha establecido que quienes desarrollen programas para

ella han de alcanzar el nivel 3 de CMM en 1998. Se tienen noticias de que la NASA piensa actuar de forma parecida. Re- creaciones matemáticas En tanto los humanos creen programas, siempre se producirán errores; hasta los diseños más cuidados pueden desviarse. No obstante, los bugs detectados en los estadios iniciales raramente amenazan los plazos y presupuestos de un programa. Los que provocan efectos devastadores son casi siempre deslices cometidos en el diseño inicial que llegan intactos hasta el producto definitivo. Los fabricantes de programas para mercados masivos, que no han de complacer a un cliente individual, pueden adoptar un enfoque a posteriori y de fuerza bruta para eliminar los defectos: hacen circular el producto deficiente con el nombre de versión “beta” y dejan que multitudes de usuarios se encarguen de descubrir las fallas. Según Charles Simonyi, un Arquitecto Jefe de Microsoft, la nueva versión del sistema operativo Windows será objeto de tests “beta” por veinte mil voluntarios. Tal sistema es muy eficaz, pero también oneroso, ineficiente y poco práctico, dado que los productos masivos para computadores personales sólo suponen el diez por ciento del mercado de software en los Estados Unidos, que mueve 92.800 millones de dólares al año. En consecuencia, los investigadores formulan diversas para atacar los errores tempranamente, e incluso para impedir que ocurran. Una ideas consiste en tener en cuenta que el problema que se supone resuelve el sistema, siempre cambia a medida que se lo va construyendo. Las planificaciones del aeropuerto de Denver cargaron sobre las espaldas de BAE modificaciones por valor de 20 millones de dólares en el diseño del sistema de equipajes mucho después de haberse iniciado su construcción. IBM sufrió de igual manera las indecisiones de los directivos de la FAA. Ambas empresas habían dado por supuesto, ingenuamente, que una vez aprobado su diseño, se las dejaría en paz para construirlo. Algunos desarrolladores están abandonando esa ilusión y repensando al software como algo que, más que construirse, se cultiva. En un primer paso, se hilvana rápidamente un prototipo merced a componentes estándar de interfases gráficas. Lo mismo que las maquetas utilizadas en arquitectura, el prototipo de un sistema puede servir para aclarar malentendidos entre el programador y su cliente antes de empezar a establecer los cimientos lógicos. Pero los prototipos sirven de poco en la detección de inconsistencias lógicas del diseño, pues sólo remedan el aspecto externo de su comportamiento. “La gran mayoría en software de gran envergadura son errores de omisión”, nota Laszlo A. Belady, director de Mitsubishi Electric Research Laboratory. Y una vez escrito el programa los modelos en nada facilitan la detección de bugs. Cuando la exigencia de corrección del programa es absoluta, dice Martyn Thomas, gerente general de Paxis, una compañía británica de software, los ingenieros recurren a

análisis matemáticos para predecir cuál será el comportamiento de sus creaciones en el mundo real. Por desdicha, las matemáticas tradicionales, aptas para la descripción de sistemas físicos, no son aplicables al universo sintético binario de un programa de computador; es la matemática discreta, una especialidad mucho menos madura, la que gobierna este campo. Aun así, valiéndose del instrumental, no muy amplio todavía, de la teoría de conjuntos y del cálculo de predicados, los científicos de la computación se las han arreglado para traducir especificaciones y programas al lenguaje matemático, donde pueden analizarse con los instrumentos teóricos denominados métodos formales. Praxis ha usado recientemente métodos formales en un proyecto de control de tráfico aéreo para el órgano administrativo responsable de la aviación civil en Gran Bretaña. Aunque su programa era mucho más pequeño que el de la FAA, ambos afrontaban un problema similar: la necesidad de mantener sincronizados sistemas redundantes, de manera que si uno de ellos fallase, el otro pudiera entrar en servicio instantáneamente. “Lo difícil consistía en garantizar que los mensajes se entregaran en el orden debido a las dos redes gemelas”, según Anthony Hall, un consultor principal de Praxis. “Tratamos de conseguir demostraciones matemáticas de nuestro enfoque, que fallaron, porque el diseño era erróneo. La detección de errores en ese estadio inicial tiene enormes ventajas”. El sistema quedó concluido a tiempo y entró en servicio en octubre de 1993. Praxis sólo utilizó notaciones formales solamente en las secciones más críticas del software, pero otras firmas de software han aplicado el rigor matemático a la totalidad del desarrollo de un sistema. En París, GEC Alsthom está utilizando un método formal llamado “B”, al tiempo que invierte 350 millones de dólares en perfeccionar los programas de control de velocidad y de guiado de los 6000 trenes eléctricos del sistema nacional de ferrocarriles francés, la SNCF. El sistema puede ahorrar miles de millones de dólares si permite aumentar la velocidad de los trenes y su frecuencia, el sistema puede ahorrar miles de millones de dólares evitando los nuevos tendidos de líneas necesarios de otro modo. La seguridad es una preocupación obvia. Por eso lo que los desarrolladores de GEC escribieron el diseño completo y el programa final en notación formal y luego usaron matemáticas para demostrar la consistencia de ambos. “Los test funcionales siguen siendo necesarios por dos razones”, indica Fernando Mejía, director de la sección de desarrollo formal de GEC. En primer lugar, a veces los programadores cometen errores en las demostraciones. En segundo lugar, los métodos formales solamente pueden garantizar que el software cumple con su especificación, no que sean capaces de manejarse con las sorpresas que depara el mundo real. No son éstos los únicos problemas de los métodos formales. Ted Ralston, director de planeamiento estratégico de Odyssey Research Associates, en Ithaca, Nueva York, hace notar que la lectura de página tras página de fórmulas algebraicas resulta más soporífera todavía que la revisión de código de compujtadora. Odyssey es una de las empresas que están tratando de automatizar los métodos formales para que les resulten menos onerosos a los programadores. En Francia, GEC colabora con Digilog para comercializar herramientas de programación para el método B. Siete compañías e instituciones, Aerospace entre ellas,

así como el organismo responsable de la energía atómica y el ministerio de defensa franceses, están probando la versión beta. Del otro lado del Atlántico, los métodos formales por sí mismos tienen todavía que abrirse paso. “Yo soy escéptico que los estadounidenses sean lo suficientemente disciplinados para aplicar métodos formales en alguna forma generalizada”, dice David A. Fisher del National Institute of Standards and Technology (NIST). Existen excepciones, no obstante, sobre todo en el círculo cada vez más amplio de las empresas que experimentan una metodología de programación denominada “enfoque de sala limpia” (clean-room approach). Este método trata de conjugar las notaciones formales, las demostraciones de validez y los controles estadísticos de calidad con un enfoque evolutivo del desarrollo de software. Al igual que la técnica de fabricación de circuitos integrados de la que toma su nombre, el desarrollo de “sala limpia” trata de aplicar consistentemente técnicas rigurosas de ingeniería para fabricar productos que funcionen perfectamente la primera vez. Los programadores desarrollan el sistema de a una función por vez y se aseguran de certificar la calidad de cada unidad antes de integrarla en el la arquitectura. Software creciendo en esta forma, requiere toda una nueva metodología de testeo. Tradicionalmente, los desarrolladores testean un programa ejecutándolo del modo en que ellos entienden que debe funcionar, modos que, muchas veces, apenas si guardan leve parecido con los del mundo exterior. En un proceso de sala limpia, los programadores tratan de asignar una probabilidad a cada camino de ejecución -correcto e incorrecto- que los usuarios puedan tomar. Ellos pueden derivar casos de prueba de estos datos estadísticos, de forma que las rutas más frecuentemente utilizadas se analicen más profundamente. Después se hace funcionar el programa en cada una de estos casos de prueba y se cronometra cuánto tarda en fallar. Estos tiempos se le introducen a continuación a un modelo matemático, que calcula la confiabilidad del programa, a la manera más puramente ingenieril. Los informes de los que adoptaron inicialmente el enfoque alientan a utilizarlo. Ericsson Telecom, el gigante europeo de las telecomunicaciones, aplicó procesos de sala limpia en un proyecto de 70 programadores destinado a elaborar un sistema operativo para computadores de conmutación telefónica. Sus informes hablan de que los errores se redujeron a uno por cada 1000 líneas de código de programa, cuando el promedio de la industria es unas veinticinco veces mayor. Y, lo que puede ser más importante, se comprobó que la productividad del desarrollo aumentó un 70 por ciento y la de las pruebas se duplicó. No hay balas de plata6 En esta profesión se ha oído hablar ya muchas veces de “balas de plata” presuntamente capaces de hacer desaparecer los bugss que plagan los proyectos. desde los años sesenta se han anunciado docenas de innovaciones técnicas destinadas a incrementar la productividad; muchos de sus creadores han presentado incluso proyectos “demostrativos”

de la veracidad de sus pretensiones. Los partidarios del análisis y la orientados a objetos, uno de los comodines verbales del presente, proclaman que su método constituye un cambio de paradigma capaz de generar “una mejora de productividad de 14 a 1”, junto con superior calidad y mantenimiento más fácil, todo ello a menor costo. No faltan motivos para el escepticismo. Curtis recuerda que “En los años 70 se proclamó que la programación estructurada era un cambio de paradigma y otro tanto ocurrió luego con CASE [computer-assisted software engineering, ingeniería de software asistida por ordenador], repitiéndose la historia con los lenguajes de tercera, cuarta y quinta generación. Nosotros hemos oído grandes promesas tecnológicas, muchas de las cuales jamás se han cumplido”. Mientras tanto, la productividad en el desarrollo de software se ha rezagado con respecto a la de disciplinas más maduras, sobre todo con respecto a la ingeniería de computadoras. “Yo pienso del software como un objeto de culto”, dice Cox. “Nuestros principales logros fueron importados desde la cultura extranjera de la ingeniería de hardware - máquinas cada vez más rápidas y dotadas de más memoria”. Fisher tiende a acordar: ajustado por inflación “el valor agregado por trabajador en la industria ha sido de US$ 40,000 por dos décadas”, asevera. “Nosotros no estamos viendo ningún incremento.” “Yo no pienso así”, replica Richard A. DeMillo, un profesor de la Universidad de Purdue y principal directivo del Software Engineering Research Consortium. “Ha habido mejoras, pero cada uno usa diferentes definiciones de productividad”. Un estudio reciente publicado por Capers Jones -pero basado necesariamente en datos históricos dudososestablece que los programadores de Estados Unidos de América generan el doble de código que en 1970. El hecho es que nadie sabe lo productivos que son quienes desarrollan software, y ello por tres razones. La primera es que menos del diez por ciento de las compañías norteamericanas mide de forma coherente y sistemática la productividad de sus programadores. La segunda es que no se ha establecido aún una unidad de medida standard y útil en el sector. La mayoría de los estudios, incluyendo los publicados en las revistas sujetas a referato de ciencias de la computación, expresan la productividad en términos de líneas de código por trabajador por mes. Pero los programas están escritos en una gran variedad de lenguajes y varían enormemente en la complejidad de su operación. Comparando el número de líneas escritas por un programador japonés usando C con el número producido por un estadounidense usando Ada, es como comparar sus salarios sin convertir de yen a dólares. En tercer lugar, dice Fisher, “usted puede caminar en una empresa típica y encontrar a dos personas que comparten la misma oficina, perciben el mismo salario y poseen calificaciones equivalentes y usted puede detectar, sin embargo, diferencias en un factor cien en el número de instrucciones por día que producen”. Tan enormes diferencias individuales tienden a anular los efectos, mucho menos acusados, de las mejoras tecnológicas o de procesos.

Tras veinticinco años de desengaños, debido a aparentes innovaciones que resultaron ser no reproducibles o imposibles de adoptar a mayor escala, son muchos los investigadores que admiten que la ciencia de la computación requiere una rama experimental destinada a separar los resultados generales de los meramente accidentales. “Siempre se ha dado por supuesto que, si yo enseño un método, éste es correcto sólo porque yo lo digo”, denuncia Víctor R. Basili, un profesor en la Universidad de Maryland. “Se están produciendo todo genero de cosas y resulta verdaderamente escalofriante lo malas que son algunas de ellas,” dice. Mary Shaw, de Carnegie Mellon puntualiza que las ingenierías maduras han codificado en manuales las soluciones bien probadas, de forma que incluso novicios poco experimentados puedan manejar consistentemente los diseños rutinarios, dejando libres para los proyectos avanzados a los profesionales de mayor talento. No existen manuales semejantes para el software, por lo que los errores se repiten año tras año, en un proyecto tras otro. DeMillo sugiere que el gobierno debería tomar un papel más activo. “La National Science Foundation debería estar interesada en financiar investigación orientada a verificar experimentalmente resultados que ha sido establecidos por otra gente”, dice. “Actualmente si no es investigación hecha por primera vez y de gran creatividad, los administradores de los programas de la NSF tienden a discontinuar el trabajo.” DeMillo conoce de qué habla. Desde 1989 a 1991 dirigió la división de investigación en computadoras y computación de la NSF. Además, “si la ingeniería de software es una ciencia experimental, esto significa que necesita ciencia de laboratorio. Dónde están los laboratorios?” pregunta Basili. Puesto que el esfuerzo de llevar las tecnologías prometedoras a la escala de la proporciones industriales a menudo falla, los laboratorios pequeños son de utilidad limitada. “Necesitamos tener instalaciones en las que obtener datos y tratar de sacar las cosas,” dice DeMillo. “La única forma de hacer esto es tener una organización real de desarrollo de software como socio.” Ha habido sólo unos pocas de esas asociaciones. Quizás la más exitosa es el Software Engineering Laboratory, un consorcio del Goddard Space Flight Center de la NASA, Computer Sciences Corporation y la Universidad de Maryland. Basili ayhudó a fundar el laboratorio en 1976. Desde entonces, estudiantes de posgrado y programadores de la NASA han colaborado en “más de 100 proyectos,” dice Basili, la mayoría vinculados con la construcción de software para soporte terrestre para satélites. Basta echarle agua Los fabricantes de arcabuces no lograron mejorar su productividad hasta que Eli Whitney concibió la forma de producir piezas intercambiables, que pudieran ser ensambladas por cualquier operario hábil. De forma análoga una vez standarizadas, las partes del software podrían reutilizarse en diferentes escalas. Hace decenios que los programadores vienen utilizando bibliotecas de subrutinas para no tener que escribir una y

otra vez el mismo código. Pero estos componentes dejan de funcionar al ser trasladados a un lenguaje de programación diferente, o a una plataforma de hardware o entorno operativo de distinto tipo. “La tragedia es que, al devenir obsoleto el hardware, resulta necesario volver a escribir lo que era una excelente muestra de un algoritmo de clasificación conseguida en los años sesenta”, observa Simonyi de Microsoft. Fisher ve una tragedia de diferente tipo. “El verdadero precio que nosotros pagamos es que como especialista en cualquier tecnología de software usted no puede reflejar en un producto esa peculiar destreza que posee. Y si tal cosa no es posible, también es imposible ser especialista.” Y no es que falten quienes lo hayan intentado. Antes de trasladarse a NIST el año pasado, Fisher fundó y actuó de máximo responsable de Incremental Systems. “Sin ninguna duda eramos “world-class” en tres de las técnicas que intervienen en los compiladores, pero no alcanzábamos el mismo nivel de calidad en las otras siete o así”, declara. “Y descubrimos que no había ninguna forma práctica de vender componentes de compilador; era preciso que vendiéramos compiladores completos.” Así que ahora está tratando de ponerle remedio a esa situación. NIST anunció en abril que estaba preparando un Programa de Tecnología Avanzada que contribuyera a generar un mercado para software basado en componentes. En su calidad de director del programa, Fisher distribuirá 150 millones de dólares en subvenciones de investigación a compañías de software dispuestas a afrontar los obstáculos técnicos que actualmente hacen inviable producir partes de software. El máximo desafío consiste en encontrar formas de romper los lazos que ligan indisolublemente los programas a computadores específicos y a otros programas. Los investigadores están estudiando varios métodos prometedores, entre ellos un lenguaje común que podría servir para describir partes de software; programas capaces de reformar los componentes, adaptándolos a un ambiente cualquiera; y componentes provistos de múltiples opciones, que el usuario podría activar o no. Fisher favorece la idea que las componentes deberían ser sintetizadas en la acción. Los programadores deberían “básicamente capturar cómo hacer en lugar de haciéndolo,” produciendo una reformulación que cualquier computadora pueda comprender. “Luego cuando usted quiere ensamblar dos componentes, usted podría tomar esta reformulación y derivar versiones compatibles añadiendo elementos adicionales a sus interfaces. Todo podría ser automatizado,” explica. Incluso con un incentivo de 150 US$ millones y presiones del mercado forzando a las empresas a encontrar caminos más baratos para producir software, no es inminente una revolución industrial en el software. “Nosotros esperamos ver solamente ejemplos aislados de estas tecnologías en cinco a siete años - y eso en el caso que no fracase todo,” se resguarda Fisher. E incluso cuando la tecnología esté a punto, serán pocos quienes adopten los componentes a menos que éstos puedan producirse a un precio ventajoso. Y el costo de los módulos dependerá menos de la tecnología utilizada que del tipo de mercado que pueda surgir para producirlos y consumirlos.

Brad Cox, como Fisher también fue director de una compañía de componentes de programación y le resultó difícil sacarla adelante. Cree saber dónde está el problema...y su solución. Su empresa trataba de vender componentes de programas de bajo nivel, algo análogo a los microcircuitos de los ordenadores. “La diferencia entre los circuitos integrados de silicio y los ‘circuitos integrados’ para software estriba en que los primeros están formados por átomos, y perduran por conservación de la masa; en consecuencia la gente sabe como comprarlos y venderlos con seguridad,” dice Cox. “Pero este proceso de intercambio, que se encuentra en el corazón de todo el comercio, sencillamente no funciona para cosas que se pueden copiar en nanosegundos.” Cuando trató de vender los módulos creados por sus programadores, el precio que los clientes estaban dispuestos a pagar era demasiado bajo para resarcirle de los costos de desarrollo. Las razones eran dobles. La primera, que la adaptación manual de los módulos a las necesidades de cada cliente era una operación que consumía mucho tiempo; NIST confía en salvar esta barrera con su Programa de Tecnología Avanzada. El otro factor no era tanto técnico como cultural: lo que quieren los compradores es pagar por el componente una vez y luego hacer copias gratis. “La industria de la música ha tenido cerca de un siglo de experiencia con este grave problema,” observa Cox. “Ellos solían vender objetos tangibles, como partituras y rollos de pianola, pero llegaron la radio y la televisión y todo aquello se fue al garete.” Las compañías musicales se adaptaron a la radiodifusión estableciendo agencias encargadas de percibir los derechos de autor cada vez que se emite una melodía y de encauzar esos fondos hacia los artistas y los productores. Cox propone que se les pase un cargo a los usuarios cada vez que utilicen un componente de programación. “De hecho,” dice, “en el caso del software tal modelo podría funcionar mejor que con la música, gracias a las ventajas de infraestructura que proporcionan los ordenadores y las comunicaciones. Los reproductores de grabaciones no disponen de enlace a redes de alta velocidad que registren su utilización, peor los ordenadores, si.” O, por lo menos, la tendrán en el futuro. Escudriñando en el tiempo en que casi todas las computadoras estén conectadas, Cox visualiza la distribución de software de todos los tipos a través de redes que vinculen productores de componentes, usuarios finales e instituciones financieras. “Es análogo a una operación de tarjeta de crédito pero con tentáculos que penetran en cada PC,” dice. Aunque a algunos pueda sonarle ominoso, Cox argumenta que “ahora Internet es más un depósito de desperdicios que un mercado para comprar. Necesitamos una gran infraestructura que pueda soportar la distribución de todo tipo de productos.” Reconociendo la envergadura del cambio cultural que propone, Cox espera empujar su causa por años a través de la Coalition for Electronic Markets, de la que es presidente. La combinación de control industrial de procesos, herramientas técnicamente avanzadas y partes intercambiables promete transformar no sólo la forma de realizar la

programación, sino también a los encargados de efectuarla. Muchos de los expertos que convergieron en Hedsor Park acuerdan con Belady que “en el futuro, los profesionales de muchos campos usarán la programación como una herramienta de trabajo, pero ellos no querrán llamarse a sí mismos programadores ni creerán estar dedicando su tiempo a la programación. Pensarán, en cambio, estar haciendo arquitectura, o control de tráfico, o películas de cine”. Esta posibilidad suscita la pregunta de quiénes están capacitados para construir sistemas importantes. En la actualidad cualquiera puede anunciarse como ingeniero de software. “Pero cuando se tengan cien millones de programadores-usuarios, será frecuente que se hagan cosas críiticas para la vida, como, por ejemplo, construir programas para extender recetas médicas,” hace notar Barry W.Boehm , director del Center for Software Engineering de la Universidad de Southern California. Boehm es uno del creciente número de quienes recomiendan que los ingenieros de software deben certificarse, como se hace en otros campos de la ingeniería. Tal certificación sólo servirá de algo si los programadores reciben la formación adecuada. Actualmente sólo 28 universidades ofrecen programas de posgrado en ingeniería de software; cinco años atrás había sólo 10. Ninguna ofrece títulos de grado. Incluso académicos tales como Shaw, DeMillo y Basili acuerdan que en general la curricula de computer science ofrece por lo general una preparación deficiente para el desarrollo industrial de software. “Pues aspectos fundamentales, como el diseño de inspecciones del código, la producción de documentación para el usuario y el mantenimiento de los programas que van quedándose anticuados, no son cubiertos en la academia”, se lamenta Capers Jones. Los ingenieros, la infantería de toda revolución industrial, no se generan espontáneamente. Reciben una formación tendiente a evitar los malos hábitos de los artesanos que les precedieron. En tanto las lecciones de la ciencia de la computación no inculquen no sólo el deseo de construir mejores cosas, sino el de construir mejor las cosas, lo mejor que podemos esperar es que el desarrollo del software vaya pasando por una evolución industrial lenta y probablemente dolorosa. Bibliografía complementaria Encyclopedia of Software Engineering. Editada por John J. Marciniak. John Wiley & Sons, 1994. Software 2000: A View of the Future. Editado por Brian Randell, Gill Ringland y Bill Wulf. ICL y la Comisión de Comunidades Europeas, 1994. Formal Methods: A Virtual Library. Jonathan Bowen. Disponible en hipertexto en Wide World Web, con la referencia http://www.comlab.ox.ac.uk/archive/formal-methods.html

1

Traducción del Scientific American aparecida en Investigación y Ciencia, noviembre de 1994. Revisada por Alejandro Oliveros. En lo que sigue las notas son comentarios de AO a fin de aclarar la traducción. 2 Denver, Colorado, es un gran centro de esquí invernal de los Estados Unidos de América 3 Día de Brujas, 2 de noviembre 4 Del hemisferio norte 5 El promotor de las piezas de recambio 6 Alude a un artículo clásico de la Ingeniería de Software, de Fred Brooks. El título No silver bullets, recupera una leyenda según la cual al hombre lobo sólo se lo puede matar con una bala de plata en el medio del corazón.

Versión traducida por Alejandra Serrano contactar a: [email protected] No existen balas de plata: esencias y accidentes de la ingeniería software ¿Tiene que ser difícil? Dificultades esenciales No solo ahora no hay balas de plata a la vista, sino que la propia naturaleza del software hace poco probable su futura existencia; ninguna futura invención servirá para la productividad del software, confianza, y simplicidad, como lo hicieron sistemas electrónicos, transistores, y la integración a larga escala por los hardware de computadores. No podríamos esperar jamás ver duplicarse las ganancias cada 2 años. En primer lugar, se debe observar que la anomalía no es que el progreso del software sea lento, sino que el progreso de los hardware de computadores es muy rápido. Ninguna otra tecnología desde el principio de la civilización ha visto seis veces elevado a la décima potencia su ganancia en cuanto al precio de presentación en los últimos 30 años. En ningún otro tipo de tecnología se puede optar por tomar, ya sea en la ganancia o la mejora de los resultados en la reducción de los costos. Esas ganancias provienen de la transformación de la fabricación del computador de una industria del lenguaje Assembly a una industria de proceso. En segundo lugar, para ver el nivel de progreso que se puede esperar en la tecnología software, permítanos examinar las dificultades de esa tecnología. Siguiendo a Aristóteles, divido en “esencia” las dificultades inherentes a la naturaleza del software, y “accidentes” a las dificultades que actualmente asisten a su producción pero que no son inherentes. La esencia de una entidad software es el resultado de una construcción de conceptos entrelazados: conjuntos de datos, relaciones entre los elementos de datos, algoritmos y de invocaciones de funciones. Esta esencia es abstracta, ya que tal construcción conceptual es la misma bajo muchas representaciones distintas. Sin embargo es extremadamente preciso y detallado. Creo q la parte más difícil en la creación de un software es la especificación, diseño y prueba de la construcción de esta base conceptual, no el trabajo de representar y probar la calidad de la representación. Aun cometemos errores de sintaxis para asegurarnos, pero no son nada comparados con los errores conceptuales en la mayoría de los sistemas. Si esto es cierto, crear un software será siempre difícil. No hay intrínsecamente ninguna bala de plata. Consideremos las propiedades inherentes de esta esencia irreducible de los sistemas modernos de software: complejidad, conformidad, variabilidad e invisibilidad. Complejidad: Las entidades software son más complejas que talvez cualquier otra construcción humana por su tamaño, porque no tiene dos partes iguales (al menos por encima del nivel del orden). Y si las hay, ponemos las dos partes similares en una subrutina; abierta o cerrada. En este aspecto, los sistemas software difieren profundamente de los computadores, edificios o automóviles, donde abundan elementos repetidos. Los computadores digitales son por si mismos más complejos que la mayoría de las cosas que las personas crean: tienen un gran número de etapas. Esto hace difícil concebirlos, describirlos y probarlos. Los sistemas software tienen muchísimos más estados que los computadores.

Del mismo modo, un aumento de una entidad software no es simplemente una repetición de los mismos elementos a una mayor escala, es necesario un aumento en el número de distintos elementos. En la mayoría de los casos, los elementos interactúan entre si de una forma no lineal, y la complejidad del todo incrementa mucho mas que linealmente. La complejidad del software es una propiedad esencial, no accidental. Por lo tanto, las descripciones de una identidad software que dejan de lado su complejidad también lo hacen de su esencia. Durante tres siglos, las matemáticas y las ciencias físicas hicieron grandes avances construyendo modelos simplificados de fenómenos complejos, derivando propiedades de los modelos y comprobando esas derivaciones por medio de experimentación. Este paradigma funcionaba porque las complejidades ignoradas en esos modelos no eran propiedades esenciales de los fenómenos. No funciona cuando las complejidades son la esencia. Muchos de los típicos problemas de desarrollar productos software provienen de esta complejidad esencial y su no-linealidad incrementa con el tamaño. De la complejidad proviene la dificultad de comunicación entre los miembros del equipo, lo que lleva a fallas de producto, costos excesivos, retrasos en los periodos de entrega. De la complejidad proviene la dificultad de enumeración, un aún menor entendimiento y todos los posibles estados del programa; de allí viene la poca fiabilidad. De la complejidad de función viene la dificultad de iniciar la función, lo cual hace a los programas difíciles de usar. De la complejidad de estructura viene la dificultad para extender los programas a nuevas funciones sin crear efectos secundarios. De la complejidad de estructura vienen los estados invisibles, los cuales constituyen una verdadera trampilla de seguridad. De la complejidad no solo vienen problemas técnicos, sino también problemas de manejo. Esto hace difícil una visión general, impidiendo así una integridad conceptual. Hace difícil encontrar y controlar todos los cabos sueltos. Crea la tremenda carga de aprender y entender, lo que hace de la renovación de personal un desastre. Conformidad: La gente de software no es la única en enfrentar complejidad. Físicos tratan con objetos extremadamente complejos, incluso al nivel de partículas fundamentales. Sin embargo, la labor de un físico es trabajar con la firme convicción de estar unificando principios aun no descubiertos, ya sea en quarks o en “teorías del campo unificado”. Einstein sostuvo que debe haber explicaciones simplificadas de la naturaleza, porque Dios no es caprichoso ni arbitrario. Esta creencia no reconforta al ingeniero de software. Gran parte de la complejidad que el debe dominar es complejidad arbitraria, forzada sin ton ni son por las muchas instituciones humanas y sistemas a los cuales sus interfaces deben conformar. Estos difieren de interfaz a interfaz y de vez en cuando no es por necesidad, sino solo por que fueron diseñados por diferentes personas, en vez de por Dios. En muchos casos el software debe ajustarse porque es el mas reciente. Otras veces debe adaptarse porque es visto como el mas mediocre. Pero en todos los casos, gran complejidad viene de la conformación de otras interfaces; esta complejidad no puede simplificarse por ningún rediseño aislado del software. Mutabilidad: La entidad software esta constantemente sujeta a presiones de cambio. Por supuesto también lo están los edificios, autos y computadores. Pero las cosas fabricadas son cambiadas con poca frecuencia luego de su creación, son reemplazadas por modelos nuevos, o se incorporan cambios esenciales en el numero de serie de copias posteriores al diseño básico. Retrocesos en automóviles son muy poco frecuentes, e incluso se dan menos en el campo computacional.

Ambos son mucho menos frecuentes que las modificaciones en el terreno de software. En parte esto es así porque el software de un sistema abarca su función, y la función es la parte que más siente la presión de cambio. Y esto es en parte es porque el software puede ser cambiado con mayor facilidad, it is pure thoughtstuff, infinitamente adaptable. Los edificios son cambiados, pero los altos costos de estos cambios son suficientes para desalentar a quienes quieran cambiarlos. Todo software exitoso es cambiado. Se trabajan dos procesos. Primero, cuando un producto software es útil, las personas lo prueban llevándolo al límite o más allá de su dominio original. La presión para extender las funciones viene principalmente de usuarios a los que les gustan las funciones básicas y les inventan nuevos usos. Segundo, un software exitoso sobrevive mas allá de la vida normal de máquina para la que fue creada. Si no nuevos computadores, al menos vendrán nuevos discos, pantallas e impresoras, y el software debe ajustarse. En resumen, el producto software esta incrustado en una matriz cultural de aplicaciones, usuarios, leyes y máquinas vehículo. Todos estos cambian continuamente, lo que fuerza implacablemente cambios en el producto software. Invisibilidad: Software es invisible. Las abstracciones geométricas son herramientas poderosas. El primer piso de un edificio ayuda a cliente y arquitecto a evaluar los espacios, flujos de trafico y vistas. Las contradicciones y omisiones se vuelven evidentes. Dibujos a escala de partes mecánicas y maquetas, a pesar de las abstracciones, tienen la misma finalidad. Una realidad geométrica es capturada en una abstracción geométrica. La realidad del software no esta intrínsecamente incrustada en el espacio, por lo tanto, no tiene aun una representación geométrica de la forma en que la Tierra tiene mapas, los chips de silicio tienen diagramas, los computadores tienen diagramas de conectividad. Tan pronto como intentamos esquematizar la estructura del software, nos encontramos con que constituye no uno, sino varios gráficos generales superpuestos uno sobre el otro. Los varios gráficos pueden representar el flujo de control, el flujo de datos, los patrones de dependencia, la secuencia de tiempo y las relaciones nombre-espacio. Estos gráficos por lo general no son siquiera planos, y mucho menos jerárquicos. De hecho, una de las formas de establecer un control conceptual sobre tal estructura es imponer un corte de la conexión hasta que uno o mas gráficos se convierta en jerárquico. A pesar del progreso en la limitación y simplificación de las estructuras del software, estas siguen siendo intrínsecamente invisibles y por lo tanto no le permiten a la mente usar algunas de sus más poderosas herramientas conceptuales. Esta carencia no solo le impide el proceso de diseño a una sola mente, sino que también dificulta gravemente la comunicación entre mentes. Últimos Avances Resolvieron Dificultades Accidentales Si analizamos los tres pasos en el desarrollo de la tecnología software que han sido más fructíferos en el pasado, descubrimos que cada uno atacó a una de las dificultades principales en la construcción de software, pero que esas dificultades habían sido accidentales y no esenciales. También podemos ver los límites naturales a la extrapolación de cada uno de dichos ataques. Lenguajes de alto nivel: Sin duda el golpe más poderoso para la productividad, fiabilidad y simplicidad del software ha sido la utilización progresiva de lenguajes de alto nivel para la programación. La mayoría de los observadores le acreditan el

desarrollo de al menos un factor de cinco en cuanto a productividad, y con un aumento simultáneo de la fiabilidad, simplicidad y comprensibilidad. ¿Qué logra un lenguaje de alto nivel? Libera a un programa de gran parte de su complejidad accidental. Un programa abstracto esta formado por construcciones conceptuales: operaciones, tipos de datos, secuencias y comunicación. El programa concreto involucra bits, registros, divisiones, canales, discos y demases. En la medida en que el alto nivel de lenguaje incorpora las construcciones que uno quiera en el programa abstracto y evite todos los de menor nivel, éste elimina todo un nivel de complejidad que nunca fue inherente al programa en absoluto. Lo máximo que un lenguaje de alto nivel puede hacer es presentar todas las construcciones que el programador imagina en el programa abstracto. Sin duda, el nivel de nuestras ideas acerca de las estructuras de datos, tipos de datos y operaciones está creciendo, pero en una tasa siempre decreciente. Y el desarrollo del lenguaje se acerca cada vez más a la complejidad de los usuarios. Tiempo compartido (multiprogramación): El tiempo compartido significo una gran mejora en la productividad de los programadores y en la calidad de sus productos, aunque no tanto así como la que trajo el lenguaje de alto nivel. El tiempo compartido ataca una dificultad bastante diferente. Este preserva la inmediatez, y por lo tanto permite que se mantenga una visión general de la complejidad. La lenta respuesta de los lotes de programación significa inevitablemente que uno se olvide de detalles minúsculos, si no la propia idea de lo que se pensaba cuando se detuvo la programación y se pidió la compilación y ejecución. Esta interrupción es costosa en tiempo, ya que uno debe refrescarse la memoria. El efecto mas grave puede ser la dificultad para comprender todo lo que esta sucediendo en un sistema complejo. Una lenta rotación, como las complejidades lenguaje-máquina, es una dificultad accidental del proceso de software en vez de esencial. Los límites de la contribución potencial de tiempo compartido se derivan directamente. El efecto principal de la utilización compartida es para acortar el tiempo de respuesta del sistema. Cuando el tiempo de respuesta llega a cero, de alguna forma traspasa el umbral de humano de lo observable, unos 100 milisegundos. Más allá de ese umbral no se esperan beneficios. Entornos de programación unificados: “Unix and Interlisp”, el primer entorno de programación integrado en volverse masivo parece haber mejorado su productividad por factores integrales. ¿Por qué? Ellos atacan las dificultades accidentales que derivan de la utilización de programas individuales juntos, mediante el suministro de bibliotecas integradas, archivos de formato unificado y de tuberías y filtros. Como resultado de esto, las estructuras conceptuales que básicamente podrían siempre llamar, suministrar datos y usarse entre si pueden, de hecho, hacerlo fácil en la práctica. Este avance a su vez estímulo el desarrollo de whole toolbenches, ya que cada nueva herramienta podría aplicarse a cualquier programa que utilice el formato estándar. Debido a estos éxitos, los entornos son objeto de parte importante de las actuales investigaciones de ingeniería software. Veremos lo que promete y sus limitaciones en la siguiente sección. Esperanzas de la Plata

Ahora consideremos los desarrollos técnicos que son considerados como posibles “balas de plata” con mas frecuencia. ¿Qué problemas enfrentan, de esencia o de las dificultades accidentales que permanecen? ¿Ofrecen avances vanguardistas, o en crecientes? Ada y otros avances de lenguaje de alto nivel. Uno de los desarrollos recientes mas anunciados es Ada, un lenguaje de los años 80 de alto nivel y con propósitos generales. Ada no solo refleja mejoras evolutivas en conceptos de lenguajes, sino que de hecho Tal vez la filosofía de Ada es más de un anticipo que el lenguaje Ada, ya que es la filosofía de la modularización, de los tipos abstractos de datos, de jerarquización. Ada es excesivamente sustancioso, un resultado natural del proceso por el que se establecen los requisitos de su diseño. Eso no es fatal, ya que el trabajo d estos vocabularios subordinados puede resolver el problema de aprendizaje. Los vocabularios de trabajo pueden resolver el problema de aprendizaje, y los avances en hardware nos significaran MIPS más baratos para pagar los costos de compilación. Avanzar en la estructuración de sistemas de software es, en efecto, un buen aprovechamiento para los incrementados MIPS que nuestros dólares compraran. Los sistemas operativos, denunciados a toda voz en la década del 60 por su memoria y ciclo de sus costos, ha demostrado ser una excelente forma en la cual usar algunos de los MIPS y bites de memoria baratos, del pasado surgimiento de hardware. No obstante, puede que Ada no resulte ser la bala de plata que mata al monstruo de productividad de software. Es, después de todo, sólo otro lenguaje de alto nivel, y el mayor rendimiento de estas lenguas provienen de la primera transición; la transición de las complejidades accidentales en la maquina al orden mas abstracto de las soluciones “paso a paso”. Una vez que esos accidentes han sido eliminados, los restantes serán menores, y el costo de su remoción será menor. Auguro que dentro de una década a partir de ahora, cuando la eficacia de Ada sea evaluada, se verá que han hecho una diferencia sustancial, pero no por alguna característica particular del lenguaje, ni siquiera por todas ellas en conjunto. Tampoco los nuevos entornos de Ada probaran ser la causa de su mejora. La contribución más grande de Ada será que utilizarlo significara la capacitación de los programadores a modernas técnicas de diseño de software. Programación orientada a objetos: Muchos estudiantes de la técnica tienen mas expectativas en cuanto a programación orientada a objetos que cualquier otra técnica de moda. Yo estoy entre ellos. Mark Sherman de Darmouth nota en CSnet News que uno debe ser cuidadoso para poder distinguir dos ideas separadas que están bajo el titulo “tipos abstractos de datos y tipos jerárquicos”. El concepto de los tipos de dato abstractos se refiere a que un tipo de objeto debe ser definido con un nombre, un conjunto de valores y un conjunto adecuado de operaciones y no por su estructura de almacenamiento, la cual debe ser ocultada. Ejemplos de ello son los paquetes Ada (con clases privadas) y los módulos de Modula. Los tipos jerárquicos, como la clase Simula-67, le permite a uno definir interfaces generales que pueden ser mejoradas mas tarde administrándoles los tipos de subordinación. Los dos conceptos son diagonales; uno puede estar jerarquizado sin disimulo o disimulo sin jerarquización. Ambos conceptos representan verdaderos avances en el arte de crear un software. Cada uno remueve otra dificultad accidental del proceso, permitiéndole al diseñador expresar la esencia del diseño sin tener que expresar una gran cantidad de material sintáctico cuyo contenido no añade información. Para ambos, tipos abstractos y jerárquicos, el resultado es la eliminación de una gran cantidad de dificultades accidentales y la posibilidad de un gran numero de expresiones de diseño.

No obstante, estos avances no pueden hacer más que eliminar las dificultades accidentales de la expresión de diseño. La complejidad del diseño en sí es fundamental, y esos ataques no hacen cambio alguno en eso. Se puede obtener una enorme ganancia de la programación orientada a objetos sólo si tipo y especificación innecesaria en nuestro lenguaje de programación es de nueve décimas del trabajo involucrado en el diseño de un producto de programación. Lo dudo. Inteligencia artificial: Muchas personas esperan el desarrollo en la inteligencia artificial que proporcione el avance revolucionario que significara enormes ganancias en cuanto a productividad y calidad del software. Yo no. Para saber por qué debemos analizar lo que se entiende por “inteligencia artificial”. DL. Parnas ha aclarado el caos terminológico. Dos definiciones muy distintas de IA son comúnmente usadas hoy en día. IA – 1: El uso de computadores para resolver problemas que anteriormente sólo podían ser resueltos mediante la aplicación de la inteligencia humana. IA – 2: El uso de un conjunto específico de técnicas de programación conocida como heurística o programación basada en las normas. En este enfoque se utilizan humanos expertos para determinar las heurísticas o reglas básicas que usan para resolver problemas… El programa es diseñado para resolver un problema de la forma en que los seres humanos parecen hacerlo. Algo puede tener cabida en la definición de Al - 1 de hoy, pero una vez que vemos cómo funciona el programa y comprendemos el problema, no vamos a seguir pensando en él como Al... Lamentablemente no puedo identificar un contenido tecnológico que es único en esta área… La mayor parte del trabajo es de problemas específicos, y se necesita algo de abstracción y creatividad para ver como transferirlos. Yo concuerdo absolutamente con esta crítica. Las técnicas empleadas para el reconocimiento de voz parecen tener poco en común con las que se utilizan para el reconocimiento de imagen, y ambas son diferentes de las utilizadas en sistemas expertos. Me cuesta trabajo ver cómo el reconocimiento de imágenes, por ejemplo, tendrá alguna diferencia notoria en la practica de programación. El mismo problema ocurre con el reconocimiento de voz. Lo difícil en cuanto a la creación de un software decidir qué se quiere decir, no decirlo. Ninguna forma de facilitación de expresiones puede dar mas que ganancias insignificantes. Los sistemas expertos de tecnología IA-2 merecen una sección propia. Sistemas expertos: La parte mas avanzada y que se aplica más ampliamente de la inteligencia artificial es la tecnología para crear sistemas expertos. Muchos científicos de software trabajan duro para aplicar esta tecnología al entorno de la creación de un software. ¿Cuál es el concepto y cuales son las perspectivas? Un “sistema experto” es un programa que contiene un motor de inferencia generalizado y una norma de base, toma de entrada de datos y asunciones, explora las interferencias que derivan de la norma de base, procura conclusiones y consejos, y ofrece explicar los resultados mostrando su razonamiento al usuario. Los motores de inferencia normalmente pueden hacer frente a los datos borrosos o datos probabilísticas y normas, además de la lógica puramente determinista. Tales sistemas ofrecen ventajas claras sobre los algoritmos diseñados para llegar a las mismas soluciones de los mismos problemas:

•

•

La tecnología motor de la inferencia es desarrollada en una forma independiente de aplicaciones, y luego se aplica a muchos usos. Uno puede justificar un gran esfuerzo en la inferencia de los motores. De hecho, es una tecnología muy avanzada. Las partes variables de los materiales característicos de la aplicación están codificados en la norma de base de forma uniforme y se proporcionan herramientas para el desarrollo, la evolución, la prueba y la documentación de la norma de base. Esto regulariza gran parte de la complejidad de la aplicación misma.

El poder de tales sistemas no proviene de mecanismos de inferencia lujosos, sino más bien de mecanismos con bases de conocimiento cada vez mas sustanciosas que reflejan de manera mas precisa el mundo real. Creo que el avance más importante ofrecido por la tecnología es la separación entre la complejidad y programa en sí. ¿Cómo puede esta tecnología ser aplicada a la tarea de ingeniería de software? De muchas formas: Estos sistemas pueden sugerir normas de interfaz, asesoramiento sobre estrategias de experimentación, recordatorios de errores frecuentes, y ofrecer también sugerencias de optimización. Considere la posibilidad de un asesor imaginario de prueba, por ejemplo. En su forma más rudimentaria, podríamos decir q sólo enumera sugerencias en cuanto a las posibles causas de dificultades. Entre mas estructuras del sistema consagren la base de normas, y ésta tome en cuenta mas sofisticadamente los problemas sintomáticos informados, el consejero de prueba se vuelve más y más preciso en las respuestas que genera y las pruebas que recomienda. Un sistema así de especializado se diferencia radicalmente de los sistemas convencionales en que su base de normas debería probablemente ser jerárquicamente modularizada, como lo son los productos software, para que mientras que el producto es modularmente modificado, también lo sea el diagnostico de base de normas. El trabajo necesario para generar las normas de diagnóstico es el que habría que hacer de todos modos al generar el conjunto de casos de prueba para los módulos y para el sistema. Si se hace de una manera adecuada, con una estructura uniforme para las normas y un buen motor de inferencia disponible, puede realmente reducir el total de la generación de mano de obra que significan los casos de prueba, y contribuir así a un mantenimiento de por vida y la modificación de pruebas. De la misma manera, uno puede postular otros asesores, probablemente muchos y de manera simple, para las demás partes de la tarea de construcción de software. A quien desarrolla un programa se le presentan muchas dificultades en el camino por una pronta realización de un útil sistema consejero experto. Una parte fundamental de nuestro imaginario escenario es el desarrollo de formas fáciles de obtener desde la especificación de programas-estructura a la generación automática o semiautomática de las reglas de diagnóstico. Aún más difícil e importante la doble tarea de adquisición de conocimientos: la búsqueda de expertos elocuentes, auto analíticos, que conozcan la razón por la que hacen las cosas, desarrollando técnicas eficientes para la extracción de lo que saben y separando en sus componentes las bases de normas. El prerrequisito esencial para la construcción de un sistema experto es disponer de un experto. La contribución más poderosa de los sistemas expertos, sin duda será poner al servicio de programadores novatos la experiencia y la sabiduría acumulada de los mejores programadores. Esta no es una contribución pequeña. La brecha entre las mejores prácticas de ingeniería de software y las prácticas promedio es inmensa,

talvez la mas grande entre las disciplinas de la ingeniería. Una herramienta que difunde las buenas prácticas sería importante. Programación “Automática”: Por casi 40 años la gente ha estado anticipando y escribiendo acera de la “programación automática” o sobre la generación de programas resolviendo problemas del orden de la especificación de problemas. Algunos actualmente escriben como si esperaran que esta tecnología proporcione el próximo gran avance. Parmas sugiere que el término es usado para el glamour, no por su contenido semántico, afirmando: En resumen, la programación automática siempre ha sido un eufemismo de la programación con un mayor nivel de lenguaje disponible actualmente para el programador. El argumenta, en esencia, que en la mayoría de los casos tiene que ser dada la explicación del método de solución y no del problema en sí. Se pueden encontrar excepciones. La técnica de creación de los generadores es muy potente, y es habitualmente utilizada para traer grandes beneficios en la clasificación de los programas. Algunos sistemas para la integración de ecuaciones diferenciales también han permitido la especificación directa del problema, y los sistemas han evaluado los parámetros, elegidos de una biblioteca de métodos de solución, y los programas generados. Estas aplicaciones tienen propiedades muy favorables: • • •

Los problemas son fácilmente caracterizados por un número relativamente reducido de parámetros. Hay muchos métodos conocidos de solución para proporcionar una biblioteca de alternativas. Amplio análisis ha dado lugar a normas explícitas para la selección de técnicas de solución, dados los parámetros del problema.

Es difícil ver como tales técnicas generalizan a un mundo más amplio el sistema software común, donde los casos con propiedades tan impecables son la excepción. Es difícil incluso imaginar como este avance en la generalización puede pasar. Grafica de la programación: Un tema favorito para la tesis de doctorado en ingeniería de software es programación gráfica o visual, la aplicación de desde gráficos de computador a diseño de software. 6,7 Algunas veces la promesa mantenida por ese enfoque es postulada como una analogía con diseño de circuito integrado VLSI, en el cual gráficos computacionales desempeñan un papel tan provechoso. A veces el teórico justifica la metodología teniendo en cuenta los diagramas de flujo como el ideal programa-diseño y suministrando poderosos planteles para construirlos. Nada ha surgido de tales esfuerzos que resulte convincente, mucho menos emocionante. Estoy convencido de que nada lo hará. En primer lugar, como he argumentado en otra parte, el diagrama de flujo es una abstracción muy mala de la estructura software. De hecho, es mejor visto el intento de Burks, Von Neumann y Goldstine por proporcionar un control de lenguaje de alto nivel tan necesitado para sus propuestas de computador. De la forma lamentable en que el diagrama de flujo ha sido elaborado actualmente, ha demostrado que no

sirve como herramienta de diseño, los programadores dibujan diagramas de flujo después, y no antes, de describir los programas. En segundo lugar, las pantallas de hoy en día son demasiado pequeñas en píxeles para mostrar tanto el alcance como la resolución de cualquier diagrama software verdaderamente detallado. La llamada "metáfora de escritorio" de la actual lugar de trabajo es una metáfora "asiento de avión". Cualquier persona a la que se le hayan desordenado papeles mientras esta en el asiento del medio de un avión entenderá, uno puede ver solo unas pocas cosas a la vez. El verdadero escritorio ofrece una visión general y el acceso al azar a una gran cantidad de páginas. Además, cuando llegan ataques de creatividad, se sabe que más de un programador o escritor ha abandonado el escritorio para estar en algún lugar mas espacioso. La tecnología hardware tendrá que desarrollarse considerablemente antes de que el alcance de nuestras extensiones sea suficiente para el diseño de escritorio de software. Esencialmente, como he argumentado antes, el software es muy difícil de visualizar. Ya sea por los diagramas de control de flujo, referencias variables cruzadas, flujo de datos, estructuras jerárquicas de datos, o lo que sea, uno siente tan solo una dimensión del intrincadamente elaborado software. Si uno fuerza todos los diagramas generados por las muchas visiones relevantes resulta difícil extraer una visión general. La analogía VLSI es esencialmente engañosa, un diseño de circuito integrado es una descripción bidimensional cuya geometría refleja su realización en un espacio tridimensional. Un sistema software no lo es. Verificación de programa: Gran parte de los esfuerzos en la programación moderna van dirigidos a la prueba y reparación de fallos. ¿Se podrá encontrar talvez una bala de plata luego de eliminar los errores en el origen o en la fase de diseño del sistema? ¿Pueden la productividad y la fiabilidad del producto ser radicalmente mejorados, siguiendo así la estrategia tan opuesta de proveer diseños sin errores, antes de derrochar el inmenso esfuerzo en implementarlos y probarlos? No creo que la productividad vaya a encontrar magia aquí. La verificación de programa es un concepto muy poderoso y será muy importante para cosas como un seguro manejo de núcleos de sistema (o kernels). Sin embargo esta tecnología no promete ahorrar mano de obra. Las comprobaciones significan tanto trabajo que tan solo unos pocos programas importantes han sido verificados alguna vez. Verificación de programas no significa que estos sean a prueba de errores. Tampoco hay magia aquí. Las pruebas matemáticas también pueden ser fallidas. Así que aunque la verificación podría reducir la carga de lo que significa probar los programas, no la puede eliminar. Mas grave aún, incluso la verificación de programa perfecta solo puede establecer que un programa cumple su especificación. La parte más difícil de la tarea del software es alcanzar una especificación completa y consistente, y gran parte de la esencia de la creación de un programa de hecho es la depuración de errores en la especificación. Entornos y herramientas: ¿Cuántas ganancias se pueden esperar de la explotación de investigaciones dirigidas hacia mejores entornos de programación? La primera reacción instintiva de uno, es que los grandes problemas de rentabilidad fueron los primeros en ser atacados y han sido resueltos; sistemas jerárquicos de archivos, archivos de formato uniforme para hacer posible interfaces uniformes de programa, y herramientas generales. Los editores inteligentes con lenguaje específico son avances que aun no se utilizan masivamente en la práctica, pero lo máximo que pueden prometer es no tener errores sintácticos ni errores semánticas simples.

Talvez el mayor logro de los entornos de programación será el uso de bases de datos integradas para seguirles el rastro al gran número de detalles que deben ser recordados con precisión por el programador, y mantenido al día por un grupo de colaboradores en un solo sistema. Ciertamente este trabajo vale la pena, y sin duda dará frutos en cuanto a productividad y confiabilidad, pero por su propia naturaleza los beneficios serán insignificantes. Estaciones de trabajo: ¿Qué ganancias puede esperar el material grafico de software del incremento seguro y veloz de la capacidad de memoria y poder de la estación de trabajo individual? ¿Cuántos MIPS pueden ser utilizados fructíferamente? La composición y edición de programas y documentos es totalmente respaldada por today’s speeds. Compiling puede significar un aumento, pero un factor de cada 10 en velocidad de máquina would surely leave thinktime a la actividad dominante en el día del programador. De hecho parece serlo ahora. Ciertamente le damos la bienvenida a estaciones de trabajo más poderosas. No podemos esperar mejoras mágicas de ellas.

Ataques prometedores en la esencia conceptual Aunque ningún avance tecnológico promete una clase de resultados mágicos como a los que estamos acostumbrados en el área del hardware, hay una abundancia de buen trabajo ahora y la promesa de un progreso permanente. Todos los ataques tecnológicos a los accidentes del proceso software están fundamentalmente limitados por la ecuación de productividad: Tiempo de tarea = Σ (frecuencia)i x (tiempo). Si, como se cree, los componentes conceptuales de la tarea están tomando la mayor parte del tiempo, entonces ninguna cantidad de actividad en los componentes de la tarea, que son solamente la expresión de conceptos, puede brindar ganancias considerables. Por lo tanto debemos considerar esos ataques dirigidos a la esencia del problema software, la formulación de esas complejas estructuras conceptuales. Afortunadamente algunos de estos ataques son prometedores. Comprar versus crear: La solución más radical y posible para la construcción de un software es no construirlo. Cada día esto es más fácil, más y más vendedores ofrecen más y mejores productos software para una variedad de aplicaciones. Mientras que nosotros, ingenieros software, hemos trabajado en la metodología de producción, la revolución de los computadores personales ha creado no uno, sino muchos mercados masivos para software. Cada quiosco trae mensualmente revistas, los cuales promocionan docenas de productos a precios que van desde unos pocos dólares a unos cuantos cientos de dólares. Fuentes mas especializadas ofrecen productos mas poderosos para la estación de trabajo y otros mercados “Unix”. Incluso herramientas software y entornos pueden ser traídos listos para su

utilización. Yo he propuesto en todas partes un mercado para los módulos individuales. Cualquiera de estos productos es más barato que construir uno nuevo. Incluso a un costo de cien mil millones de dólares, un software comprado cuesta solo cerca de lo que cuesta un programador por un año. ¡Y la entrega es inmediata! Al menos los productos que realmente existen, productos cuyo creador puede dirigir a un usuario feliz. Mas aun, tales productos tienden a ser mucho mejor certificados y de alguna forma mejor mantenidos que los de creación personal. El desarrollo de los mercados masivos es, según yo, la más profunda tendencia en ingeniería software. El costo de software siempre ha sido costo de programación, y no de replica. Compartir esos costos entre incluso unos pocos usuarios disminuye radicalmente los costos por persona. Otra forma de verlo es que el uso de X cantidad de copias de un sistema software efectivamente multiplica la productividad de sus creadores X cantidad de veces. Eso es una mejora en la productividad de la disciplina y de la nación. El problema clave es, por supuesto, es la aplicación. ¿Puedo yo usar un paquete disponible listo para ser utilizado para hacer mi trabajo? Algo sorprendente ha pasado aquí. Durante los años 50’ y 60’ estudio tras estudio han demostrado que los usuarios no usarían paquetes listos para utilizarse para planillas, inventarios, recibos de cuenta, etc. Los requerimientos eran muy específicos, la diferencia entre casos era muy grande. Durante los 80’ encontramos tales paquetes siendo altamente requeridos y usados masivamente. ¿Qué ha cambiado? No los paquetes. Puede que actualmente sean más generalizados y adaptables que en ese entonces, pero no es mucha la diferencia. Tampoco en las aplicaciones. De hecho las necesidades tecnológicas y de negocios actualmente son mas diversas y complicadas que las de hace 20 años atrás. El gran cambio ha sido en el porcentaje de costos de hardware y software. En 1960 el comprador de una maquina de dos millones de dólares sentía que podía costear $250.000 mas por un programa de planilla personalizado, uno que se escabulla fácilmente en el hostil ambiente social computacional. Hoy en día, el comprador de una maquina de oficina de $50.000 no puede costear un programa de planilla personalizado, asi que adapta el procedimiento de planilla a los paquetes disponibles. Los computadores son tan comunes actualmente que las adaptaciones son acogidas rápidamente. Existen impresionantes excepciones a mi argumento de que la generalización de paquetes de software ha cambiado poco con los años: las hojas de cálculo electrónicas y los sistemas simples de base de datos. Estas poderosas armas se prestan para muchísimos usos, algunos bastante poco ortodoxos. Hay abundantes artículos e incluso libros sobre como afrontar tareas inesperadas con la hoja de cálculo. Un gran numero de aplicaciones que actualmente habrían sido escritas por programas habituales como Cobol o Report Program Generador (programa generador de reportes) son ahora hechos con estas herramientas. Muchos usuarios operan ahora sus computadores a diario en varias aplicaciones sin siquiera escribir un programa. De hecho, muchos de esos usuarios no pueden escribir nuevos programas para sus maquinas, pero sin embargo han logrado resolver nuevos problemas con ellos. Yo creo que la estrategia productiva mas poderosa de software para muchas organizaciones hoy en día es la de equipar el sencillo intelecto computacional de los trabajadores que están en la línea de fuego con computadores personales y un buenos programas de escritura, dibujo, fichero y hoja de calculo y después dejarlos

libres. La misma estrategia llevada a cabo con estrategias generalizadas de matemáticas y paquetes estadísticos y algunas capacidades simples de programación también funcionara para cientos de científicos de laboratorio. Requerimientos, refinamiento y rápida creación de prototipos La parte más difícil en la creación de un sistema software es decidir precisamente qué construir. Ninguna otra parte del trabajo conceptual es tan difícil como establecer los detallados requerimientos técnicos, incluyendo todas las interfaces a las personas, maquinas y otros sistemas de software. Ninguna otra parte del trabajo paraliza los resultados del trabajo si se hace mal. Ninguna otra parte es mas difícil de arreglar después. Por lo tanto, la función mas importante que el creador de software desempeña para el cliente es la extracción iterativa y refinamiento de los requerimientos del producto. La verdad es que el cliente no sabe lo que quiere. El cliente normalmente no sabe que respuestas deben ser contestadas, y casi nunca piensa en el problema en el detalle tan importante de la especificación. Incluso la simple respuesta “has que el nuevo sistema software funcione como nuestro antiguo manual de información y procesos del sistema” es de hecho demasiado simple. Uno nunca quiere exactamente eso. Sistemas software complejos son, además, cosas que actúan, se mueven, trabajan. La dinámica de esas acciones es difícil de imaginar. Así es que para planear cualquier diseño software es necesario permitir una extensa iteración entre el cliente y el diseñador como parte de la definición del sistema. Iría más lejos y sostendría que es realmente imposible para un cliente, incluso que trabaje con ingeniería software, especificar de manera completa, precisa y correcta los exactos requerimientos de un producto software moderno antes de probar algunas versiones del producto. Por lo tanto, uno de los esfuerzos tecnológicos más prometedores que ataca la esencia y no los accidentes del problema software es el desarrollo de aproximaciones y herramientas para la rápida creación de prototipos de sistemas ya que la creación de prototipos es parte de la iterativa especificación de requerimientos. Un “sistema software prototipo” es uno que simula las interfaces importantes y desempeña las funciones principales del software deseado, mientras que no es necesario estar ligado por la misma velocidad, tamaño o limitaciones de costo de hardware. Los prototipos normalmente ejecutan las tareas principales de la aplicación, pero no pretenden tratar las tareas excepcionales, respondiendo correctamente a inválidas entradas de datos o abortar impecablemente. El propósito del prototipo es hacer real la estructura conceptual especificada, para que el cliente pueda probar su consistencia y utilidad. Muchas de los actuales procedimientos software se apoyan en la suposición de que uno pueda especificar un sistema satisfactorio por adelantado, ayudando a su construcción, teniéndolo listo e instalándolo. Grandes diseñadores: Podemos tener buenos diseños si seguimos buenas prácticas. Las prácticas para un buen diseño pueden ser difíciles. Los programadores están entre la parte mas inteligente de la población, así que pueden aprender buenas practicas. En EEUU se esta haciendo un esfuerzo por promulgar las practicas modernas. Nuevos planes de estudio, nueva literatura, nuevas organizaciones como Software Engineering Institute, todas con el fin de aumentar el nivel de nuestra práctica.

Sin embargo, no creo que podamos subir un nivel. Ya sea que la diferencia entre diseños pobres y conceptuales yazca en el método de diseño, la diferencia entre diseños buenos y excelentes seguramente no. Grandes diseños vienen de grandes diseñadores. La construcción de un software es un proceso creativo. Metodologías sólidas pueden fortalecer y liberar la mente creativa; no puede inspirar el trabajo duro. Las diferencias no son menores (son como las diferencias entre Salieri y Mozart). Estudio tras estudio muestra que los mejores diseñadores producen estructuras que son mas rapidas, mas pequeñas, mas simples, mas pulcras y son producidas con menor esfuerzo. Las diferencias entre el gran diseñador y el promedio son enormes. Un poco de retrospección muestra que aunque muchos software buenos y útiles han sido diseñados por comités y creados como parte de proyectos (multipartes), esos sistemas software que han entusiasmado fans son el producto de una o pocas mentes diseñadoras. Consideremos Unix, APL, Pascal, Modula, la interfase Smalltalk, incluso Fortran; y contrastémoslos con Cobol, PL/I, Algol, MVS/370, y MS-DOS. Por lo tanto, aunque yo apoyo fuertemente los esfuerzos en el desarrollo en el plan de estudios que se estan desarrollando actualmente, creo que el esfuerzo mas importante que podemos (trepar) es el desarrollo de métodos para aumentar grandes diseñadores. Ninguna organización software puede ignorar este desafió. Buenos gerentes no son tan escasos como los buenos diseñadores. Grandes gerentes y grandes diseñadores son ambos muy escasos. La mayoría de las organizaciones hace considerables esfuerzos por encontrar los prospectos administrativos; no conozco ninguna que haga el mismo esfuerzo en encontrar grandes diseñadores de los que la excelencia de sus productos depende. Mi primera propuesta es que cada organización software debe determinar y proclamar que los grandes diseñadores son tan importantes para su progreso como lo son los gerentes, y que deben ser igualmente fomentados y recompensados. No solo en cuanto al salario, también gratificaciones de reconocimiento deben ser equivalentes: tamaño de la oficina, amoblado, equipo técnico personal, fondos de viaje, equipo de apoyo. ¿Como aumentar a los grandes diseñadores? -Identificar sistemáticamente a los mejores diseñadores lo mas pronto posible. Los mejores no siempre son los más experimentados. -asignar un orientador profesional para que se haga responsable por el desarrollo del prospecto. -desarrollar y mantener un plan profesional de desarrollo para cada prospecto -dar oportunidades de crecimiento a los diseñadores, para que interactúen y se estimulen entre si.

Unidad 2: Proceso de Desarrollo Iterativo e Incremental: Unificado de Desarrollo 2.1 Modelo de proceso En el módulo 1 hemos visto el concepto de modelo relacionado con el ciclo de vida de desarrollo de software. Este modelo es una forma de representar la realidad de una manera simplificada, lo que permite entender más fácilmente las actividades que se deben realizar. Todos los negocios, empresas e instituciones tienen procesos de negocio que son informatizados, por lo que los responsables de capturar los requerimientos y necesidades del cliente deben conocer estos procesos, entenderlos y modelarlos. La importancia de modelar los procesos de negocio es para todas las personas involucradas en el proceso, al igual que para el cliente que valida si se entendió bien el proceso. La forma de modelar el proceso es importante ya que tiene que ser simple y a la vez claro, con el nivel de detalle necesario para que no queden dudas, sin llegar a un nivel de complejidad que dificulte el entendimiento del mismo.

2.1.1. Concepto de Proceso como una plantilla Si los procesos tienen que ser conocidos por más de una persona y tienen que ser claros y entendibles, se debería pensar en una forma estándar de representación. Si bien cada empresa puede adquirir una forma de representación, la que sea más adecuada, según las características de los RRHH, el contexto y factores como normas de certificación en calidad de procesos, esto puede diferir de un lugar a otro. Las plantillas de procesos definen aspectos claves que ayudan al equipo que se integra a un proyecto. La plantilla se personaliza de acuerdo al lugar donde se utilice, las características del equipo y las normas de calidad a que responden. Una plantilla de proceso puede definir tanto las actividades de un proceso de negocio como las opciones de seguridad para controlar su proyecto y el funcionamiento del equipo. Veamos algunas características de seguridad: 

Definir las plantillas y que estén disponibles en un portal del proyecto.



Definir y exigir las notas de protección del control de código fuente, para que no se pierdan versiones ni estén almacenadas en lugares que no son accesibles por todos los integrantes del equipo.



Definir los tipos de elemento de trabajo y las consultas disponibles.



Definir los informes para supervisar el progreso y crear un informe de estado.



Definir las iteraciones y las unidades organizativas que se utilizan.

Materia: Ingeniería de Software Profesora: Lic. Adriana Pérez

-1-

Si lo que tenemos que representar es un proceso de negocio que tiene que ver con un requerimiento funcional del sistema, tenemos que plasmarlo en la plantilla de procesos para que quede documentado. ¿Qué diferencias existen entre proceso, procedimiento e instructivo? No todas las empresas e instituciones tienen definidas las tareas necesarias para realizar una actividad o más grave aún, no tienen el diseño de los procesos fundamentales. Por ejemplo, una empresa que se dedica a la comercialización de productos debería tener definido y diseñado al menos los procesos de compra y el de ventas, que son los centrales de su actividad. Esto depende de la madurez de la empresa y de los empleados, ya que de ellos depende en gran parte que se cumpla el proceso tal como está definido. Otras tantas empresas tienen establecidas algunas formas para realizar el trabajo, desde tareas ligeramente organizadas hasta sistemas enormemente formalizados. Estos métodos o formas para realizar el trabajo se denominan procesos. Los procesos no pueden ser estáticos, se van desarrollando a lo largo del tiempo para satisfacer las necesidades de las empresas y contribuir a la eficiencia en su funcionamiento. Un proceso está compuesto por macro actividades, las cuales contienen actividades organizadas, si las actividades son varias y tienen algún orden lógico de ejecución, alternativas o controles que realizar, se pueden explotar en “Procedimientos”. Un procedimiento entonces es un conjunto de tareas que nos indica qué debemos realizar para que se cumpla eficientemente la macro tarea del proceso. Por ejemplo, en el Proceso de Venta de Productos, las actividades centrales las podríamos definir como: 1. Cliente: solicita el producto. 2. Vendedor: ofrece el producto 3. Cliente: define si lo compra. 4. Vendedor: realiza la factura. 5. Cliente: abona 6. Empaque: entrega el producto. La actividad “Ofrecer el producto” implica una serie de actividades, como fijarse si hay en stock, el precio, buscarlo, otros. Estas tareas definen el “Procedimiento de Ofrecer el producto”. Si para la actividad de “Fijarse si hay en stock”, el vendedor debe realizar acciones bien definidas, como por ejemplo, entrar al sistema, cargar el código del producto, fijarse si hay stock libre o comprometido o si no hay y tomar la decisión de ofrecer o no, es parte del Instructivo. De este modo, el “Instructivo” indica “cómo” se debe realizar una acción de un procedimiento o proceso, es la mínima expresión, la que tiene mayor detalle. Plantillas de procesos Cuando hablamos de plantillas de procesos no nos referimos sólo a una sino a varias plantillas. Estas plantillas indican cómo se configura el proyecto. Cada una de estas plantillas ofrece un conjunto predeterminado de elementos de trabajo, según estos, podremos encontrar las plantillas de procesos, de procedimientos, de instructivos, de documentos, de informes, entre los más usados.

Materia: Ingeniería de Software Profesora: Lic. Adriana Pérez

-2-

¿Cómo diseñamos una plantilla de proceso? Entre todas las plantillas que utiliza una empresa, nos centramos en la plantilla de proceso. Para diseñar una plantilla de proceso debemos tener en cuenta qué datos debe contener:       

 

Nombre: Un nombre claro que identifique al proceso. Código: el código normalmente está compuesto por 3 letras, las mismas para todos los procesos, por ejemplo, PRC (PROCESO), seguido de la nomenclatura que identifique a cada uno. Objetivo: determina el objetivo del proceso. Alcance: qué áreas, procesos y roles involucra en el proceso. Relaciones: Con qué procesos y procedimientos se relaciona, de entrada y de salida. Documentos asociados: de entrada y de salida Desarrollo: identifica las actividades a realizar, el orden y quién es el responsable o Número de paso o Actividad o Responsable. Indicadores: son los parámetros o fórmulas que se utilizan para poder medir al proceso. Anexo: Lo que se agrega que aporta más información o grado de detalle para su mejor entendimiento. o Glosario: las palabras que necesitan aclarar su significado. o Gráfico: lo que se detalló en el desarrollo en forma de Diagrama de flujo o alguna otra metodología que permita visualizar el proceso.

Recuerde que la plantilla es el marco para todos los procesos, donde cada registro llena los campos con lo específico del proceso que se está diseñando. Control de cambios Con el uso de los procesos puede ser que necesite realizar algún cambio en la plantilla o en el proceso; este cambio debe quedar documentado, para ello se establece una plantilla de “Control de cambio” donde se deja asentado el documento en el que se está realizando el cambio, el texto anterior y el nuevo texto. Este control de cambio es fundamental para tener versionados los documentos y la trazabilidad de los mismos. Datos indispensables de la plantilla de “Control de cambio”:  Proceso.  Documento.  Razón de cambio.  Texto original.  Nuevo texto.  Página donde está el texto. Estos datos se repiten en un mismo documento de “Control de cambio” por proceso o por documento, quedando reflejado el historial de cambios.

Materia: Ingeniería de Software Profesora: Lic. Adriana Pérez

-3-

Administrador de plantilla de procesos Todas las plantillas y documentos generados a partir de ellas deben estar almacenadas de forma tal que permitan la utilización de los integrantes del equipo, para ello es conveniente designar un responsable de dicha tarea, que será el encargado de la “Administración” de la documentación y sus cambios. Complementos de plantilla de procesos Los complementos de plantilla de procesos son componentes que se ejecutan cuando se crea un nuevo proyecto de equipo, pueden estar definidos con anterioridad o con el proyecto. Un complemento instala los archivos necesarios o configura los datos para su área. Por ejemplo, el complemento Seguimiento de elementos de trabajo configura tipos de elemento de trabajo, consultas y elementos de trabajo iniciales para un nuevo proyecto. En general podemos encontrar los siguientes datos de los complementos de procesos: Complemento de plantilla de procesos

Descripción

Clasificación

Define las iteraciones y las áreas iniciales de un proyecto y del equipo.

Grupos y permisos

Define los grupos de seguridad iniciales de los integrantes del equipo de proyecto y sus permisos.

Herramienta a utilizar

Define las herramientas a utilizar para los complementos diseñados

Seguimiento de elementos de trabajo

Define los tipos de elemento de trabajo iniciales de un proyecto, consultas e instancias del elemento de trabajo.

Informes

Define los informes iniciales de un proyecto y configura el lugar de almacenamiento del informe.

Control de versiones

Define los permisos de seguridad de control de versiones iniciales de un proyecto y los cambios realizados en los documentos.

Archivos de definición de procesos Los archivos de definición de procesos son un conjunto de archivos que definen un agregado de tareas que deben ejecutarse para llevar a cabo una función específica. En el caso del proceso de desarrollo de software, se emplean los archivos de procesos, de procedimientos, de instructivos, control de cambio y toda aquella documentación que se defina en cada etapa del proceso.

2.1.2. Concepto de actividades y etapas o flujos de trabajo Cuando se realiza cualquier trabajo se piensa en las actividades o tareas que se deben realizar para lograr el objetivo planteado y cómo podemos organizar estas actividades o tareas,

Materia: Ingeniería de Software Profesora: Lic. Adriana Pérez

-4-

normalmente en etapas. Pero nos detenemos a pensar previamente, en cuál es la diferencia que existe entre tarea y actividad. Veamos primero qué nos dice la Real Academia Española sobre estos significados. Actividad: 1. f. Facultad de obrar. 2. f. Diligencia, eficacia. 3. f. Prontitud en el obrar. 4. f. Conjunto de operaciones o tareas propias de una persona o entidad. Tarea: 1. f. Obra o trabajo. 2. f. Trabajo que debe hacerse en tiempo limitado.

Etapa: 3. f. Fase en el desarrollo de una acción u obra.

Acción: 1. f. Ejercicio de la posibilidad de hacer. 2. f. Resultado de hacer. Como se puede apreciar, todos los términos hacen referencia a realizar un trabajo, sólo que en diferentes grado de detalle o generalización. No es necesario filosofar sobre los conceptos de acción y tarea, las dos llevan a la concreción de una actividad. De las definiciones de la Real Academia Española rescato los siguientes conceptos: Actividad: Conjunto de operaciones o tareas propias de una persona o entidad, nos indica que la actividad está compuesta por varias tareas, por ejemplo, la actividad „realizar un dibujo‟, implicará ver cuáles son las tareas o acciones que debe realizar para lograr el objetivo. Tarea: Trabajo que debe hacerse en tiempo limitado. Esta definición aporta el concepto de tiempo asociado a la tarea, lo que indica que una tarea no puede disponer de infinito tiempo, nos sugiere el concepto de eficiencia, tarea realizada en tiempo y forma. Si la actividad lleva asociada un conjunto de numerosas a tareas, es conveniente organizarla de forma que se vallan cumpliendo etapas. Estas etapas representan un flujo de trabajo. Flujo de trabajo es el estudio de los aspectos operacionales de una actividad de trabajo. ¿Qué es Workflow? Se define Workflow al flujo de trabajo a seguir para la consecución de una tarea o trabajo predeterminado. El flujo de trabajo determina cómo se estructuran las tareas, cómo se realizan,

Materia: Ingeniería de Software Profesora: Lic. Adriana Pérez

-5-

cuál es su orden correlativo, cómo se sincronizan, cómo fluye la información que soporta las tareas y cómo se le hace seguimiento al cumplimiento de las tareas. También se puede definir como un sistema de secuencia de tareas de un proceso de negocio. Su definición y control puede ser manual, informatizado o mixto. Organiza y controla tareas, recursos y reglas necesarias para completar el proceso de negocio. Las nuevas tendencias en la regulación de las organizaciones, hacen del Workflow una herramienta clave para lograr mayor agilidad y aumentar la descentralización de las actividades administrativas y comerciales. La importancia del Workflow consiste en buscar la máxima automatización de los procesos de trabajo y el control total de las diferentes etapas, durante las cuales los documentos, la información o las tareas pasan de un participante a otro, o sea de un rol a otro, según unas normas o procedimientos previamente definidos. En estos últimos años, se han ido desarrollando diversas aplicaciones de software, muchas de ellas han evolucionado a partir de sistemas de gestión, ya sea de imagen, sistemas de gestión de documentos, sistema de gestión administrativa, gestión comercial, sistemas de correo electrónico o de bases de datos. Comparemos ahora los sistemas tradicionales con los sistemas basados en Workflow: Objetivos Sistemas de Información tradicional:  Mejorar la productividad  Aumentar la calidad del trabajo  Reducir costes El ámbito de un Sistema de Información tradicional está determinado por:  Modelo de datos  Funciones independientes. La principal limitación asociada a los Sistemas de Información (S.I.) tradicionales es que, no contemplan los procedimientos, organización y métodos de trabajo del sistema real. Cuando las organizaciones no cuentan con el estudio de los procedimientos organizativos se derivan los siguientes problemas:  Necesidad de adaptar los procedimientos organizativos al sistema de información  Posibilidad de conflicto entre los procedimientos organizativos y los módulos funcionales  Falta de control sobre las actividades de la organización como un todo. Recordemos que una aplicación de Flujos de Trabajo (Workflow) permite automatizar la secuencia de acciones, actividades o tareas utilizadas para la ejecución del proceso, incluyendo el seguimiento del estado de cada una de sus etapas y la aportación de las herramientas necesarias para su gestión. Los objetivos de un sistema de Workflow son:  Reflejar, automatizar y mecanizar los métodos y su organización en el sistema de información  Establecer los mecanismos de control y de seguimiento de los procedimientos organizativos

Materia: Ingeniería de Software Profesora: Lic. Adriana Pérez

-6-

 

Independizar el método y flujo de trabajo de las personas que lo ejecutan Soportar procesos de reingeniería de negocio

Dentro del Workflow se pueden distinguir tres tipos de actividades:  Actividades colaborativas: Un conjunto de usuarios trabajan sobre un mismo repositorio de datos para obtener un resultado común.  Actividades cooperativas: Un conjunto de usuarios trabajan sobre su propio conjunto particular, estableciendo los mecanismos de cooperación entre ellos. El trabajo individual es visto desde el punto de vista global del resultado final.  Actividades de coordinación: se establece cómo será el trabajo cooperativo entre los individuos. Veamos una imagen que representa al Workflow, sus elementos y relaciones:

Para implementar un trabajo basado en Workflow es necesario reconocer sus elementos de trabajo: 



Infraestructura necesaria, para lograr el ambiente colaborativo, para ello es necesario: o Establecer una comunicación mediante herramientas de mensajería electrónica o Un entornos de trabajo con información y recursos compartidos o Una herramienta global que permita la coordinación de ambos entornos de trabajo Contar con tecnologías necesarias que faciliten el trabajo: o Es necesario contar con un contenedor dinámico de objetos o Modelo de acceso y distribución de la información o Infraestructura para el desarrollo de aplicaciones y procesos de negocio, que puede ser una herramienta que integre los recursos externos y las aplicaciones interempresariales.

Veamos ahora los elementos constitutivos de ambos sistemas. Elementos S.I. tradicional:  Entidades, Funciones, Flujos de datos, Tablas, Módulos, Columnas, entre otros.

Materia: Ingeniería de Software Profesora: Lic. Adriana Pérez

-7-

Elementos S.I. Workflow:  Procesos, conjunto de actividades organizadas.  Rutas, secuencia de las actividades.  Reglas, tanto de negocio como de los procedimientos o las que se establezcan como necesarias.  Roles, no como cargos funcionales sino como actor de una actividad  Políticas, que pueden ser de seguridad o del tipo de empresa o institución. En la actualidad existen herramientas de software que contemplan el trabajo bajo el modelo de Workflow. Veamos en una gráfica lo que cuentan estas herramientas.

2.1.3. Componentes del proceso Se entiende por componente al “elemento que compone o entra en la composición de un todo”. Los procesos están compuestos por elementos, entre los más importantes identificamos a:  las acciones,  las personas responsables de realizar las acciones,  los materiales,  equipamiento,  procedimientos,  Documentación. Todos los componentes del proceso son igualmente importantes, aunque la actividad y quien la realiza parecen ser fundamentales, sin estos componentes no tenemos proceso alguno.

2.1.4. Procesos especializados Los procesos definen el funcionamiento interno de una empresa o institución; dentro de los procesos de negocio se pueden identificar los procesos centrales, también llamados procesos claves, los procesos estratégicos, los de la alta gerencia y los de apoyo, aquellos que acompañan a los procesos centrales.

Materia: Ingeniería de Software Profesora: Lic. Adriana Pérez

-8-

Por ejemplo, una empresa que se dedica a la comercialización de productos, tendrá como proceso clave el de ventas, mientras que de apoyo puede ser el proceso de despacho o el administrativo. Todo proceso tiene un inicio y un fin, puede decirse que el proceso de venta finaliza cuando el cliente compró el producto solicitado. Pero ya hace unos años que ha cobrado mucha importancia el cliente y la relación con la empresa; si se quiere atender a la calidad de la atención al cliente es conveniente ver el límite del proceso más allá del momento de la facturación y su partida, cobra importancia el servicio de post venta, lo que implica un seguimiento considerando que el cliente queda en relación con la empresa. Este tipo de proceso que se especializa puntualmente en algo, es considerado proceso especializado, como lo es un CRM (“Customer Relationship Management” o en español, “Gerenciamiento Relacionado al Cliente”.) En todas las disciplinas existen “Procesos especializados”, es muy importante detectarlos y tratarlos como tal, es decir, ser especialistas en una cosa, esto es lo que no se debe perder.

2.1.5. ¿Cómo se construye un proceso de desarrollo de software? Un proceso de desarrollo de software se construye a partir de los lineamientos de la teoría de procesos, la cual puede incluir la visión de Workflow. Recordemos los conceptos que vio en el Módulo 1, sobre Proceso de desarrollo de software. Definición: Conjunto estructurado de actividades para desarrollar un sistema de software. Estas actividades varían dependiendo de la organización y el tipo de sistema que debe desarrollarse. Debe ser explícitamente modelado si va a ser administrado. Pilares en el desarrollo de software PROCESO PERSONAL Participante

Plantilla

HERRAMIENTAS

PROYECTO

Automatización

Resultado

PRODUCTO

¿Qué se espera de un proceso de software? De un proceso de software se espera que sea capaz de evolucionar y que durante su evolución se limite por:

Materia: Ingeniería de Software Profesora: Lic. Adriana Pérez

-9-

   

la tecnología las herramientas la gente los patrones organizacionales

El proceso de software debería comportarse de una manera definida y dinámica, permitiendo:    

Utilizarse con una variedad de ciclos de vida. Seleccionar los artefactos a producir. Definir actividades y personas participantes. Modelar conceptos.

¿Cuál es el criterio que se debe tener para definir un proceso de desarrollo de software? En la definición de un proceso de desarrollo de software se identifican elementos del proceso que responden a una pregunta bien definida, veamos algunos de los elementos más importantes del proceso:  Propósito, ¿Por qué se realizó el proceso?  Entrada, ¿Qué productos de trabajo se utilizan?  Salida, ¿Qué productos de trabajo se generan?  Rol, ¿Quién o qué realiza la actividad definida en el proceso?  Actividad, ¿Qué se hace?  Criterio de entrada, ¿Cuándo puede iniciarse el proceso?  Criterio de salida, ¿Cuándo puede considerarse un proceso completo?  Procedimiento, ¿Cómo son implementadas las actividades?

2.1.6. ¿Cómo se adapta un proceso de desarrollo a un proyecto real? Todo proyecto que se genera en el ámbito profesional responde a una situación particular, dada en un contexto y una realidad. Si el proyecto tiene como objetivo obtener un producto de software, entonces tiene asociado el proceso de desarrollo de software. Cada proyecto es único, aunque sea semejante a otro, siempre posee alguna característica o regla que lo diferencia de otro, no obstante el proceso de desarrollo ya está definido y puede aplicarse a cualquier proyecto. Para ello tiene que permitir elegir cualquier metodología relacionada con los distintos ciclos de vida, por lo cual se basa en las actividades básicas definidas en el proceso. Actividades del proceso de desarrollo de software Las cuatro actividades o etapas básicas del proceso se organizan de forma distinta en diferentes procesos, estas actividades son:  Especificación  Desarrollo  Validación y  Evolución. En el enfoque en cascada se organizan de forma secuencial, mientras que en el desarrollo evolutivo se entrelazan, esto depende del tipo de software, de las personas y de la estructura organizacional implicada, expresa Sommerville, (Ingeniería de Software, Pág. 84)

Materia: Ingeniería de Software Profesora: Lic. Adriana Pérez

- 10 -

Etapa de especificación del software Esta etapa, por ser la primera, es muy importante, es el proceso de comprensión del problema y definición de los servicios que requiere el sistema, como así también la identificación de las restricciones de funcionamiento y de desarrollo. En esta etapa no sólo se realiza la captura de los requerimientos, sino que también se realiza el análisis de los mismos. Los contenidos de esta etapa se profundizarán en el módulo 3. Existen 4 fases principales en el proceso de Ingeniería de requerimientos: 1- Estudio de viabilidad, se estima si las necesidades del cliente se pueden satisfacer. 2- Obtención y análisis de requerimientos, se utilizan distintas técnicas de recolección de datos e información, que luego es analizada. 3- Especificación de requerimientos, se describe la lista de requerimientos en un documento. 4- Validación del requerimiento, se comprueba si es correcta la lista de requerimientos con el cliente. Etapa de diseño e implementación del software La etapa de implementación del software incluye a los procesos de diseño y construcción del software, ya que es el proceso de convertir una especificación del sistema en un sistema ejecutable. Esta etapa varía según el enfoque de ciclo de vida adoptado, por ejemplo, en un enfoque en cascada se implementará un ejecutable que contiene el total de las especificaciones diseñadas y programadas, mientras que en un enfoque evolutivo implicará un refinamiento de las especificaciones del software. Diseño La actividad de diseño involucra a los datos, subsistemas, componentes e interfaces, tanto internas como externas que requiere la especificación de los requerimientos. Las actividades específicas del proceso de diseño son: 1- Diseño arquitectónico, intervienen los subsistemas y componentes que forman el sistema y sus relaciones, identificándolas y documentándola. 2- Especificación abstracta, se abstraen los servicios y restricciones bajo las cuales debe funcionar el sistema. 3- Diseño de interfaz, para cada subsistema se diseña y documenta su interfaz con otros subsistemas. También se diseñan los prototipos de interfaz con el usuario. 4- Diseño de componentes, se asignan servicios a los componentes y se diseñan sus interfaces. 5- Diseño de la estructura de datos, se diseña la base de datos a utilizar y la relación con las estructuras ya existentes. 6- Diseño de algoritmos, se realiza el diseño detallado de los algoritmos a utilizar. Esta definición de actividades varía dependiendo de la metodología que se esté utilizando, en un modelo muy estructurado aparecerán todas, haciendo el proceso muy pesado en cuanto a tiempos de documentación, mientras que en metodologías ágiles, más livianas, la documentación

Materia: Ingeniería de Software Profesora: Lic. Adriana Pérez

- 11 -

disminuye y las algunas actividades se elimina, como por ejemplo, la especificación abstracta y el diseño de algoritmos. Desarrollo La actividad de desarrollo sigue naturalmente a la etapa de diseño. El desarrollo del software es el proceso de codificación en un lenguaje de computación, de los requerimientos definidos, analizados y diseñados. Al programador le llega la documentación de los requerimientos y es su responsabilidad transformarlos en un programa ejecutable. Al finalizar su programación es necesario que realice la comprobación de su funcionamiento, es decir, el chequeo de que su trabajo está bien realizado, que el programa funciona correctamente y que cumple con las especificaciones, o sea verifica los requerimientos, que no se hayan efectuados cambios. Este es el momento en que se pueden encontrar errores, es el mismo programador el que los depura hasta llegar a una versión confiable. Las herramientas CASE se pueden utilizar para generar un programa esqueleto a partir del diseño, esto incluye código para definir e implementar las interfaces, necesitando el programador solo agregar detalles de código. Etapa de Validación del software La validación del software es la etapa en la que se realizan comprobaciones. En general se conoce como V & V, verificación y validación, se utiliza para mostrar que el sistema se ajusta a su especificación y que cumple las expectativas del cliente. Esta etapa implica procesos de comprobación de requerimientos, en el seguimiento de las etapas. Este proceso se puede realizar al final del proceso de desarrollo o bien después de cada etapa, como lo muestra el modelo V.

Las etapas del proceso de prueba son: 1- Prueba de componentes, se prueban los componentes individuales para verificar que funcionan correctamente. 2- Prueba del sistema, se realiza la prueba del sistema integrando todos los componentes. Se realizan todos los tipos de pruebas de acuerdo a lo planificado en el proyecto, además

Materia: Ingeniería de Software Profesora: Lic. Adriana Pérez

- 12 -

de la validación para comprobar que el sistema cumple con los requerimientos funcionales y no funcionales definidos en la etapa de especificación. 3- Prueba de aceptación, parte final del proceso donde se prueba con los datos proporcionados por el cliente, antes de su aceptación final. Etapa de evolución del software Una vez entregado el producto de software al cliente se comienza a usar; esta etapa es muy importante ya que el cliente se dará cuenta si hay algún requerimiento para refinar, agregar o cambiar, estos sucesos hacen a la evolución del software. Si el software informatiza los procesos de negocio y estos son dinámicos es lógico pensar que el software también debe serlo, es por ello que habrá cambios en el software. Es la etapa lleva más tiempo en el proceso de desarrollo de software, porque se mantiene en el tiempo. El problema de esta etapa es que muchas veces se confunde mantenimiento de la evolución del software con mantenimiento de arreglo de errores del software. Si el software fue entregado al cliente con errores significa que no cumplió con las etapas del proceso correctamente, sobre todo la de prueba de software, lo cual lleva a muchos problemas:  Cliente desconforme  Producto que no es de calidad  Tiempo perdido en recodificación del software  Gasto operativo que se incrementa sin poder medir las pérdidas  No se puede cobrar al cliente el costo de la resolución de errores.  Nuevamente crisis del software. Hagamos un breve resumen de los contenidos aprendidos hasta aquí. Los temas tratados en este Módulo tienen que ver directamente con la Ingeniería de software y su relación con los procesos. Hemos visto el concepto de proceso desde la visión del negocio y del proceso de desarrollo de software, con un enfoque tradicional y desde el enfoque de Workflow. Tenga en cuenta los puntos clave que remarcamos a continuación:  Todos los procesos representan algún flujo de trabajo que implica actividades organizadas de algún modo con personas responsables de ejecutarlas.  Los flujos de trabajo como Workflow representan mejor la realidad de los procesos, dan una vista horizontal del mismo, con lo que un actor no es sólo responsable de su actividad, sino que es responsable del proceso, en cuanto que hay otro actor que depende de que su actividad esté resuelta satisfactoriamente.  Los procesos de software son las actividades relacionadas con la producción de un sistema de software.  Todos los procesos de software incluyen las etapas fundamentales: especificación, implementación, prueba y evolución.  La validación y verificación de los requerimientos es necesaria para que el producto de software a entregar cumpla con las expectativas del cliente.

Materia: Ingeniería de Software Profesora: Lic. Adriana Pérez

- 13 -

2.2 El Proceso Unificado de Desarrollo de Software Es un entorno de proceso genérico (Framework) que puede especializarse para una gran variedad de sistemas de software, en diversas áreas de aplicación, distintos tipos de organización y de tamaños de proyectos. Proceso Unificado de Desarrollo de Software está asociado con “El Proceso Unificado de Racional” (RUP) que es un ejemplo de modelo de proceso moderno que proviene del UML (Lenguaje de Modelado Unificado).

El Proceso Unificado de Racional El Proceso Unificado de Racional reúne elementos de todos los modelos de procesos genéricos, iteraciones de apoyo y utiliza buenas prácticas en la especificación y el diseño. El RUP, a diferencia de los procesos genéricos que presentan un solo enfoque, se describe desde 3 perspectivas: 1- Desde una perspectiva dinámica que muestra las fases del modelo en el tiempo. 2- Desde una perspectiva estática que muestra las actividades del proceso. 3- Desde una perspectiva práctica que sugiere buenas prácticas a utilizar durante el proceso. El RUP es un modelo en fases que identifica cuatro fases diferentes en el proceso de software relacionadas con asuntos de negocio: 1. Inicio, su objetivo es establecer un caso de negocio para el sistema, identificando todas las entidades externas, ya sean personas y/o sistemas, que interactúan con el sistema y determinar cómo se presentan dichas interacciones. Esta fase presenta lo que el sistema aporta al negocio. 2. Elaboración, su objetivo es presentar el dominio del sistema, establecer un marco de trabajo arquitectónico, desarrollar el plan del proyecto e identificar los riesgos. Finalizada la fase se debe contar con un plan de proyecto, la especificación de requerimientos, los casos de uso y una descripción arquitectónica. 3. Construcción, esta fase comprende el diseño a programación y las pruebas del sistema, integrando las partes y obteniendo un sistema de software operativo y su documentación. 4. Transición, esta fase comprende la actividad de instalar el sistema en un entorno real para su uso, es decir que pasa del entorno del programador al del usuario final. Como no se cuenta con el 100% de los requerimientos, estas fases se presentan de forma iterativa e incremental. La vista estática se centra en las actividades que realizan en la etapa de desarrollo, denominándose “flujos de trabajo”, apoyados por los diagramas de UML. La vista dinámica acompaña a la estática presentando os flujos de trabajo en el tiempo, haciendo que ambas no estén asociadas a flujos de trabajo específicos. Las buenas prácticas que presenta RUP El RUP recomienda seis buenas prácticas de la Ingeniería del software en el desarrollo de sistemas:

Materia: Ingeniería de Software Profesora: Lic. Adriana Pérez

- 14 -

1. Desarrolle el software de forma iterativa, planificando incrementos del sistema basados en las prioridades del usuario, desarrollando y entregando las funcionalidades de mayor prioridad al inicio del proceso de desarrollo. 2. Gestione los requerimientos, documentándolos debidamente, estando al tanto de los cambios y analizando los impactos que estos cambios tienen en el sistema. 3. Utilice arquitecturas basadas en componentes, identificando aquellos componentes que puedan ser reusables. 4. Modelo de forma visual el software, para ello utilice los diagramas de UML de la vista estática y dinámica. 5. Verifique la calidad del software, en cada etapa verifique que cumpla con las especificaciones de las etapas anteriores y los estándares de calidad. 6. Controle los cambios del software, manteniendo las versiones, los procedimientos y la debida gestión de configuración. UML y el Proceso Unificado de Desarrollo de Software Cuando Ivar Jacobson, Grady Booch y James Rumbaugh decidieron unir sus modelos de análisis y diseño orientado a objetos determinando el Lenguaje Unificado de Modelado, lo hicieron pensando que los diagramas apoyarían al proceso de desarrollo de software, es por ello que se cuenta con dos libros, el de UML y el de El Proceso Unificado de desarrollo de Software, donde presentan los artefactos de UML y cómo apoyan al proceso. En esta etapa de la materia haremos referencia a los diagramas de UML, pero no los desarrollamos ya que usted los conoce, en caso de no recordarlos sugerimos reforzar los conocimientos con la lectura del libro de UML. El Proceso Unificado está basado en componentes, por lo que el software está sustentado en componentes de software interconectados a través de interfaces. No hay un proceso universal, el Proceso Unificado está diseñado para la flexibilidad y la extensibilidad dadas por las siguientes características:  Permite una variedad de ciclos de vida.  Selecciona qué artefactos producir.  Define las actividades y sus actores.  Modela conceptos. La estructura del proceso se puede representar de la siguiente forma:

Ya hemos presentado las definiciones de proceso, trabajador o rol, Workflow y actividad, sólo resta definir qué es un artefacto.

Materia: Ingeniería de Software Profesora: Lic. Adriana Pérez

- 15 -

Un Artefacto, es una pieza de información que es producida, modificada o usada por un proceso.

2.2.1 Características del Proceso de Desarrollo Unificado (Conducido por Use cases, Centrado en la Arquitectura, Iterativo e Incremental) El Proceso Unificado presenta aspectos que se deben tener en cuenta a la hora de aplicar su modelo, ya que marcan el proceso, estos aspectos se resumen en tres fases claves:  Dirigido por casos de uso  Centrado en la arquitectura  Iterativo e incremental. Dirigido por casos de uso: Un caso de uso (UC) es un fragmento de funcionalidad del sistema que proporciona al usuario un resultado importante. Estos casos de uso representan los requisitos funcionales, todos los casos de uso juntos constituyen el Modelo de casos de uso, el cual describe la funcionalidad total del sistema. Una funcionalidad del sistema debe responder a la pregunta ¿qué debe hacer el sistema?, cuando lo planteamos como caso de uso la pregunta es ¿qué debe hacer el sistema para cada usuario? Con esta pregunta no sólo identificamos la funcionalidad, sino que también identificamos el actor responsable del UC. Los UC no sólo representan las funcionalidades, también guían el proceso de desarrollo, ya que los analistas, abordan las funcionalidades, los diseñadores efectúan las interfaces y la arquitectura de datos que la soporte, los programadores lo convierten en código ejecutable, los prueban e implementan para que los usuarios lo puedan utilizar y comprobar si cumplen con lo especificado, satisfacen sus necesidades y cubren sus expectativas. Centrado en la arquitectura La arquitectura en un sistema de software es análoga a la arquitectura de un edificio, se describe mediante diferentes vistas del sistema en construcción, incluye los aspectos estáticos y dinámicos del sistema. La arquitectura surge de la visión del cliente, de sus necesidades y se refleja en los casos de uso, no obstante existen otros factores que influyen en la arquitectura, entre los más importantes podemos citar:  La plataforma donde debe funcionar  Los componentes reutilizables de que se dispone  Sistemas heredados  Requisitos no funcionales La arquitectura es una vista de diseño completo con las características más importantes que deja los detalles de lado. La actividad de diseño permite al arquitecto centrarse en los objetivos adecuados, como son:  La comprensibilidad  La capacidad de adaptación al cambio  La reutilización.

Materia: Ingeniería de Software Profesora: Lic. Adriana Pérez

- 16 -

La arquitectura no es independiente de los casos de uso, están interrelacionados, ya que cada producto consta de una función y una forma, donde la función corresponde a los casos de uso y la forma a la arquitectura. Estas dos fuerzas deben equilibrarse para lograr un producto con éxito. La arquitectura debe permitir el desarrollo de todos los casos de uso, pero además ambos deben evolucionar en paralelo y permitir que el sistema evolucione y soporte los cambios de requerimientos. Se aconseja que el arquitecto trabaje sobre los casos de uso claves, los que representan entre el 5 y el 10% del total de las funcionalidades del sistema, son los más significativos y complejos, luego escala hacia el total de los UC. El proceso es Iterativo e Incremental Normalmente los proyectos son de magnitud y llevan meses, quizás un año o más de trabajo. En estos casos es conveniente dividir el trabajo en partes más pequeñas o miniproyectos. Cada miniproyecto es una iteración que resulta que resulta en un incremento. Las iteraciones hacen referencia a los pasos del flujo de trabajo y los incrementos, al crecimiento del producto. Es común tener el problema del incremento sin medida, por lo que es conveniente tener bien definidos los alcances de cada miniproyecto, con iteraciones controladas por la planificación para obtener una efectividad máxima. Los desarrolladores basan la selección de lo que se implementará en una iteración, en dos factores:  Un conjunto de UC que juntos amplían el producto.  Una nueva iteración se construye sobre los artefactos de desarrollo tal como quedaron en la iteración anterior. En cada iteración se dan las mismas fases que en el Proceso Unificado, por lo que los desarrolladores identifican y especifican los UC relevantes, crean un diseño utilizando la arquitectura seleccionada como guía, implementan el diseño mediante componentes y verifican que estos componentes verifiquen los casos de uso. Cuando una iteración cumple con su objetivo se sigue con la siguiente iteración. Si la iteración no cumple con su objetivo se debe revisar y encontrar el error que, si se realizaron las validaciones correspondientes, sólo podría estar de la última etapa. En caso de error los desarrolladores deben revisar sus decisiones previas y probar con otro enfoque. Recordemos las fases del proceso iterativo e incremental con la gráfica que lo representa:

Materia: Ingeniería de Software Profesora: Lic. Adriana Pérez

- 17 -

La gráfica del ciclo de vida nos muestra el esfuerzo de cada fase con los flujos de trabajo relacionados en cada una de ellas. También se tienen en cuenta los flujos de trabajo de soporte, los cuales acompañan a todas las fases, como son la gestión de cambio y configuración, la gestión de proyectos y el entorno de trabajo. ¿Cómo sabemos que es un ciclo iterativo e incremental? Para determinar si es un ciclo iterativo e incremental se deben reconocer las características a cumplir:  Es planificado y controlado.  Es predicable  Acomoda los cambios a los requerimientos con menos alteraciones.  Está basado en prototipos ejecutables que evolucionan, no en la documentación.  Involucra a clientes y usuarios a lo largo del proceso.  Es conducido por los riesgos.

2.2.2 Persona, Proyecto, Producto y proceso en el Desarrollo de Software El resultado final de un proyecto de software es un producto que va tomando forma durante el proceso gracias a la intervención de muchos tipos distintos de personas, cada una tiene su nivel de esfuerzo y con un flujo de trabajo asociado. Las cuatro “P” en el proceso de desarrollo de software son:  Personas, las personas son seres humanos con distintas funciones dentro del proceso. Los principales actores del proyecto son: los analistas, los arquitectos, los programadores, los ingenieros de pruebas, los encargados de la gestión de soporte, los clientes y usuarios.

Materia: Ingeniería de Software Profesora: Lic. Adriana Pérez

- 18 -

  

Proyecto, es el elemento organizativo a través del cual se gestiona el desarrollo de software que tiene como resultado una versión de un producto. Producto, son los artefactos que se crean durante la vida del proyecto, el código ejecutable, los modelos y la documentación. Proceso, es la definición de un conjunto de actividades necesarias para transformar los requisitos de usuario en producto.

Además se necesita contar con las herramientas necesarias para automatizar las actividades definidas en el proceso.

2.2.3 Conceptos básicos en el proceso unificado y de los workflows del Proceso Ya hemos tratado todos los conceptos básicos necesarios para poder integrar el proceso unificado con los Workflow, para lograr una visión general y particular del proceso de desarrollo de software. El proceso unificado produce modelos durante su desarrollo, estos modelos son: 1- Modelo de negocio 2- Modelo de dominio 3- Modelo de casos de uso 4- Modelo de análisis 5- Modelo de diseño 6- Modelo de proceso 7- Modelo de despliegue 8- Modelo de implementación 9- Modelo de prueba. Veamos la relación que existe entre el Workflow y los modelos a través de la siguiente gráfica:

Materia: Ingeniería de Software Profesora: Lic. Adriana Pérez

- 19 -

En la gráfica anterior se identifican los Workflow que son parte del proceso unificado:  Modelo de negocio  Requerimientos  Análisis  Diseño  Implementación  Prueba. Cada uno de ellos ha sido definido con anterioridad en este Módulo. Si relacionamos estos Workflow con el ciclo de vida, identificamos los flujos de trabajo en detalle necesarios para cada uno de los planteados en dicho ciclo, como son: 

Workflow de captura de requerimientos, tienen como objetivo lograr la lista de requerimientos, para ello se deben realizar actividades que están relacionadas con los modelos o artefactos resultantes: o Listar los requerimientos necesarios, se obtiene la Lista de Aspectos. o Comprender el contexto del sistema, se obtiene el modelo de negocio y el modelo de dominio. o Capturar requerimientos funcionales, se obtiene el modelo de casos de uso o Capturar requerimientos no funcionales, se obtienen los requerimientos complementarios para los UC específicos del sistema.

La captura de requerimientos se realiza en las cuatro fases del proceso unificado, siendo de mayor cantidad de trabajo en las dos primeras, o sea, en las fases de inicio y elaboración. 

Workflow de análisis, tiene como objetivo realizar el análisis de los requerimientos, sus ventajas son: o Permite una especificación más precisa de los requerimientos. o Se describe en lenguaje técnico, del programador. o Le da estructura a los requerimientos. o Puede verse como un primer corte de los requerimientos.

El análisis se realiza en las tres primeras fases del proceso, o sea, inicio, elaboración y construcción obteniendo las clases de análisis y el modelo de análisis. 

Workflow de diseño, su objetivo es obtener el diseño completo del sistema para lograr: o Una comprensión completa de los requerimientos y sus restricciones. o Refinar los requerimientos obteniendo clases e interfaces individuales o Descomponer el trabajo de implementación en piezas entendibles y manejables por distintos actores del proceso. o Capturar las interfaces de relación entre sistemas. o Crear una abstracción de la implementación del sistema.

El diseño se presenta en las fases de inicio, elaboración y construcción, incluyendo el análisis arquitectónico que proporciona un documento de arquitectura del software, construye el modelo de diseño y diseña la persistencia obteniendo como resultado el modelo de datos y su persistencia. 

Workflow de implementación, su objetivo es lograr la implementación de un producto ejecutable, para ello se realizan las siguientes actividades:

Materia: Ingeniería de Software Profesora: Lic. Adriana Pérez

- 20 -

o o o o o

Se planean las implementaciones de cada iteración. Se distribuyen los componentes en los nodos donde se implementan, por ejemplo, la base de datos en el servidor de datos y las aplicaciones en el servidor de aplicaciones. Se implementa el diseño de clases y subsistemas. Se realiza las primeras pruebas de unidad de componentes. Se realiza la integración de los componentes en un ejecutable.

La actividad de implementación se relaciona con las fases de elaboración, construcción y transición. 

Workflow de prueba, su objetivo es probar el producto final garantizando que es de calidad, para ello realiza las siguientes tareas: o Realiza la planificación de las pruebas necesarias para cada iteración. o Diseña e implementa las pruebas, diseñando los casos de uso de prueba. o Realiza los test necesarios, documentando los resultados. o Automatiza los test de prueba que puedan ser reutilizados.

Las pruebas se realizan en las cuatro fases, garantizando que cada una de ellas cumple con los objetivos de calidad y con los requerimientos del cliente. Para ampliar sobre los contenidos de esta lectura sugerimos recurrir al texto de Jacobson, Booch y Rumbauch, “El Proceso unificado de Desarrollo de Software”, parte I y II, capítulos 1 al 11 inclusive (bibliografía básica).

Materia: Ingeniería de Software Profesora: Lic. Adriana Pérez

- 21 -

HACIA UNA ONTOLOGÍA PARA FÁBRICAS DE SOFTWARE Kenyer Domínguez1 María A. Pérez2, Luis E. Mendoza2 y Anna Grimán2

RESUMEN Actualmente se está retomando el concepto de Fábricas de Software (FS) donde la reutilización juega un rol protagónico. Debido a la existencia de visiones diferentes en el área y a pesar de que el concepto de FS no es nuevo en la Ingeniería de Software, aún no se cuenta con la madurez conceptual necesaria como para identificar claramente el tratamiento de ciertas variables dentro del proceso. Por ello, en este artículo se realiza una revisión histórica del concepto FS y se propone una ontología basada en las definiciones más recientes. Este artículo forma parte de una investigación en progreso que pretende precisar la calidad sistémica en compañías desarrolladoras de software que decidan implantar una FS. Palabras Claves: Fábricas de Software, ontología, reutilización, mejores prácticas.

1. INTRODUCCIÓN

Dado los exigentes requerimientos en el cumplimiento de tiempos y presupuestos que las empresas desarrolladoras de software viven constantemente, la eficiencia en el proceso de desarrollo se ha constituido en una necesidad creciente. Sin embargo, ésta es una variable que no necesariamente propicia su efectividad. 1 Es por ello que la reutilización en el proceso de producción de software ha sido foco de interés desde hace algún tiempo, sin obtener éxitos reales. Actualmente, los desarrolladores crean aplicaciones desde cero por medio del uso de herramientas genéricas, procesos adecuados y arquitecturas personalizadas; una práctica que consume mucho tiempo y que da lugar a errores. 2 Consciente de esta realidad, algunas organizaciones han establecido diversas estrategias de trabajo e incluso han agrupado las mejores prácticas en esta materia con el fin de industrializar el desarrollo de software. Es por ello que actualmente se está retomando el concepto de Fábricas de Software (FS) donde la reutilización juega un rol protagónico. Debido a la existencia de visiones diferentes en el área 1

Decanato de Investigación y Desarrollo, Universidad Simón Bolívar. Apartado Postal 89000, Caracas 1080-A. Caracas Venezuela. E-mail: [email protected] 2 Laboratorio de Investigación en Sistemas de Información (LISI), Departamento de Procesos y Sistemas, Universidad Simón Bolívar. Apartado Postal 89000, Caracas 1080-A. Caracas Venezuela. E-mail: [email protected], [email protected] y [email protected].

y a pesar de que el concepto de FS no es nada nuevo en la Ingeniería de Software; aún no se cuenta con la madurez conceptual necesaria, como para identificar claramente el tratamiento de ciertas variables dentro del proceso, una de ellas es la calidad. En este artículo se pretende establecer una ontología que permita entender las diferentes acepciones del concepto FS, así como las características, innovaciones e implicaciones de las visiones más recientes de FS en el ámbito de la Ingeniería del Software. Este artículo forma parte de una investigación en progreso que busca estimar la calidad sistémica en compañías desarrolladoras de software que decidan implantar una FS. A continuación se presentan los antecedentes de esta investigación, luego se describe la metodología, para luego dar una descripción de cada uno de los conceptos involucrados a medida que se muestra la representación gráfica de los elementos resaltantes, finalmente se muestra el modelo conceptual integrado y se proponen las conclusiones y recomendaciones.

2. ANTECEDENTES

En la Ingeniería del Software se han hecho muchos intentos para solventar la ausencia de un proceso de desarrollo bien definido y bien gerenciado que afecta, tanto a los desarrolladores como a usuarios y clientes, al no obtener el producto deseado dentro del tiempo y los costos estimados. La aplicación de un modelo de FS es uno de esos intentos, donde la reutilización del código, la especificación de procesos y el desarrollo dirigido por modelos juegan un papel protagónico. 1

No obstante, el término FS ya ha sido utilizado en la Ingeniería de Software. Según [10], el término FS fue utilizado por primera vez entre 1950 y 1960 en Estados Unidos y Europa para mejorar la productividad en el desarrollo de software a través de herramientas estándar y reutilización de métodos y de componentes; luego, entre 1970 y 1980, los fabricantes de computadores en Japón adoptan de nuevo el concepto y mejoran considerablemente el desarrollo de software. Aún en la década de 1990, según [10] se reportaron investigaciones sustanciales en relación al término FS. Posteriormente, [11] anuncia su visión del concepto atada a su producto “Visual Studio Team System 2005” y a su plataforma Microsoft .NET. Casi en la misma fecha, [3], presentan las técnicas que utilizan para el desarrollo de una FS en Brasil, donde incluso actualmente se está conformando una Fábrica de Software basada en Código Abierto [14]. Como antecedentes importantes en el tema de las FS se tienen las visiones más recientes encontradas en la literatura: [3] y [6]. Según [3], una compañía de software que no tenga las siguientes características no puede ser considerada una FS: - Producción de software en masa y en gran escala, - Estandarización de tareas y controles; y - División de trabajo y automatización.

conceptos comunes de cada definición, así como también los no comunes pero más importantes; (2) para restringir el alcance, sólo se tomaron en cuenta las versiones más recientes de FS; (3) no se encontraron ontologías en este tema por lo que no hubo reutilización de ontologías existentes; (4) los términos importantes son descritos iterativamente a lo largo de este artículo, especificando la jerarquía entre ellos así como también sus relaciones; (5) a este nivel no se especifican las propiedades ni se crean las instancias dado que aun no se aplica a ningún caso de estudio.

4. ONTOLOGÍA PROPUESTA PARA FS

De acuerdo con [3], una FS debe ser flexible, capaz de producir varios tipos de productos, implementar conceptos de ingeniería del software y debe ser capaz de analizar, proyectar, implementar, desarrollar y mejorar sistemas. Se observa que el término FS no es nada nuevo pero, en su mayoría, las diferentes versiones del concepto FS coinciden en la producción en masa de una Familia de Productos (perteneciente a un determinado Dominio de Solución), que cumplen con determinados requerimientos comunes (pertenecientes a un determinado Dominio del Problema), que son establecidos por un conjunto de personas involucradas. Estos involucrados no necesariamente son los desarrolladores, sino que también contempla a los clientes, usuarios, proveedores e incluso los arquitectos de software.

3. METODOLOGÍA UTILIZADA En la Figura 1 se presenta un primer nivel de conceptos en base a los antecedentes reseñados. Se observa que el término FS engloba una cantidad de conceptos que conviene manejarlos ordenadamente y este es justamente el fin de esta investigación en progreso. Según [12] una ontología es una descripción explícita y formal de conceptos en un dominio de discurso. Estos autores en su metodología para crear ontologías, proponen los siguientes siete pasos: 1. Determinar el dominio y el alcance. 2. Considerar la reutilización de ontologías existentes. 3. Enumerar los términos importantes. 4. Definir las clases y su jerarquía 5. Definir las propiedades de las clases 6. Definir las relaciones de las clases 7. Crear las instancias Para efectos de presentación en este artículo, no se detallan cada uno de los pasos propuestos; sin embargo, a continuación se resaltan las actividades realizadas en cada uno de ellos: (1) para encontrar los términos relevantes se identificaron aquellos

Por su parte, [6] definen el término FS como una ‘Línea de Productos de Software’ (LPS) que configura herramientas, procesos y contenido usando una plantilla basada en un esquema dado, con el fin de automatizar el desarrollo y mantenimiento de variaciones de un producto arquitectónico mediante adaptaciones, ensamblaje y configuración de componentes basados en frameworks soportados por un ambiente. La definición de Greenfield se toma como punto de referencia para la ontología que se desea proponer, posteriormente se verá que la misma, en sus detalles, contiene las definiciones del resto de los autores mencionados. Para entender mejor este modelo, se realiza una segunda iteración para analizar por separado los conceptos más relevantes: Línea de Productos de Software (LPS), plantilla, esquema y ambiente.

2

Figura 1. Elementos que intervienen en la definición de FS.

4.1. Línea de Productos de Software

Según [4], una línea de productos se puede ver como un conjunto de productos que están estrechamente relacionados (por su funcionalidad), que son vendidos a los mismos grupos de compradores, que son comercializados a través del mismo tipo de distribución, o que caen en el mismo rango de precios. Este concepto también tiene su origen en la industria tradicional, pero es aplicable al desarrollo de software y su utilización no resulta muy novedosa. La conocida utilización del concepto de LPS quizá se deba a su alto nivel de generalidad, pudiéndose aplicar tanto en organizaciones grandes como en pequeñas. La mayoría de las organizaciones producen familias de sistemas similares que se diferencian por ciertas características; pero a nivel general, según [2] se han detectado tres actividades generales que pueden ser aplicadas en cualquier situación. Para estos autores, las tres actividades están altamente relacionadas: el avance en una de las actividades necesariamente implica el avance en las demás, por lo que en realidad no se puede decir que exista un orden entre ellas, pero por razones de espacio cada una será descrita individualmente y de forma lineal. • Desarrollo de Activos Centrales (Core Asset Development) Esta actividad se enfoca en la producción de recursos generales para cualquier producto. Aquí se define el alcance de la línea de productos, el plan de producción, los componentes, la arquitectura, los requerimientos, así como también las restricciones, los estilos, patrones y frameworks, entre otros. Se configura también el inventario de activos (assets) preexistentes, lo que más tarde FS denomina Biblioteca de Objetos. • Desarrollo del Producto (Product Development): Esta actividad se encarga de ensamblar los activos desarrollados o almacenados en la actividad anterior para crear productos acordes con los requerimientos

del mercado; sin embargo, este proceso raramente es lineal. La creación de productos implica una continua relación con el alcance, el plan de producción y los activos centrales (core assets). • Gestión (Management): La dirección juega un rol crítico en el éxito de la línea de producción. Las actividades deben tener unos recursos asignados, coordinados y supervisados. La dirección, tanto a nivel técnico como organizacional debe estar fuertemente asociada al esfuerzo de la LPS. Pero la dirección no sólo está dirigida hacia adentro, también se debe tener en cuenta la relación con los proveedores y consumidores. Este aspecto posteriormente es llamado Cadena de Suministro por FS. Por su parte, [3], aunque basado en el modelo de FS de [1], propone un modelo que separa la producción de activos centrales o componentes, del proceso de producción de software, y el proceso de gestión lo llama “Organización del trabajo”. Este modelo está compuesto por dos grandes actividades: Producción de Software y Producción de Componentes. La concepción de FS de [6] es un poco más amplia ya que abarca el modelado del dominio de aplicaciones. FS está fielmente basado en LPS y comparte actividades con el modelo de [3], tales como Análisis, Diseño e Implementación, pero en el modelo de [6]. éstas están orientadas para una línea de productos. Los activos en el modelo de [6] son los que [3] denomina componentes. Este último modelo también contempla la posibilidad de seleccionar las herramientas más adecuadas para cada dominio, con la opción de personalizarlas. Es importante resaltar la similitud que posee el modelo de FS de [3] y la plantilla de FS propuesta por [6] dado que ambos modelos fueron publicados en fechas similares pero utilizando referencias bibliográficas distintas, lo que refleja el interés actual en mejorar los procesos de desarrollo para producir sistemas de mayor calidad. Una vez conocido el término LPS y su rol 3

dentro de FS (ver Figura 2), se pueden definir el resto de los elementos que la conforman: esquema, plantilla

y ambiente.

Figura 2. Conceptos de la Línea de Productos de Software.

4.2. Esquema, Plantilla y Ambiente

Según [5] una FS es una LPS que configura herramientas de desarrollo con guías y paquetes de contenido, cuidadosamente diseñados para construir tipos específicos de aplicaciones. Estos mismos autores establecen que una FS contiene tres ideas claves: un esquema, una plantilla y un ambiente de desarrollo. • Un esquema se puede pensar como una receta. Es una lista de ingredientes como proyectos anteriores, directorios de código fuente, archivos SQL y archivos de configuración. Además, el esquema explica cómo deben ser combinados estos ingredientes para crear el producto. El esquema establece cuáles lenguajes específicos del dominio (DSL del inglés Domain Specific Language) deben ser usados y describe cómo los modelos basados en esos DSL pueden ser transformados en código o en otros artefactos. El esquema describe la arquitectura de la línea de productos y las relaciones entre componentes y los frameworks involucrados. • Una plantilla es cómo un paquete o bolsa de supermercado que contiene todos los ingredientes listados en el esquema. La plantilla provee los patrones, guías, ejemplos, herramientas específicas como editores gráficos de DSL, scripts, hojas de estilo (style sheets) y otros ingredientes necesarios para construir el producto.

• Un ambiente de desarrollo es como la cocina donde es elaborado el alimento. Herramientas de alto nivel como Microsoft Visual Studio Team System hacen posible un ambiente de trabajo adecuado para construir una familia de productos. Según [5], esta analogía puede ser ejemplificada un poco más teniendo entonces que los productos son los platos servidos en un restaurant. Los involucrados (stakeholders) son como los usuarios que ordenan platos del menú. Una especificación de producto es como una orden de un plato con algunos extras. Los desarrolladores de productos (product developers) son como los cocineros que preparan los platos descritos en las órdenes y quienes pueden modificar ciertos ingredientes. Los desarrolladores de la línea de productos (product line developers) son como los chefs que deciden qué aparecerá en el menú y qué ingredientes, procesos y equipos de cocina deben ser usados. Estos tres elementos (plantilla, esquema y ambiente) se muestran en la Figura 3 y conforman las bases tecnológicas de una FS según la concepción de [6]. El término FS no sólo está compuesto por aspectos tecnológicos, a continuación se definen ciertos conceptos de economía aplicados al desarrollo de software y que también deben estar presentes en toda empresa que decida adoptar esta tendencia.

4

Figura 3. Elementos tecnológicos que conforman una FS.

4.3. Conceptos de Economía

El concepto de canales de mercadeo o cadena de suministro es utilizado por cualquier organización que produzca algún bien o servicio. La industria del software no escapa de esta realidad pero hasta el momento se ha limitado a utilizar este concepto sólo para mercadear el producto ya desarrollado, pero no como parte del proceso de desarrollo. Según [8], un canal de mercadeo realiza la labor de llevar los bienes de los productores a los consumidores, superando las brechas del tiempo, plaza y posesión. Según [6], una FS puede ser segmentada tanto vertical como horizontalmente para delegar responsabilidades a proveedores externos, creando de esta forma cadenas de suministros para el desarrollo de un producto de software. Otro concepto utilizado por FS es la economía de reutilización. Según [7] citado por [6], el hecho de reutilizar soluciones de un sub-problema común en un dominio dado puede reducir el costo total de resolver múltiples problemas en el mismo dominio. Además, la reutilización puede reducir el tiempo total de lanzamiento al mercado (time to market) y mejorar la calidad del producto. Es importante señalar la nueva connotación que se le otorga a este concepto dentro de una FS, donde se toma en cuenta no sólo la reducción del tiempo sino del costo del proyecto e incluso se mejora el retorno de la inversión ya que al invertir en patrones arquitectónicos, componentes y posibles eslabones en la cadena de suministro, la reutilización hace posible ver los resultados financieros de forma más rápida, favoreciendo las economías de escala y de alcance.

Según [6], estos dos conceptos con frecuencia son confundidos y aunque ambos reducen el tiempo y el costo del producto y mejoran su calidad produciendo múltiples productos en lugar de copias individuales, existen grandes diferencias entre ellos. La economía de escala establece la posibilidad de realizar múltiples instancias idénticas partiendo de un diseño simple. Por su parte, la economía de alcance se plantea cuando múltiples pero similares diseños y prototipos son producidos colectivamente más que individualmente. La diferencia principal entre la economía de escala y la economía de alcance, en términos de FS, está en el momento en que se produce la reutilización. En el primer tipo de economía, la reutilización se produce después de tener el producto desarrollado, mientras que en la economía de alcance, la reutilización se produce durante el desarrollo del producto. La relación de estos conceptos se puede ver en la Figura 4. Tanto la economía de escala como la de alcance, dentro de la concepción de Fábrica de Software, aumentan la eficiencia en el proceso de desarrollo de software dado que no se limitan al desarrollo de un producto a la vez, sino que transitan hacia el desarrollo en masa, sustentado fuertemente por el concepto de Línea de Productos de Software. Al mejorar la eficiencia, por ende, se mejora la calidad en el proceso de desarrollo. Según [3], el desarrollo de una FS implica que las mejores prácticas de la ingeniería del software sean aplicadas sistemáticamente. A continuación se muestran brevemente algunas de las mejores prácticas que esta tendencia ofrece.

5

Figura 4. Conceptos de Economía en una FS.

4.4. Mejores Prácticas

Según [6], FS está basado en la convergencia de ideas claves en desarrollo dirigido por modelos y reutilización sistemática. Para los autores citados, el Desarrollo Dirigido por Modelos (MDD del inglés Model-Driven Development) reduce el problema de la abstracción por medio del uso de modelos que capturan información de tal manera que pueda ser fácilmente procesada, en lugar de crear modelos sólo como documentación. Esta es una de las principales prácticas propuestas por FS ya que, según estos autores, los modelos deben ser utilizados para desarrollar, más que para documentar el producto. Todos estos esfuerzos van encaminados a pasar, de la forma tradicional basada en el código fuente, a una nueva forma de desarrollar productos de software basada en modelos, donde se reutilicen cada vez más los intentos anteriores. Para [13], la Ingeniería del Software Basada en Componentes (ISBC) lucha por conseguir un conjunto de componentes de software preconstruidos y estandarizados para encajar en un estilo arquitectónico específico para algún dominio de aplicación. Este conjunto de componentes constituye el Desarrollo de Activos Centrales de LPS. Así como [7] establece que un framework es un grupo de clases para un tipo específico de software, se puede intuir entonces que un framework de procesos es un grupo de sub-procesos para un determinado tipo de dominio. De acuerdo con [5] un framework de procesos es una estructura que organiza los microprocesos usados para construir artefactos que componen los miembros de la familia de productos. Desarrollar un framework de procesos para una línea de productos de software tiene sentido porque el costo puede ser efectivamente amortizado con la producción de muchos productos.

Estos mismos autores afirman que un framework de procesos esencialmente descompone un proceso en micro-procesos adjuntados al desarrollo de varios tipos de artefactos, incluyendo la descripción de los requerimientos necesarios para tal fin. En estas descripciones se puede enumerar consideraciones tan variadas como puntos clave de decisiones, análisis de trade-off asociados con cada punto de decisión, actividades opcionales o requeridas y los resultados a ser producidos en cada actividad. En este sentido, según [9], hasta ahora la arquitectura de un sistema permanecía siempre en una especie de caja negra siendo un secreto conocido sólo por sus autores. Una buena arquitectura del software fomenta la reutilización y permite obtener y mantener el control intelectual del desarrollo así como también gerenciar su complejidad y mantener la integridad del sistema, manejando de forma implícita la calidad en el desarrollo. La Figura 5 agrupa los conceptos involucrados en las mejores prácticas que reúne FS.

5. MODELO CON CONCEPTOS COMPARTIDOS

Una vez que se han descrito por separado los aspectos compartidos en torno a FS, conviene mostrarlos en un modelo unificado donde están presentadas nuevas relaciones no mostradas hasta el momento. Una de las principales relaciones está basada en que los aspectos económicos adaptados por FS al desarrollo de software, están soportados por los aspectos tecnológicos, de esta forma se tiene que la economía de reutilización fomenta la reutilización sistemática, las economías de escala y alcance fomentan el Desarrollo Dirigido por Modelos, y la Cadena de Suministros debe estar coordinada por la Dirección de la Línea de Productos de Software.

6

Figura 5. Mejores Prácticas en el Desarrollo de Software.

Por otro lado, al presentar todos los modelos de forma unificada, se destacan aquellos conceptos que se repiten y que a su vez sirven de integradores entre las partes involucradas. De esta forma se puede establecer que en una FS, la Línea de Productos de Software desarrolla un conjunto de productos con características similares conformando una Familia de Productos. Para desarrollar estos productos se sigue un esquema determinado que describe la arquitectura del sistema y a su vez establece las relaciones entre los frameworks utilizados y los componentes a ensamblar. Estos componentes se van registrando en el inventario de componentes fomentando la reutilización sistemática. Como se ha mostrado hasta ahora, el término FS, además de poseer múltiples definiciones, reúne una gran cantidad de conceptos que conviene identificar para poder manejar una idea general de su alcance. En la Figura 6 se muestra una versión unificada del modelo conceptual propuesto, incluyendo las nuevas relaciones descritas anteriormente. Los recuadros no implican ningún tipo de orden ni relevancia entre conceptos, se utilizan sólo para agrupar conceptos similares y facilitar la lectura del modelo. Si bien FS no aporta conceptos nuevos en el desarrollo de productos de software, la innovación consiste en la agrupación de conceptos anteriores (LPS, MDD, reutilización sistemática y framework de procesos), pero presentados en conjunto, como un nuevo intento para pasar de la producción tradicional a una automatizada.

6. CONCLUSIONES Y TRABAJOS FUTUROS

FS no sólo implica cambios tecnológicos sino también cambios en la economía; por lo tanto, cualquier empresa que decida adoptar FS como base para su

forma de producir software, debe tener en cuenta ciertos conceptos de economía que no estaban involucrados anteriormente en este sector de producción. Luego de desarrollar este trabajo, las conclusiones obtenidas pueden resumirse en dos aspectos fundamentales: • Se dan los primeros pasos para organizar y documentar todo el conocimiento que gira en torno al concepto de Fábricas de Software. • Hasta el momento no existe una forma de precisar la calidad de una empresa que decida implantar una FS como tendencia de trabajo. Como corolario a la primera afirmación, se tiene que la reutilización y el desarrollo de varios productos en paralelo, deben ser las características fundamentales en una empresa que decida encaminarse hacia una Fábrica de Software. Otro aspecto de la problemática, es que el tema de la calidad de los sistemas no es atacado profundamente en todas las versiones de FS, aunque siempre se busca mejorar la eficiencia y mitigar, en la medida de lo posible, los errores y sus consecuencias, tratando siempre de medir la calidad del producto. FS propone ciertos cambios en el proceso de desarrollo de software pero no establece una forma clara de medir su calidad. Por lo tanto, el resultado esperado se encamina a establecer un modelo de especificación de la calidad sistémica (calidad del producto y calidad del proceso) en empresas venezolanas que cumplan con las características de FS. Para ello además, se aplicará esta primera ontología a un caso de estudio para validar los conceptos. Luego se formulará el modelo y se hará su validación aplicando el método DESMET, el cual permite evaluar métodos y herramientas usados en el área de Ingeniería de Software. Se espera entonces que el modelo tenga al menos un 75% de aplicabilidad y de pertinencia.

7

Figura 6. Modelo conceptual propuesto para Fábricas de Software.

Frameworks y Mecanos”. Informe Técnico, Departamento de Informática. Universidad de Salamanca. 2002.

7. REFERENCIAS BIBLIOGRÁFICAS

[1]

[2]

[3]

[4]

V. Basili, G. Caldiera y G. Cantone “A Reference Architekcture for the Component Factory”. ACM Transaction on Software Engineering and Methodology. Vol 1. nº 1. pp 53-80. Enero, 1992. P. Clements y L. Northrop. “Software Product Lines. Practices and Patterns”. SEI Series in Software Engineering. Addison Wesley. Segunda Edición. Boston, USA. pp. 29-31. 2001. J. Fabri, A. Presende, L. Begosso, A. L´Erário, F. Fujii y M. de Paula. “Techniques for the Development of a Software Factory: Case CEPEIN-FEMA”. 17th International Conference Software and Systems Engineering and their Applications. ICSSEA 2004. Paris, Noviembre 30 – Diciembre 3. 2004. F. García, J. Barras, M. Laguna y J. Marqués. “Líneas de Productos, Componentes,

[5]

J. Greenfield, y K. Short. “Moving to Software Factories”. White Paper, actualizado el 15 de Julio de 2004, tomado en Enero de 2005 de http://www.softwarefactories.com/ScreenShots/M S-WP-04.pdf

[6]

J. Greenfield, K. Short, S. Cook, y S. Kent. “Software Factories. Assembling Applications with Patterns, Models Frameworks and Tools”. Wiley. Primera Edición. 2004.

[7]

I. Jacobson, M. Griss y P. Jonsson. “Software Reuse : Architecture, Process and Organization for Business Success”. ACM Press, 1997.

[8]

P. Kotler. “Dirección de Marketing”. La edición del milenio. Prentice Hall. 2001.

[9]

P. Kruchten. “The Rational Unified Process. An Introduction”. Third Edition. Addison Wesley 8

Longman, Inc. 2003. [10] N. Lim, S. James, y F. Pavri. ”Diffusing Software-based Technologies with a Software Factory Approach for Software Development. A Theoretical Framework”. Proceeding of the 22nd Information Systems Research Seminar in Scandinavia (IRIS22): Enterprise Architectures for Virtual Organisations. 7-10 Agosto, Keuruu, Finland. 1999. [11] Microsoft Prensa. “Microsoft aumenta su ecosistema de socios alrededor de Visual Studio 2005 Team System”. Tomado en Febrero de 2004 de

http://www.microsoft.com/latam/prensa/2004/Oct ubre/VisualStudio.asp [12] N. Noy. y D. McGuinness. “Ontology Development 101: A Guide to Creating Your First Ontology”. in Protege Documentation. Stanford University: Stanford, CA. 2001 [13] R. Pressman. “Ingeniería del Software. Un enfoque práctico”. Quinta Edición. Mc Graw Hill. 2002. [14] OXE Open Source Software Factory, “Open Experience Environment”. Tomado en Julio de 2005 de http://php.cin.ufpe.br/~oxe/

9

2

DESARROLLO ITERATIVO E INCREMENTAL

“El desarrollo iterativo únicamente se debe utilizar en aquellos proyectos que se quiere que tengan éxito” (UML gota a gota de Martín Fowler)” [Larman05].

2.1

LA ITERACIÓN Y EL INCREMENTO

El desarrollo iterativo e incremental es un enfoque para construir software (o cualquier cosa) en el cual todo el ciclo de vida está compuesto por varias iteraciones. Las iteraciones son pequeños proyectos compuestos de varias actividades cuyo objetivo es entregar una parte de un sistema parcialmente completo, probado, integrado y estable. Todo el software es integrado en cada entrega de cada iteración hasta obtener el producto software completo en la última iteración [Larman05].

La definición de dicho enfoque se enmarca en lo qué es una iteración, en la planificación de la misma y en el concepto generado de incremento, los cuales se mencionan a continuación.

2.1.1 La iteración. Una iteración es un mini proyecto que tiene como resultado una versión interna de cada uno de los artefactos que pueden ser generados en un proceso de desarrollo de software. Se puede visualizar como un flujo de trabajo [JBR00] compuesto por las actividades fundamentales del proceso (especificación, análisis, diseño, implementación, etc.) adoptado por un equipo de desarrollo para utilizar y producir los artefactos en los que se puede dividir una solución software.

El conjunto total e integrado de las iteraciones representará la versión externa del software, es decir, el producto final de cara al usuario; para llegar a ello, cada una de las iteraciones dentro del ciclo de vida del software cumplen diferentes objetivos. Las primeras iteraciones se centran en la compresión del problema y de la tecnología, se preocupan por producir el análisis del negocio, actividad o proceso que apoyará e integrará el producto. Luego se orientan las iteraciones a establecer las bases del diseño (arquitectura) que se robustecerá a medida que fluye el ciclo de vida. Las iteraciones siguientes se concentrarán en la construcción e integración de los componentes que se van generando producto de las mismas.

12

Aunque se describe un proceso secuencial de iteraciones no se debe entender un proceso iterativo como la división por partes de cada una de las fases del proceso “cascada”; una iteración incluye su propia planificación, su especificación, su análisis y otras actividades como diseño, implementación o validación (pruebas); puede entenderse mejor como un proceso compuesto por pequeñas cascadas, donde cada iteración se concentrará más en una actividad que en las otras [Larman05].

2.1.2 Planificación y secuenciación de las iteraciones. Un ciclo de vida iterativo requiere más planificación y comprensión que un modelo en cascada [JBR00] donde toda su planificación se realiza al principio y contiene mayor incertidumbre y falta de fidelidad para las fases siguientes en el proceso de desarrollo. En contraste, en el modelo iterativo no se planifica el proyecto durante el inicio, sólo se dan los primeros pasos; no se intenta llevar a cabo la construcción sin establecer las bases de la planificación en iteraciones previas. Cada planificación de una iteración tiene en cuenta los resultados de las iteraciones precedentes, la selección de la especificación o funcionalidades a realizar y el estado actual del ciclo de vida del proceso, y termina con la preparación de la versión interna.

La evolución del software (proceso o producto) no sucede sin un plan que la preceda. Se pretende con la iteración en el desarrollo de software, ordenar cada flujo de trabajo para obtener un camino directo en el cuál las primeras iteraciones proporcionan la base de conocimiento para las siguientes. Estas iteraciones dan como resultado un mayor conocimiento de los requisitos, los problemas, los riesgos y el dominio de la solución, mientras que las siguientes dan como resultado una serie de incrementos aditivos que conforman finalmente la versión externa, el producto final para el cliente. La secuencia de iteraciones, que siempre avance, representará el éxito de la aplicación del modelo, sin tener que volver nunca a los resultados de una iteración previa para corregir el modelo debido a algo descubierto en una iteración posterior.

Las iteraciones pueden solaparse en el tiempo, en el sentido que una esté a punto de terminar cuando otra está comenzando. La planificación para la siguiente iteración debe comenzar a medida que se va terminando y preparando la entrega de la anterior. La entrega de una iteración significa que se ha llegado finalmente a una conclusión dentro del equipo de trabajo, que se ha integrado todo el software de la iteración y puede crearse la versión interna.

El objetivo principal de la planificación de las iteraciones es realizar una secuenciación del trabajo de manera que puedan desarrollarse primero las decisiones, especificaciones y funcionalidades más importantes.

13

2.1.3 Qué es un incremento. Simplemente, el resultado de una iteración es un incremento [JBR00]. Un incremento está representado en la diferencia entre la versión interna dada por una iteración y la versión interna obtenida de la siguiente.

En un momento del ciclo iterativo (secuencia de iteraciones) algunos módulos o subsistemas estarán terminados e integrados, contendrán toda la funcionalidad requerida y plasmada en los requisitos, estarán implementados, probados y validados; otros sistemas estarán parcialmente terminados y otros sin haberse iniciado. Un incremento se puede ver entonces como la diferencia entre dos momentos determinados en el ciclo de vida del proceso. Se van construyendo incrementos de manera iterativa, dando forma a cada unos de los subsistemas que representan el sistema final que será visualizado cuando se realice la integración del último incremento.

2.1.4 Qué no es una iteración. Un ciclo de vida iterativo no es un desarrollo aleatorio; no es algo que sólo afecte a los desarrolladores; no es rediseñar una y otra vez hasta que los desarrolladores prueben que algo funciona; no es impredecible; no puede ser una excusa para fracasar en la planificación y en la gestión [JBR00].

Una iteración controlada se planifica y es una herramienta que pueden utilizar los directores de proyecto para controlarlo, y al principio del ciclo de vida, reduce los riesgos que pueden amenazar el progreso en el desarrollo. Las versiones internas proporcionadas por cada iteración posibilitan la retroalimentación de los usuarios y esto lleva a una corrección temprana de la trayectoria del proyecto.

2.2

EL PROCESO UNIFICADO DE DESARROLLO RUP

El proceso unificado de desarrollo RUP (Rational Unified Process) es el representante más conocido del proceso iterativo e incremental. Su aplicación, como su enseñanza, es ampliamente difundida por organizaciones, empresas dedicadas al desarrollo de software, universidades y expertos en prácticas y procesos de ingeniería de software, entre otros, alrededor del mundo.

14

2.2.1 Orígenes. El antecedente más importante en la historia de RUP se ubica en 1967 con la Metodología Ericsson (Ericsson Approach) elaborada por Ivar Jacobson, una aproximación del desarrollo basado en componentes, que introdujo el concepto de Casos de uso. Entre los años de 1987 a 1995 Jacobson fundó la compañía Objectory AB y lanza el proceso de desarrollo Objectory (abreviación de Object Factory). Posteriormente en 1995 la renombrada compañía Rational Software Corporation adquiere a Objectory AB y entre 1995 y 1997 desarrolla el proceso ROP (Rational Objectory Process) a partir del Objectory 3.8 y del enfoque metodológico de Rational (Rational Approach) adoptando el lenguaje unificado UML [Larman05] como lenguaje de modelado. Desde ese entonces y a la cabeza de Grady Booch, Ivar Jacobson y James Rumbaugh, Rational Software desarrolló e incorporó diversos elementos para expandir su ROP, destacándose especialmente el conocido modelado del negocio [Letelier02]. En junio del 1998 se lanza el RUP-Rational Unified Process, el conocido Proceso Unificado de Desarrollo propuesto por la Rational Corporation, hoy parte de IBM.

2.2.2 Características esenciales. Los autores de RUP destacan que el proceso de software propuesto por RUP tiene tres características esenciales: está dirigido por los Casos de uso, está centrado en la arquitectura, y es iterativo e incremental.


Proceso dirigido por Casos de uso. Los Casos de uso son una técnica de modelado para la captura y representación de requisitos que obliga a pensar en términos de importancia para el usuario y no sólo en términos de funciones a contemplar. Se define un Caso de Uso como un fragmento de funcionalidad del sistema que proporciona al usuario un valor agregado. Los Casos de uso representan los requisitos funcionales del sistema.

En RUP los casos de uso no son sólo una herramienta para especificar los requisitos del sistema; también guían su diseño, implementación y prueba. Los casos de uso constituyen un elemento integrador y una guía de trabajo, que no sólo inicia el proceso de desarrollo sino que también proporcionan un hilo conductor, permitiendo establecer trazabilidad entre los artefactos que son generados en las diferentes actividades del proceso de desarrollo. Basándose en los casos de uso, se crean los modelos de análisis y diseño, luego la implementación que los lleva a cabo, y se verifica que efectivamente el producto implemente adecuadamente cada caso de uso, haciendo que cada modelo esté sincronizando con cada uno de ellos.
Proceso centrado en la arquitectura. La arquitectura de un sistema es la organización o estructura de sus partes más relevantes, lo que permite tener una visión común entre todos los involucrados en el proceso (desarrolladores y usuarios) y una perspectiva más clara del sistema completo, necesaria para controlar el desarrollo.

15

La arquitectura involucra los aspectos estáticos y dinámicos más significativos del sistema, está relacionada con la toma de decisiones que indica cómo tiene que ser construido el sistema y ayuda a determinar en qué orden. Además la definición de la arquitectura debe tomar en consideración elementos de calidad del sistema, rendimiento, reutilización y capacidad de evolución, por lo que debe ser flexible durante todo el proceso de desarrollo. La arquitectura se ve influenciada por la plataforma software, el sistema operativo, los gestores de base de datos y protocolos, entre otros aspectos técnicos. Muchas de estas restricciones constituyen requisitos no funcionales del sistema.

En el caso de RUP, además de utilizar los Casos de uso para guiar el proceso se presta especial atención al temprano establecimiento de una buena arquitectura que no se vea fuertemente impactada ante cambios posteriores presentados durante la construcción y el mantenimiento. Existe una interacción entre los Casos de uso y la arquitectura, los Casos de uso deben encajar en la arquitectura cuando se llevan a cabo y la arquitectura debe permitir el desarrollo de todos los Casos de uso requeridos, actualmente y en el futuro. Esto provoca que tanto arquitectura como Casos de uso deban evolucionar en paralelo durante todo el proceso de desarrollo de software.

Es conveniente ver el sistema desde diferentes perspectivas para comprender mejor el diseño, por lo que la arquitectura se representa mediante varias vistas que se centran en aspectos concretos del sistema, abstrayéndose de los demás. Para RUP, todas las vistas juntas forman el llamado modelo “4+1” de la arquitectura, el cual recibe este nombre porque lo forman las vistas lógica, de implementación, de proceso y de despliegue, más la vista de Casos de uso que es la que da la afinidad a todas.


Un proceso iterativo e incremental. El equilibrio correcto entre los casos de uso y la arquitectura en el desarrollo sólo se consigue con el tiempo. Para esto, la estrategia que se propone en RUP es tener un proceso iterativo e incremental en donde el trabajo se divide en partes más pequeñas o mini proyectos, permitiendo que dicho equilibrio entre casos de uso y arquitectura se vaya logrando durante cada mini proyecto, así durante todo el proceso de desarrollo, cada mini proyecto se puede ver como una iteración (un recorrido más o menos completo a lo largo de todos los flujos de trabajo, actividades fundamentales o disciplinas) de la cual se obtiene un incremento que produce un crecimiento en el producto software.

16

Una iteración puede realizarse por medio de una cascada pasando por los flujos fundamentales de Requisitos, Análisis, Diseño, Implementación y Pruebas, como se muestra en la figura 2.1. También existe una planeación de la iteración, un análisis de la iteración y algunas actividades específicas propias de cada iteración. Al finalizarla se realiza una integración de los resultados con lo obtenido de realizar iteraciones anteriores [Letelier02].

Figura 2.1. Una iteración RUP.

[Letelier02]

El proceso iterativo e incremental consta de una secuencia de iteraciones. Cada iteración aborda una parte de la funcionalidad total, pasando por todos los flujos de trabajo relevantes y refinando la arquitectura. Cada iteración se analiza cuando termina; se puede determinar si han aparecido nuevos requisitos o han cambiado los existentes, afectando a las iteraciones siguientes. Durante la planificación de la siguiente iteración, el equipo también examina cómo afectarán los riesgos que aún quedan al trabajo en curso y toda la retroalimentación de la iteración pasada se utiliza para reajustar los objetivos de las siguientes iteraciones. Se continúa con esta dinámica hasta que se haya finalizado por completo con una versión final del producto software. 2.2.3 Estructura general del proceso RUP. El proceso puede ser descrito en dos dimensiones o ejes como se ve en la figura 2.2:

17

FIG 2.2. Estructura del proceso RUP.

[Letelier02]

El eje horizontal representa la línea del tiempo y es considerado el eje de los aspectos dinámicos del proceso. Indica las características del ciclo de vida del proceso, representado en fases (Inicio, Elaboración, Construcción y Transición), iteraciones e hitos.

Eje vertical representa los aspectos estáticos del proceso. Describe el proceso en términos de componentes de proceso, disciplinas o flujos de trabajo “workflows”, artefactos, roles y actividades.

2.2.3.1 Estructura dinámica del proceso. RUP divide el proceso en cuatro fases: Inicio, Elaboración, Construcción y Transición, dentro de las cuales se realizan varias iteraciones en un número variable, según el proyecto, y en las que se hace un mayor o menor énfasis en las distintas disciplinas llamadas “Workflows - Flujos de Trabajo”. En la Figura 2.2 se muestra cómo varía el esfuerzo asociado a las disciplinas según la fase en la que se encuentre el proyecto. Se observa que en cada fase participan todas las disciplinas, pero que dependiendo de la fase, el esfuerzo dedicado a una disciplina varía.

18



Las primeras iteraciones de las fases de Inicio y Elaboración se enfocan hacia la comprensión del problema y la tecnología, la delimitación del ámbito del proyecto, la eliminación de los riesgos críticos, y al establecimiento de una línea base para la arquitectura. Durante la fase de inicio las iteraciones hacen ponen mayor énfasis en actividades modelado del negocio y de requisitos.



En la fase de Elaboración, las iteraciones se orientan a la construcción de la línea base de arquitectura, abarcan los flujos de trabajo de requisitos, modelo de negocios (refinamiento), análisis, diseño y una parte de implementación.



La fase de Construcción se lleva a cabo por medio de una serie de iteraciones. Para cada iteración se seleccionan algunos casos de uso, se refina su análisis y diseño, y se procede a su implementación y pruebas. Se realiza una pequeña cascada para cada ciclo. Se realizan tantas iteraciones como se requieran, hasta que se termine la implementación de una versión del producto.



En la fase de Transición se pretende garantizar que se tiene un producto preparado para su entrega a los usuarios.

2.2.3.2 Estructura estática del proceso. Un proceso de desarrollo de software define quién hace qué, cómo y cuándo. RUP define cuatro elementos: los roles, las actividades, los productos (artefactos) y los flujos de trabajo o disciplinas que responden a cada una de estas preguntas.


Roles y Actividades. Una persona puede desempeñar diversos roles, así como un mismo rol puede ser representado por varias personas. Las responsabilidades de un rol son tanto el llevar a cabo un conjunto de actividades como el ser el dueño de un conjunto de artefactos. Una actividad en concreto es una unidad de trabajo que una persona desempeña.

RUP define grupos de roles, agrupados por participación en actividades relacionadas. Estos grupos son: 

Analistas: Analista de procesos de negocio, Diseñador del negocio, Analista de sistema y Especificador de requisitos.

19



Desarrolladores: Arquitecto de software, Diseñador, Diseñador de interfaz de usuario, Diseñador de base de datos, Implementador e Integrador.



Gestores: Jefe de proyecto, Jefe de control de cambios, Jefe de configuración, Jefe de pruebas, Jefe de despliegue, Ingeniero de procesos, Revisor de gestión del proyecto y Gestor de pruebas.



Apoyo: Documentador técnico, Administrador de sistema, Especialista en herramientas, Desarrollador de cursos y Artista gráfico.



Especialista en pruebas: Especialista en Pruebas (Tester), Analista de pruebas, Diseñador de pruebas.



Otros roles: Stakeholders (participantes), Revisor, Coordinador de revisiones y Revisor técnico


Artefactos. Los productos o artefactos son los resultados tangibles del proyecto, las cosas que se van creando, modificado y usando hasta obtener el producto final durante el proceso de desarrollo de software. Un artefacto puede ser cualquiera de los siguientes: un documento, un modelo (como el de casos de uso), un elemento propio del modelo (una clase o un caso de uso), un subsistema o componente.
Flujos de trabajo (Disciplinas). Con simplemente la enumeración de roles, actividades y artefactos no se define un proceso, se necesita contar con una secuencia de actividades realizadas por los diferentes roles, así como la relación entre los mismos. Un flujo de trabajo es una relación de actividades que producen unos resultados observables, y en RUP son:



Modelado del negocio. Con esta disciplina se pretende llegar a un mejor entendimiento de la organización donde se va a implantar el producto (software).



Requisitos. Esta es una de las disciplinas más importantes, porque en él se establece qué tiene que hacer exactamente el sistema a construir. En esta línea los requisitos son el contrato que se debe cumplir, de modo que los usuarios finales tienen que comprender y aceptar los requisitos que se especifiquen.

20



Análisis y Diseño. El objetivo de este flujo es traducir los requisitos a una especificación que describe cómo implementar el sistema, mediante su representación a través de los diferentes modelos UML definidos para las actividades de análisis y diseño.



Implementación. En éste flujo se implementan las clases y objetos, en código fuente, binarios y ejecutables. Además se deben hacer las pruebas de unidad: cada desarrollador es responsable de probar las unidades que produzca. El resultado final de este flujo de trabajo es un sistema ejecutable.



Pruebas. Este flujo de trabajo es el encargado de evaluar la calidad del producto que está siendo desarrollando, pero no para aceptar o rechazar el producto al final del proceso de desarrollo, sino para ir integrándolo en todo el ciclo de vida.



Despliegue. El objetivo de este flujo de trabajo es producir con éxito entregables del producto y distribuirlos a los usuarios.



Gestión del proyecto. La gestión del proyecto es el arte de lograr un balance al administrar objetivos, riesgos y restricciones para desarrollar un producto que sea acorde a los requisitos de los clientes y los usuarios.



Configuración y control de cambios. El objetivo de ésta disciplina es mantener la integridad de todos los artefactos que se crean en el proceso, así como de mantener información del proceso evolutivo que se ha seguido.



Entorno. La finalidad de éste flujo de trabajo es dar soporte al proyecto con las adecuadas herramientas, procesos y métodos. Brinda una especificación de las herramientas que se van a necesitar en cada momento, así como definir el instante concreto del proceso en el que han de ser empleados.

2.2.4 Prácticas. RUP identifica 6 mejores prácticas con las que define una forma efectiva de trabajar en equipos de desarrollo de software. 

Gestión de requisitos. RUP brinda una guía para encontrar, organizar, documentar, y seguir los cambios de los requisitos funcionales y sus restricciones. Utiliza la notación de Caso de Uso y escenarios para representar los requisitos.

21



Desarrollo de software iterativo. Desarrollo del producto mediante iteraciones con hitos bien definidos, en las cuales se repiten las actividades pero con distinto énfasis, según la fase del proyecto.



Desarrollo basado en componentes. La creación intensiva de sistemas en software requiere dividir cada 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 se desarrollan sus componentes.



Modelado visual (usando UML). UML es un lenguaje para visualizar, especificar, construir y documentar los artefactos de un sistema software. Utilizar herramientas de modelado visual facilita la gestión de dichos modelos, permitiendo ocultar o exponer detalles cuando sea necesario. El modelado visual también ayuda a mantener la consistencia entre los artefactos del sistema: requisitos, diseños e implementaciones. El modelado visual ayuda a mejorar la capacidad del equipo para gestionar la complejidad del software.



Verificación continúa de la calidad. Es importante que la calidad de todos los artefactos se evalúe varias veces durante el proceso de desarrollo, especialmente al final de cada iteración. En esta verificación las pruebas juegan un papel fundamental y se integran a lo largo de todo el proceso. Para todos los artefactos, no necesariamente ejecutables, las revisiones e inspecciones deben ser continúas.



Gestión de los cambios. El cambio es un factor de riesgo crítico en los proyectos de software. Los artefactos software cambian no sólo por acciones de mantenimiento posteriores a la entrega del producto, sino que durante el proceso de desarrollo aparecen nuevos cambios en los requisitos. Otro gran desafío que debe abordarse en la construcción de software es la participación de múltiples desarrolladores trabajando a la vez en un mismo incremento y quizás en distintas plataformas. La ausencia de una disciplina, rápidamente conduciría al caos. Las prácticas de Gestión de Cambios y de Configuración es la disciplina que RUP encarga para este aspecto.

22