Universidad Tcnica Federico Santa Mara

Departamento de Informtica
Valparaso, Chile

PLAN DE CALIDAD PARA

POST EMERGENCY SUPPORT
SYSTEM
MEMORIA PARA OPTAR AL TTULO DE:
INGENIERO DE EJECUCION EN INFORMATICA

Carlos Ramrez Espinoza

PROFESOR GUIA:
Marcello Visconti
PROFESOR CORREFERENTE:
Luis Hevia

2016

1 INTRODUCCION

El siguiente documento tiene como propsito establecer el plan de calidad para el

desarrollo de una versin funcional de la aplicacin PESS (Post Emergency Support System).
Actualmente esta se encuentra en su versin inicial, la cual consiste en un prototipo funcional,
pero que no cumple con los estndares necesarios como para ser comercializable en la
sociedad actual.
A continuacin, se presenta el contexto en el cual surge la aplicacin PESS, y las
problemticas que busca solucionar
Chile es un pas que constantemente es vctima de distintos desastres naturales, ya
sea terremotos, inundaciones, aluviones, erupciones volcnicas, etc. Pero en poca
primavera-verano, las temperaturas suben y como consecuencia de esto, se eleva la tasa de
focos de incendios por todo el pas. Estos incendios, adems de ser extremadamente difciles
de contener, dejan a su paso tremendos daos estructurales, ya sea en grandes ciudades
como en hectreas y hectreas de bosques.
Cuando se dan situaciones en que una ciudad sufre daos considerables por producto
de un incendio, luego de que se logra controlar y se normalizan los servicios primarios,
distintas entidades del gobierno organizan grupos de ayuda para las vctimas, siendo estos
conformados principalmente por las fuerzas armadas con la misin de mantener el orden
pblico. Pero a diferencia de otros pases,Chile es un pas muy solidario a la hora de
levantarse despus de tragedias y ante estas situaciones se originan iniciativas de voluntarios,
de vecinos, de pequeos empresarios y de organizaciones locales, hacindose parte de los
trabajos de respuesta ante una emergencia.
Sin embargo, al momento de la organizacin de grupos de ayuda voluntarios, surgen
ciertos problemas, ya sea que algunos de estos grupos de voluntarios actan por su cuenta, o
no cuentan con comunicacin con los otros grupos, o alguno de los grupos lo componen
personas que no cuentan con las herramientas o con las condiciones fsicas o mdicas para
participar de esta actividad.
Tomando en cuenta estas consideraciones, concretamente los eventos acontecidos
en Valparaso durante el mes de Abril del 2014, fecha en la cual se registr un incendio de
grandes proporciones que termin con daos considerables y muchas casas totalmente
destruidas, la aplicacin PESS se desarrolla con el objetivo de coordinar la ayuda posterior a
esta clase de eventos, tanto ayuda material como los trabajos realizados por voluntarios y las
herramientas necesarias para realizar estos trabajos.
Utilizando la aplicacin PESS, se podr coordinar en un rea fija (previamente
seleccionada), funciones como registrar los puntos de trabajo,inscribir voluntarios, asignarles

materiales o herramientas, y tambin asignar voluntarios a las distintas tareas de ayuda que
requieran de ellos para restablecer el sector afectado por la catstrofe.

1.1 Propsito

El propsito de este documento es definir un Plan de Calidad para la aplicacin web

PESS, abreviatura para Post Emergency Support System, para posteriormente desarrollar
de una nueva versin.
La aplicacin PESS, al momento de redactar este documento, se encuentra en su
primera versin, la cual consiste en un prototipo funcional que cuenta con todas las
funcionalidades establecidas en el plan de proyecto. Sin embargo, esta no se encuentra en un
estado ptimo para ser comercializada,esto debido a que no cuenta con los estndares de
calidad apropiados.

1.2 Alcance

El alcance de este documento ser definir las metodologas de trabajos en las

