martes, 25 de octubre de 2011

INGENIERIA DE REQUISITOS 2




.

INGENIERIA DE REQUISITOS

En este artículo se presenta un modelo de requisitos como apoyo para la construcción de un sistema auxiliar para la adquisición de productos comerciales por medio de la web.

Este trabajo hace parte de un proyecto de investigación que tiene como objetivo proponer una metodología de Ingeniería de Requisitos (IR) para el análisis de Marketline.

A menudo los diseñadores de sistemas cometen el error de comenzar a diseñar e implementar soluciones que no han sido completamente  especificadas y que corresponden a problemas a los que les falta delimitación, lo cual conduce a la construcción de sistemas que no satisfacen la necesidades de los clientes y que incurren en el aumento de los costos y en el incumplimiento d los plazos establecidos. Todo lo anterior refleja las carencias que existen en cuanto a la definición de requisitos.


En esta sección se presentan los conceptos básicos que permiten entender las secciones siguientes  El proyecto se enmarca dentro de dos grandes áreas: la ingeniería de requisitos (IR) y las aplicaciones web.

En la ingeniería de software se denomina aplicación web a aquellas aplicaciones que los usuarios pueden utilizar accediendo a un servidor web a través de Internet o de una intranet mediante un navegador. En otras palabras, es una aplicación software que se codifica en un lenguaje soportado por los navegadores web.
Las aplicaciones web son populares debido a lo práctico del navegador web como cliente ligero, a la independencia del sistema operativo, así como a la facilidad para actualizar y mantener aplicaciones web sin distribuir e instalar software a miles de usuarios potenciales. Existen aplicaciones como los webmails, wikis, weblogs y  tiendas en línea que son ejemplos bien conocidos de aplicaciones web.
Es importante mencionar que una página Web puede contener elementos que permiten una comunicación activa entre el usuario y la información. Esto permite que el usuario acceda a los datos de modo interactivo, gracias a que la página responderá a cada una de sus acciones, como por ejemplo rellenar y enviar formularios, acceder a gestores de base de datos de todo tipo y de esta forma adquirir sus productos de una forma interactiva y practica.


Por otro lado, la ingeniería de requisitos es una rama de la ingeniería de software que apoya  al diseñador de sistemas en su tarea de traducir los objetivos del mundo real a funciones, restricciones de un sistema.

A continuación se muestran dos modelos de las fases que componen a la ingeniería de requisitos.


IDENTIFICACION DE REQUISITOS

Podemos obtener esta información de fuentes muy diversas: documentos, aplicaciones existentes, a través de entrevistas, etc. En base a esta información, el equipo de desarrollo elabora el catálogo de requisitos.

En este proyecto de investigación se trabajara mediante la técnica de recopilación de información conocida como “ENTREVISTA”, que permite a analista tomar conocimiento del problema y comprender los objetivos de la solución buscada. A través de esta técnica el equipo de trabajo se acerca a problema de una forma natural.

Básicamente, la estructura de la entrevista abarca tres pasos:

·         identificación de los entrevistados
·         preparación de la entrevista
·         realización de la entrevista y documentación de los resultados (protocolo de la entrevista).

 A pesar de que las entrevistas son esenciales en el proceso de la captura de requisitos y con su aplicación el equipo de desarrollo puede obtener una amplia visión del trabajo y las necesidades del usuario, es necesario destacar que no es una técnica sencilla de aplicar.

De acuerdo a las necesidades de la gente, deducimos que para ellos resultaría  más fácil  realizar sus compras cotidianas por medio de la web. Con una aplicación en donde nos muestre la lista de los productos con sus respectivas características y precios incluyendo la opciones de seleccionar y eliminar producto de la lista de artículos a comprar. Además de completar un formulario de registro mediante el cual se le otorgara un número de usuario y una contraseña y de esta forma pueda acceder a realizar sus compras en línea.

