Tema IV. Requerimientos No Funcionales Versin: 1.2 Porf.

Norhemma Acevedo ste tema es una traduccin adaptada del libro: Soren Lauesen. Software Requirements. Styles and Techniques. Samfundslitteratur, 1999. Realizndose una traduccin (adaptada) del Captulo 3. 4.1 Requerimientos No Funcionales. Los requerimientos son generalmente clasificados en requerimientos funcionales y no funcionales. Los requerimientos funcionales describen los servicios del sistema y su comportamiento. Los requerimientos no funcionales describen propiedades del sistema y las restricciones que existen sobre ste. Un subconjunto particular de requerimientos no funcionales puede indicar ciertas cualidades que el sistema debe poseer, tales como adaptabilidad o eficiencia, entre otros. Tales tipos de requerimientos son conocidos como requerimientos de calidad. Ya que especifican la calidad requerida del sistema. Estos requerimientos no funcionales especifican como el sistema debe realizar sus funciones, por ejemplo, cun rpido funciona, que tan fcil es aprender a usarlo, cun fcil es su mantenimiento, entre otros. Los ingenieros de requerimientos plantean que los requerimientos no funcionales son muy importantes, aunque generalmente se les presta poca atencin. La razn es que son difciles de especificar y existe poca literatura

disponible al respecto. En este captulo, discutiremos varios tipos de requerimientos no funcionales. Nos centraremos en los requerimientos que pueden ser verificados. Uno de los problemas bsicos con los requerimientos no funcionales es que no son imprescindibles tal como lo son los requerimientos funcionales. Un requerimiento funcional es, en la mayora de los casos, algo que el usuario necesita, sin ello, no respondera a sus necesidades. Los requerimientos no funcionales son diferentes. Si un requerimiento no funcional no se logra, el usuario puede, an, usar el sistema -al menos en muchos casos-. Entonces, es verdaderamente un requerimiento?, posteriormente trataremos esto, utilizando un ejemplo. 4.2 Factores de Calidad Cules son los factores de calidad?. Algunos autores y organismos de estandardizacin han dado respuesta a esta pregunta. La Tabla 1 compara dos clases de listas. En la Tabla 1, del lado izquierdo se presenta un estndar de una empresa, del lado derecho se presenta el estndar ISO 9126 (Ao 1991). A la izquierda est el primer intento (titulado McCall 1). La lista es una taxonoma de dos niveles. En el nivel superior, se sitan tres importantes usos del software:

Operacin: El uso diario dado por los usuarios finales. Revisin: Mantenimiento y extensin del software. Transicin: Uso del software en torno a nuevas tcnicas.

Incluido en cada nivel, encontramos los siguientes factores de calidad: Factores de calidad a nivel de Operacin:

Integridad: Que tan bien el sistema maneja los cambios fsicos (por ejemplo. previene intentos maliciosos de acceso, etc. El trmino seguridad se usa tambin para este factor.

McCall y Matsumoto E.E.U.U., 1.980

Correctitud: Cuanto cumple la aplicacin con las especificaciones planteadas por el usuario. Confiabilidad: Cun frecuentemente el sistema responde como se espera. Usabilidad: Cun fcil es aprender a usar el sistema, cuan eficiente es para las tareas diarias, etc. Eficiencia: Qu tan rpido responde el sistema, cuntos recursos utiliza, cmo procesa exactamente los valores, etc. Factores de calidad a nivel de Revisin

Mantenibilidad: Cun fcil es localizar y reparar fallas. Prueba: Que tan fcil es probar el sistema despus de un cambio. Flexibilidad: Cun fcil es incorporar al sistema nuevas caractersticas, es decir, extenderlo. Factores de calidad a nivel de Transicin:

Portabilidad: Que tan fcil es trasladar el sistema a una nueva plataforma de hardware o software. Interoperabilidad: Cuan fcil es para el sistema cooperar con otros sistemas, por ejemplo transferir archivos hacia hojas de clculo, incorporar unidades accesorias de hardware, etc.

Reusabilidad: Cun fcil es reutilizar parte del software en otros sistemas. Los autores sugieren tambin mecanismos ideales para medir estos

factores de calidad. La flexibilidad, por ejemplo, se podra medir como el tiempo promedio en el cual se incorpora al sistema una nueva caracterstica. Los autores reconocen, sin embargo, que tal esquema de medicin no es real debido a que es imposible definir una caracterstica promedio para todos los casos.

En la Tabla 1, del lado derecho se presenta el estndar ISO 9126 (Ao 1991). En el nivel superior, en el estndar ISO, se tienen seis factores de calidad:

Funcionalidad: Aqu se presenta una pequea confusin pues los factores de calidad se suponen ser requerimientos no funcionales. Varios aspectos de la lista de McCall son colocados aqu, tales como seguridad e interoperabilidad.

Confiabilidad: Es similar a la confiabilidad de McCall, pero abarca tambin la tolerancia a fallas (robustez) y capacidad de recuperacin despus de las fallas.

Usabilidad, eficiencia y portabilidad: Similares a McCall. Mantenibilidad: Similar a McCall. Este modelo indica ms explcitamente que es importante el tiempo de localizacin de fallas as como evitar la introduccin de nuevos errores (anlisis y estabilidad).

McCALL Operacin Integridad (integrity) Correctitud (correctness) Confiabilidad (reliability) Usabilidad (usability) Eficiencia (Efficiency) Revisin Mantenibilidad (maintainability) Prueba (testability) Flexibilidad (flexibility) Transicin Portabilidad (portability) Interoperabilidad (interoperability)) Reusabilidad (reusability)

