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

Proceso unificado de desarrollo de software

¿Que es el proceso unificado de desarrollo de software?

Pues según Larman: "El proceso unificado de desarrollo de software es un metodología de construcción de software dirigido por casos de uso, iterativo e incrementa".

¿Que significa eso?

Pues primero que todo hay que saber que el proceso unificado, se divide en cuatro etapas inicio, elaboración, construcción y transición, las cuales van repitiéndose o "iterando" y cada repetición que se hace le suma o "incrementa" algo al proyecto, este incremento pude ser mejoras al proyecto o el hecho de agregar funciones a el, en estas etapas se llevar acabo varias disciplinas, las cuales se pueden dar simultáneamente a través de todo el proceso de desarrollo de software (ver imagen 1), las cuales son : análisis de requisitos, diseño, implementación y prueba.

(Imagen 1)

Ademas se dice que es dirigido por casos de uso pues, durante el proceso de desarrollo se van tomando varios casos de uso, y se va creando un camino a través de las distintas disciplinas, una vez finalizado en otra repetición se toma otros casos de uso y se sigue el proceso.

Fuente: wikipedia.org y DAVID GERMAN CHACON ARREDONDO 

Elicitacion de Requerimientos

La elicitacion de requerimientos es una da las actividades mas importantes de la ingeniería en requerimientos, básicamente se trata de de tomar toda la información del cliente, interpretarla y convertirla en requerimientos.

Existen varios tipos de métodos para poder realizar esta actividad, cada uno con sus pros y contras, lo mas recomendable al empezar el proceso es escocer una de estas metodologías como modelo pues esto nos ayuda a  seguir un orden secuencial de ideas, que facilita la debida comprensión del producto final.

Crear un programa es todo un proceso y entender lo que el programa debe hacer es la parte mas importante, por lo cual reunir los datos es lo primero que debe hacer un ingeniero de requerimientos, y debe ser lo mas exacto posible porque todo el proyecto dependen de estos dato.

Fuentes: www.ecured.cu y ingenieriaderequerimientos.wordpress.com.

Consejos al escribir documento de Requerimientos

El documento de requerimientos es un documento técnico, por lo que hay que tener varios consideraciones a tomar en cuenta al escribirlo.

El primer punto a tomar en cuenta es la ortografía, el autocorrector que usa "world" u otro editor de texto pude ser de gran ayuda al crear este tipo de documentos, pero no se debe de confiar mucho en ellos, pues dependiendo de la forma en la que están configurados podrían no mostrar algún tipo de error, lo mas recomendable es, si no se sabe la forma en la que se escribe una palabra hacer una búsqueda en "google" u otro buscador, para encontrar la forma correcta de escribirla, también se puede usar un diccionario si no se tiene acceso a Internet.

Otro aspecto a tener en cuenta es el tiempo de las oraciones y en la persona en la persona en la que se habla, se debe ser consistente en este aspecto en todo el documento, por ejemplo si se habla en primera persona en tiempo presente se debe continuar así durante el resto del documento.

Siguiendo están los los signos de puntuación, si no se sabe el uso correcto de algún signo de puntuación, es muy recomendable estudiarlos antes de empezar a escribir el documento, recordar que un documento técnico conlleva cierta seriedad, por lo cual se debe ser especialmente meticuloso con estos detalles.

Antes de empezar a escribir se recomienda ordenar de forma secuencial las ideas, para ello se recomienda seguir una de las varias estructuras que ya existen como guía.

Por ultimo, aunque no es tanto un consejo a la hora de escribir si no al terminar, pedirle a una o varias personas de confianza leer el documento, para ver si es comprensible, antes de entregar el documento, de ser posible intentar que estas personas sepan sobre ortografía y gramática para que puedan ayudar a corregir algún error, también que no estén relacionados con con el área de computación(de ser posible), puesto que un documento de requerimientos se crea pensado en que el lector no posee conocimiento previo del área, de esta forma podemos probar que se puede entender por el cliente.

Fuente: Propia

Características de un buen documento de Especificación de Requerimientos de software (ERS)

Desacuerdo a la IEEE un buen ERS debe ser:

 Correcto: Esto indica que el ERS posee todas las funciones o requisitos necesarios para el programa a crear. No hay una forma de asegurar que el ERS respete esta característica, por lo cual solo se pude mostrarle al usuario o cliente para que revisen si el documento cumple con sus expectativas.

Inequívoco o no ambiguo: Esto significa que todo lo escrito en el ERS tenga una sola forma de ser interpretado o sea, que no se pueda entender de varias formas.

 Completo: Para que un ERS sea completo se debe cumplir con tres elementos los cuales son:

            *Poseer todos los requisitos funcionales y no funcionales a seguir.

*La forma que se comportara el sistema ante cualquier situación que se le presente.

*Tener todas las figuras y diagramas referenciadas y con un índice.

Consistente: El ERS no debe poseer ningún tipo de contradicción, por ejemplo no pude haber un  requerimiento que diga “al introducir un numero de cédula, retornar el nombre” y otro que diga “al  introducir un numero de cédula, retornar el apellido” al mismo tiempo (esto suponiendo que el  número de cédula, no se está introduciendo en distintos lugares).

Delinear que tiene importancia y/o estabilidad: Esto significa que los requerimientos del ERS, deben indicar que tan importante y/o estables son, en pocas palabras indicar que tan importante es ese requerimiento para el programa, o que tan posible es que ese requerimiento cambie o sea completamente eliminado del proyecto.

Comprobable: Significa que hay una forma posible, para una maquina o persona, de verificar la valides de cada requisito. Todo requisito ambiguo es considerado no comprobable.

Modificable: Esta característica nos dice que un ERS debe poder modificarse sin cambiar su estructura o estilo, o sea en caso de requerir un cambio este pueda realizarse fácilmente sin tener que cambiar todo el documento.

 Identificable: Que todos los requisitos son entendibles y están bien referenciados.

Fuente: www.ctr.unican.es

¿Qué es la Ingeniería de Requerimientos?

La ingeniería de software es una de las partes más importantes y menos apreciadas del diseño de un programa, esta disciplina está basada en establecer todas las condiciones que debe cumplir un programa para satisfacer a todas las partes interesadas (usuario y cliente), para así poder pasar a la etapa de diseño teniendo una idea exacta de lo que se necesita crear. A este documento, que incluye estas especificaciones, es al que llamamos requerimientos.

¿Por qué son tan importantes los requerimientos?  

La razón más grande de porque son tan importante los requerimientos, es por el costo que conlleva repararlos errores de un programa,  puesto que es más fácil modificar un proyecto que está en la etapa de alzar requerimientos, que uno que se encuentra ya  en una etapa de diseño o posterior (el costo puede ser de 10 a 100 veces superior). Esto quiere decir que para evitar un mayor costo en un proyecto es mejor hacer todas las modificaciones, cambios o correcciones al estar levantando los requerimientos.

Desacuerdo al Centro de Estudio de Ingeniería de Software (CEIS), un 57% de los errores causados en un proyecto de diseño de software se dan dentro de la etapa de requerimientos, mientras que en el diseño y programación son solo de un 27% y 7% respectivamente (ver gráfica 1).

(Gráfica 1)

Por lo cual tanto la ingeniería de requisitos que se encarga de este documento (requisitos) tan importante se le debería dar  mayor importancia de la que recibe actualmente, pero con el paso del tiempo y el crecimiento constante de la importancia del software en el mundo, es muy posible que esta rama vaya siendo más reconocida, des pues de todo esta rama tanto como la ingeniería de software en si siguen conceptos relativamente nuevos.

Fuente: CEIS