ERS

El ERS o Especificación de Requerimientos de Software es un documento que va dirigido tanto a clientes como al equipo encargado del desarrollo de software, debe de estar escrito en un lenguaje de fácil entendimiento para ambas partes, su principal objetivo es  que pretende describir completamente el comportamiento de un sistema que se piensa desarrollar. En él se incluyen casos de uso o requisitos funcionales que describen o explican las interacciones entre usuarios y el software, además de los requisitos funcionales se encuentran también los requisitos no funcionales, éstos son los que dan las restricciones de diseño o implementación en el software.

Las características para un buen documento ERS son definidas por el estándar IEEE 830-1998, que son:

• Completo: Todos los requerimientos deben estar reflejados y todas las referencias  bien definidas.
• Consistente: Debe ser coherente con los propios requerimientos y también con otros documentos de especificación.
• Inequívoco: La redacción debe ser clara de modo que no haya ambigüedad.
• Correcto: El software debe cumplir con los requisitos de la especificación.
• Trazable: Posibilidad de verificar la historia, ubicación o aplicación de un requerimiento a través de su identificación almacenada y documentada.
• Priorizable: Los requisitos deben organizarse jerarquicamente según la importancia para el negocio.
• Modificable: Debe ser fácilmente modificable.
• Verificable: Debe existir un método finito sin costo para poder probarlo.

Aunque existen muchas plantillas para crear un ERS, se debe de escoger la que mas se ajuste al proyecto que se desea implementar ya que no todas cubren la misma cantidad de campos del ERS y algunas se enfocan más en un sector especifico. 

https://www.ctr.unican.es/asignaturas/is1/IEEE830_esp.pdf

Proceso de Ingeniería de Requisitos

En la Ingeniería de Software, la Ingeniería de Requisitos,  comprende las tareas relacionadas con la obtención de las necesidades o de las condiciones para la elaboración o modificación de un software, ésto tomando en cuenta los diversos requerimientos de las partes interesadas. El propósito de ésta, es hacer que los requerimientos o requisitos sean óptimos antes de llegar al diseño del sistema. La ingeniería de requisitos tienen como objetivo:

• Definir las características de un sistema de software que satisfaga las necesidades de negocio de clientes y usuarios.
• Gestionar las lineas base y las peticiones de cambios que se vayan produciendo en la especificación de requisitos.

Éste proceso, como se muestra en la anterior imagen, comprende cuatro actividades de alto nivel:

1. Estudio de factibilidad 
2. Obtención y análisis de requerimientos
3. Especificación de requerimientos
4. Validación de requerimientos

1- Estudio de factibilidad: es de corto plazo y está orientado a resolver si el sistema:

• Contribuye a los objetivos de la organización
• Se puede implementar con tecnología actual dentro del tiempo y costo establecido
• Puede integrarse a otros sistemas existentes en la organización

2- Obtención y análisis de requerimientos: es un proceso difícil ya que:

• Los interesados no conocen con exactitud qué es lo que desean, solo saben términos muy generales
• Los interesados explican los requerimientos con sus propios términos utilizando lenguaje de su propio trabajo que el analista quizás no conoce
• El entorno es dinámico, puede cambiar la importancia de los requerimientos, pueden aparecer nuevos requerimientos.

Durante el proceso se deben realizar las siguientes actividades:

• Comprensión del dominio
• Recolección de requerimientos
• Clasificación de los requerimientos
• Resolución de conflictos
• Priorizar los requerimientos importantes
• Verificación de los requerimientos (completos, consistentes y acordes)

3- Especificación de requerimientos: en ésta etapa se describen los requerimientos que tanto el cliente como el contratista crean necesarios para el software. Algunos puntos importantes son:

• Los requerimientos de sistemas grandes son siempre cambiantes
• Surgirán nuevos requerimientos debido a:
• Comunidad de usuarios diversos
• El que paga es raramente el que utiliza el sistema
• Entorno de negocios y técnico cambiante

4- Validación de requerimientos

• Es similar al análisis pero con un bosquejo completo del documento en lugar de requerimientos incompletos
• Es importante porque los errores en los requerimientos pueden inducir a costos excesivos si se descubren durante el desarrollo o después de la implementación
• Es difícil demostrar que un conjunto de requerimientos cumplen con las necesidades del usuario desde la primera vez que se describen.

En esta etapa se deben llevar a cabo diferentes tipos de verificación:

• Verificación de validez
• Verificación de consistencia
• Verificación de integridad
• Verificación de realismo

Algunas técnicas para la verificación de requerimientos son:

• Revisiones de requerimientos con el cliente
• Construcción de prototipos
• Generación de casos de prueba
• Análisis de consistencia automático

4.1- Revisiones de requerimientos

• Proceso manual que involucra a varios lectores tanto del cliente como del contratista
• Puede ser formal o informal
• Los conflictos, contradicciones, errores y omisiones deben señalarse durante la revisión y registrarse formalmente

Durante éstas revisiones se comprueba:

• Consistencia
• Integridad
• Verificabilidad
• Comprensibilidad
• Rastreabilidad
• Adaptabilidad