Ya una vez que el usuario ha seleccionado los productos requeridos, se mostrará el total de la compra para posteriormente presionar la opción comprar  y se abrirá automáticamente una página más en donde nos indicara la confirmación o en su defecto la cancelación de la compra. Una vez realizado este proceso se enviara la lista de productos al área de ventas en la cual el encargado escogerá los productos solicitados para posteriormente ser enviados al destino.


miércoles, 12 de octubre de 2011

INGENIERIA DE REQUISITOS

CAPTURA DE REQUISITOS

El proceso comienza con la realización de la captura de requisitos, el grupo de técnicos toma la información suministrada por los usuarios y clientes. Esta información puede provenir de fuentes muy diversas: documentos, aplicaciones existentes, a través de entrevistas, etc.
Finalmente con la validación de requisitos se realiza la valoración de los mismos, comprobando si existen inconsistencias, errores o si faltan requisitos por definir.
El proceso de captura de requisitos puede resultar complejo, principalmente si el entorno de trabajo es desconocido para el equipo de analistas, y depende mucho de las personas queparticipen en él.
A continuación se presentan un grupo de técnicas que de forma clásica han sido utilizadas para esta actividad en el proceso de desarrollo de todo tipo de software.

-        Entrevistas:Las entrevistas le permiten al analista tomar conocimiento del problema y comprender los objetivos de la solución buscada. Básicamente, la estructura de la entrevista abarca tres pasos: identificación de los entrevistados, preparación de la entrevista, realización de la entrevista y documentación de los resultados (protocolo de la entrevista).

-        JAD (Joint Application Development/Desarrollo conjunto de  aplicaciones): Está basada en cuatro principios fundamentales: dinámica de grupo, el uso de ayudas visuales para mejorar la comunicación, mantener un proceso organizado y racional y una filosofía de documentación WYSIWYG (What You See Is What You Get, lo que ve es lo que obtiene), es decir, durante la aplicación de la técnica se trabajará sobre lo que se generará.

-        Brainstorming (Tormenta de ideas): es también una técnica de reuniones en grupo cuyo objetivo es que los participantes muestren sus ideas de forma libre. Consiste en la mera acumulación de ideas y/o información sin evaluar las mismas.

-        Concept Mapping: Los concept maps son grafos en los que los vértices representan conceptos y las aristas representan posibles relaciones entre dichos conceptos. Estos grafos de relaciones se desarrollan con el usuario y sirven para aclarar los conceptos relacionados con el sistema a desarrollar.

-        Sketches y Storyboards: Consiste en representar sobre papel en forma muy esquemática las diferentes interfaces al usuario (sketches). Estos sketches pueden ser agrupados y unidos por enlaces dando idea de la estructura de navegación (storyboard).


-        Casos de Uso: Los casos de uso permiten mostrar el contorno (actores) y el alcance (requisitos funcionales expresados como casos de uso) de un sistema. Un caso de uso describe la secuencia de interacciones que se producen entre el sistema y los actores del mismo para realizar una determinada función. Los actores son elementos externos (personas, otros sistemas, etc.) que interactúan con el sistema como si de una caja negra se tratase. Un actor puede participar en varios casos de uso y un caso de uso puede interactuar con varios actores.

VALIDACION DE REQUISITOS

Los requisitos una vez definidos necesitan ser validados. La validación de requisitos tiene como misión demostrar que la definición de los requisitos define realmente el sistema que el usuario necesita o el cliente desea. Es necesario asegurar que el análisis realizado y los resultados obtenidos de la etapa de definición de requisitos son correctos. Pocas son las propuestas existentes que ofrecen técnicas para la realización de la validación y muchas de ellas consisten en revisar los modelos obtenidos en la definición de requisitos con el usuario para detectar errores o inconsistencias.

-        Reviews o Walk-throughs: Está técnica consiste en la lectura y corrección de la completa documentación o modelado de la definición de requisitos. Con ello solamente se puede validar la correcta interpretación de la información transmitida.

