Sie sind auf Seite 1von 7

S y s t e m

y

t

i

r s

e

i v

U n

l

t i o n a

t e r n a

I n

W h i t n e y

c o n

n z a

i a

l

a

G r a n c o l o m b i a n o - e n

c n i c o

é

t

i

l

P o

¿CÓMO SE DESARROLLA SOFTWARE? PROCESOS TÉCNICOS

t i l P o ¿CÓMO SE DESARROLLA SOFTWARE? PROCESOS TÉCNICOS Hoy en día, el proceso

Hoy en día, el proceso de desarrollar software tiene muchos más componentes que el mero acto de escribir código. Es posible que hace algunos años (Y no pocos realmente), una sola persona pudiera generar productos de software de alta calidad trabajando de manera aislada y confiando en un proceso informal. Sin embargo, esto no es cierto hoy en día. Para que un proyecto de software de una complejidad media sea llevado a buen término en estos momentos, es necesario tener en cuenta un conjunto de subprocesos, fases y alternativas, que requieren que un desarrollador tenga claridad no solamente del detalle técnico que está implementando, sino de cómo esa parte del código interactuará con las demás de tal manera que se convierta en un componente productivo de una solución de software.

Las aplicaciones de software modernas son productos altamente complejos que comprender en muchas ocasiones un conjunto complejo de partes que interactúan y se interrelacionan de maneras no triviales. Los productos finales de un desarrollo tienen que ser desplegados en ambientes complejos y cambiantes a los que deben adaptarse y cuyas características deben ser tenidas en cuenta cuando se piensa en la solución al problema original. Aún después de que un producto de software está en funcionamiento, es muy posible que sea necesario modificarlo, y esta circunstancia debe ser tenida en cuenta desde el principio del proceso de desarrollo para que los cambios sean lo menos traumáticos que sea posible. Si en un proceso de desarrollo participa más de un desarrollador (Que como se dijo con anterioridad es lo usual hoy en día), es necesario que todos compartan la misma visión del resultado final, y se coordinen en términos del desarrollo para asegurar que el producto entregado funcione de la mejor manera posible y el código escrito por todos interactúe eficazmente.

Todos estos factores, y muchos otros que no son expresados aquí no tienen por qué ser motivo de desolación para el lector. El hecho de que existan retos dentro del proceso de desarrollo solo es un recordatorio de que los procesos deben ser llevados con un mínimo de formalismo y orden. Es necesario tener respeto por la profesión, por las responsabilidades que conlleva, y aplicar de manera adecuada el aprendizaje adquirido a lo largo de la formación. No pretendemos desanimar al futuro desarrollador. De hecho se trata de todo lo contrario. El mensaje aquí es: “Estos son los posibles retos a los que tendrá que enfrentarse. Sin embargo, el mero hecho de tenerlos claros es una ventaja, y existe la garantía de que el proceso de enseñanza que comienza le dará las herramientas para enfrentarlos y vencerlos”.

1

Así pues, abordemos el tema con confianza. Ya que no se pretende en esta lectura condensar de manera adecuada todo aquello que se verá con mucho más detalle en módulos venideros, baste decir que vamos a contemplar y describir los procesos técnicos que comprende el desarrollo de software, junto con los conceptos y procesos que se encuentran en su base. Se deja para lecturas posteriores el abordar otros aspectos, como los organizacionales y corporativos.

Comencemos diciendo que el proceso de desarrollo de software (Entendido ya no solamente como el proceso de escribir instrucciones en un lenguaje determinado, sino como el proceso que arrancando de un problema, genera una solución en forma de uno o varios programas de software), tiene varias facetas, y puede contemplarse de varias maneras.

De una manera inicial, es posible caracterizarlo como un proceso de resolución de problemas. Desde esta perspectiva, el objetivo fundamental de un proceso de desarrollo es encontrar la mejor manera de resolver un problema dado a través de la escritura de código. Sin embargo, para poder generar una solución en código a un problema es necesario haber entendido dicho problema; dadas las características complejas de muchos de los problemas a los que se enfrenta un desarrollador, esto exige en muchas ocasiones la utilización de modelos que simplifiquen el mundo de tal manera que pueda ser analizado y entendido con un nivel de detalle suficiente como para estar seguro de que la solución propuesta es adecuada, pero con un nivel de simplificación adecuado para poder generar una solución efectiva sin verse frenado por los niveles excesivos de complejidad.

En tercer lugar, es posible que aun después de la generación de modelos que permitan comprender el problema planteado, sea necesario completar la información de la que se dispone. De esta manera, pueden existir procesos de investigación que se hagan necesarios para poder contar con todo el conocimiento necesario para comprender el problema, o plantear una solución determinada.

