Unidades

METODOLOGÍAS DE DESARROLLO DE SOFTWARE

Sin título

  1. Modelo de cascada

En Ingeniería de software el desarrollo en cascada, también llamado modelo en cascada (denominado así por la posición de las fases en el desarrollo de esta, que parecen caer en cascada “por gravedad” hacia las siguientes fases), es el enfoque metodológico que ordena rigurosamente las etapas del proceso para el desarrollo de software, de tal forma que el inicio de cada etapa debe esperar a la finalización de la etapa anterior. Al final de cada etapa, el modelo está diseñado para llevar a cabo una revisión final, que se encarga de determinar si el proyecto está listo para avanzar a la siguiente fase. Este modelo fue el primero en originarse y es la base de todos los demás modelos de ciclo de vida.

La versión original fue propuesta por Winston W. Royce en 1970 y posteriormente revisada por Barry Boehm en 1980 e Ian Sommerville en 1985.

Un ejemplo de una metodología de desarrollo en cascada es:

  1. Análisis de requisitos.
  2. Diseño del Sistema.
  3. Diseño del Programa.
  4. Codificación.
  5. Pruebas.
  6. Verificación.
  7. Mantenimiento.

De esta forma, cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al rediseño y nueva programación del código afectado, aumentando los costos del desarrollo. La palabra cascada sugiere, mediante la metáfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases más avanzadas de un proyecto. Si bien ha sido ampliamente criticado desde el ámbito académico y la industria, sigue siendo el paradigma más seguido al día de hoy.

Fases del modelo

Análisis de requisitos. En esta fase se analizan las necesidades de los usuarios finales del software para determinar qué objetivos debe cubrir. De esta fase surge una memoria llamada SRD (documento de especificación de requisitos), que contiene la especificación completa de lo que debe hacer el sistema sin entrar en detalles internos.

Es importante señalar que en esta etapa se debe consensuar todo lo que se requiere del sistema y será aquello lo que seguirá en las siguientes etapas, no pudiéndose requerir nuevos resultados a mitad del proceso de elaboración del software de una manera.

Diseño del Sistema. Descompone y organiza el sistema en elementos que puedan elaborarse por separado, aprovechando las ventajas del desarrollo en equipo. Como resultado surge el SDD (Documento de Diseño del Software), que contiene la descripción de la estructura relacional global del sistema y la especificación de lo que debe hacer cada una de sus partes, así como la manera en que se combinan unas con otras.

Es conveniente distinguir entre diseño de alto nivel o arquitectónico y diseño detallado. El primero de ellos tiene como objetivo definir la estructura de la solución (una vez que la fase de análisis ha descrito el problema) identificando grandes módulos (conjuntos de funciones que van a estar asociadas) y sus relaciones. Con ello se define la arquitectura de la solución elegida. El segundo define los algoritmos empleados y la organización del código para comenzar la implementación.

Diseño del Programa. Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los requerimientos del usuario así como también los análisis necesarios para saber qué herramientas usar en la etapa de Codificación

Codificación. Es la fase en donde se implementa el código fuente, haciendo uso de prototipos así como de pruebas y ensayos para corregir errores. Dependiendo del lenguaje de programación y su versión se crean las bibliotecas y componentes reutilizables dentro del mismo proyecto para hacer que la programación sea un proceso mucho más rápido.

Pruebas. Los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona correctamente y que cumple con los requisitos, antes de ser entregado al usuario final.

Verificación. Es la fase en donde el usuario final ejecuta el sistema, para ello el o los programadores ya realizaron exhaustivas pruebas para comprobar que el sistema no falle. En la creación de desarrollo de cascada se implementa los códigos de investigación y pruebas del mismo.

Mantenimiento. Una de las etapas más críticas, ya que se destina un 75% de los recursos, es el mantenimiento del Software ya que al utilizarlo como usuario final puede ser que no cumpla con todas nuestras expectativas.

  1. Modelo en espiral

La metodología de desarrollo en espiral es una evolución de método clásico en cascada (Waterfall, top-down) y se considera un método de desarrollo incremental. Este tipo de metodología equivale al de cascada, pero en él se permite el solapamiento de varias etapas con el objetivo de flexibilizar y compensar el tiempo de desarrollo total y alcanzar resultados funcionales en etapas tempranas. Está considerada como un método de desarrollo rápido y eficiente.
Es adecuada para proyectos en los que se tienen claros los objetivos finales pero no todos los detalles de implementación están elucidados.

La metodología de desarrollo en espiral permite construir aplicaciones de tamaño medio manteniendo los recursos constantes. Normalmente el proyecto se divide en módulos más pequeños y a cada uno de ellos se le aplica el siguiente proceso:

Análisis de requerimientos. Durante esta etapa de estudia detalladamente los requerimientos que cada objetivo conlleva. Aquí establecen todos los detalles funcionales deseados.

Diseño del sistema. Con los datos de la etapa anterior, se diseña el sistema. Se realizar el diseño de la base de datos (en caso de ser aplicable), interface de usuario, entorno, etc.

Etapas de construcción. La etapa de construcción comprende básicamente la codificación y test de unidades. Esta etapa es un trabajo de programación pura.

Test y evaluación. En esta etapa se realiza un test del módulo completo así como su evaluación frente al estudio de requerimientos. En muchos casos en es esta etapa los usuarios finales participan de manera activa aportando información decisiva para la usabilidad del sistema.

Puntos fuertes

  • Permite el desarrollo de proyectos en donde los objetivos finales están perfectamente definidos pero todos los detalles no pueden ser completamente establecidos al principio.
  • Es adaptable: algunos de los requerimientos (que no los objetivos) pueden cambiar durante el ciclo de desarrollo.
  • Permite la especialización de los equipos de trabajo.
  • Apela a una gestión de proyecto ordenada.
  • Facilita la distribución de recursos de desarrollo.
  • Economía: es posible mantener constantes los recursos de desarrollo.
  • Permite conseguir funcionalidad en etapas tempranas.
  1. Modelo Rational Unified Process (RUP)

El Proceso Racional Unificado (Rational Unified Process en inglés, habitualmente resumido como RUP) es un proceso de desarrollo de software desarrollado por la empresa Rational Software, actualmente propiedad de IBM. Junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, diseño, implementación y documentación de sistemas orientados a objetos.

El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización. También se conoce por este nombre al software, también desarrollado por Rational, que incluye información entrelazada de diversos artefactos y descripciones de las diversas actividades. Está incluido en el Rational Method Composer (RMC), que permite la personalización de acuerdo con las necesidades.

Originalmente se diseñó un proceso genérico y de dominio público, el Proceso Unificado, y una especificación más detallada, el Rational Unified Process, que se vendiera como producto independiente.

Principales características

  • Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo)
  • Pretende implementar las mejores prácticas en Ingeniería de Software
  • Desarrollo iterativo
  • Administración de requisitos
  • Uso de arquitectura basada en componentes
  • Control de cambios
  • Modelado visual del software
  • Verificación de la calidad del software

El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son los productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el código fuente, etc.) y roles (papel que desempeña una persona en un determinado momento, una persona puede desempeñar distintos roles a lo largo del proceso).

Fases

  • Establece oportunidad y alcance
  • Identifica las entidades externas o actores con las que se trata
  • Identifica los casos de uso

RUP comprende 2 aspectos importantes por los cuales se establecen las disciplinas:

Proceso: Las etapas de esta sección son: Modelado de negocio

  • Requisitos
  • Análisis y Diseño
  • Implementación
  • Pruebas
  • Despliegue

Soporte: En esta parte nos encontramos con las siguientes etapas:

  • Gestión del cambio y configuraciones
  • Gestión del proyecto
  • Entorno

La estructura dinámica de RUP es la que permite que éste sea un proceso de desarrollo fundamentalmente iterativo, y en esta parte se ven inmersas las 4 fases descritas anteriormente:

  • Inicio (también llamado Incepción o Concepción).
  • Elaboración.
  • Desarrollo (también llamado Implementación, Construcción).
  • Cierre (también llamado Transición).

Fase de Inicio. Esta fase tiene como propósito definir y acordar el alcance del proyecto con los patrocinadores, identificar los riesgos asociados al proyecto, proponer una visión muy general de la arquitectura de software y producir el plan de las fases y el de iteraciones posteriores.

Fase de elaboración. En la fase de elaboración se seleccionan los casos de uso que permiten definir la arquitectura base del sistema y se desarrollaran en esta fase, se realiza la especificación de los casos de uso seleccionados y el primer análisis del dominio del problema, se diseña la solución preliminar.

Fase de Desarrollo. El propósito de esta fase es completar la funcionalidad del sistema, para ello se deben clarificar los requisitos pendientes, administrar los cambios de acuerdo a las evaluaciones realizados por los usuarios y se realizan las mejoras para el proyecto.

Fase de Transición. El propósito de esta fase es asegurar que el software esté disponible para los usuarios finales, ajustar los errores y defectos encontrados en las pruebas de aceptación, capacitar a los usuarios y proveer el soporte técnico necesario. Se debe verificar que el producto cumpla con las especificaciones entregadas por las personas involucradas en el proyecto.

  1. Xtreme Programming

La programación extrema o eXtreme Programming (de ahora en adelante, XP) es una metodología de desarrollo de la ingeniería de software formulada por Kent Beck, autor del primer libro sobre la materia, Extreme Programming Explained: Embrace Change (1999). Es el más destacado de los procesos ágiles de desarrollo de software. Al igual que éstos, la programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad. Los defensores de la XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos.

Se puede considerar la programación extrema como la adopción de las mejores metodologías de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinámica durante el ciclo de vida del software.

Características fundamentales

Las características fundamentales del método son:

  • Desarrollo iterativo e incremental: pequeñas mejoras, unas tras otras.
  • Pruebas unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo pruebas de regresión. Se aconseja escribir el código de la prueba antes de la codificación. Véase, por ejemplo, las herramientas de prueba JUnit orientada a Java, DUnit orientada a Delphi, NUnit para la plataforma.NET o PHPUnit para PHP. Estas tres últimas inspiradas en JUnit, la cual, a su vez, se insipiró en SUnit, el primer framework orientado a realizar tests, realizado para el lenguaje de programación Smalltalk.
  • Programación en parejas: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. La mayor calidad del código escrito de esta manera -el código es revisado y discutido mientras se escribe- es más importante que la posible pérdida de productividad inmediata.
  • Frecuente integración del equipo de programación con el cliente o usuario. Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo.
  • Corrección de todos los errores antes de añadir nueva funcionalidad. Hacer entregas frecuentes.
  • Refactorización del código, es decir, reescribir ciertas partes del código para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorización no se ha introducido ningún fallo.
  • Propiedad del código compartida: en vez de dividir la responsabilidad en el desarrollo de cada módulo en grupos de trabajo distintos, este método promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresión garantizan que los posibles errores serán detectados.
  • Simplicidad en el código: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podrá añadir funcionalidad si es necesario. La programación extrema apuesta que es más sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizás nunca utilizarlo.

La simplicidad y la comunicación son extraordinariamente complementarias. Con más comunicación resulta más fácil identificar qué se debe y qué no se debe hacer. Cuanto más simple es el sistema, menos tendrá que comunicar sobre éste, lo que lleva a una comunicación más completa, especialmente si se puede reducir el equipo de programadores.