ISO 9126 Funcionalidad Exactitud (accuracy) Seguridad (security) Interoperabilidad adecuado (suitability) Cumplimiento (compliance) Confiabilidad Madurez (maturity) Robustez (fault tolerante) Recuperabilidad (recoverability) Usabilidad Eficiencia Mantenibilida d Testeo (testability) Modificabilidad

(changeability) Anlizabilidad (analysability) Estabilidad (stability) Prueba Portabilidad Adaptabilidad (adaptability) Instalabilidad (installability) Conformidad (conformance) Sustituibilidad (replaceability)
Tabla 1: Factores de calidad

La Organizacin Internacional de Estndares (ISO) public un apndice informativo con sub-caractersticas, sin el cual los factores del nivel superior seran muy abstractos y difciles de entender. Varios requerimientos no funcionales adquirieron nuevos nombres como se muestra en la Tabla 1 (integridad-Seguridad, confiabilidad-madurez, flexibilidad-modificabilidad, y portabilidad-adaptabilidad). De la lista de McCall han sido obviados en la lista ISO: correctitud (falta de errores) y reusabilidad (capacidad de reutilizar segmentos del software). Algunos nuevos aspectos de calidad han surgido en el apndice informativo de la ISO 9126:

Confortabilidad: Si el sistema soporta adecuadamente las tareas del usuario. Cumplimiento y Conformidad: Que tan bien el sistema satisface los estndares del dominio y los estndares tcnicos. Nuevos sub-factores: Confiabilidad, Mantenibilidad y Portabilidad tienen nuevos sub-factores en la lista informativa. 4.3 Qu lista utilizar? Adems de stas, hay muchas otras listas de requerimientos no

funcionales, ms o menos estndares, entonces, cul usar?, la respuesta es simple: la que convenga, incluso cualquiera puede usarse como lista de chequeo, segn los aspectos a considerar en la aplicacin en cuestin. Ayuda a ello responder a las siguientes preguntas:

Cules requerimientos no funcionales son importantes en el proyecto? Como ejemplo, en un sistema para un hotel, factores como la usabilidad y confiabilidad puede ser sumamente importante, mientras que la portabilidad no es determinante. Cul es el inters del cliente? En el sistema del hotel, la usabilidad es una aspecto relevante debido a los cambios de personal que tiene poca experiencia en el rea de tecnologa de informacin; la confiabilidad importa porque no se puede ofrecer servicio a los usuarios cuando el sistema se cae (falla). Cmo pueden traducirse estos intereses en requerimientos? Esta es la parte ms difcil, y muchos analistas desisten en este punto. Pero es usualmente posible derivarlos en requerimientos no funcionales. En algunos contextos, se sigue el estndar de una compaa, pero incluso en estos casos es conveniente seguir los pasos sealados anteriormente. Se pueden consultar otras listas de factores de calidad y usarlas como listas de chequeo. 4.4 Requerimientos de Eficiencia Los requerimientos de eficiencia son el tipo ms simple de requerimientos no funcionales. Especifican aspectos como tiempo de respuesta y espacio en memoria. Podemos especificar requerimientos de tiempo relacionados con un dominio especfico, por ejemplo, el tiempo mximo que debe tomarle a un usuario experto realizar una tarea especfica. Esto es un requerimiento muy relevante. El tiempo total de las tareas consiste en los tiempos de respuesta del producto y las acciones humanas. Por convencin, los requerimientos relativos a tareas son considerados requerimientos de usabilidad.

4.5 Requerimientos de tiempo. La Figura 1 contiene ejemplos de requerimientos de tiempo, detallados