Así pues, un desarrollador de software debe tener capacidad de abstracción para poder elaborar un modelo del problema que se le presenta, habilidades de consecución de información para completar las partes de dicho modelo que resulten incompletas, y criterio y habilidades de solución de problemas para poder definir cuál es la mejor solución e implementarla de manera que se convierta en un producto de software. Todo esto antes de empezar a escribir una línea de código. Desde luego que el proceso de generar el código que se convertirá en la solución final al problema es muy importante y sofisticado, y es justamente por eso que debe dedicarse el tiempo y atención suficientes a los procesos previos. Para que en el punto de escribir el código, se tenga la claridad suficiente de que no se están desperdiciando las habilidades y el esfuerzo del desarrollador.

2

Veamos pues, en un poco más de detalle cada uno de los aspectos mencionados con anterioridad:

MODELADO Un modelo es una representación abstracta de un sistema que ofrece información sobre el mismo, de tal manera que permite responder preguntas sobre el sistema real. Los modelos son extremadamente útiles cuando se está lidiando con sistemas que son demasiado complejos, grandes o costosos para ser examinados de manera directa. A pesar de que los modelos no contienen toda la información que contiene el sistema original, si contienen información suficiente para que sea posible tomar decisiones y hacer predicciones bastante acertadas acerca del comportamiento del sistema original. Dadas las características de la mayor parte de los problemas que se solucionan con software hoy en día, es muy probable que el desarrollador deba lidiar con conceptos y medios que no le son familiares. En ese caso, resulta más que útil poder generar un modelo que describa la situación o el ambiente, sin tener que convertirse en un experto absoluto en el área del problema.

INVESTIGACIÓN Y ADQUISICIÓN DE CONOCIMIENTO Este es un proceso que se da a lo largo de todo el desarrollo de software. Información puede llegar al final del proceso que haga necesario repensar el diseño desde el principio, de manera que es necesario que el desarrollador tenga la habilidad y la disposición de enfrentarse a hechos y datos que le hagan reevaluar su postura y sus intenciones dentro del marco del proceso de desarrollo.

SOLUCIÓN DE PROBLEMAS. Ya se ha dicho que el ejercicio de desarrollo de software es un ejercicio de solución de problemas. En su manera más simple, un proceso de solución de problemas podría seguir estos pasos:

1. Se formula el problema

2. Se analiza el problema

3. Se buscan posibles soluciones

4. Se decide una solución apropiada

5. Se implementa la solución

En el área del desarrollo de software las condiciones no son muy diferentes. Se podrían enunciar las siguientes fases:

1. Levantamiento de requerimientos

2. Análisis

3. Diseño

4. Implementación

Describamos cada una de ellas con un poco de detalle:

3

LEVANTAMIENTO DE REQUERIMIENTOS El objetivo fundamental de esta actividad es aclarar, en conjunto con el cliente y los usuarios, que es lo que se espera y desea de la aplicación de software. La idea es que se defina el problema en conjunto, y en conjunto también se describa la solución al mismo, siempre desde la perspectiva del usuario del sistema. El proceso debe llevarse a cabo con el mayor detalle y cuidado, pues resulta no solo conveniente sino necesario tener la mayor certeza posible de que las dos partes del proceso, el cliente y el desarrollador tienen la misma visión y el mismo conjunto de expectativas respecto al producto de software fruto del proceso de desarrollo. Cualquier tipo de desacuerdo o confusión debe ser subsanado o aclarada de inmediato, pues las divergencias de criterio en este punto se propagarán a través de todo el proceso, resultando en un producto que no cumple con las expectativas del cliente, o que no tiene las características técnicas esperadas por el desarrollador. Los principales elementos que se definen al terminar esta fase son los actores que interactuarán con el sistema, las descripciones de dichas interacciones, y las relaciones que existen entre ellas. Ningún tipo de detalle técnico o característica no visible al usuario serán tenidos en cuenta en este punto. Este tipo de detalles se tratarán más adelante. Sin embargo, no se puede insistir suficiente en que el hecho de que no se trate de un proceso técnico no le resta importancia al levantamiento de requerimientos. Siendo los requerimientos definidos en esta fase la base de todas las demás fases del proceso, es extremadamente importante que se verifique constantemente que sean completos, correctos, consistentes, no ambiguos y realistas. El cumplimiento de estas características en una fase temprana como esta, facilitará el resto del proceso de desarrollo.