El proceso de obtención de requisitos es un poco complicado según el cliente y el software que se desee desarrollar, ya que no siempre los clientes tienen claro qué es lo que desean, sino que dan ideas de lo que le gustaría tener, es por ésto que muchas veces se deben de cambiar los requerimientos incluso después de haber empezado el desarrollo del sistema, por esa razón se debe tomar en cuenta el tipo de cliente y el sistema que éste desea e intentar descifrar correctamente qué es lo que él desea con tal de evitar la mayor cantidad de cambios.

Indefinido. (2013). ¿Requisitos o Requerimientos?. noviembre 2, 2013, de Investigación IT Sitio web: http://web.archive.org/web/20160310011046/http://investigacionit.com.ar/es/requisitos-o-requerimientos/

http://www.juntadeandalucia.es/servicios/madeja/contenido/subsistemas/ingenieria/ingenieria-requisitos

Modelos de desarrollo de Software

En la actualidad existen varios tipos de modelos para el desarrollo de software, éstos no representan exactamente cómo debe de desarrollarse el software, sino que son una representación abstracta de una manera en particular. Gracias a estos modelos es mucho mas sencillo poder desarrollar software, ya que se pueden modificar y adaptar de acuerdo a las necesidades que tenga el software que se desea desarrollar. Antes del desarrollo del proyecto se debería de elegir el modelo que se desea implementar ya que cada uno cuenta con ventajas y desventajas, en algunas ocasiones se puede elegir una combinación de los modelos para un mejor desarrollo. Existen tres paradigmas de los modelos de desarrollo de software:

1. Paradigma Tradicional: Es uno de los mas antiguos, se invento con la creación del método estructurado, al elegir un proyecto, éste varia en etapas, hay que tener en cuenta que uno de los mayores problemas de este paradigma es que las etapas no son independientes una de otra, creando así una dependencia estructural. Algunos pros y contras son: 
2. Paradigma Orientado a Objetos: Estos modelos se basan en la programación orientada a objetos, por eso se refieren al concepto de clase, análisis de requisitos y diseño. Algunas características son: 
• Permite la reutilización de software.
• Facilita el desarrollo de herramientas informáticas de apoyo al desarrollo.
3. Paradigma de Desarrollo Ágil: Está basado en procesos ágiles. Éstos intentan evitar los tediosos caminos de las metodologías tradicionales, enfocándose en las personas y los resultados.

Entre los modelos de desarrollo de software se encuentran:

-Modelo Lineal Secuencial o Cascada: Es un proceso secuencial de desarrollo en el que los pasos a realizar son ejecutados hacia abajo como en una cascada, cabe resaltar que en caso de que exista algún problema en algún paso, se deberá empezar nuevamente con la primera etapa de análisis, cada etapa es independiente una de otra y no se pueden realizar de manera simultanea por ésta razón el modelo de cascada es uno de los mas caros de realizar, un error puede realizar perdidas de tiempo y dinero a las personas.

- Modelo de Prototipos: Éste permite realizar modelos de aplicaciones de software que permitan ver la funcionalidad básica de la misma, sin tener que incluir toda la lógica del modelo terminado. El prototipo permite al cliente evaluar de forma temprana el producto que está adquiriendo e interactuar con desarrolladores y diseñadores para ver si se están cumpliendo las expectativas previstas. Éstos prototipos no poseen la funcionalidad completa del sistema pero conforme vaya avanzando el proyecto, los prototipos irán mas completos en torno a funcionalidad.

- Modelo "Rapid Application Development" (RAD): Es una metodología que implica el desarrollo iterativo y la construcción de prototipos. El objetivo de este modelo es un desarrollo rápido y entrega de una alta calidad en un sistema de un bajo coste de inversión, además parte el proyecto en segmentos pequeños proporcionando una mayor facilidad de cambio durante el proceso de desarrollo. Cabe resaltar que en este modelo es imprescindible la activa participación de los usuarios.

La siguiente imagen podría decirse que resume un poco varios criterios con algunos paradigmas o modelos de desarrollo de software.

Existen muchos modelos para el desarrollo de software y cada uno tiene sus ventajas y desventajas de acuerdo al proyecto que se desea realizar, aunque muchos sean tediosos o complicados de realizar éstos modelos son de gran ayuda para el desarrollo de aplicaciones, basta con entenderlos y escoger el que se adapte mas, además se puede usar más de un modelo con tal de modificar y realizar uno que nos simplifique aun mas el desarrollo de las aplicaciones. La tecnología va avanzando y con ella los modelos de desarrollo de software también, por eso en una época en que todo cuenta (tiempo, dinero, clientes), lo mejor es siempre buscar un modelo que facilite el desarrollo y mantenga al cliente al tanto de todo lo que sucede con su proyecto.

Sulbaran, H.. (2014). Paradigmas en el desarrollo de software. septiembre 24, 2014, de Blogspot.com Sitio web: https://helisulbaransistemas.blogspot.com/2014/09/paradigmas-en-el-desarrollo-de-software.html