Requerimientos de tiempo: R 1.1: El producto ser capaz de procesar 100 transacciones de pago por segundo cuando el sistema esta al mximo R 1.2: El producto deber ser capaz de procesar una alarma en 1 segundo, 1000 alarmas en 5 segundos. R 1.3: En un tiempo de trabajo estndar, el uso del CPU debe ser menos del 50%, dejando otro 50% para otros trabajos. R.1.4: Para las funciones de edicin simples, el tiempo de respuesta debe ser menor a 1 segundo. Para actualizaciones simples de la base de datos menos de 5 segundos. Para reportes sencillos por pantallas menos de 20 segundos. (Vlido para el 95% de los casos en actividad estndar) R1.5: Buscar una pgina navegando arriba y abajo en un documento de 200 pginas, debe tomar como mnimo 1 segundo. Buscar Figura 1: requerimientos de eficiencia (tiempo) usando una palabra clave debe tomar a lo mucho 5 segundos.

en diversas maneras. Estos requerimientos significan: R1.1: Proviene de un sistema que maneja transacciones de tarjetas de crdito. Una transaccin es un evento con datos asociados. Se especifica el
Cubre todas funciones del software? rendimiento de las procesamiento, en trminos del nmero de eventos de entrada Qu figura? 2 minutos? 4 minutos?

que el software puede manejar por unidad de tiempo. R1.2: Proviene de un sistema que controla la fuente de energa elctrica en un rea geogrfica. Una alarma es un evento que indica un mal funcionamiento de la fuente de energa en el rea. El usuario tiene que decidir que hacer cuando se dispara la alarma. Para un caso especfico, el usuario esperaba cerca de 1500 alarmas al ao, por tanto un segundo por alarma pareca suficiente, considerando que el usuario pasara varios segundos estimando que hacer. R1.3: Proviene de un sistema de multitareas que pueda desarrollar varias actividades simultnea-mente. El software no debe monopolizar el CPU. El 50% del tiempo de uso del CPU debe estar disponible para otras actividades.

R1.4: Surge de una tpica aplicacin de negocios. Tiene tres clases de funciones y define un tiempo de respuesta mximo para cada clase de funcin (una especificacin ms precisa de las tres clases puede ser necesaria en algunos proyectos). Dado que los tiempos de respuesta pueden variar, dependiendo de las entradas y del estado del sistema, el requerimiento indica que solo el 95% de los eventos se manejan dentro del lmite, y solamente en una situacin de actividad estndar. Los tres lmites 1, 5 y 20, estn basados en estudios de la psicologa humana. Un tiempo de respuesta de 1 minuto despus de corregir un campo en un archivo puesto en pantalla no es percibido por la mayora de los usuarios. Un tiempo de respuesta de cinco minutos, cuando finaliza un registro, es el lmite de espera para la mayora de los usuarios. Si tiene que esperar ms de veinte minutos buscar otra cosa que hacer. 4.5.1 Las restricciones, cules valores les asociamos? Tenemos que especificar el tiempo de respuesta, tiempo de procesamiento, entre otros, para todas las funciones del software? Inicialmente si, de lo contrario, tendramos que aceptar un sistema cuyo tiempo de respuesta para una funcin ordinaria no especificada, sea de una hora. Pero si esta funcin no es realmente crtica, Qu lmite debemos especificar?: Un segundo?, Un minuto?, Cinco minutos? Algunas veces, los requerimientos no funcionales no son realmente obligatorios. Por ejemplo, asuma que el usuario ha especificado un tiempo de respuesta promedio de dos minutos para una funcin de reporte. Qu sucede si no puede conseguir ese tiempo de respuesta, sino nicamente 4 minutos? En muchos casos, el usuario lo aceptar de todos modos, particularmente si nadie ms puede satisfacer el resto de sus requerimientos a un precio razonable. Aparentemente, el usuario puede permitirse este lmite tan alto en el tiempo de respuesta, entonces por qu solicit un tiempo de respuesta tan bajo? l debi especificar 4 minutos. Desafortunadamente, esto implica que el proveedor no se vera obligado a hacer un esfuerzo para ofrecer tiempos cercanos a 2 minutos, de modo que el usuario obtendra un sistema con ms deficiencias. Adems, si el usuario especifica 4 minutos, usando el mismo argumento, pudiese verse obligado a aceptar un lmite ms alto de tiempo.