Roles

Programador. Escribe las pruebas unitarias y produce el código del sistema.

Cliente. Escribe las historias de usuario y las pruebas funcionales para validar su implementación. Asigna la prioridad a las historias de usuario y decide cuáles se implementan en cada iteración centrándose en aportar el mayor valor de negocio.

Tester. Ayuda al cliente a escribir las pruebas funcionales. Ejecuta pruebas regularmente, difunde los resultados en el equipo y es responsable de las herramientas de soporte para pruebas.

Tracker. Es el encargado de seguimiento. Proporciona realimentación al equipo. Debe verificar el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, comunicando los resultados para mejorar futuras estimaciones.

Entrenador (coach). Responsable del proceso global. Guía a los miembros del equipo para seguir el proceso correctamente.

Consultor. Es un miembro externo del equipo con un conocimiento específico en algún tema necesario para el proyecto. Ayuda al equipo a resolver un problema específico.

Gestor (Big boss). Es el dueño de la tienda y el vínculo entre clientes y programadores. Su labor esencial es la coordinación.

  1. Modelo desarrollo manejado por rasgos

Este proceso se considera como punto medio entre los procesos pesados y ágiles, aunque en la práctica es más similar a este último, es una combinación de XP y RUP. Pensado para proyectos relativamente cortos, al igual que los anteriores también está basado en iteraciones que producen un software funcional que puede ser visto, probado y monitorizado por el cliente.
Estas iteraciones son decididas en base a las funcionalidades que el software debe tener, funcionalidades definidas por el cliente, este proceso está dividido en cinco fases:

  • Develop an Overall Model – Desarrollo de un modelo global,
  • Build a Feature List – Construcción de una lista de funcionalidades,
  • Plan by Feature – Plan de releases (entregas) basadas en las funcionalidades a implementar,
  • Design by Feature – Diseñar en base a las funcionalidades definidas.
  • Build by Feature – Implementar en base a las mismas funcionalidades.
    Aquí en el equipo de trabajo si existen jerarquías, siempre debe haber un jefe de proyecto, y aunque es un proceso considerado ligero también incluye documentación (la mínima necesaria para que algún nuevo integrante pueda entender el desarrollo de inmediato).
  1. Microsoft Solutions Framework (MSF)

Es un enfoque personalizable para entregar con éxito soluciones tecnológicas de manera más rápida, con menos recursos humanos y menos riesgos, pero con resultados de más calidad. MSF ayuda a los equipos a enfrentarse directamente a las causas más habituales de fracaso de los proyectos tecnológicos y mejorar así las tasas de éxito, la calidad de las soluciones y el impacto comercial.

MSF se centra en:

  • Alinear los objetivos de negocio y de tecnología
  • Establecer de manera clara los objetivos, los roles y las responsabilidades
  • Implementar un proceso iterativo controlado por hitos o puntos de control
  • Controlar los riesgos de manera proactiva
  • Responder con eficacia ante los cambios

Principios fundamentales

Los siguientes principios y conceptos de MSF sirven de guía al equipo de proyecto para entregar una solución de calidad. Cada miembro del equipo deberá comprender y aplicar estos principios en sus interacciones con otros miembros del equipo, con la organización y con las partes interesadas.MSF se basa en nueve principios fundamentales:

  1. Fomentar una comunicación abierta. Para que el equipo sea eficaz y eficiente, tanto usted como su equipo deben compartir niveles de información apropiados entre los miembros del equipo y en toda la empresa.El equipo debe comprender la naturaleza de lo que se debe hacer y el modo en que se comunican los miembros del equipo y los contactos externos.Lo difícil es determinar un nivel apropiado para cada relación y qué información se debe compartir.
  2. Intentar lograr una visión compartida. El hecho de tener una visión compartida empodera a los miembros del equipo y les permite actuar con agilidad para poder tomar decisiones rápidas pero bien fundadas con el objetivo de lograr una visión.Al tener una visión compartida, los miembros del equipo pueden ir satisfaciendo los requisitos a medida que se vayan detectando.
  3. Empodere a los miembros del equipo. Empoderar a los miembros del equipo no solo es una de las muchas maneras de sobrevivir en un entorno en constante cambio, sino que los miembros del equipo también aprenden a encontrar modos de alcanzar el éxito de manera creativa y a ayudarse unos a otros.Si no se permite a los miembros del equipo dar lo mejor de sí mismos, no solo disminuye su creatividad, sino que también pueden sufrir de baja moral y ser incapaces de contribuir a crear un equipo de alto rendimiento.
  4. Establecer responsabilidades claras y compartidas. A menudo, los miembros del equipo empoderados se sienten más responsables de sus decisiones y están dispuestos a ser corresponsables de un proyecto.A mayor responsabilidad de los miembros del equipo, mayor calidad.Por ejemplo, si un miembro del equipo afirma que ha completado una tarea pero se detecta que no tiene el nivel de calidad adecuado, ese miembro del equipo es responsable de resolver este problema de manera que la tarea completada tenga los niveles de calidad indicados.Si se fomenta el crecimiento positivo y la responsabilidad en lugar de castigar tales deslices, el miembro del equipo comparte la responsabilidad de la solución general y sus entregas.Esto fomenta la motivación entre los miembros más sólidos del equipo para ayudarse mutuamente a dar lo mejor de sí mismos.
  5. Ofrecer valor incremental. Este principio tiene dos facetas:
    1. Asegurarse de que lo que se entrega tiene un valor óptimo para las partes interesadas.
    2. Determinar los incrementos óptimos en los que se entregará valor (o la “frecuencia de entrega”).
  6. Mantenerse ágil, esperar cambios y adaptarse a ellos. Como los cambios pueden darse a menudo y en el peor momento posible, disponer de una manera ágil de manejarlos ayuda a minimizar los trastornos habituales que provocan.Mantenerse ágil significa que una organización está preparada para los cambios y puede adaptarse y ajustarse sin contratiempos.
  7. Invertir en la calidad. Muchas organizaciones adoptan el principio de calidad, a menudo con una definición bastante difusa, pero no saben cómo cuantificarla.La calidad es algo que se debe incorporar de manera proactiva al ciclo de vida de entrega de la solución y no es algo que aparezca de la nada.
  8. Aprender de todas las experiencias. Si todos los niveles de una organización no aprenden de lo que funcionó y lo que no funcionó anteriormente, ¿cómo se puede esperar que mejoren la próxima vez?Los miembros del equipo deben comprender y darse cuenta de que el aprendizaje se da en todos los niveles:
    • A nivel de proyecto, como por ejemplo, al perfeccionar un proceso válido para todo el proyecto
    • A nivel individual, como por ejemplo, al buscar la manera de interactuar mejor con otros miembros del equipo
    • A nivel de la organización, como por ejemplo, al ajustar las métricas de calidad que se recopilan para cada proyecto
  9. Colaborar con clientes internos y externos. Las probabilidades de éxito del proyecto aumentan cuando el cliente trabaja con el equipo del proyecto.Eso no quiere decir que los clientes tengan que hacer el trabajo de un equipo.Sin embargo, cuando los clientes colaboran estrechamente y de manera incremental con un equipo de entrega, la solución satisface mejor sus expectativas.Colaborar con los clientes es ventajoso para ambas partes, ya que ayuda a reducir la incertidumbre, reduce el tiempo necesario para resolver temas de requisitos y aumenta la comprensión por parte del equipo de las propuestas de valor de la solución por medio del contacto periódico.
  10. Modelo incremental

El modelo incremental fue propuesto por Harlan Mills en el año 1980. Surgió el enfoque incremental de desarrollo como una forma de reducir la repetición del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirir experiencia con el sistema. Este modelo se conoce también bajo las siguientes denominaciones:

  • Método de las comparaciones limitadas sucesivas.
  • Ciencia de salir del paso.
  • Método de atacar el problema por ramas.

El Modelo Incremental combina elementos del Modelo Lineal Secuencial con la filosofía interactiva de Construcción de Prototipos. El modelo incremental aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento del software. El primer incremento generalmente es un producto esencial denominado núcleo.

En una visión genérica, el proceso se divide en 4 partes:

  • Análisis
  • Diseño
  • Código
  • Prueba

Características

  • Se evitan proyectos largos y se entrega “algo de valor” a los usuarios con cierta frecuencia.
  • El usuario se involucra más.
  • Difícil de evaluar el costo total.
  • Difícil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como un todo.
  • Requiere gestores experimentados.
  • Los errores en los requisitos se detectan tarde.
  • El resultado puede ser positivo.

Ventajas

  • Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa la funcionalidad parcial.
  • También provee un impacto ventajoso frente al cliente, que es la entrega temprana de partes operativas del software.
  • El modelo proporciona todas las ventajas del modelo en Cascada realimentado, reduciendo sus desventajas sólo al ámbito de cada incremento.
  • Resulta más sencillo acomodar cambios al acotar el tamaño de los incrementos.

Desventajas

  • El modelo incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad, de procesamiento distribuido y/o de alto índice de riesgos.
  • Requiere de mucha planeación, tanto administrativa como técnica.
  • Requiere de metas claras para conocer el estado del proyecto.

Desarrollo rápido de aplicaciones

El desarrollo rápido de aplicaciones o RAD (acrónimo en inglés de rapid application development) es un proceso de desarrollo de software, desarrollado inicialmente por James Maslow en 1980. El método comprende el desarrollo interactivo, la construcción de prototipos y el uso de utilidades CASE (Computer Aided Software Engineering). Tradicionalmente, el desarrollo rápido de aplicaciones tiende a englobar también la usabilidad, utilidad y la rapidez de ejecución.

Hoy en día se suele utilizar para referirnos al desarrollo rápido de interfaces gráficas de usuario tales como Glade, o entornos de desarrollo integrado completos. Algunas de las plataformas más conocidas son Visual Studio, Lazarus, Gambas, Delphi, Foxpro, Anjuta, Game Maker, Velneo, GeneXus o Clarion. En el área de la autoría multimedia, software como Neosoft Neoboo y MediaChance Multimedia Builder proveen plataformas de desarrollo rápido de aplicaciones, dentro de ciertos límites.

Antecedentes

Comenzando con las ideas de Barry Boehm y Scott Shultz, Martin desarrolló el Rapid Application Development durante los años 1980 en IBM y finalmente lo formalizó publicando un libro en 1990.

Fases del rad

  • Modelado de gestión: el flujo de información entre las funciones de gestión se modela de forma que responda a las siguientes preguntas: ¿Qué información conduce el proceso de gestión? ¿Qué información se genera? ¿Quién la genera? ¿A dónde va la información? ¿Quién la proceso?
  • Modelado de datos: el flujo de información definido como parte de la fase de modelado de gestión se refina como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las características (llamadas atributos) de cada uno de los objetos y las relaciones entre estos objetos.
  • Modelado de proceso: los objetos de datos definidos en la fase de modelado de datos quedan transformados para lograr el flujo de información necesario para implementar una función de gestión. Las descripciones del proceso se crean para añadir, modificar, suprimir, o recuperar un objeto de datos. Es la comunicación entre los objetos.
  • Generación de aplicaciones: El DRA asume la utilización de técnicas de cuarta generación. En lugar de crear software con lenguajes de programación de tercera generación, el proceso DRA trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o a crear componentes reutilizables (cuando sea necesario). En todos los casos se utilizan herramientas automáticas para facilitar la construcción del software.
  • Pruebas de entrega: Como el proceso DRA enfatiza la reutilización, ya se han comprobado muchos de los componentes de los programas. Esto reduce tiempo de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se deben ejercitar todas las interfaces a fondo.

