Consejo para hacer requerimientos

En el pasado he dado consejos para crear un documento de requerimientos, pero en esta ocasiona nos vamos a centrar únicamente en la creación de requerimientos.

Vamos a hablar del método, que he encontrado mas útil para la creación de requerimientos, dentro de un grupo de trabajo.

Paso 1: Escoger una plantilla para para los requerimientos, al hacer esto facilita poder trabajar con un equipo pues todos hacen su trabajo siguiendo un formato establecido. Al escoger la plantilla se debe de asegurar que la escogida tenga todo lo necesario para el proyecto en cuestión, también es valido tomar una plantilla ya hecha y modificara.

Paso 2: Escoger llaves o palabras claves, antes de empezar a elaborar los requerimientos,  se deben estable ser los valores validos en cada espacio, por ejemplo:

En el campo "estado" puede ir los valores "en construcción", "sin aprobar", "en edición" y "aprobado".

También se debe definir que significa cada valor en el proyecto.

Paso 3: En listar todas las funciones y limitaciones del programa, incluyendo las mas inestables, básicamente en este paso una vez que se haya hecho el proceso de elicitación, se ponen todos los requisitos funcionales y no funcionales.

Paso 4: Asignar dificultad en una escala numérica, esta parte es muy importante porque en el proceso de documentar los requerimientos, puede haber requerimientos que necesiten mucho mas tiempo que otros, por lo cual para poder distribuir equitativamente los requerimientos se les debe asignar dificultad, preferiblemente una numérica.

Paso 5: Crear un prototipo a grandes rasgos, esto puede ser de ayuda para todos los miembros del grupo, pues permite que todos vean como debería ser el programa, se recomienda que todo el grupo este presente en este paso.

Paso 6: Dividir el trabajo con una dificultad total, equitativa (hasta donde sea posible) para todos sus miembros, tomando en cuenta que la dificultad total es igual a la suma de la dificultad de cada requerimiento asignado.

Trabajando de esta forma e encontrado que el trabajo realizado puede ser de buena calidad, sin la necesidad de invertir mucho tiempo.

Fuente: Propia

UML

El UML es un lenguaje gráfico, que sirve para definir un sistema. El UML básicamente, lo que hace es definir un estándar de como creer un diagrama. El UML es un estándar aprobado por la ISO (International Organization for Standardization /  Organización Internacional de Normalización) desde el 2005.

Los diagramas de UML se dividen en 2 tipos:

 Estructurales: Son los que muestran la parte estructurada del sistema, o sea como esta dividido el programa, cada parte del programa y como se relaciona con las otras partes. Algunos ejemplos de diagramas estructurales pueden ser:

*Diagrama de clases.
*Diagrama de componentes.
*Diagrama de despliegue.
*Diagrama de objetos.
*Diagrama de paquetes.
*Diagrama de perfiles.
*Diagrama de estructura compuesta.

De comportamiento: Los diagramas de comportamiento intentan demostrar los estados por los que pasan los componentes durante la ejecución del sistema, así como la forma en la que responden a ciertos eventos ocurridos en esta ejecución. Algunos ejemplos pueden ser:

*Diagrama de actividades.
*Diagrama de casos de uso.
*Diagrama de máquina de estados.

De interacción: Los diagramas de interacción son un subgrupo de los diagramas de comportamiento, muestran la forma en la que colaboran componentes del sistema dentro de cierto comportamiento. Algunos ejemplos pueden ser:

*Diagrama global de interacciones.
*Diagrama de comunicación.
*Diagrama de secuencia.
*Diagrama de tiempos.

Fuentes: es.wikipedia.org/UML, es.wikipedia.org/ISO, es.slideshare.net/De_Comportamiento, es.slideshare.net/De_interacción

Diagrama de secuencia

En esta entrada hablaremos un poco de los diagramas en secuencia. Los diagramas en secuencia son diagramas que muestran la interacción de una entidad con el programa, en medida de tiempo, osea nos muestra cuanto tiempo esta esa entidad usando el sistema, para ello se utilizan las lineas de vida o tiempos. El diagrama de secuencia también muestra los mensajes enviados a las diferentes entidades.

El diagrama de secuencia consta de tres elementos principales los cuales son:

Objetos (entidades): los objetos son elementos que interactúan con el sistema (personas o módulos), son representados con rectángulos, con su nombre adentro normalmente subrayado y son posicionados en la parte superior del diagrama (ver imagen 1).

Linea de vida o tiempo: El tiempo es cuando un elemento usa el sistema, se representa con una linea vertical cuando el elemento no usa el sistema y se convierte en un rectángulo vertical de poca anchura cuando el elemento si usa el sistema, esta linea se ubica justo debajo del elemento al que representa la linea de tiempo (ver imagen 1).

Mensaje: Un mensaje es una transferencia de control de un elemento a otro, osea es un indicador de un elemento que le dice a otro que actué mientras el espera una respuesta, se representa con una flecha y esa ubicado entre las lineas de vida de los elementos (ver imagen 1).

  (Imagen 1)

Fuentes: wikipedia.org y slideshare.net

Modelo entidad-relación

