Desarrollo de Software: Proceso, Ética y Modelado con UML


Visión general del proceso de desarrollo de software

El proceso de desarrollo de software es afectado por la creatividad y juicio de las personas involucradas. En el desarrollo de software hay una serie de desafíos adicionales, relativos esencialmente a la naturaleza del producto obtenido. Un proceso de desarrollo de software tiene como propósito la producción eficaz y eficiente de un producto software que reúna los requisitos del cliente.

Desafíos en la comunicación con el cliente

1) El proyecto no se hace solo, porque incluso existiendo una gran ayuda por parte de los usuarios, si no se consigue interpretar con precisión lo que quieren y no se dinamiza un feedback continuo de los mismos durante todo el proceso de desarrollo, se incrementarán las posibilidades de que algún requisito funcional no se haya recogido adecuadamente o de que se haya realizado un software con una usabilidad incómoda para los usuarios.

Estas circunstancias son fuente de innumerables problemas en las fases finales del proyecto y provocan retrasos, sobrecostes y grandes dificultades para cerrar el proyecto, además de crear conflictos con el cliente que pueden perjudicar las relaciones futuras con el mismo. Esto hace que sea fundamental el papel que desempeñan tanto el jefe de proyectos, como el equipo de analistas funcionales y analistas programadores.

Importancia de la diversidad de usuarios en el equipo

2) Es importante que entre el grupo de usuarios asignados al proyecto haya usuarios que vayan a estar implicados en el futuro uso del sistema de información, es decir, no es suficiente que el equipo de usuarios esté formado por “ideólogos” o “teóricos” que se nutrirán del resultado del trabajo de la herramienta, sino que es fundamental que participen usuarios que después se tengan que poner el buzo de trabajo y vayan a trabajar con el software. Es importante conseguir la combinación de ambos tipos de usuarios (tampoco es positivo que en el grupo de usuarios no participen usuarios directores, ya que pueden existir conflictos entre usuarios que éstos deben solucionar y también es recomendable que el software no sólo se diseñe para el corto plazo, sino que sirva para tareas de gestión, planificación, etc… y esta visión la proporcionan principalmente los usuarios directores), por lo que el jefe de proyectos debe poner en conocimiento del cliente esta necesidad, como es lógico explicando los riesgos de que no se aplique esta estrategia.

Colaboración y diálogo con los usuarios

3) Los analistas están para ayudar y para colaborar con los usuarios en la especificación y diseño de la solución, pero no están para “dar lecciones” a los usuarios y enseñarle cómo deben hacer su trabajo. Si los usuarios hacen su trabajo de una determinada manera, aunque no sea la más ortodoxa, siempre tendrá una justificación que sólo se entendería si realmente estuviéramos haciendo su trabajo durante un tiempo y viéramos los problemas con los que se enfrentan cotidianamente. La clave por tanto está en la colaboración y en el diálogo, es decir, se pueden proponer cosas al usuario, se le pueden dar ideas, pero no se le puede dar una vuelta al calcetín de cómo hacen sus tareas, salvo que ellos mismos lo soliciten y procurando en estos casos y en consenso con los usuarios que los cambios sean tranquilos.

Documentación del proyecto

4) Es fundamental documentar el proyecto, en primer lugar con la documentación que se especifique en las normativas de desarrollo de la organización para la que se realiza el servicio, con las matizaciones que indique el Director del Proyecto, en segundo lugar con la documentación que establezcan las normativas internas de calidad de tu organización (no requerirá un sobreesfuerzo, ya que en la mayor parte de los casos coincidirá) y a todo lo anterior sumarle toda la documentación de trabajo que sea necesaria para trabajar con los usuarios, que no tienen por qué entender de modelos de datos, de diagramas de casos de uso, etc…, es más, es un error trabajar con los usuarios utilizando dichas herramientas, ya que estas son de utilidad técnica y no hablan el mismo lenguaje de los usuarios. Este tipo documentación, por tanto, no tiene por qué tener los formalismos de la técnica y tiene como objetivo que el usuario capte lo que el analista está interpretando y se pueda ir perfilando a partir de esto, tanto requisitos, como casos de uso, interfaces, etc… Es muy importante trabajar todo esto, ya que comenzar demasiado pronto con la construcción, es algo muy arriesgado, ya que los costos de modificar algo en las distintas fases de la construcción pueden ser muy importantes y provocar que se tengan que reconstruir varias veces distintas funcionalidades de la aplicación.