Características de rad

Equipos Híbridos

  • Equipos compuestos por alrededor de seis personas, incluyendo desarrolladores y usuarios de tiempo completo del sistema así como aquellas personas involucradas con los requisitos.
  • Los desarrolladores de RAD deben ser “renacentistas”: analistas, diseñadores y programadores en uno.

Herramientas Especializadas

  • Desarrollo “visual”
  • Creación de prototipos falsos (simulación pura)
  • Creación de prototipos funcionales
  • Múltiples lenguajes
  • Calendario grupal
  • Herramientas colaborativas y de trabajo en equipo
  • Componentes reusables
  • Interfaces estándares (API)

“Timeboxing”

  • Las funciones secundarias son eliminadas como sea necesario para cumplir con el calendario.

Prototipos Iterativos y Evolucionarios

  • Reunión JAD (Joint Application Development):
    • Se reunen los usuarios finales y los desarrolladores.
    • Lluvia de ideas para obtener un borrador inicial de los requisitos.
  • Iterar hasta acabar:
    • Los desarrolladores construyen y depuran el prototipo basado en los requisitos actuales.
    • Los diseñadores revisan el prototipo.
    • Los clientes prueban el prototipo, depuran los requisitos.
    • Los clientes y desarrolladores se reunen para revisar juntos el producto, refinar los requisitos y generar solicitudes de cambios.
    • Los cambios para los que no hay tiempo no se realizan. Los requisitos secundarios se eliminan si es necesario para cumplir el calendario.

Conclusión

Después de haber investigado y analizado cada uno de los modelos de desarrollo de software, ahora conocemos y sabemos que existen diversas formas de crear nuestras aplicaciones. Cada uno de los modelos tienen sus características, sus ventajas y desventajas, principalmente los pasos o procedimientos que se deben seguir para realizar nuestro software. El modelo de cascada, en lo personal, es el modelo que más llamó mi atención, opino que es un modelo práctico y eficiente, hasta ahora la mayoría de pasos que se especifican en este modelo, se han estudiado y llevado a cabo en nuestro proyecto realizado. También considero que los demás modelos son ramificaciones del modelo de cascada, ya que son muy parecidos, pero entre ellos conservan sus especificaciones que los hacen diferentes.

Fuentes de información

http://es.wikipedia.org/wiki/Desarrollo_en_cascada

http://www.acertasoftware.com/mspiral.html

http://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational

http://es.wikipedia.org/wiki/Programaci%C3%B3n_extrema

http://ingsoftware8.blogspot.mx/2007/09/metodologias-rup-y-xp.html

http://msdn.microsoft.com/es-es/library/jj161047.aspx

http://metodologiarad.weebly.com/

**************************************************************************************************

1.- PARADIGMAS DE LA INGENIERÍA DE SOFTWARE

Enfoque estructurado

En el Enfoque Estructurado se usan los DFD (Diagrama de Flujo de Datos) como principal herramienta para entender al sistema antes de plasmarlo a código fuente. DFD es un diagrama en el que participan procesos (métodos), flujo de datos (argumentos) y archivos (Base de datos). Hay de diferentes niveles dependiendo la complejidad del sistema que se analiza, hablando de lenguajes tiene muchas diferencia con la orientada a objetos, un mínimo cambio en el código puede llegar alterar al resto del programa cosa que en la orientada a objetos eso no sucede lo cual es una ventaja porque así no se pierde tiempo en arreglar cosas ya hechas. Una desventaja es que una porción de código en lenguaje estructurado es difícil que pueda servir en otros proyectos, esto si es habitual en lenguaje orientada a objetos, con solo importar clases ya hechas se escribe menos código y se ahorra tiempo.

Diagrama de Flujo de Datos

  • Un diagrama de flujo de datos (DFD) es un modelo lógico-gráfico para representar el funcionamiento de un sistema en un proyecto software.

Diccionario de Datos

  • El diccionario de datos es un listado organizado de todos los datos que pertenecen a un sistema.
  • El objetivo de un diccionario de datos es dar precisión sobre los datos que se manejan en un sistema, evitando así malas interpretaciones o ambigüedades.

Diseño de Módulo

Un modelo de datos es un lenguaje orientado a describir una Base de Datos. Típicamente un Modelo de Datos permite describir:

  • Las estructuras de datos de la base: El tipo de los datos que hay en la base y la forma en que se relacionan.
  • Las restricciones de integridad: Un conjunto de condiciones que deben cumplir los datos para reflejar correctamente la realidad deseada.
  • Operaciones de manipulación de los datos: Operaciones de agregado, borrado, modificación y recuperación de los datos de la base.
  • Otro enfoque es pensar que un modelo de datos permite describir los elementos de la realidad que intervienen en un problema dado y la forma en que se relacionan esos elementos entre sí.

El enfoque Estructurado, fue seleccionado como técnica de investigación de requerimientos, ya que permite al analista conocer el sistema o proceso en una forma lógica y manejable, al mismo tiempo que proporciona la base para asegurar que no se omite ningún detalle. Este es un método para el análisis de sistemas manuales o automatizados, que conduce al desarrollo de especificaciones para sistemas nuevos o para efectuar modificaciones a los ya existentes. Aunado a ello y por ser considerados como una herramienta capaz de describir y analizar el movimiento de los datos a través de un sistema, la representación gráfica de los procesos del sistema estará a cargo de los Diagramas de Flujos de Datos (DFD).

Enfoque orientado a objetos

El contexto del Enfoque Orientado a Objetos (EOO) un objeto es una entidad que encapsula datos (atributos) y acciones o funciones que los manejan (métodos). También para el EOO un objeto se define como una instancia o particularización de una clase.

Los objetos de interés durante el desarrollo de software no sólo son tomados de la vida real (objetos visibles o tangibles), también pueden ser abstractos. En general son entidades que juegan un rol bien definido en el dominio del problema. Un libro, una persona, un carro, un polígono, son apenas algunos ejemplos de objeto.

Cada objeto puede ser considerado como un proveedor de servicios utilizados por otros objetos que son sus clientes. Cada objeto puede ser a la vez proveedor y cliente. De allí que un programa pueda ser visto como un conjunto de relaciones entre proveedores clientes. Los servicios ofrecidos por los objetos son de dos tipos:

  1. Los datos, que llamamos atributos.
  2. Las acciones o funciones, que llamamos métodos.

Fundamentos del Enfoque Orientado a Objeto

El Enfoque Orientado a Objeto se basa en cuatro principios que constituyen la base de todo desarrollo orientado a objetos. Estos principios son: la Abstracción, el Encapsulamiento, la Modularidad y la Herencia. Otros elementos a destacar (aunque no fundamentales) en el EOO son: Polimorfismo, Enlace dinámico (o binding), Concurrencia y Persistencia.

El análisis orientado a objetos (AOO) y el diseño orientado a objetos (DOO) constituyen un enfoque distinto de desarrollo de sistemas. Estas técnicas se basan en los conceptos de la programación orientada a objetos, que han sido codificados en UML (Lenguaje Unificado de Modelación), un lenguaje estandarizado de modulación en el cual los objetos generados no solo incluyen código referente a los datos sino también instrucciones acerca de las operaciones que se realizaran sobre los datos.

EL Paradigma Orientado a Objetos es una disciplina de ingeniería de desarrollo y modelado de software que permite construir más fácilmente sistemas complejos a partir de componentes individuales.

Objetos + Mensajes = Programa

El proceso Orientado a Objetos se mueve a través de una espiral evolutiva que comienza con la comunicación con el usuario. Es en esta parte donde se define el dominio del problema y se identifican las clases básicas del problema. La planificación y el análisis de riesgos establecen una base para el plan de proyecto OO. El trabajo técnico asociado con la ingeniería del software OO sigue las siguientes tareas:

  • Identificar clases candidatas.
  • Buscar clases en biblioteca.
  • Extraer nuevas clases si existen.
  • Desarrollar las clases sino existen.
  • Añadir las nuevas clases a la biblioteca.
  • Construir n-ésima iteración del sistema.

La ingeniería de software hace hincapié en la reutilización. Por lo tanto las clases se buscan en una biblioteca (de clases existentes) antes de construirse

Las Características del Enfoque Orientado a Objetos son:

  • Objeto: Los datos están cuantificados en entidades discretas y distinguibles llamadas objetos.
  • Clase: Significa que los objetos con la misma estructura de datos (atributos) y comportamiento (operaciones) se agrupa para formar una clase.
  • Atributo: Describen la clase o el objeto de alguna manera
  • Mensajes: Medio por el cual interactúan los objetos
  • Polimorfismo: Significa que una misma operación puede comportarse de modos distintos en distintas clases.
  • Herencia: Compartir atributos y operaciones entre clases tomando como base una relación jerárquica.

2.- MODELOS DE PROCESO DE SOFTWARE

Modelo de cascada

Es el más antiguo de todos los modelos de Ingeniería del Software. El modelo lineal presenta una estructura secuencial (de ahí el nombre de Modelo en cascada) formada por seis fases o etapas:

  • Análisis del Sistema
  • Análisis de Requisitos de Software
  • Diseño
  • Codificación
  • Prueba
  • Mantenimiento

Las fases incluyen dentro de sí determinadas tareas que clasifican de una forma clara el trabajo a realizar.

El desarrollo de las fases, como he mencionado antes, se produce de manera secuencial. Una vez se produce el análisis tanto del Sistema como de los requisitos del software demandado por el cliente, (fases en las que la intervención del cliente es absolutamente necesaria), se procede a la fase de diseño de la arquitectura global del software. Un diseño elaborado de forma cuidadosa llevará a una rápida codificación. Tras haber traducido el programa a un lenguaje comprensible para el ordenador, se comprueban los elementos de forma individual y más tarde de manera homogénea (todos los sistemas a la vez). Una vez entregado el software al cliente, la fase de Mantenimiento comprenderá las actualizaciones y las correcciones de errores que sean necesarias en el programa.

El Modelo en cascada no permite retroceder (más tarde analizaremos las ventajas e inconvenientes de todos los modelos en común), por lo que se hace estrictamente necesario que al final de cada fase el analista de sistemas o, en su caso, el programador, verifique y valide todo el trabajo realizado, ya que un error no detectado a tiempo podría perjudicar gravemente la fecha de entrega del software a nuestro cliente.

Modelo espiral

Este modelo, también no secuencial, es algo más complejo que los anteriores, aunque incluye un elemento muy útil e importante en el desarrollo del software: análisis de riesgos. El modelo en espiral concreta cuatro fases:

  • Planificación
  • Análisis de Riesgos
  • Ingeniería (Construcción del prototipo)
  • Evaluación por el cliente

Si ésta última fase es afirmativa, el modelo continúa con la estructura del Ciclo de vida Clásico. Si el cliente no está satisfecho con el resultado, se cubre otra banda de la espiral y se vuelve a la primera fase (de planificación).