-        Auditorías: La revisión de la documentación con esta técnica consiste en un chequeo de los resultados contra una checklist predefinida o definida a comienzos del proceso, es decir sólo una muestra es revisada.

-        Matrices de trazabilidad: Esta técnica consiste en marcar los objetivos del sistema y chequearlos contra los requisitos del mismo.

-        Prototipos: Algunas propuestas se basan en obtener de la definición de requisitos prototipos que, sin tener la totalidad de la funcionalidad del sistema, permitan al usuario hacerse una idea de la estructura de la interfaz del sistema con el usuario.

TRATAMIENTO DE REQUISITOS

Son muchos los autores que han propuesto técnicas y modelos para el desarrollo de este tipo de sistemas, pero como se ha comentado, estas propuestas se centran principalmente en las últimas fases del proceso de desarrollo.

-        WSDM: Web Site Design Method
Es una propuesta para el desarrollo de sitios web, en la que el sistema se define en base a los grupos de usuarios. Su proceso de desarrollo se divide en cuatro fases: modelo de usuario, diseño conceptual, diseño de la implementación e implementación.

-        SOHDM: Scenario-based Object-Oriented Hypermedia Design Methodology Esta propuesta presenta la necesidad de disponer de un proceso que permita capturar las necesidades del sistema.
-        RNA: Relationship-Navegational Analysis Plantea una secuencia de pasos para el desarrollo de aplicaciones web, centrándose  fundamentalmente en el flujo de trabajo de análisis. El proceso de trabajo que presenta RNA se basa en la realización de las siguientes fases:

Análisis del entorno, Elementos de interés, Análisis del conocimiento, Análisis de la navegación e Implementación del análisis.

-        UWE: UML-Based Web Engineering Propuesta metodológica basada en el Proceso Unificado y UML para el desarrollo de aplicationes web. UWE cubre todo el ciclo de vida de este tipo de aplicaciones, centrando además su atención en aplicaciones personalizadas (adaptivas). Esta metodología distingue entre la tarea de elicitar requisitos, definir y validar los requisitos. El resultado final de la captura de requisitos en UWE es un modelo de casos de uso acompañado de documentación que describe los usuarios del sistema, las reglas de adaptación, los casos de uso y la interfaz. UWE clasifica los requisitos en dos grandes grupos: funcionales y no funcionales.

METODOLOGIA 2

Metodologías más sofisticadas del software libre

Metodologías  más sofisticadas del software libre
Ø eXtreme programming
Ø Métrica v3
eXtreme programming: la metodología más próxima a la forma de organización y participación en proyectos de software libre.
Considerada una metodología ágil para el desarrollo de software basada en los principios básicos de desarrollo de software toma en cuenta aspectos como:
Ø Simplicidad
Ø Comunicación
Ø Retroalimentación
Ø Coraje
Métrica v3: una metodología clásica considerada como imprescindible para realizar proyectos con la administración española.
® Conceptos
· Gestión de proyectos
La gestión de proyectos abarca desde que es lo que s quiere realizar hasta todas las actividades necesarias para cumplir con un objetivo determinado.
Incluye:
Ø Planificación
Ø Definición
Ø Ordenamiento
Ø Gestión

· Ciclo de vida del software
Fases de desarrollo por las cuales nuestro proyecto se va concibiendo.
Ø Toma de requisitos
Ø Análisis
Ø Diseño
Ø Desarrollo
Ø Pruebas
Ø Instalación
Ø Uso
Ø Mantenimiento
Ø Obsolescencia
· Análisis de requisitos
Considerada la primera fase del ciclo de vida de un proyecto es donde uno como desarrollador de software necesita desde un inicio tomando en cuenta todas las necesidades del usuario para llevar a cabo una planeación.