Responsabilidad profesional y ética en la Ingeniería de Software

La ingeniería del software se lleva a cabo dentro de un marco legal y social que limita la libertad de los ingenieros. Los ISW deben aceptar que su trabajo comprende responsabilidades más amplias que simplemente la aplicación de habilidades técnicas. Deben comportarse de una forma ética y moral responsable, no basta con poseer estándares normales de honestidad e integridad. No debería utilizar su capacidad y sus habilidades para comportarse de forma deshonesta o de forma que deshonre la profesión de la ingeniería del software.

Existen áreas donde los estándares de comportamiento aceptable no están acotados por las leyes, sino por la responsabilidad profesional, algunas de estas son:

  • Confidencialidad. Respetar la confidencialidad de sus empleadores o clientes, independientemente de que se haya firmado un acuerdo formal de confidencialidad.
  • Competencia. No debe falsificar su nivel de competencia, ni aceptar conscientemente trabajos que están fuera de su capacidad.
  • Derechos de propiedad intelectual. Debe ser consciente de las leyes locales que gobiernan el uso de la propiedad intelectual, como las patentes y el copyright. Debe asegurarse de que la propiedad intelectual de los empleadores y clientes está protegida.
  • Uso inapropiado de las computadoras. No debe emplear sus habilidades técnicas para utilizar de forma inapropiada las computadoras de otras personas. Desde los relativamente triviales (utilizar juegos en las máquina de un empleado, por ejemplo) hasta los extremadamente serios (difusión de virus).

Código de ética (ACM/IEEE)

http://ethics.iit.edu/ecodes/node/5641

Los ingenieros de software deberán comprometerse consigo mismo en convertir el análisis, especificación, diseño, desarrollo, prueba y mantenimiento de software en una profesión respetable y beneficiosa. De acuerdo con su compromiso con la salud, seguridad y bienestar del público, los ingenieros de software deberán apegarse a ocho principios.

Principios del código de ética en Ingeniería de Software

  • Público: Los ingenieros de software deberán actuar consistentemente con el interés público.
  • Cliente y Empleador: Los ingenieros de software deberán actuar de una forma determinada que esté en los mejores intereses de su cliente y empleador consistente con el interés público.
  • Producto: Los ingenieros de software deberán asegurar que sus productos y modificaciones relacionadas logren el más alto estándar profesional posible.
  • Juicio: Los ingenieros de software deberán mantener integridad e independencia al emitir su juicio profesional.
  • Gerencia: Los gerentes y líderes de ingeniería de software deberán suscribirse y promocionar un enfoque ético para la gerencia de desarrollo y mantenimiento del software.
  • Profesión: Los ingenieros de software deberán fomentar la integridad y reputación de la profesión consistente con el interés público.
  • Colegas: Los ingenieros de software deberán ser justos y comprensivos con sus colegas.
  • Interés Propio: Los ingenieros de software deberán participar en el aprendizaje de por vida del ejercicio de su profesión y deberán promover un enfoque ético para el ejercicio de esta.

Conceptos Básicos de la Orientación a Objetos

2.1.- Qué es un Objeto

De manera intuitiva, la tendencia general es asociar el término objeto con todo aquello a lo que se puede atribuir la propiedad física de masa, como una tostadora de pan, aunque es posible encontrar objetos de índole no tangible, como por ejemplo una dirección postal. En el ámbito de la informática, un objeto define una representación abstracta de las entidades del mundo, tangibles o no, con la intención de emularlas. Existe pues, una relación directa entre los objetos del mundo y los objetos informáticos, de modo que puede emplearse el término objeto de manera indistinta.

