consulta sobre gestion de requisitos

Guia de gestion de requisitos de software

Introduccion
Los mejores productos, desde el punto de vista del usuario, son aquellos creados por
desarrolladores que tienen muy claro lo que se pretende conseguir con el producto y cómo
obtenerlo. Para llegar a este punto, se debe entender el trabajo del usuario, cómo afectará el
producto a su trabajo y cómo se adecuará a los objetivos de la organización.
Lo que hace el producto y las condiciones que debe satisfacer en este contexto son los
requisitos del producto.

¿Qué es un requisito?
Un requisito es algo que el producto debe hacer o una característica que debe tener. Un
requisito existe por el tipo de demanda que tiene el producto o porque el cliente quiere que
el requisito sea parte del producto entregado. La tarea de todo analista de requisitos es
hablar con la gente, entenderla, escuchar lo que dicen y también lo que no dicen, para
entender lo que necesitan.

Requisitos del sistema/software
Definen las funcionalidades y características que debe tener el sistema para
satisfacer tanto los requisitos de negocio como los de usuario.
Van a servir como base para llevar a cabo la arquitectura, diseño y planes de
pruebas del sistema.

OBTENCIÓN DE REQUISITOS
La obtención de requisitos se define como el proceso de identificar las necesidades del
negocio, solucionando las posibles disparidades entre las personas involucradas en el
mismo, con el propósito de definir y destilar los requisitos para cumplir las restricciones
impuestas por las distintas partes.
Un buen proceso de obtención de requisitos soporta el desarrollo de la especificación de los
requisitos, de tal forma que tengan los siguientes atributos:
Deben ser completos, consistentes y han de estar dentro del alcance del proyecto
Deben tener un único identificador
Cumplen con los objetivos de los clientes
Son viables y apropiados para el desarrollo
Los requisitos han de ser “testeables” (deben tener capacidad de prueba).

GESTIÓN DE LOS REQUISITOS
La gestión de requisitos es el conjunto de actividades que ayudan al equipo de trabajo a
identificar, controlar y seguir los requisitos y sus cambios en cualquier momento. Es decir, la
gestión de requisitos consiste en gestionar los cambios de los requisitos, las relaciones entre
ellos, las dependencias entre la especificación de requisitos y otros documentos producidos
por el proceso de desarrollo de software. De esta forma se asegura la consistencia entre los
requisitos y el sistema construido.
Por lo tanto, los objetivos principales del proceso de gestión de requisitos serán:
Gestionar la recogida de requisitos
Obtener la aprobación de los participantes del proyecto
Gestionar los cambios (trazabilidad)
La gestión de requisitos es un proceso que se desarrolla a lo largo de toda la vida del
producto.

GESTIÓN DE CAMBIOS
Los requisitos cambian durante todo el ciclo de vida de desarrollo del producto como se vio
en apartados anteriores. Los cambios deben controlarse y documentarse, es decir, hay que
convivir con ellos y por ello la gestión de cambios es esencial para tratar dichos cambios.
Cuando, durante el proyecto y una vez aceptada la línea base de requisitos, se solicita un
cambio sobre esta línea base, estos cambios no se pueden aceptar sin más ya que
podrían afectar al desarrollo de todo el sistema, o alguna parte esencial del mismo.
El siguiente gráfico muestra el proceso de gestión de cambios con las actividades a llevar a
cabo durante el desarrollo del mismo:

La primera tarea a realizar tras recibir una petición de cambio es valorar el impacto del
mismo. Para ello se deberá ir recorriendo todo el árbol de requisitos viendo como les afecta
el cambio, y aquí es donde entra la trazabilidad de los requisitos.

Una vez analizado el impacto del cambio, se debe tomar una decisión. Si se acepta el
cambio, tras negociarlo con el cliente, se continuará con la actividad de implementar el
cambio. En caso contrario, se deberá negociar con el cliente el siguiente paso a realizar.

Si se ha aceptado el cambio, hay que reflejar ese cambio en todos los productos que
resulten afectados por dicho cambio (si el cambio es mínimo algunos productos como el plan del proyecto, puede que no sea necesario modificar). Además se deberá generar un
nuevo punto de partida (línea base) de requisitos.