4.5.2 Mtricas abiertas Una salida para el usuario es especificar sus expectativas y preguntar al proveedor lo que l puede ofrecer. Esto usualmente genera una discusin de lo que es factible. Por otro lado, el usuario puede comparar varias ofertas y seleccionar la mejor de acuerdo con una evaluacin total. El principio de preguntar al proveedor lo que puede ofrecer, en lugar de especificar de forma estricta los requerimientos, es importante en muchos tipos de proyectos. Se utiliza el trmino mtricas abiertas para nominar esta poltica. 4.6 Requerimientos de Capacidad Otro tipo de requerimientos de eficiencia lo constituyen los requerimientos de capacidad. El termino capacidad se refiere a los recursos computacionales que el software puede utilizar durante cierto tiempo. La Figura 2 presenta requerimientos de eficiencia (capacidad). Se comentan los requerimientos all expresados: R 2.1: Se origina en un sistema computarizado. Asume el hecho que algunos programas no usen todo el espacio de memoria que est disponible, previniendo que otros programas puedan iniciarse. R 2.2: La fuente es un sistema de administracin pblica con varios departamentos, todos circunscritos a una misma base de datos. El nmero de usuarios es esencial para definir como se instala el sistema, cmo se maneja la comunicacin de los datos, etc. R 2.3: Se tom el sistema de reservacin de hotel. En l se especifica el nmero de registros que el sistema puede almacenar. Especificar un factor de crecimiento (del 20% al ao) es propio de este tipo de sistemas. En principio, el volumen de todas las tablas (entidades) debe especificarse. La especificacin permite al proveedor tener una apreciacin de la escala.

R 2.4: Extrado tambin del sistema de la reservacin del hotel. Este requerimiento surgi al considerar modelar virtualmente por pantalla casos extremos. Esencialmente, el analista se pregunt a si mismo que mostrara la
Requerimientos de capacidad: R 2.1: El producto deber utilizar menos de 16 MB de memoria incluso si hay mas disponibilidad. R 2.2: Numero simultaneo de usuarios < 2000 R 2.3: Volumen de base de datos: N de invitados < 10.000 con crecimiento del 20% por ao. N de cuartos < 1.000 R 2.4: La pantalla de husped podr mostrar por lo menos 200 cuartos reservados/ocupados por da, ejemplo para un evento de la compaa con un solo "usuario". Requerimientos de rango y exactitud: R 3.1: El campo nombre tendr 150 caracteres. R 3.2: Las reservaciones se podrn hacer al menos dos aos antes. R 3.3: Los datos se almacenaran en 14 bits exactamente, amplindose a 18 bits en dos aos.

pantalla virtual en los peores casos, por ejemplo cuando la lista de huspedes est copada. El anlisis demostr que algunas veces un husped (el administrador de personal de una compaa grande), reserva 200 cuartos en la misma poca para la celebracin anual de ventas. Los nombres de cada husped no se podran tener disponibles hasta que no se registrasen. probablemente, tal Muy situacin

debe ser considerada en el diseo.

Figura 2: requerimientos de eficiencia (capacidad)

4.7 Requerimientos de rango y exactitud Los ltimos tipos de requerimientos de eficiencia son de rango y exactitud. Comprende el rango de los datos, cuan grandes y pequeos pueden ser estos, que tan exactos tienen que ser los datos. La Figura 2 presenta ejemplos tpicos. Observe que algunos estndares de factores de calidad (ejemplo el estndar 9126 de la ISO) consideran a los requerimientos de exactitud como requerimientos funcionales. R 3.1 Especifica la longitud de los nombres para las personas, lo cual influye sobre la base de datos, los campos de la pantalla, y otros aspectos. En muchos casos no se enumerara como un requerimiento, sino se especificara en un diccionario de los datos. R 3.2 Su fuente es el sistema del hotel. Provee un catlogo con las fechas de las reservaciones. Considere esto como un requerimiento para

controlar el volumen de ocupacin de cada habitacin; tomando el caso de 1000 habitaciones deberan haber 730 (2*365) registros del estatus por habitacin. Sin embargo, implementar esto depende del criterio a usar: los cuartos libres deben tener un estatus en la base de datos, o la ausencia de este estatus indica que el cuarto est libre. La demanda del usuario no se basa en el volumen de la base de datos, sino en el catlogo de fechas de reservacin. R 3.3 Es extrado de un sistema automatizado de medidas. Estos sistemas miden aspectos fsicos mediante convertidores analgicos-digitales. El requerimiento final podra haber sido un convertidor analgico-digital de 14 bits de precisin. Muchos desarrolladores se alegraron, porque esta medida se ajusta a la palabra de un computador de 16 bits. Sin embargo, se conoca de antemano que la nueva generacin de convertidores analgicos-digitales tendra de 16 a 18 bits de exactitud. El requerimiento tom esto en consideracin, dejndole a los desarrolladores la decisin de manejarlo a 18 bits desde el principio, o utilizar el viejo cdigo al principio y cambiarlo luego a 18 bits. 4.8 Usabilidad Cuando el primer cajero automtico (ATM por sus siglas en ingls) fue instalado, la gente lo utiliz poco. Tcnicamente trabajaban sin problemas, entonces porqu no se usaban?. Una razn simple: eran demasiado difciles de utilizar. Desde entonces, los desarrolladores han ido mejorando poco a poco el uso del cajero automtico, y hoy la mayora de la gente los considera fciles de utilizar. La usabilidad (facilidad de uso, simplificando) es de vital inters en la mayora de los sistemas. Los sistemas costosos han fallado por tener una baja usabilidad; el proveedor podra no cargar con esta responsabilidad ya que el sistema satisface los requerimientos funcionales, y no se le indic nada respecto a la usabilidad. Los requerimientos de usabilidad deben ser tangibles a fin que puedan verificarse y monitorearse durante su desarrollo. Obtener todas estas metas es difcil, en la prctica, pero existen tcnicas que permiten, en un alto porcentaje,