Los objetos tienen dos características, que son su estado y su comportamiento. El estado es una situación en la que se encuentra el objeto, tal que cumple con alguna condición o condiciones particulares, realiza alguna actividad o espera que suceda un acontecimiento. Una tostadora puede estar encendida y cargada de pan y, en cuanto a su comportamiento, lo normal en este estado es tostar pan.

Los objetos mantienen su estado en uno o más atributos, que son simplemente datos identificados por un nombre, y exhiben su comportamiento a través de métodos, que son trozos de funcionalidad asociados al objeto. En este sentido, un objeto es realmente un conjunto de atributos y métodos. Pero un objeto sólo revela su verdadera utilidad cuando es integrado en un contexto de comunicación con otros objetos, a través del envío de mensajes, para componer un sistema mucho mayor y demostrar un comportamiento más complejo. Una tostadora en un armario resulta de poca utilidad, pero cuando interactúa con otro objeto, como un ser humano, se convierte en una herramienta útil para tostar pan. El humano intercambiaría con la tostadora el mensaje “tuesta el pan que tienes en la bandeja” a través de la pulsación del botón de tostar.

A partir del ejemplo anterior, es fácil deducir que el envío de mensajes es la forma en que se invocan los métodos de un objeto y que la invocación de métodos es el mecanismo a través del cual un objeto puede cambiar su estado o el de otro objeto. Los atributos y los métodos de un objeto pueden tener un menor o mayor grado de visibilidad, desde “privado” hasta “público”, lo que hace que aparezca un concepto nuevo, la encapsulación. La encapsulación oculta los detalles del funcionamiento interno del objeto, exponiendo sólo aquello que pueda ser de interés.

Introducción a UML: Lenguaje Unificado de Modelado

1.- Introducción

En los tiempos que corren, el software tiene la tendencia de ser grande y complejo. Los usuarios demandan interfaces cada vez más completas y funcionalidades más elaboradas, todo ello influyendo en el tamaño y la complejidad del producto final. Por ello, los programas deben ser estructurados de manera que puedan ser revisados, corregidos y mantenidos, rápida y eficazmente, por gente que no necesariamente ha colaborado en su diseño y construcción, permitiendo acomodar nueva funcionalidad, mayor seguridad y robustez, funcionando en todas las situaciones que puedan surgir, de manera previsible y reproducible.

Ante problemas de gran complejidad, la mejor forma de abordar la solución es modelar. Modelar es diseñar y estructurar el software antes de lanzarse a programar y es la única forma de visualizar un diseño y comprobar que cumple todos los requisitos para él estipulados, antes de que la flotilla de programadores comience a generar código. Modelando, los responsables del éxito del producto pueden estar seguros de que su funcionalidad es completa y correcta, que todas las expectativas de los usuarios finales se cumplen, que las posibles futuras ampliaciones pueden ser acomodadas, todo ello mucho antes de que la implementación haga que los cambios sean difíciles o imposibles de acomodar. Modelando, se abstraen los detalles esenciales de un problema complejo y se obtiene diseños estructurados que, además, permiten la reutilización de código, reduciendo los tiempos de producción y minimizando las posibilidades de introducir errores.

UML es un lenguaje gráfico que sirve para modelar, diseñar, estructurar, visualizar, especificar, construir y documentar software. UML proporciona un vocabulario común para toda la cadena de producción, desde quien recaba los requisitos de los usuarios, hasta el último programador responsable del mantenimiento. Es un lenguaje estándar para crear los planos de un sistema de forma completa y no ambigua. Fue creado por el Object Management Group, OMG, un consorcio internacional sin ánimo de lucro, que asienta estándares en el área de computación distribuida orientada a objetos, y actualmente revisa y actualiza periódicamente las especificaciones del lenguaje, para adaptarlo a las necesidades que surgen. El prestigio de este consorcio es un aval más para UML, considerando que cuenta con socios tan conocidos como la NASA, la Agencia Europea del Espacio ESA, el Instituto Europeo de Bioinformática EBI, Boeing, Borland, Motorla y el W3C, por mencionar algunos.