Trazabilidad

Un concepto clave en el proceso de gestión de cambios es la Trazabilidad. Los requisitos
deben ser trazables, es decir, “rastreables”. Se podría decir que un requisito es trazable si
se pueden identificar todas las partes del producto existente relacionadas con ese requisito.
Todos los requisitos deberían ser trazables para mantener consistencia entre los distintos
documentos de un proyecto.

Es importante conocer aspectos de los requisitos tales como:

-

Su origen (Quién los propuso)

-

Necesidad (Por qué existe)

-

Relación con otros requisitos (Dependencias)

-

Relación con otros elementos (Dependencias)

El uso de matrices de trazabilidad es una buena técnica para llevar a cabo esta actividad de
forma eficiente. A continuación se propone una posible matriz de trazabilidad:

MEJORES PRÁCTICAS

En el desarrollo de software, una mejor práctica es un método bien definido que contribuye
a una implementación exitosa del proyecto software. Las organizaciones crean mejores
prácticas para que les ayuden a resolver problemas pudiendo disminuir la tasa de fallo de
sus proyectos.

MEJORES PRÁCTICAS EN EL DESARROLLO DE REQUISITOS

A continuación se describen una serie de mejores prácticas orientadas al desarrollo de
requisitos:

Documentar el alcance y visión del proyecto: permitirá tener un mejor
entendimiento de los requisitos y asegurará que todas las personas involucradas en
el proyecto trabajen hacia la misma meta.

Mantener un glosario del proyecto: facilitará una comunicación efectiva
asegurando un entendimiento unánime.

Uso de técnicas de obtención de requisitos de usuario: para facilitar esta tarea.

Involucrar a toda la gente implicada: asegura una validación temprana del
entendimiento de los requisitos.

Desarrollo incremental de requisitos: puede minimizar la cantidad de re-trabajo del
proyecto.

Captura de requisitos usando casos de uso: será más fácil gestionar los
requisitos y hacer un seguimiento de los mismos.

Validar requisitos: para mejorar el éxito de los proyectos es crítico que se validen
los requisitos de forma adecuada.

Verificar requisitos: para asegurar que los requisitos proporcionan una base
adecuada para llevar a cabo el diseño, la construcción y las pruebas.

MEJORES PRÁCTICAS EN LA GESTIÓN DE REQUISITOS

A continuación se muestran una serie de mejores prácticas relacionadas con la gestión de
requisitos:

Priorizar requisitos: para determinar aquellos que se deberían cumplir en la primera
versión o producto y aquellos que pueden llevarse a cabo en sucesivas versiones.

Establecer líneas base de los requisitos: para asegurar que cualquier modificación
en los requisitos que cambie la línea base se trata como cambios de alcance.

Comunicación abierta: para asegurar que la información relacionada con los
requisitos se comunica de forma consistente. Una comunicación abierta también
implica comunicar a la gente correcta y al conjunto mínimo de personas.

-Gestión de cambios de los requisitos: es esencial gestionar estos cambios de
forma efectiva y eficiente.

-Uso de herramientas para la gestión de requisitos: para facilitar la gestión de
requisitos.

-

Mantener trazabilidad de requisitos: para llevar un seguimiento de la vida de un
requisito.

-Establecer un plan de mejora de procesos para la ingeniería de requisitos: para
cumplir con las necesidades actuales y futuras de forma más eficiente y con mayor
calidad.

-Formar a los analistas de requisitos: para asegurar que los analistas de requisitos
tienen el conocimiento, entre otros aspectos, de cómo escribir buenos requisitos, etc.

DOCUMENTOS DE REQUERIMIENTOS--JUSTIFICACIÓN

Requisitos comunes de los interfaces: 

Están relacionadas con las pantallas, ventanas (formularios) que debe manipular el usuario para realizar una operación determinada. Dicha manipulación el usuario la realizará por medio del teclado y el Mouse (ratón).  Especificación de requisitos de software. 

Interfaces de usuario :
Las interfaces de usuario están relacionadas con las pantallas, ventanas
(formularios) que debe manipular el usuario para realizar una operación
determinada. Dicha manipulación el usuario la realizará por medio del teclado y el
Mouse (ratón).  Especificación de requisitos de software