aciertos, en particular si se seleccionan y combinan varios estilos de requerimientos. 4.8.1 Factores de usabilidad Antes de estudiar los diferentes estilos, discutiremos brevemente que es la usabilidad. La usabilidad no tiene nada que ver con fallas del sistema. Asumimos que el sistema trabaja segn lo previsto por el diseador. La usabilidad se refiere a la forma como el usuario percibe y usa el sistema. Hay muchas maneras de definir usabilidad, pero en lo que sigue, usaremos esta definicin: La usabilidad consiste de cinco factores: Fcil de aprender. Qu tan fcil es para varios grupos de usuarios aprender a usar el sistema? Eficiencia de la tarea. Qu tan eficiente es para el usuario comn? Fcil de recordar. Qu tan fcil de recordar es para un usuario casual? Fcil de entender. Qu tan fcil es comprender lo que el sistema hace? Satisfaccin subjetiva. Qu tan satisfecho est el usuario con el sistema? Los diferentes estilos de requerimientos especifican y miden estos factores ms o menos directamente. Los desarrolladores dicen a menudo que es imposible hacer que un sistema satisfaga por completo todos los factores de calidad. Esto puede ser verdad, y uno de los propsitos de los requerimientos de la usabilidad es especificar el nivel necesario para cada factor. Como por ejemplo, un sistema de control de vuelo y un sistema basado en la Web para atraer nuevos clientes deben contemplar diferentes factores de la usabilidad.

4.8.2 Problemas y mecanismos de prueba de la usabilidad Un hecho importante, validado por muchos experimentos, es que nadie puede prever los problemas de usabilidad que puede tener un usuario ni siquiera un experto en usabilidad. Los expertos en esta materia pueden predecir muchos problemas de usabilidad a nivel de diseo, pero alrededor de la mitad de los problemas son falsos, en el sentido que los usuarios no sienten

que esto sea un problema. Lo que es peor, los expertos en usabilidad ignoran ms de la mitad de los problemas que los usuarios reales experimentan. Solo algunos tipos de prueba con usuarios reales pueden revelar los problemas de usabilidad. Para corregir los problemas, necesitamos identificarlos durante la primera etapa del desarrollo. Consecuentemente, las especificaciones de usabilidad que no pueden ser probadas durante el desarrollo, tendrn serias debilidades. El tipo de prueba necesaria para mostrar los problemas de usabilidad se denomina prueba de usabilidad. Es un experimento donde los usuarios reales, con un conocimiento apropiado, intentan desarrollar tareas verdaderas por medio del sistema o de un prototipo. Los observadores registran los problemas encontrados por el usuario y el tiempo de ejecucin de las tareas.

4.8.3 Requerimientos de usabilidad La Figura 3 presenta seis estilos para los requerimientos de usabilidad. Para cada estilo, hemos indicado el riesgo para el usuario y el proveedor cuando usan el estilo. El riesgo del usuario radica en que aunque pueda conseguir lo que especific, quizs no obtendr lo que realmente necesita. El riesgo del proveedor es que puede no ser capaz de alcanzar los requerimientos - o hacerlo a un costo excesivo.

Seis estilos para usabilidad Estilo de performance R.1: Los usuarios novatos deben ser capaces de realizar las tareas Q y R en 15 minutos. Los usuarios expertos debern realizar las tareas Q,R, y S en 2 minutos. Estilo de defectos R.2: En promedio, un usuario novato encontrar menos de 0,2 defectos serios en usabilidad al realizar las tareas

Riesgo Usuario Proveedor

Q y R. Estilo de procesos R.3: Durante diseo, una secuencia de 3 prototipos debern realizarse. A cada prototipo se le har pruebas de usabilidad y se corregirn los principales defectos. Estilo de subjetividad R.4: El 80% de usuarios debe percibir al sistema fcil aprender y eficiente para el uso diario. Estilo de diseo R.5: El sistema utilizar las ventanas diseadas. (Se acepta si la usabilidad del diseo ha sido probada)

Estilo de lineamientos R.6: El sistema seguir la gua de estilo de Microsoft Windows. Los mens tendrn como mximo tres niveles