Modelo incremental

El modelo incremental es una evolución del modelo de cascada; viene a suplir el problema de no poder retroceder en las fases de desarrollo del software. Es, por tanto, un modelo no secuencial.

El funcionamiento es sencillo. Comienza con el análisis de los requisitos, tras el cual se prepara un primer diseño. La novedad de este modelo respecto del anterior, es la introducción de iteraciones para “bifurcar” diseños. Es decir, este modelo ofrece la posibilidad de comenzar un diseño, arquitectura, estructura, etc del software, que de no convencer al cliente (o al propio programador) es rechazado y se comienza con una segunda iteración (o un segundo diseño), sin necesidad de realizar un nuevo análisis de requisitos. Pueden realizarse tantas iteraciones (también llamadas incrementos) como sean necesarias.

Proceso de desarrollo unificado

El Proceso Unificado de Desarrollo Software o simplemente Proceso Unificado es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura y por ser iterativo e incremental. El refinamiento más conocido y documentado del Proceso Unificado es el Proceso Unificado de Rational o simplemente RUP.

El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos específicos. De la misma forma, el Proceso Unificado de Rational, también es un marco de trabajo extensible, por lo que muchas veces resulta imposible decir si un refinamiento particular del proceso ha sido derivado del Proceso Unificado o del RUP. Por dicho motivo, los dos nombres suelen utilizarse para referirse a un mismo concepto.

El nombre Proceso Unificado se usa para describir el proceso genérico que incluye aquellos elementos que son comunes a la mayoría de los refinamientos existentes. También permite evitar problemas legales ya que Proceso Unificado de Rational o RUP son marcas registradas por IBM (desde su compra de Rational Software Corporation en 2003). El primer libro sobre el tema se denominó, en su versión española, El Proceso Unificado de Desarrollo de Software (ISBN 84-7829-036-2) y fue publicado en 1999 por Ivar Jacobson, Grady Booch y James Rumbaugh, conocidos también por ser los desarrolladores del UML, el Lenguaje Unificado de Modelado. Desde entonces los autores que publican libros sobre el tema y que no están afiliados a Rational utilizan el término Proceso Unificado, mientras que los autores que pertenecen a Rational favorecen el nombre de Proceso Unificado de Rational.

Características

Iterativo e Incremental

El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto de cuatro fases denominadas Inicio, Elaboración, Construcción y Transición. Cada una de estas fases es a su vez dividida en una serie de iteraciones (la de inicio puede incluir varias iteraciones en proyectos grandes). Estas iteraciones ofrecen como resultado un incremento del producto desarrollado que añade o mejora las funcionalidades del sistema en desarrollo.

Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que recuerdan a las definidas en el ciclo de vida clásico o en cascada: Análisis de requisitos, Diseño, Implementación y Prueba. Aunque todas las iteraciones suelen incluir trabajo en casi todas las disciplinas, el grado de esfuerzo dentro de cada una de ellas varía a lo largo del proyecto.

Dirigido por los casos de uso

En el Proceso Unificado los casos de uso se utilizan para capturar los requisitos funcionales y para definir los contenidos de las iteraciones. La idea es que cada iteración tome un conjunto de casos de uso o escenarios y desarrolle todo el camino a través de las distintas disciplinas: diseño, implementación, prueba, etc. El proceso dirigido por casos de uso es el rup. Nota: en UP se está Dirigido por requisitos y riesgos de acuerdo con el Libro UML 2 de ARLOW, Jim que menciona el tema.

Centrado en la arquitectura

El Proceso Unificado asume que no existe un modelo único que cubra todos los aspectos del sistema. Por dicho motivo existen múltiples modelos y vistas que definen la arquitectura de software de un sistema. La analogía con la construcción es clara, cuando construyes un edificio existen diversos planos que incluyen los distintos servicios del mismo: electricidad, fontanería, etc.

Enfocado en los riesgos

El Proceso Unificado requiere que el equipo del proyecto se centre en identificar los riesgos críticos en una etapa temprana del ciclo de vida. Los resultados de cada iteración, en especial los de la fase de Elaboración deben ser seleccionados en un orden que asegure que los riesgos principales son considerados primero.

Proceso de software personal

El proceso personal de software Es un conjunto de prácticas disciplinadas para la gestión del tiempo y mejora de la productividad personal de los programadores o ingenieros de software, en tareas de desarrollo y mantenimiento de sistemas. Está alineado y diseñado para emplearse en organizaciones con modelos de procesos CMMI o ISO 15504. Fue propuesto por Watts Humphrey en 1995 y estaba dirigido a estudiantes. A partir de 1997 con el lanzamiento del libro “An introduction to the Personal Software Process” se dirige ahora a ingenieros juniors.

Se puede considerar como la guía de trabajo personal para ingenieros de software en organizaciones que emplean un modelo CMMI con nivel de madurez o de capacidad de procesos que implica la medición cualitativa y mejora de procesos.

Uno de los mayores problemas que tiene es la gran cantidad de datos que hay que tomar. El PSP tiene obsesión por la toma de datos y elaboración de tablas. El PSP se orienta el conjunto de áreas clave del proceso que debe manejar un desarrollador cuando trabaja de forma individual.

Niveles

  • Nivel 0:
    • proceso actual.
    • Registro de tiempos.
    • Registro de defectos.
  • Nivel 0.1 :
    • Estándares de codigo.
    • Medición de tamaño.
  • Nivel 1 – Inicial:
    • Estimacion de tamaño.
    • Reporte de pruebas.
  • Nivel 1.1:
    • Calendario de planeación de tareas.
  • Nivel 2 – Repetible:
    • Revisión de diseño y código.
  • Nivel 2.1:
    • Plantillas de Diseño.

3.- MODELO DE CASOS DE USO

El modelo de casos de uso describe la funcionalidad propuesta del nuevo sistema. Un caso de uso representa una unidad discreta de interacción entre un usuario (humano o máquina) y el sistema. Un Caso de Uso es una unidad simple de trabajo significativo; por ejemplo, “Validarse en el sistema”, “Registrarse en el sistema” y “Crear un pedido” son todos casos de uso.Cada caso de uso tiene una descripción que describe la funcionalidad que se construirá en el sistema propuesto. Un caso de uso puede “incluir” la funcionalidad de otro caso de uso o “extender” a otro caso de uso con su propio comportamiento.Una descripción de caso de uso generalmente incluirá:

  • Comentarios generales y notas describiendo el caso de uso
  • Requisitos -cosas que el caso de uso debe permitir hacer al usuario, tales como <capacidad para actualizar pedido>, <capacidad para modificar pedido>, etc.
  • Restricciones -reglas acerca de qué se puede y qué no se puede hacer-. Incluye:
    • Pre-condiciones que deben ser verdaderas antes de que el caso de uso se ejecute, por ejemplo <crear pedido> debe preceder a <modificar pedido>
    • Post-condiciones que deben ser verdaderas una vez que el caso de uso se ejecutó, por ejemplo <el pedido está modificado y es consistente>
    • invariantes: éstas son siempre verdaderas -por ejemplo, un pedido debe tener siempre un número de cliente.
  • Escenarios -descripciones secuenciales de los pasos que se toman para llevar a cabo el caso de uso. Pueden incluir escenarios múltiples, para satisfacer circunstancias excepcionales y caminos de proceso alternativos
  • Diagramas de escenarios -diagramas de secuencia para describir el flujo de trabajo- similar al punto 4 pero descrito gráficamente.
  • Atributos adicionales como fase de implementación, número de versión, rango de complejidad, estereotipo y estado

Actores

Un actor es un usuario del sistema. Incluye usuarios humanos y otros sistemas computarizados. Un actor usa un caso de uso para desempeñar alguna porción de trabajo que es de valor para el negocio. El conjunto de casos de uso al que un actor tiene acceso define su rol global en el sistema y el alcance de su acción.

Relaciones de inclusión y extensión entre casos de uso

Un Caso de Uso puede incluir la funcionalidad de otro como parte de su procesamiento normal. Generalmente se asume que los casos de uso incluidos se llamarán cada vez que se ejecute el camino base. Un ejemplo puede ser listar un conjunto de órdenes de clientes de las cuáles poder elegir antes de modificar una orden seleccionada; en este caso, el Caso de Uso <listar órdenes> se puede incluir en el Caso de Uso <modificar orden> cada vez que éste se ejecute.

Un Caso de Uso puede ser incluido por uno o más casos de uso, ayudando así a reducir la duplicación de funcionalidad al factorizar el comportamiento común en los casos de uso que se reutilizan muchas veces.

Un Caso de Uso puede extender el comportamiento de otro Caso de Uso; típicamente cuando ocurren situaciones excepcionales. Por ejemplo, si antes de modificar un tipo particular de orden de cliente, un usuario debe obtener la aprobación de alguna autoridad superior, entonces el Caso de Uso <obtener aprobación> puede extender opcionalmente el Caso de Uso normal <modificar orden>.

Diagrama de Secuencia

El UML provee un medio gráfico para representar la interacción entre los objetos a lo largo del tiempo en los diagramas de secuencia. Éstos muestran típicamente a un usuario o a un actor y los objetos y componentes con los que interactúen durante la ejecución de un Caso de Uso. Un diagrama de secuencia representa típicamente un único escenario de Caso de Uso o flujo de eventos.

Los diagramas son una vía excelente para documentar los escenarios de uso, para capturar los objetos necesarios de manera temprana en el análisis y para verificar el uso de los objetos más tarde en el diseño. Los diagramas de secuencia muestran el flujo de mensajes de un objeto a otro y, como tales, representan los métodos y los eventos soportados por un/a objeto/clase.

El diagrama ilustrado abajo muestra un ejemplo de un diagrama de secuencia, con el usuario o actor a la izquierda iniciando un flujo de eventos y mensajes que corresponden al escenario del caso de uso. Los mensajes que pasan entre objetos se convertirán en operaciones de clases en el modelo final.

Diagrama de Implementación

Un Caso de Uso es una descripción formal de la funcionalidad que el sistema tendrá cuando se construya. Un diagrama de implementación se asocia típicamente con un caso de uso para documentar qué elementos de diseño (por ejemplo, componentes y clases) implementará la funcionalidad del Caso de Uso en el nuevo sistema. Esto provee un alto grado de trazabilidad al diseñador, al cliente y al equipo que construirá el sistema. La lista de casos de uso a los que se asocia un componente o una clase documenta la funcionalidad mínima que debe ser implementada por el componente.

El ejemplo de arriba muestra que el caso de uso “Acceso” implementa el requisito formal “1.01 Acceder al sitio web”. También establece que el componente de lógica de negocios y el componente de páginas ASP implementan alguna parte o toda la funcionalidad de “Acceso”. Un refinamiento adicional es mostrar la pantalla de “Acceso” (una página web) como una implementación de su interfaz. Estos enlaces de implementación o realización definen la trazabilidad desde los requisitos formales, a través de casos de uso, a componentes y pantallas.

Modelo de casos de uso

4.- MODELO DE SECUENCIAS

Utilidad

Un diagrama de secuencia muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada caso de uso. Mientras que el diagrama de casos de uso permite el modelado de una vista business del escenario, el diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario y mensajes intercambiados entre los objetos.