· Estimación de Costos
Esta suele realizarse basándose en parte al que tan grande y de que tantos recursos dependa el proyecto así como un estimado de tiempo que se tendrá que invertir para llevar acabo dicho proyecto.
· Diseño
Fase en la que se definen distintos puntos en base a los requisitos del usuario y los componentes con los que contamos en el que se emplean diagramas, arquitectura, interfaz etc.
· Documentación
Formatos en los cuales debemos describir detalladamente toda la arquitectura del proyecto desde código fuente, manuales de uso, documentos de seguimiento etc.
· Pruebas y Calidad
Anticiparnos a cualquier tipo de falla en el proyecto para que este tenga el mayor éxito tanto para uno como desarrollador y mucho más para el usuario o cliente y sobre todo que cumpla con los requisitos estipulados por el usuario. Todo esto llevando a cabo documentación de pruebas en las cuales se haya verificado que todo se encuentre en orden.
· Seguridad
Principios básicos tomados en el punto de seguridad:
Ø Confidencialidad
Ø Integridad
Ø Disponibilidad
® Conclusión
Sin duda un gran aporte en cuanto al desarrollo de sistemas ya que nos da una pauta detallada de cómo es que debe llevarse a cabo un proyecto con este enfoque. Tomando en cuenta los conceptos y las metodologías llevadas a cabo en la lectura muchas de las cuales desconocía veo como el desarrollo de un proyecto es un contexto bastante amplio para su desarrollo.

Ahora hablaremos de la metodología eXtreme Pregramming o programación extrema para el desarrollo de proyectos de software libre es una metodología de las llamadas “Agiles”. Se basa en los principios de simplicidad, la comunicación, la retroalimentación, y el coraje que implica a todo el equipo y a los usuarios o clientes.
Las metodologías agiles proponen una implicación total del cliente en el proyecto. Primeramente se realiza un plan de proyecto basados en versiones del producto acordadas a partir de funcionalidades concretas después Se realiza el desarrollo para las funcionalidades concretas finalmente una vez que se entregan la versión del proyecto cumpliendo con lis requisitos el proceso vuelve a iniciarse con un conjunto mayor de funcionalidades  Los procesos y prácticas de esta metodología están basados en la experiencia del equipo de desarrollo y en los errores cometidos.
El eXtreme Programmind se puede dividirse en cuatro fases.
· Planeación
· Diseño
· Desarrollo
· Pruebas
En la primera fase que es la planificaron se empieza con la confeccione de las “Historias de usuario” que son breves frases en la que se describe una prestación o proceso sin ningún tipo de tecnicismos. Para cada historia deberíamos de poder estimar su tiempo ideal de desarrollo que debería de ser de 1,2 o 3 semanas como máximo (Si el tiempo es mayor se debe de partir la historia en trozos que no excedan las estimaciones). A continuación se pasa a la planificación de la siguiente fase, en la reunión de planificación de las fases se deben de implicar al cliente, desarrolladores y al gestor del proyecto. El objetivo será planificar las siguientes fases así el cliente será quien dicte el orden de las historias de usuario, y los desarrolladores quienes estimen el tiempo.
Para planificar se pueden tomar dos criterios:
· Tiempo para pasar a la siguiente fase.
· Alcance que deseamos que tenga.
El método de planificación rápida y adaptativa nos permite hace dos historias mientras que otras metodologías tardarían en documentar, planificar y realizar una estimación completa, que quizá no será tan fiable a esto se le denomina velocidad de proyecto mientras más cantidad de historias se completen en el menor tiempo posible  mayor será la velocidad del proyecto esto implica que se terminara más rápido.
Una de las tareas de los desarrolladores es convertir las historias del usuario en tareas de una duración de tres días como máximo para la programación de cada una de ellas.Es posible que las historias del usuario o cliente diferentes tengan las mismas tareas así la fase de planificación nos permite filtrar esas tareas.