Figura 3: Estilos para requerimientos de usabilidad

Estilo de performance R1: Los principiantes pueden ser capaces de realizar las tareas Q y R en 15 minutos. Los usuarios expertos son capaces de realizar las tareas Q, R, y S en 2 minutos. En el estilo de performance especificamos cuan rpido los usuarios pueden aprender varias tareas, con que rapidez pueden realizar sus labores despus del entrenamiento, entre otros. Podemos verificar estos requerimientos a travs de pruebas de usabilidad. Por medio de prototipos, podemos hacer pruebas de usabilidad durante la primera etapa del desarrollo, de modo de proyectar los requerimientos del diseo. El estilo armoniza bien con los casos del uso. Las tareas pueden ser casos de uso. Adems, los requerimientos de performance podran encontrar un lugar en la descripcin del caso de uso. El estilo captura bastante bien la esencia de la usabilidad, lo que significa que si el software cumple los requerimientos, el usuario consigue lo que necesita. El problema principal es seleccionar las tareas adecuadas.

Sin embargo, el estilo es riesgoso para el proveedor. No hay garanta de que se puedan recabar todos los requerimientos. Un factor como la eficiencia en el uso diario puede ser difcil de verificar durante el desarrollo. Sorprendentemente, cuando el usuario selecciona y compra un software estndar, el estilo conlleva bajo riesgo para ambas partes. Por qu? Porque el software est terminado y se pueden tomar medidas antes de decidir comprarlo. Estilo de Defectos R2: En promedio, un usuario nuevo encontrar menos de 0,2 defectos de usabilidad al realizar las tareas Q y R. Un problema serio de usabilidad es una tarea que falla, es decir, una tarea que el usuario no puede terminar. As que el requerimiento debera definirse como que el 80% de los usuarios sean capaces de terminar las tareas por si mismos. El estilo de defecto se asemeja al estilo de performance, pero en lugar de medir tiempos de ejecucin de las tareas, identifica los defectos de usabilidad del sistema y especifica con que frecuencia pueden ocurrir. Un defecto de usabilidad puede hacer que el usuario incurra en equivocaciones o se sienta molesto. Por ello se le solicita al usuario pensar en voz alta durante la prueba de usabilidad mientras un observador registra los defectos. La ventaja principal del estilo es que la lista de defectos provee a los desarrolladores un excelente feedback, permitindoles corregir el diseo con mayor facilidad. La desventaja es que estamos menos seguros de captar la esencia de la usabilidad. Por ejemplo, el bajo rendimiento diario ser reportado como un defecto de usabilidad si el usuario se queja por ello. Estilo de proceso R3: Durante el diseo, se realizarn tres prototipos. Cada prototipo deber ser probado en cuanto a usabilidad y se corregirn los principales defectos. El estilo de proceso especifica el procedimiento de desarrollo a usarse para asegurar la usabilidad. El estilo no dice nada acerca del resultado del desarrollo, pero el usuario espera que el proceso genere un buen resultado. El

ejemplo especifica el desarrollo basado en un prototipo iterativo ya que se admite como un proceso eficaz. Cuntas iteraciones necesitamos hacer? Debemos especificar el criterio de finalizacin del nmero de interacciones, por ejemplo continuar hasta no detectar ningn defecto serio de usabilidad, pero entonces tendramos un estilo de defecto, en lugar de un estilo de procesos. Sin embargo, podramos especificar que las iteraciones sern negociadas entre el usuario y el proveedor despus de tres iteraciones. Esto an estara en el marco de estilo de procesos. El usuario no puede estar seguro de tener lo que necesita, porque se deja mucho en mano de los desarrolladores, quienes seleccionan a menudo las tareas y los usuarios para la prueba de usabilidad, o hacen solamente cambios menores a los prototipos en lugar de redisearlos. El resultado puede ser que la usabilidad sigue siendo inaceptable despus de tres iteraciones. Estilo subjetivo R4: El 80% de los usuarios deber indicar que el sistema es fcil de aprender y es eficiente para el uso diario. Con el estilo subjetivo, preguntamos a los usuarios su opinin, tradicionalmente a travs de cuestionarios. Esto parece captar la esencia de usabilidad. Desafortunadamente, los usuarios expresan a menudo satisfaccin con el sistema a pesar de tener evidencias de que el sistema es incmodo y les hace perder mucho tiempo. La satisfaccin con el sistema est fuertemente influenciada por factores organizacionales fuera del alcance del desarrollador del sistema. Otro problema con el estilo subjetivo es que es difcil verificar el requerimiento durante el desarrollo. Muchos expertos preguntan a los usuarios su opinin subjetiva despus de haber hecho pruebas de usabilidad del prototipo, pero esto no se correlaciona con sus opiniones despus del desarrollo del sistema. El resultado es que tanto el usuario como el proveedor corren un alto riesgo. Estilo de Diseo

