1.

REQUERIMIENTOS NO FUNCIONALES (CARLOS LOBO)

Requerimientos no funcionales. Son restricciones de los servicios o funciones ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo y estndares. Los requerimientos no funcionales a menudo se aplican al sistema en su totalidad. Normalmente apenas se aplican a caractersticas o servicios individuales del sistema. Los requerimientos no funcionales, como su nombre sugiere, son aquellos requerimientos que no se refieren directamente a las funciones especficas que proporciona el sistema, sino a las propiedades emergentes de ste como la fiabilidad, el tiempo de respuesta y la capacidad de almacenamiento. De forma alternativa, definen las restricciones del sistema como la capacidad de los dispositivos de entrada/salida y las representaciones de datos que se utilizan en las interfaces del sistema. Los requerimientos no funcionales rara vez se asocian con caractersticas particulares del sistema. Ms bien, estos requerimientos especifican o restringen las propiedades emergentes del sistema. Por lo tanto, pueden especificar el rendimiento del sistema, la proteccin, la disponibilidad, y otras propiedades emergentes. Esto significa que a menudo son ms crticos que los requerimientos funcionales particulares. Los usuarios del sistema normalmente pueden encontrar formas de trabajar alrededor de una funcin del sistema que realmente no cumple sus necesidades. Sin embargo el incumplimiento de un requerimiento no funcional puede significar que el sistema entero sea inutilizable. Por ejemplo, si un sistema de vuelo no cumple sus requerimientos de fiabilidad, no se certificar como seguro para el funcionamiento; si un sistema de control de tiempo real no cumple sus requerimientos de rendimiento, las funciones de control no funcionarn correctamente. Los requerimientos no funcionales no slo se refieren al sistema software a desarrollar. Algunos de estos requerimientos pueden restringir el proceso que se debe utilizar para desarrollar el sistema. Ejemplos de requerimientos de procesos son la especificacin de los estndares de calidad que se deben utilizar en el proceso, una especificacin que el diseo debe producir con una herramienta CASE particular y una descripcin del proceso a seguir. Los requerimientos no funcionales surgen de las necesidades del usuario, debido a las restricciones en el presupuesto, a las polticas de la organizacin, a la necesidad de interoperabilidad con otros sistemas software o hardware, o a factores externos como regulaciones de seguridad o legislaciones sobre privacidad. La Figura 6.3 es una clasificaci6n de los requerimientos no funcionales. Puede verse en este diagrama que los requerimientos no funcionales pueden venir de las caractersticas requeridas del software

(requerimientos del producto), de la organizacin que desarrolla el software (requerimientos organizacionales) o de fuentes externas. 2. CLASIFICACIN DE LOS REQUERIMIENTOS NO FUNCIONALES (CARLOS BARRIOS)

Requerimientos del producto. Estos requerimientos especifican el comportamiento del producto. Algunos ejemplos son los requerimientos de rendimiento en la rapidez o eficiencia de ejecucin del sistema y cunta memoria se requiere; los requerimientos de fiabilidad que fijan la tasa de fallos para que el sistema sea aceptable; los requerimientos de portabilidad, y los requerimientos de usabilidad. Requerimientos organizacionales. Estos requerimientos se derivan de polticas y procedimientos existentes en la organizacin del cliente y en la del desarrollador. Algunos ejemplos son los estndares en los procesos que deben utilizarse; los requerimientos de implementacin. Como los lenguajes de programacin o el mtodo de diseo a utilizar, y los requerimientos de entrega que especifican cundo se entregar el producto y su documentacin. Requerimientos externos. Este gran apartado incluye todos los requerimientos que se derivan de los factores externos al sistema y de su proceso de desarrollo. stos pueden incluir los requerimientos de interoperabilidad que definen la manera en que el sistema interacta con sistemas de otras organizaciones; los requerimientos legislativos que deben seguirse para asegurar

que el sistema funcione dentro de la ley. Y los requerimientos ticos. Estos ltimos son puestos en un sistema para asegurar que ser aceptado por sus usuarios y por el pblico en general.

3.

CALIDAD DE SOFTWARE (ILBER) Es el desarrollo de software basado en estndares con la funcionalidad y rendimiento total