Típicamente se examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. Si se dispone de la descripción de cada caso de uso como una secuencia de varios pasos, entonces se puede “caminar sobre” esos pasos para descubrir qué objetos son necesarios para que se puedan seguir los pasos. Un diagrama de secuencia muestra los objetos que intervienen en el escenario con líneas discontinuas verticales, y los mensajes pasados entre los objetos como flechas horizontales.

Tipos de mensajes

Existen dos tipos de mensajes: sincrónicos y asincrónicos. Los mensajes sincrónicos se corresponden con llamadas a métodos del objeto que recibe el mensaje. El objeto que envía el mensaje queda bloqueado hasta que termina la llamada. Este tipo de mensajes se representan con flechas con la cabeza llena. Los mensajes asincrónicos terminan inmediatamente, y crean un nuevo hilo de ejecución dentro de la secuencia. Se representan con flechas con la cabeza abierta.

También se representa la respuesta a un mensaje con una flecha discontinua.

Pueden ser usados en dos formas

  • De instancia: describe un escenario específico (un escenario es una instancia de la ejecución de un caso de uso).
  • Genérico: describe la interacción para un caso de uso. Utiliza ramificaciones (“Branches”), condiciones y bucles.

Estructura

Los mensajes se dibujan cronológicamente desde la parte superior del diagrama a la parte inferior; la distribución horizontal de los objetos es arbitraria. Durante el análisis inicial, el modelador típicamente coloca el nombre ‘business’ de un mensaje en la línea del mensaje. Más tarde, durante el diseño, el nombre ‘business’ es reemplazado con el nombre del método que está siendo llamado por un objeto en el otro. El método llamado o invocado pertenece al objeto receptor del mensaje.

CONCLUSIONES

Después de haber leído este interesante tema me doy cuenta de que existen muchas técnicas para desarrollar nuestro software; en la mayoría de las ocasiones, los programadores si no tienen una buena base, lo primero que quieren hacer es codificar, sin antes haber analizado el problema a solucionar.

Eso es un error my común y fatal, ya que esto no nos permite hacer un análisis minucioso de lo que se quiere resolver, en ocasiones si se llega a una solución, sin embargo es posible que no sea la solución óptima a nuestro problema.

En nuestra carrera los casos de uso son vistos y utilizados en muy pocas ocasiones, o al menos en una materia que curse los utilizamos muy poco, realmente no se tiene bien cimentadas este tipo de técnicas, solo en primer semestre se nos enseña a utilizar los diagramas de flujo que son utilizados en la programación estructurada, pero el resto de los semestre se enfoca a la programación orientada a objetos.

REFERENCIAS DE INFORMACIÓN

https://sites.google.com/site/paradigmasdelais/4-1-el-enfoque-estructurado

https://sites.google.com/site/paradigmasdelais/4-2-el-enfoque-orientado-a-objetos

http://html.rincondelvago.com/modelos-de-procesos-de-software.html

http://es.wikipedia.org/wiki/Proceso_Unificado

http://es.wikipedia.org/wiki/Personal_Software_Process

http://www.sparxsystems.com.ar/resources/tutorial/use_case_model.html

http://es.wikipedia.org/wiki/Diagrama_de_secuencia

Presentación de: MODELO DE CASOS DE USO

Modelo de casos de uso

**********************************************************************************************************************************

UNIDAD 2

INGENIERÍA DE REQUISITOS

2.1 Tareas de la ingeniería de requisitos

En la ingeniería de sistemas y la ingeniería de software, la Ingeniería de requisitos o Ingeniería de requerimientos comprende todas las tareas relacionadas con la determinación de las necesidades o de las condiciones a satisfacer para un software nuevo o modificado, tomando en cuenta los diversos requisitos de las partes interesadas, que pueden entrar en conflicto entre ellos.

¿Qué son Requerimientos?

Normalmente, un tema de la Ingeniería de Software tiene diferentes significados. De las muchas definiciones que existen para requerimiento, a continuación se presenta la definición que aparece en el glosario de la IEEE .

(I) Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo. (2) Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal. (3) Una representación documentada de una condición o capacidad como en (1) o (2).

Muchas veces se habla de requerimientos en vez de requisitos; esto se debe a una mala traducción del inglés. La palabra requirement debe ser traducida como requisito, mientras que requerimiento se traduce al inglés como request.

El propósito de la ingeniería de requisitos es hacer que los mismos alcancen un estado óptimo antes de alcanzar la fase de diseño en el proyecto. Los buenos requisitos deben ser medibles, comprobables, sin ambigüedades o contradicciones, etc.

Implicaciones

La Ingeniería de Requisitos implica todas las actividades del ciclo de vida dedicadas a:

  • La educción (a veces llamada “elicitación”, debido a una mala traducción de “elicitation”) de los requisitos de usuario.
  • El análisis y negociación de requisitos para derivar requisitos adicionales.
  • La documentación de los requisitos como especificación.
  • La validación de los requisitos documentados contra las necesidades de usuario.
  • Así como los procesos que apoyan estas actividades.

Fases de implementación

Desde un punto de vista conceptual, las actividades son de cinco clases.

  • Obtener requisitos: A través de entrevistas o comunicación con clientes o futuros usuarios, para saber cuáles son sus expectativas.
  • Analizar requisitos: Detectar y corregir las carencias o falencias comunicativas, transformando los requisitos obtenidos de entrevistas y requisitos, en condiciones apropiadas para ser tratados en el diseño.
  • Documentar requisitos: Igual que todas las etapas, los requisitos deben estar debidamente documentados.
  • Verificar los requisitos: Consiste en comprobar la implementación de los requerimientos.
  • Validar los requisitos: Comprobar que los requisitos implementados sean funcionales para lo que inicialmente se construyó el producto.
  • Inicio: Tiene por objetivo identificar el ámbito del proyecto general. Comienza con una serie de conversaciones informales entre los participantes del mismo. Esta fase suele ser acompañada de los documentos de definición de la visión global y la visión del dominio del sistema. Se inicia muchas veces por: se descubre un nuevo mercado y se descubre un nuevo servicio.
  • Obtención: Se sugiere a los ingenieros recopilar requisitos de manera organizada, preguntando a los usuarios y otros interesados cuales son os objetivos para el sistema o producto, que es lo que se debe lograr, de que forma el producto satisface las necesidades del negocio y como se utilizara el producto día d día. Se identifican una serie de problemas que ayudan a entender porque es difícil la obtención de requisitos:
  • 1 Problema de ámbito
  • 1 Problema de comprensión
  • 1 Problemas de volatilidad
  • Elaboración: Se crea un modelo de análisis con la información obtenida del cliente en las fases de inicio y obtención. La información conseguida con el cliente durante el inicio y obtención se expande y se refina durante la elaboración. Esta actividad se enfoca en el desarrollo de un modelo técnico refinado de las funciones, características y restricciones del software. La elaboración se conduce mediante la creación y refinamiento de escenarios del usuario que describan la forma en que el usuario final y otros actores interactúan con el sistema.
  • Negociación: En esta etapa el ingeniero de requisitos debe negociar con el cliente los alcances y límites del sistema. De forma iterativa los requisitos se prioriza, modifican, combinan o eliminan buscando acuerdos que beneficien a todas las partes. Se identifican y analizan los riesgos asociados con cada requisito.
  • Especificación: Es el producto final de la ingeniería de requisitos, y se convierte en la materia prima para las actividades posteriores en el proceso de desarrollo del sistema. Una especificación puede ser un documento escrito, un conjunto de modelos gráficos, un modelo matemático formal, una colección de escenarios de uso, un prototipo o cualquier combinación de estos.
  • Validación: Un equipo de validación toma el producto de la fase de especialización, lo revisa para detectar errores, conflictos u omisiones y los corrige con el fin de garantizar la consistencia de requisitos. La validación de requisitos examina la especificación para asegurar que todos los requisitos de software se han establecidos de manera precisa; que se han detectado las inconsistencias omisiones y errores y que estos han sido corregidos y que el producto de trabajo cumple con los estándares establecidos para el proceso, proyecto y producto.
  • Gestión de requisitos: Ayuda a rastrear los requisitos según las características de los mismos, el código fuente relacionado, dependencia entre requisitos, subsistemas e interfaces internas y externas de forma que pueda identificarse con rapidez para entender como afectara una modificación diferentes aspectos del sistema a construir. Es un conjunto de actividades que ayudan al equipo de proyecto a identificar, controlar y rastrear los requisitos y los cambios a estos en cualquier momento mientras se desarrolla el proyecto.

Ejemplo gráfico de las tareas de ingeniería de requisitos:

Ingenieria-de-Requerimientos

Mapa conceptual del tema:

Mapa conceptual - Tareas de la ingeniería de requisitos

2.2 Técnicas de la ingeniería de requisitos

La ingeniería de requisitos puede ser un proceso largo y arduo para el que se requiere de habilidades psicológicas. Los nuevos sistemas cambian el entorno y las relaciones entre la gente, así que es importante identificar a todos los actores involucrados, considerar sus necesidades y asegurar que entienden las implicaciones de los nuevos sistemas. Los analistas pueden emplear varias técnicas para obtener los requisitos del cliente. Históricamente, esto ha incluido técnicas tales como las entrevistas, o talleres con grupos para crear listas de requisitos. Técnicas más modernas incluyen los prototipos, y utilizan casos de uso. Cuando sea necesario, el analista empleará una combinación de estos métodos para establecer los requisitos exactos de las personas implicadas, para producir un sistema que resuelva las necesidades del negocio.

·         Entrevistas

Las entrevistas son un método común. Por lo general no se entrevista a toda la gente que se relacionará con el sistema, sino a una selección de personas que represente a todos los sectores críticos de la organización, con el énfasis puesto en los sectores más afectados o que harán un uso más frecuente del nuevo sistema.

·         Talleres

Los requisitos tienen a menudo implicaciones cruzadas desconocidas para las personas implicadas individuales y que a menudo no se descubren en las entrevistas o quedan incompletamente definidas durante la misma. Estas implicaciones cruzadas pueden descubrirse realizando en un ambiente controlado, talleres facilitados por un analista del negocio, en donde las personas implicadas participan en discusiones para descubrir requisitos, analizan sus detalles y las implicaciones cruzadas. A menudo es útil la selección de un secretario dedicado a la documentación de la discusión, liberando al analista del negocio para centrarse en el proceso de la definición de los requisitos y para dirigir la discusión.

Existen dos técnicas de este tipo que son las más utilizadas: Brainstorming (Lluvia de ideas) y JAD (Joint Application Development, Diseño de Aplicación Conjunta). La diferencia que existe entre ambas técnicas es que durante la tormenta de ideas se tiene como objetivo generar una gran cantidad de ideas, es desestructurada y la información que se obtiene puede ser visual, textual o coloquial; mientras que en el JAD el taller es ordenado, la información que se obtiene es visual y su objetivo es generar requisitos y la interfaz del sistema.

Durante una sesión de Lluvia de ideas, todos los participantes pueden aportar distintas ideas en un ambiente libre de prejuicios. Ningún participante debe juzgar negativamente la propuesta de otros, sino que se anotan todas las ideas en una pizarra y serán evaluadas al final de la sesión. El principio básico es no descartar de manera apresurada ningún planteo, de modo que existe la posibilidad de que surjan otras ideas derivadas de la idea original y se generan varios puntos de vista del problema.