ANÁLISIS. El proceso de análisis busca generar modelos que sean precisos, lo más completos posible, y sobre todo útiles, tanto del problema en cuestión como de las soluciones posibles al mismo. El punto de partida de este subproceso es el conjunto de requerimientos que se han definido para el software, y el proceso implica la documentación y formalización de dichos requerimientos. Es necesario alcanzar un nivel de comprensión del problema que permita extraer la información relevante e incluirla en el modelo. Así mismo, es necesario definir un modelo propuesto de solución que satisfaga los requerimientos planteados y que sea funcional dentro del modelo de problema encontrado. Es posible que el resultado final de la fase de análisis no se comprensible para el cliente, pero su función es ser claro para los desarrolladores, pues solamente de esta manera podrá luego trasladarse a un diseño y una implementación adecuadas que satisfagan las necesidades iniciales. Otra ventaja de tener un modelo resultante del análisis que sea detallado y comprensible es que se facilita la toma de decisiones pues se tiene una visión real y clara del software a desarrollar. Una de las principales causas de aplazamiento en la toma de decisiones (Que después se convierte en una fuente de demoras, problemas y sobrecostos), es la falta de información

4

completa, detallada, clara y consistente. Un buen modelo de análisis reduce en gran medida este riesgo.

La salida fundamental de un buen proceso de análisis es un modelo que contenga los elementos que interactúan para dar solución al problema por medio de una aplicación de software, así como los atributos que describen cada uno de esos elementos y las relaciones que existen entre ellos, todo esto desde la perspectiva del usuario.

Existen muchas maneras de documentar un proceso de análisis, sin embargo, uno de los mecanismos preferidos en el campo del desarrollo de software es utilizar UML –Unified Modeling Language, o Lenguaje Unificado de Modelado- que es el estándar de facto para la representación de modelos de análisis y diseño de software.

DISEÑO. En este punto, se busca obtener el detalle de la solución planteada, de tal manera que se tenga claridad respecto a las partes que la componen y las relaciones que existen entre ellas. Esta vez la preocupación está en definir esta estructura desde el punto de vista interno de la solución. El nivel de detalle aquí es importante, pues es con el resultado de esta fase que se abordará el proceso de implementación, y todo aquello que haya sido ignorado en este subproceso, quedará por fuera de la solución final implementada, a no ser que se hagan revisiones más adelante. Es importante recalcar sin embargo, que modificaciones hechas durante la implementación son más costosas que aquellas hechas durante el diseño, que a su vez son mucho más costosas que aquellas correcciones realizadas durante la fase de análisis.

Deben definirse en esta fase guías acerca de cómo se manejarán elementos comunes a todos los subsistemas del software desarrollado, incluyendo manejo de datos, configuraciones de hardware, estrategias de control de acceso, etc.

El resultado final de la fase de diseño consiste en tener un conjunto de metas de diseño que guiarán el proceso de aquí en adelante, así como una descomposición de la solución desde el punto de vista estructural en términos de código. Esto último corresponde a una división en subsistemas, haciendo énfasis en la ubicación, responsabilidades y relaciones que cada uno de dichos subsistemas presenta.

IMPLEMENTACIÓN. La implementación es la fase en la que un diseño detallado se convierte en una solución de software real y completamente funcional. Esta fase abarca todo el tiempo y los procesos que sean necesarios para traducir una especificación de solución tal como fue diseñada en la fase anterior a un ejecutable que solucione los problemas planteados durante la fase de levantamiento de requerimientos. Si el proceso completo fue llevado de manera adecuada, los cambios y contratiempos en esta fase deberían ser mínimos, sin embargo, una fase de implementación llevada a cabo de una manera organizada incluye puntos de control en los que se verifica que el

5

software desarrollado coincide con lo que el cliente espera y el diseño dicta, y que el comportamiento de la aplicación en el punto en que se encuentra el proceso de desarrollo es adecuada y no presenta fallos. Sobra decir que en el momento en que dichos fallos o divergencias aparezcan, deben ser tratados y solucionados de inmediato.

El resultado principal de una fase de implementación llevada de una manera adecuada es el software desarrollado en un estado completamente funcional, en plena coincidencia con los requerimientos planteados durante la primera fase del proyecto, entregado a satisfacción del cliente, y dentro de los marcos de tiempo y presupuesto pronosticados. Desde luego, buena parte de estas condiciones no dependen de circunstancias meramente técnicas, por lo que no puede garantizarse que seguir las fases y recomendaciones esbozadas en este documento redunde en el cumplimiento de todos los aspectos mencionados. El proceso de construir un producto software comprende otras actividades además de las meramente técnicas.

6

BIBLIOGRAFÍA

BRUEGGE B., DUTOIT, A.(2003), Object-Oriented Software Engineering, Prentice Hall,

7