Es importante mencionar que las interfaces de usuario también abarcan las
ayudas correspondientes en cada uno de los procesos que realice el sistema.
Las interfaces de usuario ayudaran al usuario final trabajando en un ambiente
Form, por lo que se dichas interfaces incluirán:
• Botones
• Menús despegables
• Mensajes informativos
• Mensajes de error
• Cuadros de diálogo
• Formularios para el ingreso, modificación, actualización y eliminación de
datos. Así como para las operaciones y las ayudas que se mencionó
anteriormente.
• Otros
A continuación se muestra una previa de lo que será las interfaces de usuario:
En caso de que no ingrese correctamente el USUARIO  o el PASSWORD se
desplegara un mensaje de  datos incorrectos.


 Interfaces de hardware: 


La pantalla del monitor.- el software deberá mostrar información al usuario a
través de la pantalla del monitor.
Ratón.- el software debe interactuar con el movimiento del ratón y los botones del
ratón. El ratón se activan las zonas de entrada de datos, botones de comando y
seleccione las opciones de los menús.
Teclado.- el software deberán interactuar con las pulsaciones del teclado. El
teclado de entrada de datos en el área activa de la base de datos.
Impresora.- el software impimira los reportes en la impresora instalada.

 Interfaces de comunicación:
La interfaz de comunicación entre el servidor de base de datos y la
aplicación desarrollada en un lenguaje de programación.

requisito funcional:
Un requisito funcional define el comportamiento interno del software: cálculos, detalles técnicos, manipulación de datos y otras funcionalidades específicas que muestran cómo los casos de uso serán llevados a la práctica. Son complementados por los requisitos no funcionales, que se enfocan en cambio en el diseño o la cimentación.

requisitos no funcionales:
Un requisito que especifica criterios que pueden usarse para juzgar la operación de un sistema en lugar de sus comportamientos específicos, ya que éstos corresponden a los requisitos funcionales. Por tanto, se refieren a todos los requisitos que ni describen información a guardar, ni funciones a realizar.Los requisitos no funcionales más habituales son la estabilidad, la portabilidad y el costo.

JUSTIFICACIÓN Y ESPECIFICACIONES: 


DE LOS REQUERIMIENTOS  DEL SOFTWARE
  
Elemento clave para la aclaración de cada una de las dudas referentes al software  teniendo como base los requerimientos establecidos inicialmente por el cliente,llevando a cabo el proceso paso a paso sin dejar de lado pequeños aspectos que rodearon su elaboración, de igual manera establecer cada una de las figuras que hicieron parte de el proceso como son :
los programas utilizados
herramientas didácticas
ejemplos existentes
cronograma de tiempo y  actividades 

EBOOK

ebook

fotos diagrama de gantt

herramientas para administracion de datos

Herramientas para la administración de proyectos

El software de administración de proyectos

Es un concepto que describe varios tipos de software, incluyendo programación, asignación de recursos, software de colaboración, comunicación y sistemas de documentación, utilizados para ayudar a organizar un proyecto complejo en diferentes tareas y en un tiempo determinado.

Estas son algunas herramientas para la gestión y administración de proyectos;

1.         ActiveCollab: Quizás sea la mejor opción de gestor de proyectos con herramientas de colaboración para un buen trabajo en equipo y muchas funcionalidades, para trabajar con ilimitados proyectos, equipos de trabajo y clientes. Prueba usarlo con el tema Colab. Disponible en castellano gracias a Minizen, hemos puesto una copia aquí. Actualización 19-09-2007: Han lanzado la versión 1.0 con edición gratis hasta 5 proyectos y después unos precios desorbitados.

2.   PHPCollab: Es ya un veterano de los gestores de proyectos y colaboración para grupos de trabajo, con posibilidad de gestión de permisos, mapas gráficos de progreso de tareas, reportes en pdf, … Llevan años sin actualizar.

3.  DotProject: Esta bastante bien, dispone de soporte para foros, calendarios, seguimiento de proyectos y tareas. Disponible también en castellano. Un gran proyecto que de momento parece descontinuado.