En el Joint application development se trabaja directamente sobre los documentos a generar, las temáticas que se tratan durante las reuniones siguen un esquema y se busca que la misma sea ordenada y racional. Se define una agenda con los puntos principales a tratar durante la jornada. Este tipo de taller tiene el inconveniente de que es muy difícil poder reunir a todas los participantes, es costoso y generalmente es necesaria más de una reunión para establecer los requisitos del sistema.

·         Forma de contrato

En lugar de una entrevista, se pueden llenar formularios o contratos indicando los requisitos. En sistemas muy complejos éstos pueden tener centenares de páginas.

·         Objetivos medibles

Los requisitos formulados por los usuarios se toman como objetivos generales, a largo plazo, y en cambio se los debe analizar una y otra vez desde el punto de vista del sistema hasta determinar los objetivos críticos del funcionamiento interno que luego darán forma a los comportamientos apreciables por el usuario. Luego, se establecen formas de medir el progreso en la construcción, para evaluar en cualquier momento qué tan avanzado se encuentra el proyecto.

·         Prototipos y Casos de uso

Un prototipo es una pequeña muestra, de funcionalidad limitada, de cómo sería el producto final una vez terminado. Ayudan a conocer la opinión de los usuarios y rectificar algunos aspectos antes de llegar al producto terminado.

Un caso de uso es una técnica para documentar posibles requisitos, graficando la relación del sistema con los usuarios u otros sistemas. Dado que el propio sistema aparece como una caja negra, y sólo se representa su interacción con entidades externas, permite omitir dichos aspectos y determinar los que realmente corresponden a las entidades externas. El objetivo de esta práctica es mejorar la comunicación entre los usuarios y los desarrolladores, mediante la prueba temprana de prototipos para minimizar cambios hacia el final del proyecto y reducir los costes finales. Esta técnica se enfrenta a los siguientes peligros potenciales.

  • A los directivos, una vez que ven un prototipo, les cuesta comprender que queda mucho trabajo por hacer para completar el diseño final.
  • Los diseñadores tienden a reutilizar el código de los prototipos por temor a “perder el tiempo” al comenzar otra vez.
  • Los prototipos ayudan principalmente a las decisiones del diseño y de la interfaz de usuario. Sin embargo, no proporcionan explícitamente cuáles son los requisitos.
  • Los diseñadores y los usuarios finales pueden centrarse demasiado en el diseño de la interfaz de usuario y demasiado poco en producir un sistema que sirva el proceso del negocio.

Los prototipos pueden ser: diagramas, aplicaciones operativas con funcionalidades sintetizadas. Los diagramas, en los casos donde se espera que el software final tenga diseño gráfico, se realizan en una variedad de documentos de diseño gráficos y a menudo elimina todo el color del diseño del software (es decir utilizar una gama de grises). Esto ayuda a prevenir la confusión sobre la apariencia final de la aplicación.

·         Especificación de requisitos del software

Una especificación de requisitos del software es una descripción completa del comportamiento del sistema a desarrollar. Incluye un conjunto de casos de uso que describen todas las interacciones que se prevén que los usuarios tendrán con el software. También contiene requisitos no funcionales (o suplementarios). Los requisitos no funcionales son los requisitos que imponen restricciones al diseño o funcionamiento del sistema (tal como requisitos de funcionamiento, estándares de calidad, o requisitos del diseño).

Las estrategias recomendadas para la especificación de los requisitos del software están descritas por IEEE 830-1998. Este estándar describe las estructuras posibles, contenido deseable, y calidades de una especificación de requisitos del software.

Mapa conceptual del tema:

10711305_1513012145612816_1284817419_n

2.3 Modelado de requisitos

El modelo de requisitos tiene como objetivo delimitar el sistema y capturar la funcionalidad que debe ofrecer desde la perspectiva del usuario. Este modelo puede funcionar como un contrato entre el desarrollador y el cliente o usuario del sistema, y por lo tanto proyecta lo que el cliente desea según la percepción del desarrollador. Por lo tanto, es esencial que los clientes puedan comprender este modelo.

El modelo de requisitos es el primer modelo a desarrollarse, sirviendo de base para la formación de todos los demás modelos en el desarrollo de software. En general, el cualquier cambio en la funcionalidad del sistema es más fácil de hacer, y con menores consecuencias, a este nivel que posteriormente. El modelo de requisitos que desarrollaremos se basa en la metodología Objectory (Jacobson et al. 1992), basada principalmente en el modelo de casos de uso.

Actualmente esta metodología es parte del Proceso Unificado de Rational (RUP). El modelo de casos de uso y el propio modelo de requisitos son la base para los demás modelos, y se resume aquí:

  • Requisitos: El modelo de casos de uso sirve para expresar el modelo de requisitos, el cual se desarrolla en cooperación con otros modelos como se verá más adelante.
  • Análisis: La funcionalidad especificada por el modelo de casos de uso se estructura en el modelo de análisis, que es estable con respecto a cambios, siendo un modelo lógico independiente del ambiente de implementación.
  • Diseño: La funcionalidad de los casos de uso ya estructurada por el análisis es realizada por el modelo de diseño, adaptándose al ambiente de implementación real y refinándose aún más.
  • Implementación: Los casos de uso son implementados mediante el código fuente en el modelo de implementación.
  • Pruebas: Los casos de uso son probados a través de las pruebas de componentes y pruebas de integración.
  • Documentación: El modelo de casos de uso debe ser documentado a lo largo de las diversas actividades, dando lugar a distintos documentos como los manuales de usuario, manuales de administración, etc.

2.4 Herramientas CASE para la ingeniería de requisitos

A medida que pasa el tiempo se logra entender que el empleo del software es una buena opción para agilizar y sistematizar las tareas en el desarrollo de procesos. El desarrollo de software no es la excepción; en este caso dichas herramientas se han denominado CASE (Ingeniería De Software Asistida Por Computador). Estas incluyen un conjunto de programas que facilitan la optimización de un producto ofreciendo apoyo permanente a los analistas, ingenieros de software y desarrolladores. CASE es la aplicación de métodos y técnicas que dan utilidades a los programas, por medio de otros, procedimientos y su respectiva documentación.

A continuación se hace referencia a 3 herramientas que ayudan a la gestión de requisitos; es decir al proceso de identificación, asignación y seguimiento de los mismos, incluyendo interfaz, verificación, modificación y control de cada requisito, durante el ciclo de vida del proyecto. Los cambios/actualizaciones de requisitos deben ser gestionados para asegurar que se mantenga la calidad del producto.

Hasta hace poco tiempo las herramientas para la gestión de requisitos de software se limitaban a editores de texto, los cuales hacían de esta tarea una labor tediosa y confusa. Actualmente, se cuenta con múltiples opciones, como las que se mencionan a continuación:

IRQA

Herramienta CASE de Ingeniería de Requisitos, diseñada para soportar las actividades realizadas en el proceso de especificación de sistemas. Ésta facilita y formaliza la comunicación entre el cliente, el proveedor y los distintos miembros del equipo de desarrollo. Facilita la captura, organización y análisis de las condiciones, así como la especificación de la solución mediante el apoyo metodológico adaptable a cada cliente.

CONTROLA

Herramienta de apoyo al proceso de ingeniería de software en pequeñas empresas. Se creó gracias a la expansión que tuvo el mercado y a la generación de grandes y pequeñas empresas, las cuales requieren un instrumento para el desarrollo de sus proyectos. Ofrece recursos importantes tales como: Administración de requisitos, administración de casos de uso, administración de casos de prueba y error, planeamiento de liberaciones, administración de implementaciones, control de dependencia entre Implementaciones, matriz de rastreabilidad y rastreabilidad de los requisitos.

OSRMT (Open Source Requirements Management Tool)

Herramienta libre para la gestión de requisitos, cuyas principales características son: trabaja en arquitectura cliente/servidor, desarrollada bajo Java; la versión 1.3 trae un módulo para manejar la trazabilidad y lo introduce para el control de cambios; así mismo, genera la documentación de los requisitos tratados.

Conclusión

Los temas abordados anteriormente fueron de gran interés, principalmente porque se va conociendo todo el proceso que se debe ejecutar para llevar a cabo un software de calidad. Como estudiantes estamos acostumbrados a escribir las líneas de código, sin antes pensar bien en su planeación; muchas veces solo se escribe y ni siquiera hacemos uso de un diagrama de flujo o de un diagrama de casos de uso.

La ingeniería de requisitos sirve para prever, para realizar nuestro software y así satisfacer la demanda del cliente, esta tiene una serie de actividades y técnicas para poder conocer los porqués y para que del software, pudiera decirse que son los cimientos del software.

Dentro del modelado de requisitos se lleva a cabo, como su nombre lo dice el modelo o planeación más formal de lo que vamos a crear, de igual forma existen diferentes modelos a seguir, pero el más famoso y usado es el de casos de uso. Las herramientas CASE tienen un papel importante para la ingeniería de requisitos, porque una clasificación de ellas, es porque también sirven para el diseño del software, por lo tanto esta ingeniería y las herramientas CASE van de la mano y trabajan en conjunto.

Referencias de información

**********************************************************************************************************************************

UNIDAD 3

MODELO DE ANÁLISIS

El modelo de análisis es la primera representación técnica de un sistema. Utiliza una mezcla de formatos en texto y diagramas para representar los requisitos del software, las funciones y el comportamiento. De esta manera se hace mucho más fácil de comprender dicha representación, ya que es posible examinar los requisitos desde diferentes puntos de vista aumentando la probabilidad de encontrar errores, de que surjan debilidades y de que se descubran descuidos.

3.1 Arquitectura de clases

IC215019

El objetivo del modelo de analisis es crear una arquitectura de objetos que sirva como base para el diseño del sistema. Dependiendo del tipo de aplicación existen varias arquitecturas. Ellas se distinguen  según la organización de los objetos de acuerdo a su funcionalidad. Esto es llamado dimension de arquitectura.

Dimension de la arquitectura

  • Unidimensional: un solo grupo de objetos para manejar la funcionalidad y la interacción externa.
  • Bidimensional: un grupo de objetos para manejar la funcionalidad y otros para las interacciones externas.
  • Tridimensional: La más usada en los sistemas de información que siendo el Modelo-Vista-Control.

Arquitectura Modelo-Vista-Control

Es un patrón de arquitectura de software que separa los datos  de una aplicación, la interfaz del usuario y la lógica de negocio en tres componentes distintos. El modelo es el sistema de gestión de base de datos y la lógica de negocio y el controlador es el responsable de recibir los eventos de entrada desde la vista.

Modelo à Información

Vista à Presentación con el usuario

Control à Comportamiento

3.2 Identificación de clases según estereotipos

Para llevar a cabo la transición del modelo de requisitos al modelo de análisis se deben identificar los objetos necesarios para implementar todos los casos de uso. La arquitectura de objetos debe considerar los tres tipos de estereotipos de objetos. Para ello se deben identificar primero las clases borde, las clases entidad y finalmente las de Control.

En general, los cambios más comunes a un sistema son los de funcionalidad y bordes. Los cambios de las interfaces deben afectar solo  a los objetos borde.
Los cambios a la funcionalidad son más difíciles de administrar, ya que ésta puede abarcar todos los tipos de objetos.