distintas etapas de la creacin del software, desde la planificacin, pasando por el diseo y la
metodologa de desarrollo, hasta la puesta en marcha y futura mantencin de la plataforma.
Se busca el poder establecer todos los requerimientos no funcionales, as como el
definir los responsables, las actividades a realizar, los recursos y los riesgos a tomar en
consideracin al momento de que se considere realizar una versin comercial de la aplicacin
en cuestin.
Cabe destacar que este Plan de Calidad dar principal enfoque a los requerimientos
no funcionales que deben estar presentes en la aplicacin y cmo estos requerimientos van a
ser parte contina del desarrollo del mismo.

2.REQUERIMIENTOS NO FUNCIONALES

Los requerimientos no funcionales (RNF) consisten en los atributos, propiedades y

restricciones que el sistema que se est desarrollando debe cumplir para operar
correctamente.
Los requerimientos no funcionales incluyen:

Restricciones: Caractersticas que no pueden ser negociadas y que son impuestas

por el cliente como gua para el sistema

Atributos de Calidad: Atributos que engloban la forma como se logran los

requerimientos funcionales

2.1.-Definicin de Atributos de Calidad

Siguiendo el estndar ISO 9126, estndar internacional para la evaluacin de la

calidad del software, en un intento de identificar los atributos clave de calidad para el software,
clasifica la calidad de software en las siguientes categoras:
1.

Eficiencia: Conjunto de atributos relacionados con la relacin entre el nivel de

desempeo del software y la cantidad de recursos necesitados bajo condiciones
establecidas.

2.

Usabilidad: Un conjunto de atributos relacionados con el esfuerzo necesario para su

uso, y en la valoracin individual de tal uso, por un establecido o implicado conjunto
de usuarios.

3.

Fiabilidad: Un conjunto de atributos relacionados con la capacidad del software de

mantener su nivel de prestacin bajo condiciones establecidas durante un perodo
establecido.

4.

Mantenibilidad: Conjunto de atributos relacionados con la facilidad de extender,

modificar o corregir errores en un sistema software.

5.

Portabilidad: Conjunto de atributos relacionados con la capacidad de un sistema

software para ser transferido desde una plataforma a otra.

2.2 Objetivos Cuantificables

Todos los requerimientos no funcionales deben poder ser cuantificados y medidos en

su grado de cumplimiento de esta forma asegurar el correcto nivel de cada uno de ellos y su
presencia por lo tanto en el producto final. Es por todo esto que se deben establecer
explcitamente objetivos cuantificables, los cuales muestren de forma objetiva y clara, tanto
para el equipo como para el cliente, el cumplimiento de estos requerimientos que apuntan a la
calidad y el rendimiento de la aplicacin. Para esto se necesita establecer los criterios de
validacin con los cuales estos objetivos se aprobarn para cada uno de los requerimientos
antes descritos.

2.2.1.- Eficiencia

En el caso de PESS, siendo una aplicacin web, su eficiencia debe ser calculada a travs de
factores como la velocidad en que se muestra el mapa de la zona, la velocidad de respuesta
de las peticiones y/o los ingresos de datos, la manera en que responde peticiones
simultneas, que el diseo sea responsivo a distintas plataformas, que funcione correctamente
con los requerimientos mnimos establecidos y la cantidad de usuarios con que la aplicacin
comienza a fallar.

2.2.1.1.- Objetivos Cuantificables.

Rendimiento

Carga

Estrs

2.2.1.2- Criterios de evaluacin

La eficiencia de software, segn ISO 9126, puede ser evaluada bajo los siguientes criterios:

Pruebas de carga: Pruebas que miden la respuesta de la aplicacin al ingreso

simultneo de muchos usuarios.

Pruebas de rendimiento: Pruebas que miden la velocidad de respuesta de la

aplicacin a muchas peticiones simultneas.

Pruebas de estrs: Pruebas que miden la cantidad de usuarios con que la aplicacin
deja de responder.