4.  PHProjekt: Dispone de una gran comunidad que programa módulos para aumentar sus funciones, con soporte para wikis, facturas, … Actualización 23-01-2008 (v.Beta 5.3.)

5.  Egroupware: Es una herramienta completa, no me acaba de convencer, pero incluye wiki, calendario, gestión de usuarios, entre otras funciones.

6.  Tuttos: Lo conocía pero nunca llegue a probarlo, parece muy completo y con soporte multilenguaje.

7.  Mantis: Una completa solución para la gestión de grupos de trabajo en proyectos, que también es OpenSource para PHP+Mysql. Actualizado 19-01-2008 (v.1.1.1).

8.  MindQuarry: es otra herramienta de gestión de proyectos totalmente OpenSource y que tiene muy buena pinta. Además dispone de amplia documentación y versiones de pago con soporte. Actualizado 24-10-2007.

9.   Gantt Project: es una aplicación de código libre para la gestión y seguimiento de proyectos bajo Windows, la nueva competencia de productos como Microsoft Project. (Actualizado 13-07-2007).

10.  Project Pier: es un fork de ActiveCollab 0.7.1 que es 100% gratis y open source. (Actualizado 18-02-2008).

11.  TaskDriver: es una solución php para gestion de proyectos y seguimiento de grupos de trabajo. Disponible la versión 1.3 y la 2.0 beta privada.

12.  Thetis: es un gestor de proyectos y grupos hecho en Ruby on Rails, disponible en inglés y chino.

13.  Redmine: es un gestor de proyectos flexible basado en web y desarrollado en Ruby on Rails, que dispone de muchas funcionalidades y no tiene nada que envidiar a otros desarrollados en php. Disponible en castellano. Última versión de 18-12-2007 (v.0.6.3).

14.  Zimbra: es un paquete de colaboración que dispone de una versión de código abierto, soporta correo, calendarios, y funciones de arrastrar y soltar, entre otras muchas. Además está disponible en múltiples idiomas y es compatible con Outlook, Evolution, Apple y dispositivos móviles.

NORMALIZACION DE BASE DE DATOS

Qué es la normalización 

Normalización es un conjunto de reglas que sirven para ayudar a los diseñadores a desarrollar un esquema que minimice los problemas de lógica. Cada regla está basada en la que le antecede. La normalización se adoptó porque el viejo estilo de poner todos los datos en un solo lugar, como un archivo o una tabla de la base de datos, era ineficiente y conducía a errores de lógica cuando se trataba de manipular los datos. Por ejemplo, vea la base de datos MiTienda. Si almacena todos los datos en la tabla Clientes, ésta podría verse como se muestra a continuación: 
Clientes 
ID_Cliente Nombre 
Apellidos 
Nombre_Producto1 Costo_Producto1 
Imagen_Producto1 Nombre_Producto2 Costo_Producto2 
Imagen_Producto2 Fecha_Pedido 
Cantidad_Pedido 
Nombre_Cia_Envios 

Siempre que un analista de sistemas de base de datos arma una base de datos, queda a su cargo descomponer dicha base en grupos y segmentos deregistros. Este proceso es la descomposición; el mismo es necesario independientemente de la arquitectura de la base de datos - relacional, red o jerárquica-. Sin embargo, para la base de datos relacional, la acción correspondiente puede dividirse y expresarse en términos formales y se denominanormalización a la misma.

La normalización convierte una relación en varias sub-relaciones, cada una de las cuales obedece a reglas. Estas reglas se describen en términos de dependencia. Una vez que hayamos examinado las distintas formas de dependencia, encontraremos procedimientos a aplicar a las relaciones de modo tal que las mismas puedan descomponerse de acuerdo a la dependencia que prevalece. Esto no llevará indefectiblemente a formar varias subrelaciones a partir de la única relación preexistente.

 NORMAS

·         Primera forma normal

Para que una relación esté en primera forma normal (1 FN), debe ser solamente una relación propia, una matriz m por n, donde:

• Ninguna celda de la matriz está vacía;

• El valor n cualquier columna está definido por el dominio para dicho atributo.

• Cada tupla tiene una clave que la identifica en forma unívoca, pero dicha clave no significa orden.

La aplicación determina la relación