Bordes
Toda la funcionalidad especificada en las descripciones de los casos de uso que depende directamente de los aspectos externos del sistema, se ubica en los objetos borde, pues a través de ellos se comunican los actores con el sistema. La tarea de una clase borde es traducir los eventos generados por un actor en eventos comprendidos por el sistema, y traducir los eventos del sistema en una presentación comprensible para el actor.

Las clases borde en otras palabras, describen la comunicación bidireccional entre el sistema y los actores. Las clases borde son bastante fáciles de identificar, donde se cuenta con al menos tres estrategias:

  • Se pueden identificar con base a los actores.
  • Se pueden identificar con base en las descripciones de las interfaces del sistema que acompañan al modelo de requisitos.
  • Se pueden identificar con base en las descripciones de los casos de uso y extraer la funcionalidad específica a los objetos bordes.
  • Estrategia correspondiente a los actores. Cada actor necesita su propia clase borde para comunicarse con el sistema. En muchos casos un actor puede necesitar de varios objetos borde. Es evidente que los objetos borde no son totalmente independientes de cada uno, ya que, en ciertos casos deben saber la existencia de los demás.

Entidad
Se utilizan objetos entidad para modelar la información que el sistema debe manejar a corto y largo plazo. La información a corto plazo existe durante la ejecución de un caso de uso, mientras que la información a largo plazo trasciende los caso de uso, por lo que es necesario guardarla en alguna base de datos o archivos.
Durante la identificación de objeto entidad, se encontrara que objetos que objetos similares aparecen en varios casos de uso.

Clases entidad

  • Validar Usuario: Este casi de uso requiere validar información exclusivamente guardada en el registro de usuario, lo que  se hace en la clase entidad RegistroUsuario, utiliza también por el caso de uso RegistroUsuario.
  • Ofrecer Servicios: Este caso de uso administra las opciones de servicio y no requiere de ninguna clase entidad.
  • Registrar Usuario: Este caso de uso requiere guardar información exclusivamente acerca del usuario, lo que se hace en la clase entidad RegistroUsuario.
  • Registrar Tarjeta: Este caso de uso requiere guardar información exclusivamente acerca de la tarjeta del usuario lo que hace en la clase entidad RegistroTarjeta.
  • Consultar Información: Este casi de uso requiere de toda la información relacionada con consultas. Se puede tomar las clases del dominio del problema y quitar aquellas relacionadas con registros y reservaciones.
  • Hacer reservación: Este caso de uso requiere de la información relacionada con reservaciones. Se pueden tomar las clases del dominio del problema y quitar aquellas relacionadas con registros.
  • Pagar Reservación: Este caso de uso requiere de la información relacionada con reservaciones. Dado que es una extensión al caso de uso Hacer Reservación, no es necesario volver a repetir todas las clases entidad, sino más bien especificar cualquier clase adicional.

Control
En la mayoría de los casos de uso, existe un comportamiento que no se puede asignar de forma natural a ninguno de los otros dos tipos de objetos ya vistos. Una posibilidad es repartir el comportamiento entre los dos tipos de objetos, pero la solución no es buena si se considera el aspecto de extensibilidad. Un cambio en el comportamiento podría afectar varios objetos, dificultando su modificación. Para evitar estos problemas, tal comportamiento se asigna a objetos control.
Es difícil lograr un buen balance en la distribución del comportamiento del caso de uso entre los objetos entidad, borde y control. Los objetos de control normalmente proveen a administración de los demás tipos de objetos.

3.3 Clases

images

Una clase es una plantilla para la creación de objetos de datos según un modelo predefinido. Las clases se utilizan para representar entidades o conceptos, como los sustantivos en el lenguaje. Cada clase es un modelo que define un conjunto de variables -el estado, y métodos apropiados para operar con dichos datos -el comportamiento. Cada objeto creado a partir de la clase se denomina instancia de la clase.

Las clases son un pilar fundamental de la programación orientada a objetos. Permiten abstraer los datos y sus operaciones asociadas al modo de una caja negra. Los lenguajes de programación que soportan clases difieren sutilmente en su soporte para diversas características relacionadas con clases. La mayoría soportan diversas formas de herencia. Muchos lenguajes también soportan características para proporcionar encapsulación, como especificadores de acceso.

Una clase también puede tener una representación (metaobjeto) en tiempo de ejecución, que proporciona apoyo en tiempo de ejecución para la manipulación de los metadatos relacionados con la clase.

Componentes

Las clases se componen de elementos, llamados genéricamente «miembros», de varios tipos:

Utilizando un símil con el lenguaje, si las clases representan sustantivos, los campos de datos pueden ser sustantivos o adjetivos, y los métodos son los verbos.

Campos de datos

Los campos de datos se utilizan para contener datos que reflejan el estado de la clase. Los datos pueden estar almacenados en variables, o estructuras más complejas, como structs, uniones e incluso otras clases.

Habitualmente, las variables miembro son privadas al objeto (siguiendo las directrices de diseño del Principio de ocultación) y su acceso se realiza mediante propiedades o métodos que realizan comprobaciones adicionales.

Métodos en las clases

Los métodos implementan la funcionalidad asociada al objeto. Los métodos son el equivalente a las funciones en programación estructurada. Se diferencian de ellos en que es posible acceder a las variables de la clase de forma implícita. Cuando se desea realizar una acción sobre un objeto, se dice que se le manda un mensaje invocando a un método que realizará la acción.

Propiedades

Las propiedades son un tipo especial de métodos. Debido a que suele ser común que las variables miembro sean privadas para controlar el acceso y mantener la coherencia, surge la necesidad de permitir consultar o modificar su valor mediante pares de métodos: GetVariable y SetVariable.

