Archivo de la etiqueta: ingeniería de software

Estimación de proyectos de software: cálculo usando el método PROBE (PROxy Based Estimation)

La estimación de proyectos software es una tarea muy compleja, pero de vital importancia en toda la etapa de desarrollo del software.

Algunos de los principios a tener en cuenta para la realización de una estimación de software:

  • Retrasar la estimación lo máximo posible. Cuanto más se retrase, más precisa será.
  • Hacer estimación por analogía. Utilizar el costo de proyectos similares.
  • Ley de Parkinson. El trabajo se extiende para rellenar el tiempo disponible.
  • Precio para ganar. El coste se estima en todo el dinero que el cliente puede gastar en el proyecto.
  • Existen técnicas de descomposición. Estimas el costo descomponiendo el producto y/o el proceso.
  • Existen modelos empíricos. Modelos de regresión que relacionan esfuerzo con tamaño o funcionalidad.

Factores importantes a considerar:

  • Complejidad del proyecto.
  • Tamaño del proyecto.
  • Estabilidad de los requerimientos.
  • Facilidad de identificar funciones.
  • Estructura de la información.
  • Disponibilidad de información histórica.

El método PROBE

Este método está descrito en el libro PSP A Self-Improvement Process for Software Engineers, aunque es un poco complicado de seguir, por eso que mejor hacer un trabajo más práctico para tratar de enfocar el aprendizaje haciendo, más que diciendo.

Un proxy es una unidad de software que se puede identificar en un proyecto. Ejemplos de ello son las pantallas (User Interfaces), archivos, objetos, entidades lógicas, funciones (Stores Procedures) y puntos de función. La representación se pueden visualizar fácilmente a partir de las especificaciones del proyecto tales como documentos de requisitos. A continuación, se pueden traducir en líneas de código en función de los tamaños de los proxies históricos similares en proyectos de desarrollo anteriores. La líneas de código junto con cifras de productividad se pueden utilizar para predecir los recursos necesarios para un proyecto.

El método completo está organizado en una planilla Excel de construcción propia:

2016-11-09_16-40-40

Proxy’s

En esta Hoja de Trabajo se establecen las estimaciones por Proxy, y a partir de la estimación de los tiempos de construcción se estiman los de las otras fases del desarrollo. Si estas estimaciones porcentuales no aplican para el caso específico, pueden reemplazarse por valores históricos (en caso de contar con ellos).

La distribución de los porcentajes de referencia va a depender de la metodología o del criterio utilizado por los evaluadores del proyecto.

¿Cómo determinar la cantidad de días de construcción?

Este es el dato que mejor se puede estimar por los expertos o por consenso. A partir de este valor se calculan los otros de acuerdo a los porcentajes de referencia.  Son los desarrolladores (expertos) los que mejor saben cuánto se demorar en construir un proxy.  De todas formas existen tablas de complejidad de referencia por lenguaje de programación que pueden utilizarse, aunque en la práctica es mucho mejor el juicio experto.

2016-11-09_17-01-40

Estimación

En esta hoja, se desglosan las funcionalidades en los proxys definidos en la etapa anterior. Las columnas en azul son el resultado de la ponderación de la cantidad de Proxys requeridos por su tiempo definido en la hoja ‘Proxy’.

Para cada funcionalidad del sistema se especifican la cantidad de proxy’s a desarrollar, por ejemplo en el caso de la funcionalidad “Login”, se requiere 1 página web sencilla, 1 mediana, 1 procedimiento almacenado (en BBDD), 1 clase mediana y 1 tabla.  Lo anterior solo para efectos del ejemplo.

Sobre esta base la planilla va calculando la cantidad de días de análisis, construcción, integración y pruebas (para efectos del ejemplo) que se requieren en este proyecto.  Las etapas por supuesto pueden ser personalizadas por el evaluador.

Aplicaciones para otras áreas que no sean de construcción de piezas de software

Cualquiera donde sea factible definir y estructurar vía proxys.  Solo basta usar un poco la imaginación.

Link a planilla de ejemplo:

https://drive.google.com/file/d/0B3-y5EFvrO7ec3drWlJhZmhfaUk/view

Referencia:

http://www.sei.cmu.edu/reports/06tn017.pdf

Método y proceso implementado con éxito en una empresa de desarrollo de software de Santiago de Chile.  https://drive.google.com/file/d/0B3-y5EFvrO7eeEdJVzlTWEdkczQ/view

Deja un comentario

Archivado bajo Gerencia de Proyectos, Ingeniería de Software

Implementación del Proceso Personal de Software (PSP) en un primer curso de Programación de Computadores

Resumen— En este artículo, se muestran aspectos relacionados con el desarrollo de la tesis de maestría titulada “Diseño de una estrategia de aprendizaje para implementar prácticas de PSP (Personal Software Process) en cursos básicos de Programación”. En esta tesis, se propone una propuesta metodológica de enseñanza que promueve la adopción de las prácticas de PSP en un curso de Fundamentos de Programación, que hace parte del currículo del Programa de Ingeniería de Sistemas y Computación de la Universidad del Quindío en Armenia (Colombia). Los resultados obtenidos en esta investigación, permiten realizar un diagnóstico y aportar una serie de reflexiones acerca de la importancia de implementar enfoques orientados a procesos que incorporen buenas prácticas y conceptos de calidad en el desarrollo de software desde etapas tempranas en la formación de los estudiantes. Con la introducción de PSP, los estudiantes van apropiando buenas prácticas de desarrollo de software y adquieren disciplina para planear y gestionar sus proyectos.