Actualmente existen muchas herramientas de prueba automticas que facilitan la

evaluacin de la eficiencia de una aplicacin. Dentro de estas herramientas se propone utilizar
Jmeter.
Jmeter, proyecto de Apache, es una herramienta que permite realizar pruebas de
rendimiento y funcionales sobre una aplicacin. Las pruebas consisten en simular distintas
situaciones de rendimiento, carga y estrs sobre la red o servidor evaluado. Estas situaciones
generarn incidencias o no conformidades que se comparan con los datos esperados y con
esto, medir cules son los por los porcentajes de eficiencia que posee la aplicacin.
Las incidencias o no conformidades se clasifican en 3 criterios:

Tiempos de respuesta

Concurrencia de usuarios

Errores HTTPS

2.2.2.- Fiabilidad

La fiabilidad es la capacidad del software para asegurar un nivel de funcionamiento

adecuado cuando es utilizado en condiciones especficas. Si un programa falla
frecuentemente, no importa si el resto de los factores de calidad son aceptables.

2.2.2.1.- Objetivos Cuantificables.

Tiempo Medio de fallos

Tiempo medio de reparacin

La medicin de fiabilidad se realiza por medio de monitoreo de un sistema en un

tiempo determinado. En este se determina el tiempo medio entre los fallos detectados y el
tiempo medio de reparacin de estos. La cantidad de fallos no es una medida til porque el
usuario se enfrenta a la aparicin de fallos y no a su cantidad total. No todos los fallos sern
detectados, ya sea porque pasen desapercibidos o que no se registren hasta despus del
lapso de tiempo establecido, por ello que se miden a travs de la media.
Para el caso de PESS, como el de cualquier aplicacin web, las peticiones y envos
de datos no toman un tiempo muy considerable, por ello se requiere medir el tiempo medio de
fallos y reparacin en un periodo de tiempo.

2.2.2.2.- Criterios de evaluacin

La fiabilidad de software, segn ISO 9126, puede ser evaluada bajo los siguientes criterios:

Madurez: L
a capacidad que tiene el software para evitar fallas cuando encuentra
errores.

Tolerancia a errores: La capacidad que tiene el software para mantener un nivel de

funcionamiento en caso de errores.

Recuperabilidad: L
a capacidad que tiene el software para restablecer su
funcionamiento adecuado y recuperar los datos afectados en el caso de una falla.

Conformidad de la fiabilidad: L
a capacidad del software de cumplir los estndares
o normas relacionadas a la fiabilidad.

2.2.3.- Usabilidad

La usabilidad corresponde al esfuerzo necesario para el uso y valoracin individual de

tal, por parte de usuarios externos.

El principal problema de la usabilidad es que es demasiado abstracta para ser medida

directamente. Esto debido a que su valor se determina por medio de los usuarios finales, por
lo que sus valores depende directamente del tipo de usuario que lo evale.
Para evaluar la usabilidad de la aplicacin se forman grupos de usuarios de distinto
tipo inspeccionen la aplicacin, estos grupos son:

Usuarios

Evaluadores

Observadores

Expertos en evaluaciones

2.2.3.2- Criterios de evaluacin

La Usabilidad, segn ISO 9126, puede ser evaluada bajo los siguientes criterios:

Entendimiento o facilidad de uso

Aprendizaje

Operabilidad

Atraccin
6

Conformidad de uso

Para el caso de PESS, siendo una aplicacin web para usuarios de distintas labores,
la plataforma debe contar con una interfaz intuitiva, consistente y responsiva; tiene que ser
fcil de usar, fcil de aprender a utilizar y que cuente con documentacin clara para cualquier
instruccin que pudiera ser poco clara.
Con todo lo mencionado anteriormente, establecemos como criterios de evaluacin.

Interfaz Intuitiva

Formato responsivo

Entendimiento

Documentacion General

2.2.4.- Mantenibilidad