Metodología próxima al software libre:
eXtreme Programming
eXtreme Programming o programación eXtrema, es una de las metodologías llamadas “ágiles”, para el desarrollo de proyectos de software .
Se basa en los principios de simplicidad, la comunicación, la retroalimentación y el coraje para implicar a todo el equipo (y a los usuarios o clientes) en la gestión del proyecto.
DISEÑO
La simplicidad es la clave de esta metodología.
  • Un diseño complejo siempre tarda más en desarrollarse que un simple.
  • Es más fácil añadir complejidad a un diseño simple que quitarla de uno complejo.
Se deben hacer las cosas lo más sencillas posible, evitando añadir funcionalidad no contemplada.
Es importante encontrar una metáfora para definir el sistema, un proceso que todos conozcan.
Al encontrar una buena metáfora nos ayudará a tener:
  1. Visión común. Todos conocen el núcleo del problema y en cómo funciona la solución.
  2. Vocabulario compartido. Dependiendo de la metáfora escogida, el vocabulario puede ser altamente técnico o muy común.
  3. Generalización. Sugerir nuevas ideas o soluciones.
  4. Arquitectura. Identificar los objetos clave y sugerir características de sus interfaces.
Se sugiere llevas acabo reuniones entre todos los desarrolladores implicados, donde se toman las decisiones mediante el uso de tarjetas CRC (class, responsabilities y colaboratión).
Este mecanismo ayuda a que todos participen y aporten sus ideas en el diseño.
Un punto clave es la refactorización, es decir el hecho de realizar cambios necesarios en las partes del código que lo requieran, sin modificar su funcionalidad o su interacción con el resto del sistema, dejándolo igual de simple pero con la nueva funcionalidad añadida.
CODIFICACIÓN
La diferencia entre esta metodología y la tradicional es la disponibilidad del cliente
El cliente debe participar en:
  • Reuniones de planificación
  • Toma de decisiones
  • Estar disponible durante los test (pequeños trozos de código que prueban la funcionalidad de un objetos) funcionales y de aceptación
Es de vital importancia acordar estándares de codificación y respetarlos en el desarrollo. Se debe ser tan concreto como sea posible.
Al someter a prueba nuestro código en pequeños test que deberá pasar, tendremos una idea más clara de lo que debemos codificar y nos guiaremos por ello, implementando únicamente lo que nos permitirá pasar los test.
Una característica diferencial de eXtreme Programming es el pair programing o la programación por parejas ya que el resultado obtenido es de mucha calidad, esto reduce el número de errores y los problemas de integración posteriores.
Designar dueños para cada objeto, que conozca todos los tests unitarios y de integración que debe pasar y se ocupe de integrarlos en cada reléase.
De este modo se añadirá al paradigma reléase-often (distribuye o implementa a menudo) el integrate-often (integra a menudo) reduciendo problemas de integración.

PRUEBAS
La construcción de las pruebas unitarias va a ahorrarnos mucho tiempo del que se invierte programando, buscando pequeños fallos.
Cuanto más complicada sea la prueba, más necesaria es para asegurar que después del desarrollo hace lo que se requiere.
  • Los tests unitarios aseguraran que los cambios introducidos no afecten la funcionalidad.
  • En un fallo o Bug con el cliente o durante el uso, debemos crear un test unitario que lo compruebe.
  • Los tests se crearan a partir del historial de usuario.
  • El cliente es responsable de definir los tests de aceptación.
  • Estos tests son del tipo “caja negra”
  • Los tests que no tengan éxito afectan la velocidad del proyecto.
CONCLUSIONES
Las pruebas unitarias, los historiales de usuario, la refactorización son recursos que también pueden ser aplicados a otras metodologías.
Lo verdaderamente destacable de eXtreame Programing es la forma de ordenar el ciclo de vida del proyecto y la involucración con el cliente.
Sus principales características lo hacen muy adecuado para proyectos de software libre.