ANALISIS Y DETERMINACIN DE LAS METRICAS A UTILIZAR PARA LA PRIMERA ITERACION DEL PROYECTO Mtrica para la etapa de Anlisis Mtrica

para la calidad de los requerimientos La mtrica propuesta para la calidad de los requerimientos est basada en el estndar 830 de la IEEE ( IEEE-STD-830-1998) y usando algunas de las propuestas de A. Davis para el clculo de los valores. Se deben tomar en cuenta las indicaciones de cada atributo para lograr una buena medicin. Se debe tener en cuenta que algunos de los atributos no pueden ser medidos inmediatamente finalizada la etapa de anlisis, sino que habra que esperar hasta la finalizacin de alguna de las siguientes etapas, por ejemplo la de implementacin. Todas las mediciones son porcentajes, que expresan la relacin entre el atributo que se est midiendo y el total del SRS. Lo ms importante es tomar en cuenta la definicin o la forma de considerar el atributo a medir. Segn el estndar IEEE-STD-830-1998 un buen SRS debe cumplir con las siguientes 8 caractersticas primordiales. Caractersticas de un buen SRS. Un buen SRS debe ser: a) Correcto b) Inequvoco c) Completo d) Consistente e) Delinear que tiene importancia y/o estabilidad f) Comprobable g) Modificable h) Identificable 1. Correcto Un SRS es correcto si, y slo si, cada requisito declarado se encuentra dentro de la implementacin del software. No hay ninguna herramienta o procedimiento que aseguran la exactitud. Alternativamente el cliente o el usuario pueden determinar si el SRS refleja las necesidades reales correctamente.

Para medir la correctitud del SRS, se deben revisar los requerimientos que ya han sido implementados, en la etapa del software donde se est midiendo.
Q= RI R = I , donde: R I + R NI RT

RI requerimientos implementados en esta etapa. RNI atributos no implementados. RT atributos totales del SRS. 2. Inequvoco Un SRS es inequvoco si, y slo si, cada requisito declarado tiene slo una interpretacin. Como un mnimo, se requiere que cada caracterstica de la ltima versin del producto se describa usando un nico trmino. En casos dnde un trmino en un contexto particular tenga significados mltiples, el trmino debe ser incluido en un glosario dnde su significado se explicita. El SRS debe ser inequvoco para aqullos que lo crean y para aqullos que lo usan. Sin embargo, estos grupos no tienen a menudo el mismo perfil y por consiguiente no tienden a describir los requisitos del software de la misma manera. La determinacin de un requerimiento ambiguo (o con ms de una interpretacin), estar a cargo del SQA (para nuestro caso, el SQA externo) del grupo. Para determinar la medida del atributo Inequvoco se utilizar la siguiente ecuacin:
Q= R NA , donde: RT

RNA requerimientos no ambiguos (determinados por el SQA), RT requerimientos totales del SRS. OBS.: Claramente se busca que Q 1 ( deseado Q = 1).

3. Completo Un SRS est completo si, y slo si, incluye los elementos siguientes:

a) Los requisitos estn relacionados a la funcionalidad, el desarrollo, las restricciones del diseo, los atributos y las interfaces externas. En particular debe reconocerse cualquier requisito externo impuesto por una especificacin del sistema y debe tratarse. b) La definicin de las salidas respecto a todos los posibles datos de entrada y a toda clase de situaciones. Se debe especificar las respuestas tanto a entradas vlidas como invlidas. c) Tener las etiquetas y referencias a todas las figuras, tablas, diagramas en el SRS y definicin de todas las condiciones y unidades de medida. El propsito de esta mtrica es determinar la completitud de un SRS durante la etapa de anlisis. Adems, los valores determinados para la asociacin de las primitivas pueden ser utilizados para identificar reas problemticas en los requerimientos del software. Primitivas. La mtrica de completitud consiste de las siguientes primitivas: B1 = Nmero de funciones que no han sido satisfactoriamente definidas. B2 = Nmero de funciones del software. B3 = Nmero de referencias a datos que no tienen un origen determinado. B4 = Nmero de referencias a datos. B5 = Nmero de funciones definidas que no se usan B6 = Nmero de funciones definidas. B7 = Nmero de funciones referenciadas no definidas. B8 = Nmero de funciones referenciadas. B9 = Nmero de puntos de decisin donde no se definen todas las condiciones u opciones B10 = Nmero de puntos de decisin. B11 = Nmero de opciones de condicin que no han sido procesadas B12 = Nmero de opciones de condicin B13 = Nmero de rutinas llamadas con parmetros que no concuerdan con los definidos B14 = Nmero de rutinas llamadas. B15 = Nmero de opciones de condicin sin determinar B16 = Nmero de opciones de condicin que no poseen procesamiento B17 = Nmero de opciones de condicin determinadas B18 = Nmero de referencias de datos que no tienen destino. Implementacin. La medida de completitud (M C) es la suma de las ponderaciones de las primitivas, expresado como: MC = wiDi Donde para cada i=1,..., 10 cada ponderacin w i tiene un valor entre 0 y 1,