En esta entrada vamos a hablar del modelo de entidad-relación, este modelo nos permite modelar datos tomando en cuenta sus relaciones con otros datos, es decir este modelo nos permite crear diagramas que reflejan la forma en la que van a interactuar los datos de un sistema de computación.

Los diagramas generados son muy usualmente usados, para la creación de bases de datos, por la forma en la que su diseño permite un fácil entendimiento de como se mueven los datos, sin embarco, los diagramas de entidad relación no son creados para crear bases de datos, sino, que las bases de datos se crean para adecuarse al diagrama.

El diagrama cuenta con varios elementos:

Entidades: Una entidad es un elemento que posee atributos y pude ser diferenciado de otros dentro de un sistema, osea que es un ser único, pero esto no significa que todos sus atributos son diferentes de elementos que también sean parte de esa entidad, por ejemplo si tengo una entidad persona y cada elemento de esa entidad tienen un nombre y cédula, dos elementos de esa entidad pueden tener el mismo nombre. Dentro del diagrama se representa con un rectángulo (ver imagen 1).

Atributos: El los atributos son características que definen a una entidad, en el caso de la entidad persona sus atributos podrían ser cédula y nombre. entro del diagrama se representan con un ovalo (ver imagen 1).

Relaciones: Las relaciones son elementos que indican cual entidad se relaciona con cual y cual es esa relación, también puede indicar la cardinalidad de la relación, osea la cantidad de cuantos se relacionan con cuantos, por ejemplo pude haber una relación de una entidad empresa y otra empleado que sea: "una empresa posee varios empleados". Dentro del diagrama se representa con un rombo (ver imagen 1).

(Imagen 1)

Fuente: es.wikipedia.org

Aseguramiento de la Calidad de Software

En esta entrada vamos a hablar sobre lo que es aseguramiento de la calidad de software, lo cual en términos simples se podría resumir en, técnicas usados durante la creación de un programa para asegurar que este cumpla con los estándares de calidad esperado. Dichas técnicas se aplican antes del desarrollo del software.

El aseguramiento de la calidad es muy importante por razones muy simples (no solo aplicable en el desarrollo de software), como que se pude confiar mas en el producto creado, es decir que el producto final cumpla con todas las expectativas del cliente (que el cliente reciba de el todo lo que originalmente esperaba de el).

Para asegurar de que se pueda asegurar la calidad del software existen grupos de SQA (Software quality assurance)  cuyo trabajo consiste en evaluar, revisar y supervisar el desarrollo del software para asegurar el cumplimiento de estándares y definir estándares que se puedan usar, informar y dar seguimiento a errores, generar realimentacion a información proporcionada al equipo de proyecto de software, entre otras responsabilidades.

El asegura miento de la calidad dentro del entorno de la creación de software, nos permite crear una garantía a nuestros clientes, de que cada pieza del programa a sido revisado con cautela, puesto que el diseño de programas o aplicaciones es algo intangible hasta en sus ultimas etapas estas garantías son muy importantes.

Fuentes: es.slideshare.net, en.wikipedia.org y dankocs2012.blogspot.com

Requerimientos duraderos y volátiles

Dentro de una especificación de requerimientos, nos podemos encontrar con dos tipos de requerimientos los volátiles y los duraderos. Esta clasificación nos permite saber cuales requisitos son de mayor importancia.

Duraderos o Estable
Lo requerimientos duraderos son aquellos que tienen baja posibilidad de ser cambiados en el transcurso del proyecto, y en caso de hacerlo es muy probable que haya que cambiar casi todo el programa. Estos requerimientos son la actividades principales e indispensables de la aplicación o programa.

Volátiles
Son básicamente el opuesto de los requerimientos, osea los requerimientos con mayor probabilidad de cambiar, pueden ser requerimientos que cumplan con funcionalidades extra o innecesarias, para el correcto funcionamiento del programa.

Fuente: scribd.com

Prototipos

¿Que es un prototipo?

Un prototipo es algo parecido a la primera versión de un producto final, es una muestra de como quedara el producto o parte del producto.

¿De que nos sirven los prototipos?

Los prototipos nos ayuda a darle una idea al cliente de como quedara el producto final, ademas de poder escuchar las opiniones de el y corregir cosas con las que el cliente no este satisfecho, así previniendo invertir recursos en un producto que el cliente no quiera. Se recomendaría ir actualizando el prototipo para que el cliente vaya viendo la evolución de este, de forma que se genere un ciclo hasta finalizar el producto, quesea: se habla con el cliente  y recolecta información, se genera un plan para resolver los problemas que haya que resolver, se hace todo el diseño, se elabora el prototipo, se enseña al cliente y de el se reúne información para volver al paso uno hasta que el cliente este satisfecho (ver imagen 1).

(Imagen 1)

Por ultimo esta ver como funcionan los prototipos en nuestro tema principal, los requerimientos de software, pues muy sencillamente una vez que tenemos los requerimientos diseñamos el prototipo en base a ellos y una vez que recibimos las opiniones del cliente, actualizamos los requerimientos con base a ello (en el caso de que el cambio sea funcional) y re-diseñamos el prototipo, asegurándonos de que vaya de la mano con los requerimientos.

Fuente: www.mindomo.com