Para que una relación sea normalizada en pasos adicionales, debe encontrarse en la primera forma normal. Colocar los datos en la primera forma normal está a cargo del diseñador de la aplicación. Estos datos se encuentran disponibles de alguna manera inicialmente. Si la aplicación existe en forma manual, o ha sido anteriormente computarizada pero no todavía como relación, el diseñador reorganiza los datos de modo de conformar una matríz 1FN.

La segunda inicial más importante es la dimensión de la relación ¿cuántos componentes existen en la tupla o cuántas columnas en la tabla? ¿De qué manera se compara esto con el número de campos en el documento fuente?.

En la figura se puede observar un documento como muestra, una factura típica. Parte de la información es fija y otra variable. La figura nos muestra un formulario impreso dentro de l cual se ha agregado información. La impresión puede dividirse en dos categorías.

• Información descriptiva para el usuario

• Nombres de atributos.

La información impresa es necesariamente fija. Podemos observar el nombre de la compañía en la figura, así como otras particularidades (tales como el número de teléfono que no figura aquí). Otros nombres impresos corresponden a los atributos cuyos valores se escriben en el momento en que el formulario es llenado. Estos nombres de atributos son también los nombres de campos para almacenar los datos en el sistema. Los que se escribe son los valores de atributos.

La información convertida queda formada en tuplas. La próxima pregunta es cuantas tuplas representarán a la formación en esta forma. Debe notarse que el número de partes ordenadas varía de una factura o pedido a otro.

·         Segunda Forma Normal

Una relación está en segunda forma normal (2FN) solamente si todos los atributos son dependientes en forma completa de la clave.

Descripcion De La Segunda Forma Normal (2 Fn)

Su nombre ya nos indica el hecho de que la segunda forma normal es por lo general el próximo paso de normalización y descomposición. Para ser accesible a la normalización, y poder ser puesta en segunda forma normal, la relación debe poseer las siguientes propiedades:

• Debe estar en primera forma normal

• Debe tener una clave compuesta.

La consecuencia inmediata de los requerimientos expresados más arriba es que cualquier relación en primera forma normal que tiene una clave simple, está automáticamente en segunda forma normal. Comencemos con un ejemplo en forma de tabla de una relación consistente en 17 atributos, que se presenta en la figura. La misma se encuentra en primera forma normal y tiene una clave compuesta que consiste en dos atributos P y Q. Estos están subrayados en la figura para mostrar que sirven como clave. La tupla de relación puede también escribirse linealmente en forma simbólicamente:

R = (A,B,C,D,E,F,G,H,I,L,M,N,O,P,Q)

El próximo paso es crear un grafo de dependencia, presentando aquí como figura. Debe notarse que este grafo se crea examinado con conocimientos y atributos para determinar como participan y relacionan entre ellos.

No resulta suficiente analizar la matríz de relación, la cual puede hacernos creer que existe una dependencia debido a que la muestra de la cual se ha extraído dicha relación es pequeña. Si somos inducidos a error por los datos existentes y construimos una dependencia donde esta no existe, se planteará un problema. Cuando lleguen nuevos datos que contradigan la dependencia, deberá dejarse de lado el esquema completo.

Supongamos en consecuencia que el grafo que se puede observar en la figura ha sido derivado en forma funcional y que expresa correctamente las dependencias. Resulta claro a partir de este grafo que los atributos que parten de P son dependientes solamente de este. De un modo similar los que parten de Q dependen solamente de este último. Solamente aquellos que parten de la línea de trazos que conecta a P y Q tienen dependencia completa de ambos. Esta es la guía para la descomposición.

·         Tercera forma normal

Una relación se encuentra en tercera forma normal (EFN) si no existen transitividades entre sus atributos y si ya se encuentra en 2 FN.

Descripción

Una relación R a poner en tercera forma normal debe estar en la segunda forma normal. Es muy común que R sea una sub-relación; la relación original estaba en primera forma normal (para ponerla en segunda forma normal fue descompuesta en varias sub-relaciones). Estas son ahora candidatas a una descomposición adicional.

Recordamos que las propiedades de la segunda forma normal (2Fn) son:

• Tenemos una matríz m x n con un valor determinado para cada componente de cada tupla.