Los lenguajes orientados a objetos más modernos (por ejemplo Java o C#) añaden la construcción de propiedad, que es una sintaxis simplificada para dichos métodos:

3.4 Diagramas de secuencias

image006

El diagrama de secuencia es un tipo de diagrama usado para modelar interacción entre objetos en un sistema según UML. En inglés se pueden encontrar como “sequence diagram”, “event-trace diagrams”, “event scenarios” o “timing diagrams”

Un diagrama de secuencia muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada caso de uso. Mientras que el diagrama de casos de uso permite el modelado de una vista business del escenario, el diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario y mensajes intercambiados entre los objetos.

Típicamente se examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. Si se dispone de la descripción de cada caso de uso como una secuencia de varios pasos, entonces se puede “caminar sobre” esos pasos para descubrir qué objetos son necesarios para que se puedan seguir los pasos. Un diagrama de secuencia muestra los objetos que intervienen en el escenario con líneas discontinuas verticales, y los mensajes pasados entre los objetos como flechas horizontales.

Tipos de mensajes

Existen dos tipos de mensajes: sincrónicos y asincrónicos. Los mensajes sincrónicos se corresponden con llamadas a métodos del objeto que recibe el mensaje. El objeto que envía el mensaje queda bloqueado hasta que termina la llamada. Este tipo de mensajes se representan con flechas con la cabeza llena. Los mensajes asincrónicos terminan inmediatamente, y crean un nuevo hilo de ejecución dentro de la secuencia. Se representan con flechas con la cabeza abierta.

También se representa la respuesta a un mensaje con una flecha discontinua.

Pueden ser usados en dos formas

  • De instancia: describe un escenario específico (un escenario es una instancia de la ejecución de un caso de uso).
  • Genérico: describe la interacción para un caso de uso. Utiliza ramificaciones (“Branches”), condiciones y bucles.

Estructura

Los mensajes se dibujan cronológicamente desde la parte superior del diagrama a la parte inferior; la distribución horizontal de los objetos es arbitraria. Durante el análisis inicial, el modelador típicamente coloca el nombre ‘business’ de un mensaje en la línea del mensaje. Más tarde, durante el diseño, el nombre ‘business’ es reemplazado con el nombre del método que está siendo llamado por un objeto en el otro. El método llamado o invocado pertenece al objeto receptor del mensaje.

3.5 Diccionario de clases según módulos

Un diccionario de clases es un catálogo, un depósito, de los elementos en un sistema. Como su nombre lo sugiere, estos elementos se centran alrededor de los datos y la forma en que están estructurados para satisfacer los requerimientos de los usuarios y las necesidades de la organización. En un diccionario de datos se encuentra la lista de todos los elementos que forman parte del flujo de datos en todo el sistema. Los elementos más importantes son flujos de datos, almacenes de datos y procesos. El diccionario guarda los detalles y descripciones de todos estos elementos.

El diccionario se desarrolla durante el análisis de flujo de datos y auxilia a los analistas que participan en la determinación de los requerimientos de sistemas.

Importancia del diccionario

Los analistas utilizan los diccionarios de datos por cinco razones importantes:

  1. Para manejar los detalles en sistemas grandes.
  2. Para comunicar un significado común para todos los elementos del sistema.
  3. Para documentar las características del sistema.
  4. Para facilitar el análisis de los detalles con la finalidad de evaluar las características y determinar dónde efectuar cambios en el sistema.
  5. Localizar errores y omisiones en el sistema.

Manejo de detalles

Los sistemas grandes tienen enormes volúmenes de datos que fluyen por ellos en forma de documentos, reportes e incluso pláticas. De manera similar, se llevan a cabo muchas actividades que utilizan los datos existentes o que generan nuevos detalles. Recuérdese, como se mencionó en la historia al inicio de este capítulo, que Lodos los sistemas experimentan cambios continuos y manejar de manera completa todos los detalles es un desafió. Con franqueza, es imposible que los analistas recuerden todo. Los que tratan de hacerlo cometen de manera invariable equivocaciones u olvidan elementos importantes. Los mejores analistas no intentan recordarlo todo, en lugar de hacerlo registran toda la información. Algunos lo hacen sobre hojas de papel y otros quizá sobre tarjetas indexadas. Muchos emplean para tal fin un procesador de palabras y una computadora personal por supuesto. Los analistas mejor organizados y más eficaces utilizan diccionarios de datos automatizados diseñados de manera específica para el análisis y diseño de sistemas.

Comunicación de significados

Los diccionarios de datos proporcionan asistencia para asegurar significados comunes para los elementos y actividades del sistema. Si se examina una muestra de diagramas de flujo de datos para el procesamiento de pedidos, es probable que se tengan pocas dificultades para comprender qué datos representan a la factura y al cheque. Los dos son términos comunes en el mundo de los negocios y muchas personas conocen su significado. Los diccionarios de datos registran detalles adicionales relacionados con el flujo de datos en el sistema de tal forma que todas las personas participantes puedan localizar con rapidez la descripción de flujos de datos, almacenes de datos o procesos.

Herramientas CASE para el análisis

case

Borland Caliber Analyst. Se trata de un producto que está compuesto por dos aplicaciones desarrolladas por la compañía Borland.

Por un lado está el Caliber DefineIT (la última de las herramientas en cuanto a fecha de lanzamiento) que permite definir los requisitos del sistema así como capturar los diferentes escenarios de negocio a través de diferentes herramientas visuales; es necesario señalar que este software es compatible con gran número de herramientas existentes en el mercado.

Por el otro está Caliber RM que nos permite gestionar dichos requisitos durante el ciclo de vida del producto, si bien no ayudaba al usuario a visualizar los requerimientos y por lo tanto no resultaba tan efectiva como ellos demandaban.

El paquete que incluye ambas aplicaciones nos permitirá realizar las siguientes tareas: representar y especificar los escenarios de manera visual, permitiendo el uso de un lenguaje común; generar diagramas de casos de pruebas y UML, mejorando tanto la velocidad como la exactitud de la definición de los requisitos; rastrear los requisitos software durante el ciclo de vida del proyecto, respondiendo de manera rápida a cualquier cambio que se produzca.

La compañía Seilevel Inc., una de las más fuertes en cuanto a los servicios relacionados con los requisitos del software, ha seleccionado esta herramienta como la mejor de este tipo. Según palabras de un directivo de la compañía ven características únicas en esta herramienta así como una experiencia de usuario excelente y una oportunidad para mejorar el trabajo de sus clientes en cuanto al análisis y gestión de requisitos se refiere.

CASE Spec. Esta herramienta está desarrollada por la empresa Goda Software, siendo esta una aplicación comercial de uso exclusivo para el sistema operativo Windows. Las principales características que avalan a esta herramienta son las siguientes:

Especificación: posibilidad de realizar las especificaciones tanto con las técnicas tradicionales como con los diagramas de casos de uso. Además, nos permite crear diagramas UML y de flujo de datos.

Seguimiento de los requisitos: a través del uso combinado de un procesador de textos y una hoja de cálculo, el usuario será capaz de realizar el seguimiento de los requisitos así como hacer un informe acerca de los mismos.

Capacidad de rastreo: mediante la existencia de una matriz se representan de manera sencilla las diferentes relaciones existentes entre los requisitos definidos y otra serie de elementos incidentes en el proyecto.

Capacidad de importar y exportar archivos.

Generación automática de la documentación del proyecto así como posibilidad de realizar amplios informes.

IRQA 4. Herramienta desarrollada por Visure y que tiene la meta de servir como aplicación para proporcionar un soporte integral en la ingeniería de requisitos de un proyecto de informática.

A parte de incluir las tareas más básicas de la ingeniería de requisitos (captura, análisis, modelado, organización y seguimiento), esta aplicación dispones de las siguientes características:

Reutilización de requisitos: permite que los requisitos definidos en un proyecto puedan ser utilizados en otros proyectos realizados por la organización, a través del uso de librerías. De esta manera se consigue ofertar una pequeña ventaja a la hora de realizar líneas de productos.

Vista documental: esta nueva opción ofrece un agrupamiento de los requisitos que permite al usuario observar una diferenciación clara entre los mismos así como facilitar toda labor relacionada con estos.

Ingeniería de requisitos: además de la gestión de los requisitos, esta aplicación proporciona funcionalidades relacionadas con la ingeniería de requisitos, lo que permite centralizar en una sola herramienta todas las actividades relacionadas con los requisitos (incluyendo las pruebas de validación y aceptación).

Al ser esta una herramienta integrada, se ofrece al usuario la libertad de seleccionar aquellas otras aplicaciones más adecuadas para la realización de otras tareas relacionadas con el ciclo de vida de un proyecto, lo que hace que no se dependa de un solo proveedor de aplicaciones.

Tiger Pro. Estamos ante una herramienta shareware desarrollada para facilitar al usuario la tarea de redactar los requerimientos de un proyecto. Este aplicativo es capaz de solucionar algunos de los defectos que aparecen a la hora de definir los requisitos de un programa. También ayuda al usuario a aclarar algunos de los requerimientos desde el punto de vista de las pruebas a realizar, señalando aquellos requerimientos cuya verificación pueda resultar complicada.

La herramienta, que se va actualizando con el paso del tiempo, permite exportar el trabajo realizado en archivos bajo el formato CSV. Los usuarios que utilicen esta herramienta podrán trabajar en los requisitos tomando como referencia los siguientes conceptos: palabras claves relacionadas con el mismo (hasta 3 palabras para cada requisito), criterio de aceptación del requisito, seguimiento del mismo (tanto hacia la fuente como hacia otros lugares), prioridad del requerimiento, riesgo que trae consigo el requisito y coste del mismo. Además, a la hora de realizar los informes correspondientes, la herramienta nos proporcionará la opción de redactar los mismos en forma textual o bien nos presentará la información de forma gráfica.

GatherSpace. A la hora de realizar la definición de los requisitos para un proyecto de informática, el trabajo conjunto de todo el equipo de desarrollo es una parte fundamental para conseguir un buen resultado. Esta herramienta de definición y gestión de requisitos utiliza Internet como su lanzadera, ya que no es necesario instalar ningún programa para utilizarla: bastará con crear una cuenta en el sitio web de la misma y comenzar a definir el proyecto que se quiere desarrollar. De esta manera, la aplicación consigue que la colaboración de todos los miembros del grupo de desarrollo sea posible de una manera mucho más eficaz.

Las características más representativas de esta herramienta son las siguientes:

Creación de una jerarquía de requerimientos: permite crear paquetes funcionales para después relacionarlos con componentes de más alto nivel para después permitir asociar casos de uso más detallados y requisitos del software a dichos componentes.

Manipular varios proyectos al mismo tiempo, controlando el acceso de los usuarios para que estos puedan ver solo alguno de los proyectos.

Posibilidad de visualizar la documentación generada a partir de los requisitos en tres formatos diferentes: HTML, PDF y Microsoft Word.

Además de contar con todas estas opciones, la compañía ha dispuesto un buen sistema de seguridad que protegerá los datos introducidos en la herramienta. Para asegurar la integridad del trabajo realizado se realizan copias de seguridad diaria de la información introducida en la herramienta y además existe la posibilidad de encriptar los datos introducidos en la misma. También es necesario señalar que el usuario podrá descargarse la información desde el servidor de la empresa tantas veces como le sea necesario.

IBM Rational RequisitePro. Esta herramienta, desarrollada por una de las compañías más importantes dentro del campo de la informática, se considera una de las herramientas más completas y potentes dentro del análisis y la gestión de los requisitos.

Una de las grandes ventajas que aporta este producto es la compatibilidad existente entre su software y algunos de los programas más utilizados. Por ejemplo, esta herramienta es capaz de comunicarse de manera muy eficiente con el Microsoft Word, de manera que la realización de los informes es más sencilla al tiempo que se ofrece al usuario una interfaz conocida para el desarrollo de su labor. Además de esta compatibilidad, el programa también se comunica con gran eficiencia con algunos de los sistemas de bases de datos más utilizados en el mundo de la informática (DB2 de IBM, Microsoft SQL Server, Microsoft Access y Oracle) de manera tal que se controla el acceso a los datos existentes en el sistema al tiempo que se tiene un repositorio central de datos.

Por si esto no fuera suficiente, la comunicación entre la base de datos utilizada y el Microsoft Word permite al usuario gestionar los requisitos desde la base de datos seleccionada al tiempo que estos se mantienen dentro de su contexto en el procesador de textos.

Al igual que la herramienta estudiada anteriormente, Racional RequisitePro ofrece la posibilidad de trabajar mediante acceso Web. De esta manera se logra tener tanto un acceso remoto como un acceso distribuido y además no se necesita que el software esté instalado en el cliente. También es necesario mencionar que la herramienta dispone de una matriz de seguimiento de los requisitos (al igual que la herramienta CASE Spec); en este caso, dicha matriz puede representarse tanto de forma gráfica como de forma textual. Además, en este caso se incorpora al seguimiento de los requisitos la existencia de un árbol de seguimiento global.

RaQuest. Se trata de la herramienta de gestión de requisitos desarrollada por la empresa Sparx Systems, desarrolladora también de la herramienta de análisis y modelado Enterprise Architect, utilizada en la Escuela.

Las características principales de esta herramienta son las siguientes:

Definición y gestión de los elementos relacionados con los requisitos, entre los que se encuentran el tipo, el estado, la dificultad del requisito, las relaciones existentes entre diferentes requisitos, etc.

Creación de paquetes para gestionar de manera más sencilla y completa los requisitos.

Generación de documentación del proyecto (tanto parcial como total) en los siguientes formatos: HTML, CSV, Word, Excel, RTF

Además de estas características, la herramienta nos ofrece una serie de vistas diferentes, dependiendo de la vista que queramos obtener del proyecto. Estas vistas son: vista del tipo lista (permite ordenar los requisitos, mostrar diferentes listas, filtrar las listas en relación a diferentes palabras y buscar en el proyecto) y vista del tipo árbol (se pueden mostrar los árboles de proyecto y miembro así como mostrar los árboles por el tipo y por el estado).

Elección de la Herramienta a Utilizar

Debido a la gran compatibilidad existente con el Enterprise Architect, a la variedad de formatos para generar la documentación y a las numerosas opciones existentes en cuanto al tipo de vistas y la definición de los elementos relacionados con los requisitos, me he decantado por utilizar la herramienta RaQuest.

Conclusión

Después de haber leído la información aquí presentada, de manera personal me doy cuenta de todo el trabajo que hay detrás de un “software”, principalmente si el sistema es para un proyecto ya pagado, porque ahí ya no debe haber errores y todo debe quedar lo más apegado a la perfección, el modelo de análisis, es la base, como su nombre lo dice nos ayuda a analizar qué es lo que vamos a resolver y como lo vamos a resolver, este modelo es el cimiento para desarrollar un buen proyecto. De ahí se desglosa la arquitectura de clases, que en pocas palabras es donde se determina como se estructurara nuestro software, es decir en cuantas partes y cómo van a interactuar entre ellas. Las clases son el alma del sistema. Dentro de ellas van los objetos, atributos, funciones del programa, sin ellas no sería posible desarrollar un sistema, y por otra parte tenemos las herramientas CASE destinadas al análisis, estas no son de mucha ayuda porque optimizan nuestro trabajo, le dan un toque más profesional a nuestro trabajo. En conclusión el modelo de análisis es la base para comenzar a desarrollar cualquier sistema, es importante desarrollar cada uno de los pasos ya mencionados aquí, para que después no haya problemas con la ejecución, la lógica y principalmente se logre el objetivo.

Fuentes de información

http://mundokramer.wordpress.com/2011/05/20/modelo-de-analisis-software/

http://ithuejutlarodrigo.blogspot.mx/2013/04/31-arquitectura-de-clases.html

http://mmc.geofisica.unam.mx/LuCAS/Tutoriales/doc-modelado-sistemas-UML/multiple-html/x194.html

http://es.wikipedia.org/wiki/Clase_%28inform%C3%A1tica%29

http://es.wikipedia.org/wiki/Diagrama_de_secuencia

http://ithuejutlarodrigo.blogspot.mx/2013/04/35-diccionario-de-clases-segun-modulos.html

http://www.google.com.mx/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0CDcQFjAB&url=http%3A%2F%2Fwww.itescam.edu.mx%2Fprincipal%2Fsylabus%2Ffpdb%2Frecursos%2Fr89172.DOC&ei=LF9zUcK5C8Xt2QWp8oHYBQ&usg=AFQjCNHe2sBpeFlW9Xa6pJ5jvxehuxcvjQ&sig2=2J7DL0LrFYmUTDCsz6dydw&bvm=bv.45512109,d.b2I

 

 

 

 

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s