Fuente y texto completo: http://ciinti.info/memorias2012/Full%20Papers/16_Proceso%20Personal%20de%20Software%20PSP.pdf

Deja un comentario

Archivado bajo Ingeniería de Software

¿Estilo arquitectónico en ‘Layers’ o ‘Tiers’?

Al parecer existe una confusión respecto al término aplicación n-capas cuando este se lleva al idioma español. El problema principal es que en inglés se manejan dos conceptos a nivel de arquitectura:

  • Aplicaciones n-Tier
  • Aplicaciones n-Layer

Ambos términos significan “de n capas”; pero existe una gran diferencia respecto al significado de cada uno de ellos. Una arquitectura n-Tier se refiere a la distribución física de las capas, es decir donde corre el código y los procesos. Una arquitectura n-Layer se refiere a la distribución lógica de las capas, es decir, como esta estructurado el código.

En la siguiente figura podemos ver una aplicación n-tier – una aplicación web – que contiene 3 capas, una capa en el cliente, otra en el servidor IIS, y otra en la base de datos; es decir, el navegador, el servidor Web y el servidor de bases de datos corren en diferentes máquinas.

image21

Por otra parte, una arquitectura n-Layer define simplemente como se organiza el código. Normalmente incluye una capa de presentación, una capa de negocios, una capa de acceso a datos, una capa de entidades de negocio y una capa de datos – repositorio de datos. El hecho de que se dividan las capas para organizar el código, no significa que las capas obligatoriamente deban corren en diferentes máquinas o que deben estrictamente correr en una sola máquina o en un único proceso.

La siguiente figura detalla una arquitectura n-Layer básica.

image_thumb[6]

Como podemos ver en la figura, en una arquitectura n-layer las capas solamente interactúan con sus capas adyacentes lo que permite abstraer funcionalidades de las capas superiores e inferiores. Por ejemplo, la capa de presentación no se da cuenta que tipo de base de datos o que repositorio de datos se utiliza por que esta solamente se comunica con la capa de negocios, y el repositorio de datos no se da cuenta en donde se esta utilizando o desplegando la información ya que este interactúa con la capa de acceso a datos.

Fuente: http://icomparable.blogspot.com/2008/10/arquitectura-n-tier-o-arquitectura-n.html

Capas

Las capas son las agrupaciones lógicas de los componentes de software que forman la aplicación o servicio. Ellos ayudan a diferenciar entre los distintos tipos de tareas realizadas por los componentes, lo que hace que sea más fácil crear un diseño que soporta la reutilización de los componentes. Cada capa lógica contiene un número de tipos de componentes discretos agrupados en sub-capas, con cada subcapa realizando un tipo específico de tarea. Al identificar los tipos genéricos de componentes que existen en la mayoría de las soluciones, se puede construir un mapa significativo de una aplicación o servicio, y luego utilizar este mapa como un modelo para su diseño. La división de una aplicación en capas separadas que tienen distintos roles y funciones ayuda a maximizar la mantenibilidad del código, optimizar la forma en que la aplicación funciona cuando se despliega de maneras diferentes, y proporcionar una clara delimitación entre los lugares donde se debe usar determinada tecnología o decisiones de diseño.

Presentación, negocio y servicios de datos

En el nivel más alto y más abstracto, la vista de la arquitectura lógica de un sistema puede ser considerado como un conjunto de servicios de cooperación agrupados en las siguientes capas, como se muestra en la Figura 1.Figura 1 La vista de la arquitectura lógica de un sistema de capas de las secciones el diseño de la aplicación se muestra en la Figura 1 se puede considerar como tres conjuntos básicos de servicios:

Figura 1 La vista de la arquitectura lógica de un sistema de capas

Figura 1 La vista de la arquitectura lógica de un sistema en capas

  • Servicios de presentación . Estos son los servicios orientados al usuario responsables de la gestión de la interacción del usuario con el sistema, y generalmente consisten en componentes situados dentro de la capa de presentación. Constituyen un puente común en la lógica de negocio del núcleo encapsulado en los servicios de negocio (business services).
  • Servicios de negocios (business services) . Estos servicios implementan la funcionalidad básica del sistema, y encapsulan la lógica de negocio relevante. Por lo general, consisten en componentes situados en la capa de negocio, que pueden exponer las interfaces de servicio que otros usuarios pueden utilizar.
  • Los servicios de datos (data services) . Estos servicios proporcionan acceso a los datos que se alojan dentro de los límites del sistema y los datos expuestos por otros sistemas back-end, tal vez accede a través de los servicios. La capa de datos expone los datos a la capa de negocio a través de interfaces genéricas diseñadas para ser convenientes para el uso de servicios de negocio (business services).

Componentes

Cada capa de una aplicación contendrá una serie de componentes que implementan la funcionalidad de esa capa. Estos componentes deben ser cohesivos y débilmente acoplados para simplificar la reutilización y el mantenimiento. La Figura 2 muestra los tipos de componentes que se encuentran comúnmente en cada capa.

Figura 2 Tipos de componentes que se encuentran comúnmente en cada capa

