Diseño de Software: octubre 2013

Requerimientos

Definición

Los requerimientos son una especificación de lo que debe ser implementado. Estos son descripciones de cómo el sistema se debe comportar, de las propiedades y atributos del mismo. Deben ser una restricción del proceso de desarrollo del sistema Sommerville and Sawyer, 1997

Una condición o capacidad que un usuario necesita para resolver un problema o alcanzar un objetivo.

Una capacidad o condición que debe poseer el sistema o los componentes del sistema para satisfacer un contrato, estándar, especificación, u otro documento formalmente impuesto.

Una representación documentada de una condición o capacidad documentada como las descritas en (1) y (2).

Estándar de la Terminología de la Ingeniería de Software de la IEEE,1997.

Características de un buen requerimiento.

Escrito en forma de “Debe”
Correcto
Realizable
Necesario
Priorizable
No Ambiguo
Verificable
Traceable (Puede Seguirse)
Independiente del Diseño
Identificador único
Necesario
Conciso
Consistente (No en conflicto con otros)
No Repetido
Localizado (en un componente o elemento del sistema)

Requerimientos funcionales.

Son declaraciones de los servicios que debe proporcionar el sistema, de la manera en que debe reaccionar ante entradas particulares y de cómo se debe comportar en situaciones particulares. En algunos casos los requerimientos funcionales de los sistemas también pueden declarar explícitamente lo que el sistema no debe hacer. Sommerville, 2005

Ejemplos de requerimiento funcional correcto

El sistema debe contar con un mecanismo de seguridad conformado por nombre de usuario, contraseña y un campo de verificación que aplica la prueba de Turing inversa.
El sistema deber permitir almacenar artículos en una base de datos relacional.

Los requerimientos anteriores son claros y expresan en forma correcta los deseos del cliente.
Ejemplos de requerimiento funcional incorrecto

El sistema debe contar con un mecanismo que provea gran seguridad.
El sistema debe permitir almacenar algunos datos importantes

Los requerimientos son incorrectos porque en el numero 1 la palabra gran no es explicita y puede prestarse para varias interpretaciones presenta ambigüedad. En el requerimiento 2 algunos no es un cuantificador valido y también se presta para interpretaciones variadas además no dice en ningún momento donde deben almacenarse los datos en cuestión.

Requerimientos no funcionales

Los requerimientos no funcionales como su nombre lo indica no se centran en las funcionalidades especificas del software o lo que debe hacer, estos se ocupan de propiedades emergentes del software como la fiabilidad, tiempos de respuesta, apariencia, capacidad de almacenamiento, etc.
No por lo anterior se deben subestimar este tipo de requerimientos un error frecuente dado que son igual y en algunos casos más importantes que los mismos requerimientos funcionales en el sentido de que si un programa es capaz de cumplir a la perfección con todos los cómputos para los que fue creado y tiene una interfaz de usuario inaccesible quedara en desuso.

Algunos ejemplos de requerimientos no funcionales, requerimientos de:

Eficiencia.
Usabilidad.
Rendimiento.
Espacio
Fiabilidad.
Portabilidad.
Implementación.
Uso de estándares.
Interoperabilidad.
Éticos.
De ley
De privacidad
De seguridad

Problemas frecuentes

Difíciles de Recolectar
Imposibilidad de Rastrear el cambio
Difíciles de Escribir
Demasiada forma, poco contenido
Falta de organización

El siguiente Link lo llevara a la platilla de IEEE 830 para documentar requerimientos.

IEEE 830 PDF

Crisis del software

Introducción.

La crisis del software fue un término utilizado los años 70, para expresar las dificultades del desarrollo de software, frente al vertiginoso incremento de la demanda por software, las complejidades de los problemas a resolver y de la inexistencia de técnicas establecidas para el desarrollo de sistemas que funcionaran adecuadamente o pudieran ser validadas. En dicho momento la ingeniería de software era incipiente.

En primera instancia el término crisis del software fue utilizado por el científico de la computación holandés y ganador del premio TURING, Edsger Dijkstra. Sin embargo se adjudica a F. L. Bauer, el término se acuño en 1968 en la primera conferencia organizada por la OTAN sobre desarrollo de software. En la misma conferencia se utilizó por primera vez el término "ingeniería del software".

Síntomas.

Sobre costos (No se respetan los presupuestos).
Incumplimiento (No se entrega el software a tiempo);
Software que no cubre los requerimientos.
Software de baja calidad.
Dificultad para mantener mejorar o modificar proyectos de software.

Conoce algún proyecto de software actual con los anteriores problemas? Cualquier parecido con la realidad es pura coincidencia! La siguiente imagen representa un poco mejor la realidad.

Reflexión.

De algún modo si se observa lo citado anteriormente se puede evidenciar que muchos proyectos de software actuales, aun continúan teniendo comportamientos que se pueden asociar a la crisis del software ya identificada en la década de los 60, lo que suscita la pregunta ¿Cómo hacer frente a la crisis del software?

La pregunta anterior no tiene una única solución, si se hace la analogía con un humano enfermo, la mayoría de enfermedades requieren recetas que incluyen varios medicamentos, para atacar sus síntomas. En dicho sentido se puede hacer otra analogía “Si la crisis del software es la enfermedad, la ingeniería de software es la medicina”.

Introdución al análisis y diseño.

Les quiero dar la bienvenida a este Blog que tiene como fin publicar algunos apuntes sobre diseño de software. Esencialmente el blog se enfoca en modelado desde los conceptos más básicos y como estos modelos pueden llevarse a una implementación.

Para empezar quiero hacer una introducción al análisis y diseño orientado a objetos.

Análisis y diseño OO.

Introducción.

En los modelos de procesos del software como el modelo en cascada, desarrollo evolutivo, desarrollo en espiral y en modelos iterativos, las etapas de análisis y diseño son consideradas como los dos primeros pasos para abordar un proyecto software, sin embargo en muchos modelos denominados agiles se enfocan menos esfuerzos en el análisis y diseño detallado destinando más esfuerzo y tiempo en la codificación y pruebas, lo que ha despertado una discusión interesante a partir de si es importante o no tener un diseño detallado que requiere mucho tiempo y esfuerzo, en este sitio no se pretende tomar una postura en la discusión, solo se ilustran algunos conceptos basicos.

En la figura se ilustran las etapas del modelo en cascada y sobresalen en color rojo las etapas de análisis y diseño.

Como su nombre lo indica el análisis y diseño OO, están fuertemente relacionado con la programación OO, en el pasado y aun en algunos sistemas de actuales se usa el modelo estructurado y se hablaba de análisis y diseño estructurado. El análisis y diseño OO, están destinados a ofrecer mecanismos que permitan abordar un proyecto software cualesquiera independiente del lenguaje de implementación siempre y cuando se ajuste al paradigma objeto.

Análisis OO.

El análisis OO comprende el desarrollo de un modelo OO del dominio de la aplicación. Los objetos identificados reflejan las entidades y operaciones que se asocian con el problema a resolver.

Sommerville, 2005

Típicamente el análisis OO se enfoca en los requerimientos y las actividades que tienen que ver con ellos tales como el levantamiento (recolección), análisis, especificación, validación y control de cambios.

Diseño OO.

El diseño orientado a objetos comprende el desarrollo de un modelo OO de un sistema de software para implementar los requerimientos identificados. Los objetos en un diseño OO están relacionados con la solución del problema por resolver. Pueden existir relaciones estrechas entre muchos objetos del problema y algunos objetos de la solución, pero inevitablemente el diseñador tiene agregar nuevos objetos para transformar los objetos del problema e implementar la solución.