Para el caso de PESS, como el de cualquier aplicacin web, se requiere que estos
tiempos sean lo ms cortos posibles. Esto ya que, al ser una aplicacin que se utiliza en
entornos variados, recibir constantes mejoras para adaptarse.
La mantenibilidad corresponde al conjunto de atributos relacionados con la facilidad
de modificar una aplicacin para corregir errores.
Para toda aplicacin web es importante el contar con una buena mantenibilidad. Esto
se debe a que este tipo de aplicaciones tienen un alto trfico de informacin y peticiones de
usuarios, adems de que es fundamental que esta sea capaz de modificarse fcilmente
durante su funcionamiento.
Es por ello que la aplicacin debe contar con un plan de mantencin que le permita
recibir fcilmente mejoras o modificaciones, y tambin que est preparada para cualquier
riesgo que estos cambios puedan provocar sobre la aplicacin.

2.2.4.2.- Objetivos Cuantificables.

El tiempo medio de cambio consiste en el total de tiempo que toma el analizar una
peticin, disear una modificacin apropiada, efectuar el cambio, probar la modificacin y
luego distribuir el cambio realizado entre todos los usuarios.

2.2.4.1.- Criterios de evaluacin

El mantenimiento se divide en 4 criterios:

Analizabilidad (Capacidad de ser analizado): La forma como el software permite

diagnsticos de deficiencias o causas de fallas, o la identificacin de partes
modificadas.

Cambiabilidad: La capacidad del software para que la implementacin de una

modificacin se pueda realizar, incluye tambin codificacin, diseo y documentacin
de cambios.

Estabilidad: La forma como el software evita efectos inesperados para

modificaciones del mismo.

Facilidad de prueba: La forma como el software permite realizar pruebas a las

modificaciones sin poner el riesgo los datos.

Para medir la mantenibilidad de la aplicacin, hay que medir el tiempo medio que toma
una modificacin de la aplicacin. Una vez estimado esto, se compara con los datos histricos
de la aplicacin para determinar el estado en que se encuentran.

Tiempo medio de cambio < 24 horas.

2.2.5.- Portabilidad

La portabilidad consiste en la capacidad de un sistema para ser transferido de un

entorno a otro.

2.2.5.1.- Objetivos Cuantificables.

Portabilidad = 1 (ET/ER)
ER: Recursos necesarios ($) para mover la aplicacin al nuevo entorno.
ET: Recursos necesarios ($) para crear al sistema para el entorno residente.

2.2.2- Criterios de evaluacin

Este se divide en 4 criterios:

Adaptabilidad: Capacidad de la aplicacin para poder adaptarse a diferentes

entornos especificados sin que se vea afectado de forma negativa ante estos
cambios.

Facilidad de Instalacin: La facilidad de la aplicacin para ser instalado en

un entorno especfico o por el usuario final.

Conformidad: Capacidad de la aplicacin para cumplir con los estndares

relacionados a la portabilidad.

Reemplazabilidad: La capacidad que tiene la aplicacin para ser

reemplazado por otra aplicacin del mismo tipo, o por una nueva versin de
esta, y para el mismo objetivo. (Ej: migrar los datos a la nueva aplicacin).

Para medir la portabilidad de la aplicacin, hay que medir que comparar los valores de
ER y ET con los que se dispone y ver como es la razon que hay entre estos. Lo ideal seria lo
siguiente:

ER < ET
Siendo lo ms aceptable que ER fuera alrededor del 40% de los recursos que cuesta ET

Bibliografia

[Wiki - IEC_9126] - https://es.wikipedia.org/wiki/ISO/IEC_9126

[Wiki - Pruebas de Carga] - https://es.wikipedia.org/wiki/Pruebas_de_rendimiento_del_software
[Testing como Prctica para Evaluar la Eficiencia en Aplicaciones Web] - Delvis Echeverra
Prez y Ariannis Abella Paumier
[Modelos de Fiabilidad de Software] - Jess Plaza Rubio