Figura 2 Tipos de componentes que se encuentran comúnmente en cada capa

Componentes de la capa de presentación

Los componentes de la capa de presentación implementan la funcionalidad necesaria para permitir a los usuarios interactuar con la aplicación. Los siguientes tipos de componentes se encuentran comúnmente en la capa de presentación:

  • componentes de la interfaz de usuario (UI) . Estos componentes proporcionan el mecanismo para que los usuarios interactúen con la aplicación. Los datos de formato para su visualización, adquirir y validar los datos introducidos por los usuarios.
  • Componentes de proceso de interfaz de usuario . Para ayudar a sincronizar y organizar las interacciones del usuario, puede ser útil para impulsar el proceso utilizando distintos componentes del proceso de interfaz de usuario. Esto evita que el flujo del proceso y la lógica de gestión de estado de ser codificada en los elementos de interfaz de usuario en sí, y le permite volver a utilizar los mismos patrones básicos de interacción con el usuario en otras interfaces de usuario (básicamente se refiere a separar los componentes de UI de la lógica de implementación de dichos componentes), para mayores referencias consultar el patrón MVP (Model View Presenter).

Componentes de la capa de Negocio

Los componentes empresariales de esta capa implementan la funcionalidad básica del sistema, y ​​encapsulan la lógica de negocio relevante. Los siguientes tipos de componentes se encuentran comúnmente en la capa de negocio:

  • Fachada de aplicaciones (Application façade). Esto es una característica opcional que se puede utilizar para combinar múltiples operaciones empresariales en un solo envió un mensaje a base de operaciones. Esta característica es útil cuando se localice los componentes de la capa de presentación en un nivel físico independiente de los componentes de la capa de negocio, lo que le permite optimizar el uso del método de comunicación que los une.
  • Los componentes empresariales (Business components) . Estos componentes implementan la lógica de negocio de la aplicación. Independientemente de que un proceso de negocio se compone de un solo paso o un flujo de trabajo orquestado, su aplicación es probable que requieren componentes que implementan las reglas de negocio y realizar tareas de oficina.
  • Flujos de trabajo empresariales (Business workflow) . Después de que los componentes de interfaz recogen los datos necesarios del usuario y lo pasa a la capa de negocio, la aplicación puede utilizar esta información para llevar a cabo un proceso de negocio. Muchos procesos de negocio implican varios pasos que se deben realizar en el orden correcto, y pueden interactuar entre sí a través de una orquestación. Los componentes empresariales de flujo de trabajo definen y coordinan las de larga duración, de pasos múltiples procesos de negocio, y se puede implementar utilizando herramientas de gestión de procesos de negocio.
  • Componentes de entidad empresarial (Business entity components) . Las entidades empresariales se utilizan para pasar los datos entre los componentes. Los datos representan entidades del mundo real de negocios, tales como productos o pedidos. Las entidades empresariales que la aplicación utiliza internamente suelen ser estructuras de datos, como DataSets, DataReaders, o Lenguaje de marcado extensible (XML) corrientes, pero también se puede implementar utilizando clases personalizadas orientados a objetos que representan las entidades del mundo real que la aplicación manejará.

Componentes de la capa de datos

Los componentes de la capa de datos facilitan el acceso a los datos que se aloja dentro de los límites del sistema y los datos expuestos por otros sistemas back-end. Los siguientes tipos de componentes se encuentran comúnmente en la capa de datos:

  • Componentes de acceso a datos (Data access components). Estos componentes abstraen la lógica necesaria para acceder a los almacenes de datos subyacentes. Si lo hace, centraliza la funcionalidad de acceso a datos y hace la aplicación más fácil de configurar y mantener.
  • Ayudante de datos y componentes de servicios públicos (Data helper and utility components). La mayoría de las tareas de acceso a datos requieren lógica común que pueda ser extraída y aplicada en distintos componentes de ayuda reutilizables. Esto ayuda a reducir la complejidad de los componentes de acceso a datos y centraliza la lógica, lo que simplifica el mantenimiento. Otras tareas que son comunes en componentes de la capa de datos, y no es específica de un conjunto de componentes, pueden ser implementados como componentes de servicios separados. Ambos componentes de ayuda y utilidad a menudo puede ser reutilizado en otras aplicaciones.
  • Los agentes de servicio (Service agents). Cuando un componente de negocio debe utilizar la funcionalidad proporcionada por un servicio externo, puede que tenga que implementar código para administrar la semántica de la comunicación con ese servicio en particular. Los Agentes del Servicio permiten aislar las idiosincrasias de diversos servicios de llamadas desde la aplicación, y puede proporcionar servicios adicionales, tales como la cartografía básica entre el formato de los datos expuestos por el servicio y el formato que requiere su aplicación.

Componentes transversales

Muchas de las tareas llevadas a cabo por el código de una aplicación se requieren en más de una capa. Los componentes transversales implementan tipos específicos de funcionalidad que se puede acceder a partir de componentes en cualquier capa. Los siguientes son los tipos comunes de componentes transversales:

  • Componentes para la implementación de la seguridad . Estos pueden incluir componentes que realizan la autenticación, autorización y validación.
  • Componentes para la implementación de tareas de gestión operacional . Estos pueden incluir componentes que implementan las políticas de manejo de excepciones, registro, contadores de rendimiento, configuración y localización.
  • Componentes para implementar la comunicación . Estos pueden incluir componentes que se comunican con otros servicios y aplicaciones.