la suma de los pesos es igual a 1, cada Di es un valor entre 1 y 0 D1 = (B2 - B1) / B2 D2 = (B4 - B3) / B4 D3 = (B6 - B5) / B6 D4 = (B8 - B7) / B8 D5 = (B10 - B9) / B10 decisin D6 = (B12 - B11) / B12 los D7 = (B14 - B13) / B14 con D8 = (B12 - B15) / B12 = = = = = = = = Funciones definidas satisfactoriamente Referencias a datos que tienen un origen Funciones definidas usadas Referencias a funciones definidas Todas las opciones de condicin en puntos de Todas las opciones de condicin con procesos en puntos de decisin usados. Parmetros de llamada a rutina que corresponden la definicin de los parmetros de la rutina llamada Todas las opciones de condicin que han sido determinadas Procesamiento sigue las opciones de condicin determinadas Referencias a datos que tienen un destino

D9 = (B17 - B16) / B17 = D10 = (B4 - B18) / B4 = Interpretacin.

El valor final de la completitud estar entre 0 y 1, siendo 1 el valor deseado. 4. Consistente La consistencia se refiere a la consistencia interior. Si un SRS no est de acuerdo con algn documento del nivel superior, como una especificacin de requisitos de sistema, entonces no es consistente. Consistencia interior Un SRS es internamente consistente si, y slo si, ningn subconjunto de requisitos individuales genera conflictos en l. Los tres tipos de conflictos probables en un SRS son: a) Las caractersticas especificadas en el mundo real de los objetos pueden discrepar. Por ejemplo: El formato de un informe del rendimiento puede describirse en un requisito como tabular pero en otro como textual. Un requisito puede declarar que todas las luces sern verdes mientras otro puede declarar que todas sean azules. b) Puede haber conflicto lgico o temporal entre dos acciones especificadas. Por ejemplo: Un requisito puede especificar que el programa sumar dos entradas y otro puede especificar que el programa los multiplicar. Un requisito puede declarar que dado "A" siempre debe seguir "B", mientras otro puede requerir que "Ay "B" ocurran simultneamente.

La consistencia interna se mide en los requerimientos que especifican una reaccin del programa ante algn estmulo, ya sea de entrada de usuario u otra accin que ocurre dentro del programa. Los requerimientos que no cumplan con alguna de estas caractersticas, les llamaremos NO DETERMINISTAS. La medida para evaluar este atributo ser:
Q= ( Ru Rnd ) , donde Ru

RU es el nmero de funciones nicas especificadas dentro del SRS Rnd nmero de funciones no deterministas especificadas dentro del ERS 5. Delinear importancia y/o estabilidad Un SRS debe delinear la importancia y/o estabilidad que l tiene mediante un identificador para indicar la importancia o estabilidad de ese requisito en particular. Claramente, no todos los requisitos del software son igualmente importantes (Paretto). Algunos son esenciales, otros deseables, etc. Grado de estabilidad La estabilidad ser la referencia al nmero de cambios esperados a cualquier requisito, basado en experiencia o conocimiento de eventos venideros que afecten a la organizacin, funciones y a personas (claves) que apoyan el sistema del software. Para medir el grado de estabilidad de un SRS se verificar, en primer lugar, que est especificado qu requerimientos pueden cambiar en alguno de los prximos procesos del desarrollo del software (en forma estimativa), dentro del documento. Entonces la medida de estabilidad de un SRS ser:
Q =1 Rc , donde Rt

Rc requerimientos que pueden cambiar dentro del desarrollo del sistema Rt total de requerimientos especificados dentro del SRS. Grado de necesidad (Importancia) Otra manera de alinear los requisitos es distinguir las clases de requisitos que hay: el esencial, el condicional y optativo.