R5: El sistema utilizar las pantallas diseadas. El men y los botones trabajarn como se describe en El estilo de diseo describe los detalles de la interfaz del usuario. Substancialmente, ello transforma los requerimientos de usabilidad en requerimientos funcionales. Los requerimientos de usabilidad son fciles de verificar en el software final y fcil de observar durante el desarrollo. El proveedor corre un riesgo bajo. A travs del diseo, los ingenieros de requerimientos han tomado toda la responsabilidad de la usabilidad. El diseador del sistema y el programador pueden hacer pequeos cambios a la usabilidad. Si el ingeniero de requerimientos ha hecho un cuidadoso trabajo con el anlisis de las tareas, el prototipaje y las pruebas de usabilidad, la usabilidad final lograda ser adecuada y por ende el usuario corre un bajo riesgo. De lo contrario, su riesgo es alto - l no conseguir lo que necesita. Los prototipos que no son probados pueden usarse como ejemplos de lo que el usuario piensa, ms no como un requerimiento de usabilidad.

Estilo de Lineamientos R6: El sistema podra seguir los lineamientos de Microsoft Windows. Los mens deben tener como mximo tres niveles. El lineamiento de estilo seala la apariencia general y la respuesta sobre la interfaz de usuario. Puede interpretarse como un requerimiento funcional que se aplica a cada ventana, etc. Los lineamientos pueden ser estndares, guas de corporaciones o reglas basadas en la experiencia. Aunque los lineamientos generalmente mejoran la usabilidad, tienen poca relacin con la esencia de la usabilidad. En otras palabras, se puede tener un sistema que los usuarios encuentren muy difcil de utilizar an siguiendo los lineamientos. (Dichos sistemas son realmente comunes, como se demuestra en muchos programas que siguen las pautas de Microsoft Windows y an as son muy difciles de utilizar). Como complemento de otros estilos, el estilo de lineamientos es muy til, particularmente para ayudar a los usuarios que alternan entre aplicaciones.

4.9 Mantenimiento La mayora de los productos necesitan mantenimiento, debido a muchos factores, tales como: los usuarios encuentran errores en ellos, la demanda crece, el ambiente cambia. Muchos proveedores hacen muy buenos negocios en esta rea y los clientes se ven forzados a pagar por estos servicios. En algunos casos, los proveedores venden la primera versin del producto a un precio accesible y despus obtienen muchos beneficios con el mantenimiento. Los costos de mantenimiento pueden convertirse en una verdadera carga para los clientes, esto debido a los honorarios cobrados por los proveedores y a interrupciones en los negocios mientras que el mantenimiento se realiza; el objetivo de los requerimientos de mantenimiento, es resguardarse de ambos factores.

4.9.1 Que es el Mantenimiento? Usualmente los ingenieros de software distinguen entre tres tipos de mantenimiento: Mantenimiento correctivo: Corregir defectos en el producto. Mantenimiento preventivo. Corregir los defectos que no han causado problemas, pero que pudieran hacerlo ms adelante. Un ejemplo tpico es cuando el proveedor corrige un defecto reportado, pero ignora que ste influye en algo ms, de manera que causar problemas ms adelante. Evitar defectos relacionados es esencial para ambos: cliente y proveedor, ya que las reparaciones adicionales resultan ser muy costosas para ambos. Mantenimiento perfectivo. Extender el sistema para cubrir demandas adicionales. Los requerimientos de mantenimiento tratan con los tres tipos sealados. Otro aspecto es cmo se definen los defectos y que tipo de reparacin necesita el cliente. Observe el ciclo de mantenimiento: qu sucede con un defecto o un pedido de cambio?.

Mantenimiento correctivo

Mantenimiento preventivo

Operacin Diaria

Producto

Operacin Diaria

Nueva versin

Mantenimiento perfectivo

Ciclo de mantenimiento :
Reportes de problemas Anlisis: defecto, demanda? Clasificar: rechazo? Labores? Reparar? Nueva versin? Hacer cambio Prueba Instalar

4.9.2 Ciclo de Mantenimiento Un problema es reportado al equipo de mantenimiento. Se analiza el reporte. Es un mal funcionamiento o un comportamiento previsto del producto?, es un pedido de cambio?, dnde est el defecto que causa el mal funcionamiento?, o cul es la necesidad real detrs del pedido de cambio? El reporte es clasificado: es un defecto o un pedido de cambio?, debemos rechazarlo porque no es realmente un problema del producto?, lo repararemos inmediatamente o se puede esperar el lanzamiento de la siguiente versin del producto?. Hacer un cambio del producto, sea como un parche a ser distribuido inmediatamente o como parte de la prxima versin. Testear el cambio. Tratar de encontrar y corregir defectos relacionados que pudiesen presentarse mas adelante. Instalar el cambio y asegure que los datos del usuario, configuraciones, entre otros, son transferidos. Muchos proveedores no tienen un ciclo de mantenimiento bien establecido y parte de los requerimientos podran ser que definan uno.