(Continúa en http://apparchguide.codeplex.com/wikipage?title=Chapter%209%20-%20Layers%20and%20Tiers)

Referencias:

http://blogs.msdn.com/b/jmeier/archive/2008/09/06/layers-and-tiers.aspx

http://www.hanselman.com/blog/AReminderOnThreeMultiTierLayerArchitectureDesignBroughtToYouByMyLateNightFrustrations.aspx

http://queens.db.toronto.edu/~papaggel/courses/csc309/docs/lectures/web-architectures.pdf

http://archive.systems.ethz.ch/www.systems.ethz.ch/education/hs11/eai/lectures/Chapter-1-EAI-2011-Layers.pdf

http://morphological.files.wordpress.com/2011/08/5-layer-architecture-draft.pdf

Deja un comentario

Archivado bajo Arquitectura de Sistemas, Arquitectura de Software, Diseño

El método científico y la Metodología del diseño de Software

Cuadro Sinóptico comparando método científico y metodología del diseño de software

metodo_cientifico_metodologia_software

Método científico

Observación, es aplicar atentamente los sentidos en un objeto,

Inducción, efecto de extraer, a partir de determinadas observaciones o experiencias particulares.

Hipótesis, Planteamiento mediante la observación siguiendo las normas establecidas por el método científico.

Verificación, solo se examina si es correcto o no el experimento.

Refutación o aceptación, si la verificación fue aceptada el experimento término si no se realiza una retroalimentación hasta continuar con la hipótesis.

Metodología del diseño de software

Análisis del problema Es una similitud entre observación e inducción porque en el se plantea el problema y para ello tuvo que ver una observación previa.

Diseño preliminar-Programación-Implementación es un anteproyecto el cual puede ser considerada como hipótesis por que a partir de ella se lleva acabo la experimentación.

Prueba si es aceptada el experimento termina que es muy similar a la refutación y/o aceptación.

Etapas del proceso

La ingeniería de software requiere llevar a cabo numerosas tareas, dentro de etapas como las siguientes:

Análisis de requisitos,

Mientras que los clientes piensan que ellos saben lo que el software tiene que hacer, se requiere de habilidad y experiencia en la ingeniería de software para reconocer requisitos incompletos, ambiguos o contradictorios. El resultado del análisis de requisitos con el cliente se plasma en el documento ERS, Especificación de Requerimientos del Sistema, cuya estructura puede venir definida por varios estándares. La captura, análisis y especificación de requisitos (incluso pruebas de ellos), es una parte crucial; de esta etapa depende en gran medida el logro de los objetivos finales.

Especificación,

Es la tarea de describir detalladamente el software a ser escrito, en una forma matemáticamente rigurosa.

Diseño y arquitectura,

Se refiere a determinar como funcionará de forma general sin entrar en detalles. Consiste en incorporar consideraciones de la implementación tecnológica, como el hardware, la red, etc. Se definen los Casos de Uso para cubrir las funciones que realizará el sistema, y se transforman las entidades definidas en el análisis de requisitos en clases de diseño, obteniendo un modelo cercano a la programación orientada a objetos.

Programación,

Reducir un diseño a código puede ser la parte más obvia del trabajo de ingeniería de software, pero no necesariamente es la que demanda mayor trabajo y ni la más complicada. La complejidad y la duración de esta etapa está íntimamente relacionada al o a los lenguajes de programación utilizados, así como al diseño previamente realizado.

Prueba,

Consiste en comprobar que el software realice correctamente las tareas indicadas en la especificación del problema. Una técnica de prueba es probar por separado cada módulo del software, y luego probarlo de forma integral, para así llegar al objetivo.Hay dos grandes formas de organizar un área de pruebas, la primera es que esté compuesta por personal inexperto y que desconozca el tema de pruebas, de esta forma se evalúa que la documentación entregada sea de calidad, que los procesos descritos son tan claros que cualquiera puede entenderlos y el software hace las cosas tal y como están descritas.

Documentación,

Todo lo concerniente a la documentación del propio desarrollo del software y de la gestión del proyecto, pasando por modelaciones (UML), diagramas, pruebas, manuales de usuario, manuales técnicos, etc; todo con el propósito de eventuales correcciones, usabilidad, mantenimiento futuro y ampliaciones al sistema.

Mantenimiento,

Mantener y mejorar el software para enfrentar errores descubiertos y nuevos requisitos. Esto puede llevar más tiempo incluso que el desarrollo inicial del software. Alrededor de 2/3 de toda la ingeniería de software tiene que ver con dar mantenimiento.

Metodología (ingeniería de software)

La rama de la metodología, dentro de la ingeniería de software, se encarga de elaborar estrategias de desarrollo de software que promuevan prácticas adoptativas en vez de predictivas; centradas en las personas o los equipos, orientadas hacia la funcionalidad y la entrega, de comunicación intensiva y que requieren implicación directa del cliente.

Método científico

El método científico está sustentado por dos pilares fundamentales. El primero de ellos es la reproducibilidad, es decir, la capacidad de repetir un determinado experimento en cualquier lugar y por cualquier persona. El segundo pilar es la falsabilidad. Es decir, que toda proposición científica tiene que ser susceptible de ser falsada (falsacionismo). Esto implica que se pueden diseñar experimentos que en el caso de dar resultados distintos a los predichos negarían la hipótesis puesta a prueba.Según James B. Conant no existe un método científico. El científico usa métodos definitorios, métodos clasificatorios, métodos estadísticos, métodos hipotético-deductivos, procedimientos de medición, etcétera. Según esto, referirse al método científico es referirse a este conjunto de tácticas empleadas para constituir el conocimiento, sujetas al devenir histórico, y que pueden ser otras en el futuro. Ello nos conduce tratar de sistematizar las distintas ramas dentro del campo del método científico.

Francis Bacon definió el método científico de la siguiente manera:

1. Observación: Observar es aplicar atentamente los sentidos a un objeto o a un fenómeno, para estudiarlos tal como se presentan en realidad.

2. Inducción: La acción y efecto de extraer, a partir de determinadas observaciones o experiencias particulares, el principio particular de cada una de ellas.

3. Hipótesis: Planteamiento mediante la observación siguiendo las normas establecidas por el método científico.

4. Probar la hipótesis por experimentación.

5. Demostración o refutación (antítesis) de la hipótesis.

6. Tesis o teoría científica (conclusiones).

Fuente: Luis Miguel Salazar Burgos (http://apuntessig01a31.blogspot.com/)

Referencias:

“El papel del método científico en el desarrollo del software”. Dra. Natalia Juristo Catedrática de Ingeniería de Software de la Universidad Politécnica de Madrid, Facultad de Ingeniería, Universidad ORT Uruguay, 24 de marzo de 2011.  Recurso online: http://www.ort.edu.uy/fi/pdf/nataliajuristo240311.pdf

1 comentario

Archivado bajo Diseño, Ingeniería de Software

Construyendo modelos de dominio

Un Modelo de Dominio es un artefacto de la disciplina de análisis, construido con las reglas de UML durante la fase de concepción, en la tarea construcción del modelo de dominio, presentado como uno o más diagramas de clases y que contiene, no conceptos propios de un sistema de software sino de la propia realidad física.

Los modelos de dominio pueden utilizarse para capturar y expresar el entendimiento ganado en un área bajo análisis como paso previo al diseño de un sistema, ya sea de software o de otro tipo. Similares a los mapas mentales utilizados en el aprendizaje, el modelo de dominio es utilizado por el análista como un medio para comprender el sector industrial o de negocios al cual el sistema va a servir.

Moving From Problem Space to Solution Space

El siguiente diagrama es un pequeño ejemplo de Modelo de Dominio, en este caso, referido al Metro o sistema de transporte subterraneo de una ciudad cualquiera.

Fig. 1 – Ejemplo de Modelo de Dominio de un sistema de subterráneo

En este diagrama se ve que un Usuario del Metro tiene cero o más boletos, comprados estos en una maquina de Venta de Boletos; dicha maquina “crea” los boletos los cuales son consumidos en un viaje, el cual tiene una estación de origen y otra de destino. Finalmente se ve que una estación tiene una o más maquinas de venta así como empleados de limpieza, seguridad y operaciones.

Es posible capturar un mayor grado de detalle en uno de estos modelos; corresponde al analista decidir cuanto detalle va a ser necesario y hasta donde llegar a modelar. El objetivo es capturar lo necesario para comprender donde va a funcionar el sistema que estamos diseñando y esto demanda una cantidad distinta de detalles cada vez.

El modelo de dominio puede ser tomado como el punto de partida para el diseño del sistema. Esto es así ya que cuando se realiza la programación orientada a objetos, se supone que el funcionamiento interno del software va a imitar en alguna medida a la realidad, por lo que el mapa de conceptos del modelo de domino constituye una primera versión del sistema.

Enlace recomendado:

Las Buenas Prácticas de la Ingeniería de Requerimientos y los Mapas Mentales como Instrumentos de Apoyo al Proceso de Análisis y Diseño de Software.  

En la aproximación llamada Desarrollo Guiado por Modelos al modelo de dominio se le conoce como Modelo Independiente del Computador o CIM, por sus siglas en inglés. El CIM es el que da inicio al proceso de desarrollo y ocupa el rol, tanto de modelo de requisitos como de modelo análisis.

Por otra parte, cuando se sigue una aproximación Centrada en Casos de Uso como RUP/UP, el modelo de dominio es utilizado como entrada en la tarea análisis de los casos de uso en la construcción de los llamados escenarios de análisis.

Es decir, y con esto quiero concluir, que el modelo de dominio ocupa un rol protagonico en el desarrollo moderno de software y constituye un artefacto que vale la pena tener en nuestros proyectos.

Fuente: http://synergix.wordpress.com

Referencias adicionales: https://jjegonzalezf.wordpress.com

Deja un comentario

Archivado bajo Diseño, Ingeniería de Software

Construyendo casos de uso

¿Include o Extend?

Un tema que genera mucha polémica entre la gente que modela casos de uso es la elección entre la relación de <<include>> y <<extend>>. Lo peor es que muchas de esas discusiones generan muy poco valor en el resultado final en el modelo y en cambio quitan tiempo valioso del proyecto. Esto se debe a que dichas relaciones, muchas veces no son del todo comprendidas por la persona que la modela, y mucho menos son comprendidas por las personas que leen el modelo. Así que al final no se le saca el provecho que en todo caso debería de tener dicha elección.

Es mejor mantener el modelo simple (Aplique el principio de KISS), incluso si esto significa utilizar menos elementos gráficos de UML, si eso va a facilitar el modelado y la comunicación en el proyecto. Pero, después de todo este tiempo y de los diferentes temas que hemos venido tratando, es importante avanzar y adentrarnos en algunos pormenores del lenguaje unificado.

Antes que todo, ¿qué es el “include” y el “extend”? 

Gráficamente lo que mostramos es una relación de dependencia entre el par de casos de uso, con el nombre correspondiente al tipo de relación de la que se trate: ya sea <<include>> o <<extend>>.
Estas, son relaciones que usamos para ligar gráficamente dos casos de uso, cuyos flujos de eventos están unidos, normalmente en una sola sesión del usuario. En otras palabras, un caso de uso que está ligado, por medio de una de estas dos relaciones, a otro caso de uso; también podría leerse o ejecutarse como un sólo caso de uso en lugar de dos. Obviamente, hay una razón por la cual decidimos separarlos en dos, lo cual explicaremos más adelante.
Imagina el conjunto de pasos que ocurren al realizar una compra en una tienda departamental. Seguramente no tendrás problema en visualizar el conjunto de pasos para solicitar la autorización de la tarjeta de crédito con la que vas a pagar, ligado a los pasos donde el vendedor registra los productos a comprar. Es decir, los flujos de eventos de ambos procesos forman una sola cosa; juntos podrían formar un solo caso de uso, en lugar de dos casos de uso unidos por alguna de estas relaciones que aquí estamos tratando.

Figura 1. Relacionando casos de uso

Include. En términos muy simples, cuando relacionamos dos casos de uso con un “include”, estamos diciendo que el primero (el caso de uso base) incluye al segundo (el caso de uso incluído). Es decir, el segundo es parte esencial del primero. Sin el segundo, el primero no podría funcionar bien; pues no podría cumplir su objetivo. Para una venta en caja, la venta no puede considerarse completa si no se realiza el proceso para cobrarla en ese momento. El caso de uso “Cobrar Renta” está incluido en el caso de uso “Rentar Video”, o lo que es lo mismo “Rentar Video” incluye (<<include>>) “Cobrar Renta”.  ¿Simple no?

Figura 2. Ejemplo de Include

Extend. La polémica al querer seleccionar una de las dos relaciones es que en el “extend” también podemos ver, desde la perspectiva del usuario, a los dos flujos como si fueran uno sólo. Y en ciertos escenarios el caso de uso base no podría cumplir su objetivo si no se ejecutara la extensión. Pero, una de las diferencias básicas es que en el caso del “extend” hay situaciones en que el caso de uso de extensión no es indispensable que ocurra, y cuando lo hace ofrece un valor extra (extiende) al objetivo original del caso de uso base. En cambio en el “include” es necesario que ocurra el caso incluído, tan sólo para satisfacer el objetivo del caso de uso base. Ejemplo: Puedes “Realizar Venta” sin “Acumular Puntos de Cliente VIP”, cuando no eres un cliente VIP. Pero, si eres un cliente VIP sí acumularás puntos. Por lo tanto, “Acumular Puntos” es una extensión de “Realizar Venta” y sólo se ejecuta para cierto tipo de ventas, no para todas.

Figura 3. Ejemplo de Extend

Casos de Abuso

Uno de los riesgos que existe cuando la gente sabe que tiene estas relaciones como un elemento a utilizar en sus modelos de casos de uso, consiste en su abuso. Mucha gente, y sobre todo la que arrastra prácticas de métodos estructurados, la suele utilizar en exceso. No es raro ver modelos de casos de uso que llegan a tener decenas de inclusiones y extensiones, incluso las inclusiones y extensiones se vuelven a extender a varios niveles, generando una maraña de casos de uso que no ofrecen valor al ser mostrados explícitamente.

Figura 4. Abuso de relaciones

Es importante comprender que el objetivo de estos tipos de relaciones NO consiste (remarco la negación) en motivar la división de los casos de uso en la mayor cantidad de pedazos. Debe de existir una razón importante para que decidamos dividir un caso de uso en dos que serán unidos por medio de alguna de estas relaciones. Si entendemos esto y somos congruentes, obtendremos un beneficio real para el proyecto; fin último del uso de UML.

La razón por la que la gente suele partir sus casos de uso en infinidad de “include” y “extend” es porque quieren conocer, entender y comunicar el máximo detalle de los casos de uso en el diagrama. Hay quien llega a utilizar, erróneamente, estas relaciones para mostrar el orden en que se ejecutan estos casos de uso. Debemos de recordar que al modelar el diagrama de casos de uso no buscamos analizar el detalle, y mucho menos los flujos. Todo ese detalle lo podremos plasmar en otro tipo de diagramas, como los diagramas de interacción, de actividad, de estados, o simplemente un texto en una especificación.

Relaciones de Análisis o Diseño

Otra situación donde abusamos de estas relaciones se da cuando queremos representar la unión de casos de uso por una decisión de diseño del sistema, específicamente por una decisión de navegabilidad entre funciones. Pensemos en cierta funcionalidad en un sistema, la cual corresponde a la ejecución de cierto caso de uso (por ejemplo “Registrar Préstamo de un Video”). Y estando en dicho caso de uso tienes a la vista en la pantalla, y decides utilizar, un botón que te permitiría iniciar otro caso de uso que tiene poco o nada que ver con el objetivo del caso de uso inicial (digamos, “Consultar Promociones”). Esto no debería de mostrarse como una relación entre estos dos casos de uso en el modelo.

No deberíamos modelar al primer caso de uso incluyendo ni siendo extendido con el segundo caso de uso ni viceversa, pues la razón por la que se ligaron (no gráficamente, sino en su ejecución) fue por una facilidad otorgada por la manera en que se diseño el sistema, la cual permite navegar fácilmente entre las diferentes funciones del sistema. La navegabilidad que otorga el sistema entre uno y otro caso de uso normalmente tiene que ver poco con que exista o no una relación entre dichos casos de uso.

Reuso: Evitando el Retrabajo

Una de las razones por las cuales deberías de considerar el uso de este tipo de relaciones, es porque identificas que hay pasos que son iguales en dos o más casos de uso. No querrás tener que escribir y darle mantenimiento a esos pasos en los documentos asociados a cada uno de ellos. Peor aún, no querrás correr el riesgo de que esos pasos se diseñen, programen y prueben de maneras diferentes y con esfuerzos aislados por ti o tu equipo de desarrollo. Finalmente son la misma cosa, ¿para qué querríamos trabajar doble? Lo que queremos es economizar, ser más eficientes en el desarrollo, y ahí es cuando viene el beneficio de identificar estos tipos de relaciones; porque es una oportunidad de identificar reuso.

Figura 5. Identificación de reuso

Si te sientes preparado para desarrollar modelos de casos de uso más sofisticados y de mayor valor, entonces considera la posibilidad de utilizar estos tipos de relaciones. Sólo asegúrate de aprovecharlas adecuadamente, buscando el beneficio real que deberían de proporcionar en tu modelo y proyecto con base en las recomendaciones mencionadas. Y recuerda unificar los criterios dentro de tu empresa para que el lenguaje sea realmente unificado o estandarizado dentro de tu empresa.

Por Sergio Orozco y Leticia Ortiz

Fuente: http://www.milestone.com.mx

1 comentario

Archivado bajo Arquitectura de Software, Diseño, Docencia, Ingeniería de Software, UNAB

Análisis de las plataformas de redes sociales actuales para obtener patrones arquitectónicos comunes y rescatar las mejores prácticas

Resumen

La presente investigación aborda la aplicación de técnicas de la Ingeniería de Software, básicamente aquellas relacionadas con Ingeniería de Requerimientos, Patrones de Diseño y Arquitectura, que permitan la creación de un modelo en función del modelo de calidad FURPS+ y patrones arquitectónicos comunes dentro de las plataformas de redes sociales mencionadas a continuación: Facebook, Twitter, Linkedin, Flickr y Myspace. Dicha investigación estará enmarcada dentro del ámbito de los Requerimientos no Funcionales (RNF) de las plataformas anteriormente mencionadas, considerando las posibles relaciones con los requerimientos funcionales (RF).

El análisis y búsqueda de patrones comunes en esta investigación, propondrá buscar la solución (es) temprana (s) a los problemas identificados tales como: persistencia de los datos, problemas asociados al almacenamiento y caching de la información, problemas de seguridad, problemas de escalabilidad de arquitectura, problemas de usabilidad y problemas de desempeño [1]; para crear un modelo en función de FURPS+ que aporte en el diseño arquitectónico de nuevas plataformas relacionadas con los requerimientos no funcionales y sus posibles conexiones con los requerimientos funcionales. Rescatando de esta investigación, las prácticas actuales utilizadas en el diseño de este tipo de plataformas.

Abstract

This investigation focuses on the application of techniques of software engineering, primarily those relating to Requirements Engineering, Design Patterns and Architecture, enabling the creation of a model based on the quality model FURPS + and architectural patterns common in platforms social networks listed below: Facebook, Twitter, Linkedin, Flickr and Myspace. This investigation is framed within the scope of non-functional requirements (NFR) of the platforms mentioned above, considering the possible relationships with the functional requirements (FR).

The analysis and search for patterns in this research, propose to find the solution (s) early (s) to the identified problems such as data persistence, problems associated with storage and caching of information security problems, problems scalable architecture, usability and performance problems [1], to create a model based on FURPS + to provide the architectural design of new platforms related to non-functional requirements and their possible connections with the functional requirements. Recovering from this research, current practices used in the design of such platforms.

Introducción

El auge de las redes sociales [2] y el gran impacto que tienen en el mundo de la Internet nos hace pensar que su popularidad hace que cada vez crezcan más y abarquen contenidos especializados y acorde a las tendencias tecnológicas y capacidades de la nueva Web 2.0.

Las nuevas tecnologías, más allá de aportar la más potente herramienta de comunicación conocida, están configurando una nueva forma de entender y organizar la sociedad, con las posibilidades y los riesgos que ello conlleva. Esta evolución de la tecnología, genera cambios radicales en el comportamiento del usuario tales como: la disminución del uso del teléfono fijo, el contacto más abierto con personas de otras nacionalidades, entre otros; con un sostenido crecimiento que provoca que los mismos usuarios creen, compartan y distribuyan contenido en la web. Este paradigma social, esta conducido por la popularidad surgida de las llamadas redes sociales de la Internet [3], las cuales permiten al usuario construir y compartir sus propios contenidos. Sitios como Flickr [4,5] donde los usuarios pueden compartir fotos, y Facebook [6,7], donde los usuarios intercambian información, videos, intereses, entre otros; son parte de la popularidad y el paradigma social.

De acuerdo a la información proporcionada por Nielsen/NetRatings1, el aumento del tráfico de las redes sociales ha tenido un crecimiento del 47% en el último año, alcanzando el 45% de todos los usuarios activos de la Web [8], estos niveles confluentes de usuarios son posibles gracias a las bajas barreras de entrada (un simple registro) que proporcionan estas comunidades. Muchos de estos servicios que ofrecen las redes sociales están diseñados de forma tan simple como iniciar sesión, ver el contenido y comenzar a subir datos a la plataforma. Esto permite al usuario que no está calificado técnicamente, participar con aquellos usuarios más experimentados.

Los patrones de acceso y recursos ofrecidos por estas plataformas se caracterizan por la variabilidad e imprevisibilidad de las interacciones sociales (p.e. los llamados slashdot effects [9]), además de la naturaleza propia de lectura y escritura a través de mensajes multimedia que ocurre dentro de estos servicios, los cuales generan una significativa cantidad de operaciones de carga con respecto a los tradicionales Web Services [10]. Siguiendo con esta línea, se observa que los servicios de redes sociales presentan una amplia gama de contenido multimedia, desde blogs hasta sitios donde la interacción ocurre con las imágenes y videos, estos factores determinan un cambio radical en el tipo y cantidad de datos que son transferidos.

La combinación de estos tipos de interacción con el usuario y los propios contenidos multimedia introducen nuevos requerimientos tanto de servidores como de infraestructura que agregan nuevas características a las tradicionales aplicaciones basadas en la Web. Si bien, existen varios estudios relacionados con el rendimiento y análisis de los cuellos de botella para aplicaciones web tradicionales [11,1], no se encontraron estudios que profundicen aún más sobre los requerimientos arquitectónicos y patrones comunes existentes en las plataformas de redes sociales.

La principal contribución de esta investigación es:

  • Buscar los lineamientos arquitectónicos y de diseño comunes entre cinco grandes plataformas de redes sociales: Facebook, Flickr, Myspace, Linkedin y Twitter, los cuales se caracterizan por tener diferentes cantidades de contenidos multimedia,
  • considerar para cada una de las redes sociales mencionadas anteriormente, los requerimientos no funcionales, buscando las posibles conexiones que existan con los requerimientos funcionales,
  • encontrar denominadores comunes en los patrones y el diseño de este tipo de plataformas,
  • de forma tal de poder rescatar de todo ello, las buenas prácticas actuales.
Referencias

[1] Q. Zhang, A. Riska, E. Riedel, and E. Smirni, “Bottlenecks and their performance implications in e-commerce systems,” in In Proc. of 9th International Workshop on Web Content Caching and Distribution, Beijing, China, 2004.

[2] Andrew Lipsman. (2007, July) http://www.comscore.com. [Online]. http://www.comscore.com/Press_Events/Press_Releases/2007/07/Social_Networking_Goes_Global

[3] A. C.Weaver and B. B. Morrison, “Social Networking,” IEEE Computer Magazine, pp. 41(2):97-100, 2008.

[4] (2008) Flickr. [Online]. http://www.flickr.com/

[5] N. Van House, “Flickr and public image sharing: distant closeness and photo exhibition,” in Conference on Human Factors in Computing Systems (CHI’07), San Jose, CA, 2007.

[6] Facebook. (2004) [Online]. http://www.facebook.com

[7] Instiuto de Maquina Herramienta. (2009) Manual sobre Facebook: redes sociales para usuario y para empresa. [Online]. http://www.imh.es/dokumentazio-irekia/manuales/manual-facebook-redes-sociales-para-usuario-y-para-empresa

[8] S. Bausch and L. Han, “Social Networking Sites Grow 47 Percent, Year over Year, Reaching 45 Percent of Web Users,” Nielsen/NetRatings Research Report, 2007.

[9] Alexander M Campbell Halavais, “The Slashdot effect : analysis of a large-scale public conversation on the World Wide Web,” University of Washington, Washington, Thesis (Ph. D.) 2001. [Online]. http://en.wikipedia.org/wiki/Slashdot_effect

[10] Francisco Curbera, Matthew Duftler, Rania Khalaf, and William Nagy, “Unraveling the Web Services Web,” IBM T.J.Watson Research Center, Research 2002.

[11] E. Cecchet, A. Chanda, S. Elnikety, J. Marguerite, and W. Zwaenepoel, “Performance comparison of middleware architectures for generating dynamic Web content,” in In Proc. of ACM/IFIP/USENIX International Middleware Conference (Middleware 2003), Rio de Janeiro, Brazil, 2003.

Download full Document (spanish)

Autor: Juan José González F.

Docente medio tiempo Universidad Andrés Bello

Magister en Ingeniería Informática con mención en Ingeniería de Software

jjegonzalezf@gmail.com

2 comentarios

Archivado bajo Arquitectura de Sistemas, Arquitectura de Software, Ingeniería de Software, Magister en Informatica