a) Esencial: Implica que el software no ser aceptable a menos que estos requisitos se proporcionan de una manera convenida. b) Condicional: Implica que stos son requisitos que reforzaran el producto del software, pero no lo hara inaceptable si estn ausentes (o un N de ellos). c) Optativo: Implica una clase de funciones que pueden o no pueden valer la pena. Esto da la oportunidad de proponer algo que excede el SRS. Si se ha especificado en el documento un orden de importancia para el SRS, este atributo se calificar con un 1, en caso contrario con un 0. 6. Comprobable (Verificable) Un SRS es comprobable si, y slo si, cada requisito declarado es comprobable. Un requisito es comprobable si, y slo si, existe algn proceso rentable finito con que una persona o mquina puede verificar que el producto del software rene el requisito. En general cualquier requisito ambiguo no es comprobable. Los requisitos No Verificables incluyen declaraciones tales como trabaja bien, buena interface humana y normalmente podra pasar "de aspecto agradable", etc., no pueden verificarse los requisitos de este tipo ya que es imposible de definir las condiciones bueno, bien o normalmente, salvo que no viene al caso (para esta temtica). La declaracin que el programa nunca entrar en un loop infinito es no verificable porque la comprobacin de esta calidad es tericamente imposible. Un ejemplo de una declaracin comprobable es: El rendimiento del programa se producir dentro de 20 seg. del evento en un 60% del tiempo; y se producir dentro de 30 seg. del evento el otro 40% del tiempo. Esta declaracin puede verificarse porque usa condiciones concretas y las cantidades mensurables. Si un mtodo no puede inventarse para determinar si el software rene un requisito particular, entonces ese requisito debe quitarse o debe revisarse, o sea es NO COMPROBABLE. La medida para este atributo ser:
Q =1 R NC RT

Donde RNC es el nmero de requerimientos encontrados que son No Comprobables (No verificables, no cuantificables, etc) y R T es el nmero total de requerimientos.

7. Modificable Un SRS es modificable si, y slo si, su estructura y estilo son tales que puede hacerse cualquier cambio a los requisitos fcilmente, completamente y de forma consistente mientras conserva la estructura y estilo. Para que sea modificable se requiere un SRS que contenga: a) Poseer un ndice y las referencias cruzadas explcitas. b) No sea redundante (es decir, el mismo requisito no debe aparecer en ms de un lugar en el SRS). c) Exprese cada requisito separadamente, en lugar de intercalarlas con otros requisitos. La redundancia no es un error, pero puede llevar fcilmente a los errores. La redundancia puede ayudar hacer un ERS ms comprensible de vez en cuando, pero un problema puede generarse cuando el documento redundante se actualiza. Por ejemplo, un requisito puede alterarse en un solo lugar dnde aparece. El ERS se pone incoherente entonces. Siempre que la redundancia sea necesaria, el ERS debe incluir explcitamente las referencias para hacerlo modificable. Segn la propuesta de A. Davis, un SRS es modificable si presenta todas estas caractersticas. No se puede sacar un porcentaje de los atributos MODIFICABLES, ya que este concepto se aplica al SRS completo. Por lo tanto, si un SRS posee todas estas caractersticas, el atributo MODIFICABLE obtiene un 1 (100% modificable), en cambio, la ausencia de alguno de estas caractersticas le atribuye un 0 (No modificable). 8. Identificable (Trazable) Un SRS es identificable si el origen de cada uno de sus requisitos est claro y si facilita las referencias de cada requisito en el desarrollo futuro o documentacin del mismo. Lo siguiente que se recomiendan dos tipos de identificabilidad: a) El identificable dirigido hacia atrs (es decir, a las fases anteriores de desarrollo). Esto depende explcitamente en cada requisito la referencias de su fuente en los documentos ms antiguos. b) El identificable dirigido hacia delante (es decir, a todos los documentos derivados por el SRS). Esto depende en cada requisito en el SRS que tiene un nico nombre o nmero de la referencia. El identificable dirigido hacia delante del SRS es especialmente importante cuando el producto del software entra en el funcionamiento y fase de mantenimiento. Como el cdigo y documentos del plan se modifican, es esencial poder determinar el

juego completo modificaciones.

de

requisitos

que

pueden

afectarse

por

esas

Para que un requerimiento en particular sea Identificable (trazable) debe poseer un ndice de referencia, el cual est presente dentro del o los documento(s) anteriores o posteriores a la definicin del SRS. Dadas estas especificaciones, la medida para el SRS Identificable ser:
Q= RI RT

Donde Ri es el numero de requerimientos identificados con un ndice de referencia a los dems documentos (Identificable) y Rt es el numero total de requerimientos.