INTRODUCCIÓN AL UML 

El Lenguaje Unificado de Modelado (UML) fue creado para forjar un lenguaje de modelado visual común y semántica y sintácticamente rico para la arquitectura, el diseño y la implementación de sistemas de software complejos, tanto en estructura como en comportamiento. UML tiene aplicaciones más allá del desarrollo de software, p. ej., en el flujo de procesos en la fabricación.

Es comparable a los planos usados en otros campos y consiste en diferentes tipos de diagramas. En general, los diagramas UML describen los límites, la estructura y el comportamiento del sistema y los objetos que contiene.

UML no es un lenguaje de programación, pero existen herramientas que se pueden usar para generar código en diversos lenguajes usando los diagramas UML. UML guarda una relación directa con el análisis y el diseño orientados a objetos.

Los lenguajes orientados a objetos dominan el mundo de la programación porque modelan los objetos del mundo real. UML es una combinación de varias notaciones orientadas a objetos: diseño orientado a objetos, técnica de modelado de objetos e ingeniería de software orientada a objetos.

UML usa las fortalezas de estos tres enfoques para presentar una metodología más uniforme que sea más sencilla de usar. UML representa buenas prácticas para la construcción y documentación de diferentes aspectos del modelado de sistemas de software y de negocios.

TEMA 2.4 VALIDACIÓN DE REQUERIMIENTOS

Objetivos

Esta actividad tiene como objetivo realizar la validación de todos los requerimientos del sistema a construir. Estos requerimientos pueden ser tanto funcionales como no funcionales.

Descripción

Los analistas se reúnen con el cliente y/o usuario del sistema para validad los requerimientos que se revelaron y especificaron, es decir que estas especificaciones reflejan realmente lo que los usuarios necesitan.

Dela reunión de validación de requerimientos pueden surgir cambios en los requerimientos que impliquen que se realicen nuevamente las actividades de las especificaciones de requerimientos y priorizando los requerimientos necesarios.

TEMA 2.3 ESPECIFICACIÓN DE REQUERIMIENTOS

La especificación de los requerimientos de software (ERS) es una descripción completa del comportamiento del sistema que se va a desarrollar.  Incluye un conjunto de casos de uso que describe todas las interacciones que tendrán los usuarios con el software. Los casos de uso también son conocidos como  requisitos funcionales.
Recomendaciones para hacer una buena especificación de requerimientos:
Completa: Todos los requerimientos deben estar reflejados en ellas.
Correcta: El software debe de cumplir con los requisitos de la especificación.
Modificable: Aunque todo requerimiento es modificable, se refiere a que se debe de ser facilmente modificable.

TEMA 2.2 OBSERVACION Y ANÁLISIS DE REQUERIMIENTOS

Existe un gran número de técnicas para obtener requerimientos. A continuación describo las más utilizadas. Hay que aclarar que ninguna de estas técnicas es suficiente por sí sola y que es recomendable combinarlas para obtener requerimientos completos.

Entrevistas

La entrevista es de gran utilidad para obtener información cualitativa como opiniones, o descripciones subjetivas de actividades. Es una técnica muy utilizada, y requiere una mayor preparación y experiencia por parte del analista. La entrevista se puede definir como un “intento sistemático de recoger información de otra persona” a través de una comunicación interpersonal que se lleva a cabo por medio de una conversación estructurada. Debe quedar claro que no basta con hacer preguntas para obtener toda la información necesaria. Es muy importante la forma en que se plantea la conversación y la relación que se establece en la entrevista.

Estos son algunos de los aspectos más importantes a tener en cuenta al realizar entrevistas:

• Preparación. Es necesario documentarse e investigar la situación de la organización analizando los documentos disponibles, de tal forma que la entrevista se enfoque en aquellos aspectos que están solamente en la mente del entrevistado y que no son accesibles por otros medios como la observación o el análisis de documentos.
• Entrevistar al personal adecuado. La mayoría de los analistas adoptan un enfoque top-down, comenzando a entrevistar a directivos para que brinden un panorama general de hacia donde deberían ir las cosas, y terminando por hablar con los empleados que aportan detalles importantes de la operación.
• Duración. Una entrevista debería durar a lo sumo un par de horas.
• Formato. Se recomienda utilizar preguntas abiertas, donde los entrevistados puedan elaborar y dar detalles, más allá de simplemente responder “si” o “no”.

TEMA 2.1 ESTUDIO DE FACTIBILIDAD

El estudio de factibilidad es un instrumento que sirve para orientar la toma de decisiones en la evaluación de un proyecto y corresponde a la última fase de la etapa pre-operativa o de formulación dentro del ciclo del proyecto. Se formula con base en información que tiene la menor incertidumbre posible para medir las posibilidades de éxito o fracaso de un proyecto de inversión, apoyándose en él se tomará la decisión de proceder o no con su implementación.

VENTAJAS Y DESVENTAJAS DE LAS METODOLOGÍAS TRADICIONALES 

Estas metodologías tradicionales imponen una disciplina de trabajo sobre el proceso de desarrollo del software, con el fin de conseguir un software más eficiente. Para ello, se hace énfasis en la planificación total de todo el trabajo a realizar y una vez que está todo detallado, comienza el ciclo de desarrollo del producto software. Se centran especialmente en el control del proceso, mediante una rigurosa definición de roles, actividades, artefactos, herramientas y notaciones para el modelado y documentación detallada [42]. Además, las metodologías tradicionales no se adaptan adecuadamente a los cambios, por lo que no son métodos adecuados cuando se trabaja en un entorno, donde los requisitos no pueden predecirse o bien pueden variar.

Entre las metodologías tradicionales o pesadas podemos citar:

• RUP (Rational Unified Procces)

• MSF (Microsoft Solution Framework)

• Win-Win Spiral Model

• Iconix

VENTAJAS Y DESVENTAJAS DE METODOLOGÍAS ÁGILES

• La primera y la que, a mi parecer es la más importante, es que estas metodologías ofrecen una rápida respuesta a cambios de requisitos a lo largo del desarrollo del proyecto gracias a su proceso iterativo, es tan importante realizar una buena recolecta de requisitos, como después poder modificarlos evitando grandes pérdidas en cuanto a costes, motivación, tiempo…
• El cliente, si quiere colaborar, puede observar como va avanzando el proyecto, y por supuesto, opinar sobre su evolución gracias a las numerosas reuniones que realiza el equipo con el cliente. Esto le da tranquilidad.
• Uniendo las dos anteriores, se puede deducir que al utilizar estas metodologías, los cambios que quiera realizar el cliente van a tener un menor impacto, ya que se va a entregar en un pequeño intervalo de tiempo un pequeño “trozo” del proyecto al cliente, y si éste quiere cambiarlo, solo se habrá perdido unas semanas de trabajo. Con las metodologías tradicionales las entregas al cliente se realizaban tras la realización de una gran parte del proyecto, eso quiere decir que el equipo ha estado trabajando meses para que luego un mínimo cambio que quiera realizar el cliente, conlleve la pérdida de todo ese trabajo.
• Importancia de la simplicidad al eliminar trabajo innecesario

Pero claro, aunque las ventajas sean muy apetecibles, estas metodologías también presentan inconvenientes que hay que asumir cuando se decide trabajar con ellas. Estos son:

• Falta de documentación del diseño. Al no haber documentación es el código (junto con sus comentarios) lo que se toma como documentación.
• Problemas derivados de la comunicación oral. No hace falta decir que algo que está escrito “no se puede borrar”, en cambio, algo dicho es muy fácil crear ambigüedad.
• Fuerte dependencia de las personas.
• Falta de reusabilidad derivada de la falta de documentación
• Restricciones en cuanto a tamaño de los proyectos
• Problemas derivados del fracaso de los proyectos ágiles. Si un proyecto ágil fracasa no hay documentación o hay muy poca; lo mismo ocurre con el diseño. La comprensión del sistema se queda en las mentes de los desarrolladores.