4.9.3 Que es un Defecto? Parte del ciclo de mantenimiento consiste en determinar si algo es un defecto o un pedido de cambio, esto puede ser difcil en la prctica. Usualmente, el contrato indica que el proveedor tiene que corregir defectos, mientras que el cliente tiene que pagar por los cambios. Para evitar malos entendidos los comits han estipulado que el contrato podra contener una normativa en la cual los desacuerdos a cerca de los defectos deberan ser decididos por algn rbitro entre ambas partes (proveedor y cliente). 4.9.4 Requerimientos de Mantenibilidad A continuacin se presentan cinco estilos para requerimientos de Mantenibilidad, algunos de ellos ilustrados con ms de un requerimiento. Estilo de performance R 1.1: El proveedor analiza y clasifica el 95% de reportes contenidos en dos horas de trabajo. Los defectos urgentes sern reparados en las prximas 30 horas del trabajo en el 95% de los casos. Limita el tiempo que el usuario tiene que esperar antes de conocer como proceder despus de un problema; en la mayora de estos casos las reparaciones se puede realizar de forma inmediata, pero existen otras reparaciones que son garantizadas dentro de un periodo especfico. Los requerimientos reconocen que algunos problemas son ms difciles, pero su nmero es limitado. Por otra parte, detalles acerca de qu se entiende por horas de trabajo, cmo se responde al usuario, etc.; se deben especificar en el proyecto. R1.2: Cuando se repara un defecto, los defectos relacionados no reparados deberan ser menos de 0.5 en el promedio. Trata con el mantenimiento perfectivo. Esto obliga al proveedor a encontrar cules problemas estn relacionados en lugar de realizar slo un parche. Se asume por supuesto que los reportes de defecto han sido recopilados y analizados.

R1.3: Para un periodo de dos aos, el proveedor aumentar el costo del producto Ello limita el costo del mantenimiento perfectivo. En esencia, esto indica que las mejoras tendrn un costo proporcional a su tamao. El costo ha sido fijado, y en el ejemplo se le pide al proveedor especificarlo, de modo que el cliente pueda comparar con otros proveedores. El estilo de performance puede acercarse a las necesidades esenciales del cliente; adems este estilo es reconocido en algunos dominios como una forma de medir el desarrollo de un trabajo independiente de tcnicas de programacin y experiencia del programador.

Estilo de Procesos de soporte R 2.1 La Instalacin de una nueva versin debe dejar el contenido de la base de datos y todos los registros personales inalterados. Trata con una situacin frecuente. El proveedor ha instalado una nueva versin para la compaa, y todos los usuarios se ven en la necesidad de pasar horas estableciendo todas las funcionalidades del nuevo sistema. Los requerimientos no dicen si el proveedor tratar de forma manual los cambios o si su producto realizar los ajustes automticamente. R 2.2: El proveedor colocar una estacin de mantenimiento calificada para los clientes. Requiere exclusivamente de una persona que se encargue del mantenimiento, de manera que un cliente no dependa de otros clientes. R 2.3: El proveedor deber depositar los cdigos y toda la documentacin de cada versin y sus correcciones. Es una medida de emergencia en caso que el proveedor suspenda las negociaciones o no satisfaga los requerimientos de mantenimiento. En este caso, el cliente puede encontrar a alguien ms que realice el mantenimiento, la codificacin y documentacin necesaria. En el estilo de proceso asistido se especifican todas las cosas que suceden durante el mantenimiento, pero no dice nada acerca de su duracin.

Estilo de Proceso de Desarrollo R3.1: Cada mdulo del programa debe ser evaluado para su mantenimiento de acuerdo a ciertos procedimientos. Al menos el 70% debe ser " altamente mantenible" (y ninguno debe ser " pobremente). Se trata de asegurar que el mantenimiento puede ser realizado por terceras partes. R3.2: El proceso del desarrollo debe tener procedimientos de test recurrentes que se realicen una y otra vez y que se continen durante doce horas. Trata con el problema frecuente de los desarrolladores cuando cambian algo que resulta tener un efecto no esperado. Un test de regresin es un procedimiento automatizado que prueba el producto con los primeros test de prueba y relata cualquier desviacin en la salida. El estilo de proceso de desarrollo tratar de forzar un enfoque de desarrollo que facilite el mantenimiento del producto.