2.- La Orientación a Objetos, OO

Aunque UML puede emplearse en cualquier paradigma, como la programación estructurada o la lógica, está especialmente cerca del paradigma de la orientación a objetos. Por tanto, es precisa una familiarización con algunos detalles de este paradigma antes de continuar con UML.

2.2.- Qué es una Clase

Los objetos no son entidades que existan de modo único. Hay muchos tipos de tostadoras e, igualmente, muchas tostadoras del mismo tipo. Se puede entender fácilmente el concepto de clase si nos permitimos emplear el término tipo como equivalente. Así, todos los objetos que son del mismo tipo, comparten el mismo juego de atributos y métodos (aunque cada objeto pueda tener un valor distinto asociado a cada atributo) y por tanto pertenecen a una misma clase. Las clases son como patrones que definen qué atributos y qué métodos son comunes a todos los objetos de un mismo tipo.

Cada objeto tiene sus atributos y su comportamiento, creados empleando una clase a modo de patrón. Una vez creado el objeto, pasa a ser una instancia particular de la clase a la que pertenece y sus atributos tienen unos valores concretos, que podrán variar de un objeto a otro (dos objetos distintos pertenecientes a la misma clase, pueden tener exactamente los mismos valores en todos sus atributos). A estos atributos, que pueden variar de un objeto a otro, se les conoce también como variables de instancia.

Hay atributos que, sin embargo, no varían de un objeto a otro, es decir todas las instancias de la clase a la que pertenecen, tienen el mismo valor para ese atributo. Todas las tostadoras del mismo tipo consumen los mismos Watios y sus resistencias son de los mismos Ohmios. A estos atributos se les conoce como variables de clase y son compartidos por todas y cada una de las instancias de la clase. De manera análoga al caso de los atributos, encontramos métodos de instancia y métodos de clase.

2.3.- Qué es la Herencia

Los objetos se definen en función de clases, es decir, tomando una clase como patrón. Se puede saber mucho acerca de un objeto sabiendo la clase a la que pertenece. Por ejemplo, con decir que la “Russell Hobbs 10243 Kudos” es un tipo de tostadora, inmediatamente se sabe que se trata de una máquina para tostar pan, probablemente eléctrica y con por lo menos una ranura en la que insertar una rebanada de pan y un botón para activar su funcionamiento.

Las clases llegan un paso más lejos, permitiendo su definición en función de otras clases, de modo que es posible establecer una jerarquía de especialización. Una clase que se define en función de otra, hereda todos los atributos y métodos de aquella y permite el añadido de nuevos o la sobre escritura de los heredados. La clase patrón se conoce con el nombre de superclase o clase padre, mientas que la que hereda se conoce como clase hija. La herencia no está limitada simplemente a padre-hija(s), la jerarquía puede ser todo lo profunda que sea necesario, hablando en términos de nietas, biznietas, etc. De la misma manera, una clase puede heredar de varias clases a la vez.

En la siguiente figura se puede ver una jerarquía de especialización de dos niveles. La clase “Animal” es la raíz, la clase padre en la jerarquía. Especifica que los animales comen, como característica más significativa de éstos. En el primer nivel de especialización encontramos las clases “Carnívoro” y “Herbívoro”, ambas son sendos tipos de animal y por tanto comen, sólo que en el caso de los carnívoros se ha especializado el tipo de comida que comen para indicar que se trata de carne. Aparece una nueva característica de este tipo de animal, que es el hecho de que los carnívoros cazan. En el caso de los herbívoros, encontramos que comen plantas y pacen. En el segundo nivel de especialización, encontramos un animal que es a la vez “Herbívoro” y “Carnívoro” y, como cabe esperar, este nuevo tipo de animal puede hacer todo lo que pueden hacer sus ancestros, comer carne, comer plantas, cazar y pacer, no encontrando ninguna característica adicional en los “Omnívoros”.

Dejar un Comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *