Diagrama de clases

Diagrama de clases.

En ingeniería de software, un diagrama de clases en Lenguaje Unificado de Modelado (UML) es un tipo de diagrama de estructura estática que describe la estructura de un sistema mostrando las clases del sistema, sus atributos, operaciones (o métodos), y las relaciones entre los objetos.

Las relaciones existen entre las distintas clases nos indican como se comunican los objetos de esas clases entre si:

los mensajes "navegan" por las relaciones existentes entre las distintas clases.

Existen distintos tipos de relaciones:

Asociaciones (conexión entre las clases).

Dependencia(relación de uso).

Generalización (relación de herencia.).

Asociación:

Una asociación es una relación estructural que describe una conexión entre objetos.

Aunque las asociaciones suelen ser bidireccionales (se pueden recorren en ambos lados), en ocasiones es deseable hacerlas unidireccionales (restringir su navegación en un único sentido).

Gráficamente, cuando las asociaciones es unidireccional, la linea termina en una punta de la flecha que indica el sentido de la asociación.

Dependencia:

Relación (mas débil que una asociación) que muestra la relación entre un cliente y el proveedor de un servicio usado por el cliente.

* Cliente es el objeto que solicita un servicio.

* Servidor es el objeto que provee el servicio solicitado.

Graficamente, la dependencia se muestra como una linea discontinua con una punta de flecha que apunta del cliente al proveedor.

Herencia (generalización y especialización)

La relación entre una superclase y sus subclases.

Objetos de distintas clases pueden tener atributo similares y exhibir comportamientos parecidos.

Fuente:

http://elvex.ugr.es/decsai/java/pdf/3C-Relaciones.pdf

Video:

https://www.youtube.com/watch?v=mHfw4Q5xubU

Administracion de Requerimientos.

Administración de Requerimientos de software.

La administración de requerimientos es un proceso que tiene por objetivo comprender y controlar los requerimientos. Como todo proceso de administración, inicia con la planeación a la par de la identificación inicial de requerimientos. Este proceso tiene diferentes formas que dependen del proceso de desarrollo de software que se esté empleando, independientemente de esto se deben considerar las siguientes etapas:

Etapas:

1. Requerimientos duraderos y volátiles.
2. Planeación de la administración de requerimientos.
3. Administración del cambio de los requerimientos.

Durante esta etapa, para cada proyecto, es necesario establecer el nivel de detalle. 

Se tiene que decidir sobre:

1. La identificación de los requerimientos.
2. Un proceso de administración del cambio.
3. Políticas de rastreo.
4. Ayuda de herramientas CASE.

La administración de requerimientos necesita de ayuda automática para: 

1. Almacenar requerimientos.
2. Administrar los cambios.
3. Administrar el rastreo.

Sistemas pequeños pueden llevarse con procesador de texto, hoja de cálculo o una pequeña base de datos.

Un proceso formal para que todos los cambios propuestos sean tratados de forma consistente.

1. Análisis del problema y especificación del cambio.
2. Análisis cambio y costeo.
3. Implementación del cambio.

Siempre existe la tentación de hacer un cambio urgente al sistema y en retrospectiva modificar el documento de requerimientos. Esto conduce a un desfase e inconsistencias. 
Etapas: 

1. Análisis del problema y especificación del cambio.
2. Análisis cambio y costeo.
3. Implementación del cambio.

Siempre existe la tentación de hacer un cambio urgente al sistema y en retrospectiva modificar el documento de requerimientos. Esto conduce a un desfase e inconsistencias. 

https://www.youtube.com/watch?v=Ojc11JqBfRE

http://clases3gingsof.wikifoundry.com/page/Administraci%C3%B3n+de+Requerimientos

SCRUM

Metodología de Proyectos SCRUM

Recientemente he tenido la suerte de asistir a un curso sobre una metodología de proyectos llamada SCRUM. Digo la suerte porque, aunque habia oido hablar de ella, no me imaginaba que podría aportar tantas ventajas a la mejora en el rendimiento de equipos, o que es usada en grandes compañías (Google, Nokia...) como parte de sus procesos, ni que fuese tan fácil de implantar ciertas partes de esta metodología.

Sobre todo es una metodología de trabajo para proyectos de desarrollo software, pero se puede adaptar a proyectos y departamentos de sistemas, que es en lo que estoy trabajando en mi empresa en estos momentos, y, porque no, en otros departamentos que necesiten llevar a buen puerto algún proyecto.

Se basa en el manifiesto ágil mediante el cual se debe valorar:

Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan.

Algunos ejemplos de los mecanismos que se emplean en esta metodología, como reuniones diarias de 10 minutos con el equipo, disponer de una pizarra con el estado de las tareas, poner hitos cortos y demostrables, descomponer tareas grandes en pequeñas.... son tan sencillos, y a la vez dan tan buenos resultados, que hacen de esta metodología un gran apoyo para que los equipos rindan mejor, con menos estres y haga que todos (clientes y proveedores) vivamos mas tranquilos.

Si alguno quiere intercambiar impresiones sobre esta metodología, estaré encantado de hacerlo y comentar mis experiencias con lo que llevo implantado hasta ahora en uno de los departamentos de mi empresa, el departamento de sistemas.

http://proyectosagiles.org/que-es-scrum/

Metodologia de desarrollo del software

Metodologías de desarrollo del software.

Ingeniería de software.

Según Sommerville (2005), para muchas personas el software son solo programas de computadora, sin embargo nos comenta que son todos aquellos documentos asociados a la configuración de datos que se necesitan para hacer que estos programas operen de manera adecuada. Estos productos de software se desarrollan para algún cliente en particular o para un mercado en general. Para el diseño y desarrollo de proyectos de software se aplican metodologías, modelos y técnicas que permiten resolver los problemas. En los años 50 no existían metodologías de desarrollo, el desarrollo estaba a cargo de los propios programadores. De ahí la importancia de contar con analistas y diseñadores que permitieran un análisis adecuado de las necesidades que se deberían de implementar.

 

Modelo Waterfall (en cascada).

Clásico. Sólo aplicable cuando están totalmente cerrados los requisitos y no van a cambiar. No hay retroalimentación entre las fases en que se divide el proyecto. Por lo que cada fase se va cerrando de forma secuencial. Todo el proceso está fijado por fechas límites y presupuestos. Este modelo sólo es aconsejable para proyectos móviles muy controlados y previsibles, no existe incertidumbre por lo que se quiere hacer ni influyen los cambios en la industria.

http://www.eumed.net/tesis-doctorales/2014/jlcv/software.htm

UML

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 re utilizació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.

Fuente:

http://webcache.googleusercontent.com/search?q=cache:RUJq8uAWnnYJ:www.conganat.org/SEIS/inforsalud04/2004_Inforsalud_TutorialUML-UP.doc+&cd=13&hl=es-419&ct=clnk&gl=mx

Vídeo:

https://www.youtube.com/watch?v=uv0VPkN_q58