que satisfacen los requerimientos del cliente. Tambin se define como procesos de desarrollo, gestin de proyectos, anlisis y diseo, especificacin de requerimientos, arquitectura, son solo algunos de los componentes que se aglomeran para conformar la ingeniera de software (IS) como disciplina para la creacin y mantenimiento de software. Dentro de sta, existe un subconjunto de teoras, herramientas y mtodos orientados a lo que se denomina la calidad del software. Para resumir de alguna manera la amplitud de este concepto, se puede decir que la calidad de software ha sido usada desde un simple argumento de venta, hasta verdaderos estudios formales y usos de mtricas para el desarrollo de software. Extraamente dentro de la IS, la calidad del software es muy complicada de definir y de enmarcar en un simple concepto terico, por lo que en esta nota, me concentrar solo en las diversas caractersticas que permiten describirla y en los elementos que importan especficamente al diseador de software. Una idea general sobre un software de calidad es aquel que debiera cumplir con los requerimientos funcionales y de performance adems de ser mantenible, confiable y aceptable. La calidad del software es el grado con el que un sistema, componente o proceso cumple los requerimientos especificados y las necesidades o expectativas del cliente o usuario. (IEEE, Std. 610-1990). Concordancia del software producido con los requerimientos explcitamente establecidos, con los estndares de desarrollo prefijados y con los requerimientos implcitos no establecidos formalmente, que desea el usuario (Pressman, 1998)

4.

CARACTERISTICAS DE CALIDAD DE UN SOFTWARE (JONATHAN)

Mantenibilidad: el software debe ser diseado de tal manera, que permita ajustarlo a los cambios en los requerimientos del cliente. Esta caracterstica es crucial, debido al inevitable cambio del contexto en el que se desempea un software. Capacidad del producto de ser modificado. Las

modificaciones pueden incluir correcciones, mejoras o adaptacin del software a cambios en el entorno, en requisitos o en especificaciones funcionales. Confiabilidad: incluye varias caractersticas adems de la confiabilidad, como la seguridad, control de fallos, etc. Capacidad del producto software para mantenerse a un nivel especifico de rendimiento cuando es utilizado bajo condiciones especficas. Eficiencia: tiene que ver con el uso eficiente de los recursos que necesita un sistema para su funcionamiento. Capacidad del producto para proporcionar un apropiado rendimiento, relativo al conjunto de recursos utilizados bajo condiciones establecidas. Usabilidad: el software debiera ser utilizado sin un gran esfuerzo por los usuarios para los que fue diseado, documentado, etc. Capacidad del producto de ser entendido, utilizado y ser atractivo al usuario cuando es utilizado bajo condiciones especficas. Funcionalidad Capacidad del producto software de proporcionar funciones que cumplan las necesidades cuando el software es utilizado bajo condiciones especficas. Portabilidad Capacidad del producto software de ser transferido desde un entorno a otro. Como puede observarse, las diversas caractersticas con las que se desea que cumpla un software de calidad varan ampliamente. Algunas tienen que ver con el usuario que interacta con el sistema, otras con el lder de proyecto y diseadores, otras caractersticas parecen muy abstractas y hasta indefinidas, etc. Como puede observarse, las diversas caractersticas con las que se desea que cumpla un software de calidad varan ampliamente. Algunas tienen que ver con el usuario que interacta con el sistema, otras con el lder de proyecto y diseadores, otras caractersticas parecen muy abstractas y hasta indefinidas, etc

5.

CARACTERISTICAS PROPICIADAS POR LA ARQUITECTURA ESTNDAR ISO 9126 (VANESSA)

El estndar ISO/IEC 9126 ha sido desarrollado en un intento de identificar los atributos clave de calidad para un producto de software (Pressman, 2002). Este estndar es una simplificacin del Modelo de McCall (Losavio et al., 2003), e identifica seis caractersticas bsicas de calidad que pueden estar presentes en cualquier producto de software. El estndar provee una descomposicin de las caractersticas en subcaractersticas

Es interesante destacar que los factores de calidad que contempla el estndar ISO/IEC 9126 no son necesariamente usados para mediciones directas (Pressman, 2002), pero proveen una valiosa base para medidas indirectas, y una excelente lista para determinar la calidad de un sistema. ISO/IEC 9126 adaptado para arquitecturas de software Losavio et al. (2003) proponen una adaptacin del modelo ISO/IEC 9126 de calidad de software para efectos de la evaluacin de arquitecturas de software. El modelo se basa en los atributos de calidad que se relacionan directamente con la arquitectura: funcionalidad, confiabilidad, eficiencia, mantenibilidad y portabilidad. Los autores plantean que la caracterstica usabilidad propuesta por el modelo ISO/IEC 9126 puede ser refinada para obtener atributos que se relacionan con los componentes de la interfaz con el usuario. Dado que estos componentes son independientes de la arquitectura, no son considerados en la adaptacin del modelo.

En la literatura es posible encontrar planteamientos en relacin al establecimiento de los atributos de calidad y su relacin con la arquitectura de software (Bass et al., 2000). Kazman et al. (2001) establecen que la arquitectura determina atributos de calidad. Bass et al. (2000) explica la relacin existente entre estos, conjuntamente con los problemas y beneficios de la documentacin de esta relacin.