• Cada valor es obtenido a partir de un dominio propiamente definimos

• Cada valor contiene una clave, ya sea simple o compuesta

• Cada componente no clave es dependiente en forma completa de su clave.

En consecuencia es evidente que tenemos, o bien una clave simple, o una clave compuesta de la cual todos los componentes no clave son dependientes en forma completa.

El objeto de esta fase es determinar todas las dependencias transitivas; la descomposición producirá a continuación sub-relaciones para las cuales no existirán dependencias transitivas -la definición de la tercera forma normal (EFN)-.

Una dependencia transitiva abarca como mínimo tres componentes. Si los componentes fueran más, la dependencia múltiple puede derivarse en varias dependencias atransitivas de tres componentes solamente dada una. Por lo tanto dirigiremos nuestra atención a una dependencia transitiva simple de tres componentes. Tal dependencia puede expresarse como:

Q ---> A ----> B

En la cual se dice que B depende de A y que A depende de Q. La transitividad existe debido a que el valor de B depende en la última instancia del valor de Q.

La dependencia transitiva es degenerada si cualquiera de las dependencias anteriores es total. Esto es, podemos prever que la relación de Q a A es muchos-unos, donde varios valor único de A. Dado un valor tal Q el valor de A queda determinado. La inversa no se aplica y en consecuencia no existe una dependencia total: dado un valor de A el valor correspondiente de Q no queda determinado a menos de que se trate de una dependencia total.

·         Cuarta forma normal

Dependencias multivaluadas

La tercera forma normal toma en cuenta la dependencia transitiva y provee una reducción óptima universal, excepto para los casos infrecuentes de dependencia multivaluadas. Ha quedado claro en épocas recientes que es posible una reducción adicional en este caso, y esto es lo que se lleva a cabomediante la cuarta forma normal.

Existe una dependencia multivaluada cuando un valor de una variable está siempre asociado con varios valores de otra u otras variables dependientes que son siempre las mismas y están siempre presentes. Esto se ilustra mejor con el ejemplo presentado en la figura. La relación FAB describe tejidos. La variable independiente (con respecto a las dependencias (multivaluadas) es el número de tejido FABNO. Con el se encuentra asociados un modelo (o patrón) y un color. En la figura, el tejido 345 vienen en dos modelos y entres combinaciones de modelo y color. En este caso se aplica el grafo de dependencia. Para hacer mas clara que esta es una dependencia multivariable, una cabeza doble de flecha apunta desde FABNO o PATRN y también desde FABNO a COLOR.

La ineficiencia en el registro de información y se resulta clara al examinar las dos nuevas relaciones. La primera de éstas, FABPAT lista el número de tejido contra el modelo; en el segundo caso, FABCOL, lista el número de tejido contra las combinaciones de color. Dado que la regla es que todas las combinaciones de las variables dependientes multivaluadas deben prevalecer, resulta simple reconstruir la relación FAB a partir de las dos sub-relaciones que resultaron.

Descomposición Para poner una relación o sub-relación en la cuarta forma normal debe poder aplicarse lo siguiente:

• Debe estar en la tercera forma normal.

• Deben existir una o mas multidependencias.

Después de construir el grafo de dependencia, el próximo paso es ejecutar proyecciones utilizando la variable independiente y una de las variables multidependientes.

FABPAT = proyectar FAB (FABNO, PATRN)

FABCOL = proyectar FAB (FABNO, COLOR)

El resultado son nuevas sub-relaciones que han sido utilizadas para ahorra espacio y permitir una más fácil actualización.

Ejemplo de profesor y texto

Consideremos otro ejemplo. Los cursos dictados en una escuela corresponden a un número de curso. Asociada a cada número de curso se encuentra ladescripción del mismo. Para cada curso existe una selección de textos y una selección de profesores. Puede darse cualquier combinación de texto yprofesor.

El grafo de dependencia. El mismo nos muestra una dependencia total entre el número de curso y la descripción del curso. Existe una multidependencia entre texto y número de curso, y también entre profesor y número de curso.

Para descomponer la sub-relación en sus relaciones más pequeñas, se efectúan tres proyecciones. Las sub-relaciones resultantes.