Académique Documents
Professionnel Documents
Culture Documents
Gener 2013
NDICE
1.1 Porque es necesario el testing? ........................................................................... 5
1.2 Qu es el testing? ................................................................................................. 5
1.3 Metodologas de testing ......................................................................................... 7
1.4 Objetivos del proyecto ........................................................................................... 8
1.5 Contenido de la memoria ....................................................................................... 9
2- MTODOS DE VALIDACIN ................................................................................ 11
2.1 V, V &T: Validacin, Verificacin y testing....................................................... 11
2.1.1- Verificacin ........................................................................................... 11
2.1.2- Validacin .............................................................................................. 11
2.1.3- Testing .................................................................................................... 12
2.2 Modelos del ciclo de vida .................................................................................... 13
2.2.1- Ciclo de vida lineal ............................................................................. 14
2.2.2- Ciclo de vida en cascada puro ....................................................... 15
2.2.3- Ciclo de vida en V .............................................................................. 16
2.2.4- Ciclo de vida tipo Sashimi ............................................................... 16
2.2.5- Ciclo de vida en casada con subproyecto ................................. 17
2.2.6- Ciclo de vida interactivo .................................................................. 18
2.2.7- Ciclo de vida por prototipos ........................................................... 19
2.2.7- Ciclo de vida evolutivo ..................................................................... 20
2.2.8- Ciclo de vida incremental ................................................................ 21
2.2.9- Ciclo de vida en espiral .................................................................... 23
2.2.10- Ciclo de vida orientado a objetos .............................................. 24
2.3 Conclusin ........................................................................................................... 25
3- ESTUDIO DE VIABILIDAD .................................................................................... 26
3.1 Introduccin ......................................................................................................... 26
3.2 Objetivo ............................................................................................................... 26
3.2.1- Descripcin de la situacin a tratar .............................................................. 26
3.2.2- Perfil de usuario ........................................................................................... 26
3.2.3- Objetivos ...................................................................................................... 26
3.3 Sistema a realizar ................................................................................................. 27
3.3.1- Descripcin................................................................................................... 27
3.3.2- Recursos ....................................................................................................... 27
3.3.3- Evaluacin de riesgos ................................................................................... 28
3.3.4- Organizacin del proyecto ........................................................................... 28
III
IV
Introduccin
La obtencin de un software con calidad implica la utilizacin de metodologas o
procedimientos estndares para el anlisis, diseo , programacin y prueba del
software que permitan uniformizar la filosofa de trabajo,
con el fin de lograr una
mayor confiabilidad, mantenibilidad y facilidad de prueba, a la vez que eleven la
productividad, tanto para la labor de desarrollo como para el control de la calidad
del software.
El proyecto se desarrolla en colaboracin con la empresa Pharma S.L., empresa que
se dedica, entre otras tareas, al desarrollo de software hospitalario, desde el
software utilizado para gestionar las peticiones e histricos de los pacientes, hasta
los drivers necesarios para las conexiones con los aparatos utilizados.
1.2 Qu es el testing?
Las definiciones del testing son variadas y estn cambiando con el tiempo. De todas
maneras hay definiciones que cubren todos los aspectos de qu es el testing.
Algunas definiciones incluyen:
.. ejecutar un programa con la intencin de certificar su calidad.
[1] Mills, 1970
..ejecutar un programa o sistema con la intencin de encontrar errores
[1] Myers, 1979
..establecer confianza que un programa o sistema hace lo que se
supone que debe hacer
[1] Hetzel, 1973
Planificacin
Control
Finalizacin o clausura (por ejemplo despus de una fase de test que ha sido
completada)
Bsqueda de defectos
Prevencin de defectos
El proceso de razonamiento del diseo de los tests al inicio del ciclo de vida
(verificando el test basado en el diseo de test) puede ayudar a prevenir defectos
desde el inicio introducindolos en el cdigo. La revisin de los documentos (por
ejemplo los requerimientos) tambin ayuda a prevenir defectos que pueden
aparecer en el cdigo.
Hay diferentes puntos de vista en el testing que pueden estar
basados en
diferentes objetivos. Por ejemplo, en el desarrollo del testing (como un
componente, integracin y sistema de testing) el objetivo principal ser encontrar
la causa de la gran mayora de fallos como sea posible, de tal manera que los
El testing puede mostrar fallos que son causados por los defectos
1.5 Contenido de la memoria
La informacin de la memoria se divide de la siguiente manera:
SW Build Notes 1, 2 y 3.
10
2-
MTODOS
DE
VALIDACIN
2.1 V, V &T: Validacin, Verificacin y testing
A continuacin se detallan trminos claves y necesarios para poder entender qu
significado tiene hacer una validacin, verificacin y testing del software.
2.1.1- Verificacin
2.1.2- Validacin
Confirmacin mediante exanimaciones y presentacin de evidencias
objetivas de que los requerimientos particulares de un uso que se
hayan especificado se han cumplido. [1]
La validacin es un proceso de determinacin de que el sistema actual cumplir el
propsito para el que se destin. De acuerdo con lo descrito, se asegura que el
software refleja correctamente lo que el usuario necesita.
La validacin da respuesta a las preguntas
Es un sistema correcto?
El conocimiento es correcto?
11
Aun as, es imposible tener absoluta garanta que un programa satisface las
especificaciones, solo se puede obtener un grado de confianza para que un
programa sea vlido.
2.1.3- Testing
El testing es una actividad desarrollada para evaluar la calidad del producto, y para
mejorarlo al identificar defectos y problemas. El testing de software consiste en la
verificacin dinmica del comportamiento de un programa sobre un conjunto finito
de casos de prueba, apropiadamente seleccionados, a partir del dominio de
ejecucin que usualmente es infinito, en relacin con el comportamiento esperado.
Es una tcnica dinmica en el sentido de que el programa se verifica ponindolo en
ejecucin de la forma ms parecida posible a como se ejecutar cuando est en
produccin. Esto se contrapone a las tcnicas estticas las cuales se basan en
analizar el cdigo fuente. El programa se prueba ejecutando slo unos pocos casos
de prueba dado que por lo general es fsica, econmica o tcnicamente imposible
ejecutarlo para todos los valores de entrada posibles. Si uno de los casos de prueba
detecta un error el programa es incorrecto, pero si ninguno de los casos de prueba
seleccionados encuentra un error no podemos decir que el programa es correcto
(perfecto). Esos casos de prueba son elegidos siguiendo alguna regla o criterio de
seleccin. Se determina si un caso de prueba ha detectado un error o no
comparando la salida producida con la salida esperada para la entrada
correspondiente. La salida esperada deber estar documentada en la especificacin
del programa.
Las limitaciones antes mencionadas no impiden que el testing se base en tcnicas
consistentes, sistemticas y rigurosas (e incluso, como veremos ms adelante,
formales). Sin embargo, en la prctica industrial, como ocurre con otras reas de
Ingeniera de Software, usualmente se considera slo una parte mnima de dichas
tcnicas tornando a una actividad razonablemente eficaz y eficiente en algo til y
de escaso impacto.
Aunque en la industria de software el testing es la tcnica predominante, en
aquellos casos minoritarios en que se realiza una actividad seria de V&V
(validacin&verificacin), en el ambiente acadmico se estudian muchas otras
tcnicas. Veamos algunos conceptos bsicos de testing. Testear un programa
significa ejecutarlo bajo condiciones controladas tales que permitan observar su
salida o resultados. El testing se estructura en casos de prueba o casos de test; los
casos de prueba se renen en conjuntos de prueba. Desde el punto de vista del
testing se ve a un programa (o subrutina) como una funcin que va del producto
cartesiano de sus entradas al producto cartesiano de sus salidas. Es decir:
P : ID OD
donde ID se llama dominio de entrada del programa y OD es el dominio de salida.
Normalmente los dominios de entrada y salida son conjuntos de tuplas tipadas
cuyos campos identifican a cada una de las variables de entrada o salida del
programa, es decir:
12
13
14
Este modelo de ciclo de vida fue propuesto por Winston Royce en el ao 1970. Es
un ciclo de vida que admite iteracin, contradictoriamente a la creencia de que es
un ciclo de vida secuencial como el lineal (Figura 2.2). Despus de realizar cada
etapa se realiza una o varias revisiones para comprobar si se puede pasar a la
siguiente. Es un modelo rgido, poco flexible, y con muchas restricciones. Aunque
fue uno de los primeros y sirvi de base para el resto de modelos de ciclo de vida.
15
Este ciclo fue diseado por Alan Davis (Figura 2.3) y contiene las mismas etapas
que el ciclo de vida en cascada puro. A diferencia de aqul, a ste se lo agregaron
dos subetapas de retroalimentacin entre las etapas de anlisis y mantenimiento y
entre las de diseo y debugging.
16
17
18
19
Este modelo acepta que los requerimientos del usuario pueden cambiar en
cualquier momento como se ve en el diagrama de la Figura 2.8.
La practica nos demuestra que obtener todos los requerimientos al comienzo del
proyecto es extremadamente difcil, no slo por la dificultad del usuario de
transmitir su idea, sino porque estos requerimientos a cumplir. El modelo de ciclo
de vida evolutivo afronta este problema mediante una iteracin de ciclos
requerimientos-desarrollo-evaluacin.
20
21
Este modelo de ciclo de vida no est pensando para cierto tipo de aplicaciones, sino
que est orientado a cierto tipo de usuario o cliente. Podremos utilizar este modelo
de ciclo de vida para casi cualquier proyecto, pero ser verdaderamente til cuando
el usuario necesite entregas rpidas, aunque sean parciales.
22
Este ciclo puede considerarse una variacin del modelo con prototipo, fue diseado
por Boehm en el ao 1988. El modelo se basa en una serie de ciclos repetitivos
para ir ganando madurez en el producto final, se puede observar su representacin
en la figura 2.10. Toma los beneficios de los ciclos de vida incremental y por
prototipos, pero se tiene ms en cuenta el concepto de riesgo que aparece debido a
la incertidumbre e ignorancias de los requerimientos proporcionados al principio del
proyecto o que surgirn durante el desarrollo. A medida que el ciclo se cumple (el
avance del espiral), se van obteniendo prototipos sucesivos que van ganando la
satisfaccin del cliente o usuarios. A menudo, la fuerte de incertidumbres es el
propio cliente o usuario, que en la mayora de las oportunidades no sabe con
perfeccin todas las funcionalidades que debe tener el producto.
En este modelo hay cuatro actividades que envuelven a las etapas: planificacin,
anlisis de riesgo, implementacin y evaluacin.
23
Algunas de las desventajas son: el costo temporal que suma cada vuelta del espira,
la dificultad para evaluar los riesgos y la necesidad de la presencia o la
comunicacin continua con el cliente o usuario.
Se observa que es un modelo adecuado para grandes proyectos internos de una
empresa, en donde no es posible contar con todos los requerimientos desde el
comienzo y el usuario est en nuestro mismo ambiente laboral.
Esta tcnica fue presentada en la dcada de los 90, tal vez, como una de las
mejores metodologas a seguir para la creacin de los productos software.
Al igual que la filosofa del paradigma de la programacin orientada a objetos, en
esta metodologa cada funcionalidad, o requerimiento solicitado por el usuario, es
considerado un objeto. Los objetos estn representados por un conjunto de
propiedades, a los cuales denominamos atributos, por otra parte, al
comportamiento que tendrn estos objetos los denominamos mtodos (Figura
2.11).
24
2.3 Conclusin
Despus de presentar los diferentes modelos de ciclo de vida utilizados nos
preguntamos: Qu modelo de ciclo de vida elegir?. Debemos elegir el modelo que
mejor se adapte al proyecto que desarrollaremos. Se debe analizar, para poder
guiarnos en nuestra eleccin, la complejidad del problema, el tiempo que
disponemos para hacer la entrega final, o si el usuario o cliente desea entregas
parciales, la comunicacin que existe entre el equipo de desarrollo y el usuario y
por ltimo, qu certeza (o incertidumbre) tenemos de que los requerimientos dados
por el usuario son correctos y completos.
El ciclo de vida en el desarrollo de los productos de Pharma S.L sigue el llamado
Modelo en V (V-Model) que se muestra en la Figura 2.12.
25
3-
ESTUDIO
DE
VIABILIDAD
3.1 Introduccin
El proyecto que se presenta consistir en realizar un estudio de verificacin y
validacin de un software orientado a sanidad, consiguiendo un certificado de
calidad que garantice un producto fiable y seguro.
La ventaja de realizar una validacin de un software ser: obtener un software de
calidad con el cual se evita que ocasione fallos que puedan causar riesgos con
consecuencias graves para los pacientes.
El inconveniente principal de realizar la validacin y verificacin de un software es
el tiempo necesario para llevarlo a cabo. Si un sistema necesita pasar por un
control de calidad el tiempo de lanzamiento al mercado es ms tardo. Debido a que
al equipo de calidad se le da un periodo limitado para realizar la validacin del
sistema, eso hace que la mayora de veces no sea posible cubrir todos los casos de
prueba ni cumplir todos los plazos de entrega.
3.2 Objetivo
3.2.1-
Descripcin
de
la
situacin
a
tratar
Actualmente existen sistemas de informacin para centros de atencin primaria
(CAP) y laboratorios que consigan tratar toda la informacin mediante un entorno
web. Se pretende obtener un software seguro y de calidad con mejores
prestaciones, consiguiendo una interfaz igual o ms rpida que para aplicaciones
instaladas en cada mquina de usuario.
La aplicacin no tiene ningn tipo de lmite en cuanto a usuarios, tanto puede ser
utilizado por una secretario/a o un tcnico/a de laboratorio o un mdico o
enfermero/a... todos ellos con un soporte informtico y conexin a internet.
3.2.3-
Objetivos
El objetivo principal es hacer que el software sea robusto, fiable y que cumpla todos
los requerimientos definidos para la aplicacin. Esto hace que la validacin deba ser
exhaustiva. Se debern validar los siguientes puntos:
Rendimiento.
26
3.3.2-
Recursos
Se utilizarn los siguientes recursos software:
HP Quality Center
Repositorio de test cases (TCs). Esta aplicacin permite crear y almacenar los
TCs necesarios para la validacin de la aplicacin. Adems permite crear la
matriz de trazabilidad.
Virtual Box
VMWare
27
28
del
software:
se
deberan
contemplar
mtodos
que
lo
Modelo en V
Modelo en espiral
Prototipo incremental
Todos ellos tienen en comn que son tiles para definir, construir y testear el
sistema.
En el desarrollo de un software en entorno regulado lo ms habitual es seguir el
modelo en V representado en la Figura 3.1
Este modelo refleja la correspondencia que existe entre las distintas fases de
desarrollo y las de validacin, as como las distintas actividades de validacin y
verificacin que se llevan a cabo durante el mismo.
La razn de esta correspondencia es porque deben realizarse pruebas de toda la
documentacin y entregables generados durante la creacin del producto final: las
especificaciones de los requisitos, los casos de uso (UC), los diagramas de diversos
tipos, el cdigo fuente y las distintas partes de la aplicacin.
29
Componente de test
Test funcional
Test no funcional
o
seguridad
almacenaje y volumen
usabilidad
instalacin
documentacin
30
Test de aceptacin
Duracin
( en horas)
Descripcin actividad
Estudio viabilidad
80
40
40
40
72
320
40
104
8
10
11
40
12
40
13
56
14
15
Evaluacin externa
16
8
24
Total de horas
8
928
31
3.6 Conclusiones
Con la validacin y verificacin se conseguir un software rgido, fiable y de calidad
de tal manera que sea atractivo para el mercado y que no comporte riesgos para el
paciente.
Se reducirn los posibles errores en el cliente con lo que se eliminarn los riesgos
de negocio y de paciente.
Considerando las ventajas y desventajas y habiendo hecho un estudio de los
riesgos del producto y del paciente esta aplicacin se considera viable.
32
4.2 Funcionalidades de TAONet 3.1
TAONet 3.1 es un software que facilita la gestin de pacientes ambulatorios en
tratamiento anticoagulante oral (TAO) ofreciendo soporte informtico a las tareas
especficas del personal de los centros a los que acuden los pacientes.
El TAO se utiliza en la prevencin y tratamiento de las enfermedades
tromboemblicas.
TAONet 3.1 ha sido desarrollado utilizando tecnologa Web, lo que permite una
integracin total entres los Centros de Atencin Primaria (CAP) y los centros de
Atencin Especializada (hospitales, laboratorios,), proporcionando acceso a la
informacin del paciente de forma flexible, escalable, fiable y multi-centro.
TAONet 3.1 Permite el manejo y coordinacin de las diferentes tareas de los
centros mdicos / hospitales donde el paciente acude para el seguimiento del
tratamiento de la enfermedad tromboemblica.
-
33
Cobertura de test.
Builds internos.
Control de versiones de Test Cases: cada vez que se modifique un Test Case
ser necesario modificar su versin, imprimir la modificacin y firmarlo.
hacer
34
Mdulo de paciente
Este mdulo incluye la funcionalidad correspondiente a la gestin de los
pacientes y a la aplicacin del tratamiento TAO de los mismos. Incluye la
gestin y almacenamiento de datos de paciente (demogrficos, diagnsticos,
resultados de analticas de laboratorio, tareas, visitas del paciente al
hospital, clculo y distribucin de la dosis de anticoagulante oral y gestin
de resultados de INR recibidos del coagulmetro Coaguchek S / XS Plus)
Estadsticas
Permite crear y visualizar diferentes tipos de estadsticas (grficos y tablas)
y filtrar por diferentes criterios (centros de salud, mdicos, sexo, fecha,
diagnsticos, etc.).
Agenda
Permite realizar tareas de gestin de la agenda en la que se incluye el
listado de pacientes y las correspondientes citas planificadas en el hospital /
centro mdico dentro de una franja temporal.
Administracin
Permite tareas relacionadas con los usuarios y los elementos que les
permiten trabajar con TAONet: (alta/baja/modificacin de usuarios, gestin
de perfiles de usuarios, administracin de centros mdicos, configuracin de
listados de Diagnsticos, notas clnicas, medicamentos, distribucin de las
dosis, formularios y agenda). El acceso a esta parte de la aplicacin depende
del perfil del usuario que ha entrado en TAONet.
35
Figura 4.2: Estrategia a seguir
36
37
Detectar
y
solucionar
incongruencias
o
discrepancias
en
los
comportamientos de una misma funcionalidad realizada por o para mdulos
diferentes.
38
Los errores y cambios de los que se habla han sido encontrados en la versin
anterior de la aplicacin TAONet 3.0.
En el test plan, Figura 4.4, 4.5 y 4.6, se organizan las pruebas a realizar en cada
build. En cada uno de estos planes aparece la siguiente informacin:
39
40
Fecha de ejecucin
Tiempo de ejecucin
Notas
41
Tiempo de ejecucin/persona.
42
43
44
45
Valor
High
Medium
Low
46
47
formal (si un documento Excel de control personal con los errores detectados). De
esta manera, y mientras el departamento de desarrollo acaba de completar la Build
1, se va informando a los programadores de errores a solucionar antes de la
entrega oficial de Build1.
No fue necesario realizar un smoke test de la versin, ni ejecutar test cases ya que
era una validacin informal.
Build 1
Primera entrega oficial de Build 1, donde se intentar introducir todos los cambios
realizados en esta versin y corregir el mximo de errores. De forma extraordinaria
se ejecuta todos los TCs. Habitualmente, cuando se detectan un gran nmero de
errores y hay nuevos cambios por implementar, se finalizada la validacin sin llegar
al 100%, dejando los TCs no ejectutados para la prxima Build. Adems en esta
caso se dejan errores pendientes por la conexin entre la aplicacin y la hardware
externo Cougucheck.
Build 2
Durante la segunta Build se validaron errores no corregidos y rehusados en la build
1. Adems se validaron nuevos tems que no haban entrado en la primera entrega,
por no estar corregidos en la Build 1. Como se puede observar en la Test Report de
la Build 2, se ejecutaron un total de 332 items e 392, lo que hace un 75% del total.
Los motivos de no completar el 100% el test plan vienen provocados por la
imposibilidad de validar la aplicacin con la conexin a Couguchek y la gravedad de
algunos errores. Por ese motivo se entreg la Build 3 sin estar completamente
ejecutada la Build 2.
Build 3
Para terminar, y teniendo en cuenta que el build 3 era el Release Candidate, se
validaron los tems corregidos en este build y se ejecutaron como regresin todos
los test cases de prioridad alta, adems de realizar una regresin de los mdulos
ms crticos de la aplicacin. Cabe destacar que en cada build se ha ejecutado los
smoke test, donde la validacin de las funciones principales de la aplicacin quedan
cubiertas
De este modo se consigue un build final estable aunque no exento de errores.
En este build se ejecutaron el 100% de los tems planeados.
48
Errores corregidos
y validados
Errores reabiertos
Nuevos errores
detectados
Nuevos errores con
riesgo de producto
High
Build1
92
Build2
75
Build 3
25
12
46
15
25
2
10
4.4.3.2 Evaluacin externa
49
50
Los usuarios nos hicieron llegar quejas pero todas ellas eran referentes a la
falta de configuracin.
La valoracin de los usuarios fue un 9 sobre 10, muy buena puntuacin para
una puesta en marcha.
51
5- CONCLUSIONES
52
53
Definicin
Bug
Build
Cambio / Peticin de
mejora (Product
Change).
Cobertura
Debugar
Especificaciones de
los Requerimientos
del Software
Host
LIS
Modelo en V
Operational Usage
Test Case
varios
PI
Pruebas de Regresin
Release candidate
Riesgo de negocio
54
Trmino
Definicin
Riesgo de producto
Smoke Test
Test de instalacin
Test de regresin
Test de rendimiento
Test de seguridad
Test functional
Test plan
Test Unitario
Testing
de
la
55
Trmino
Testing estructural o
de caja blanca
Definicin
Tcnica para realizar pruebas sobre la estructura
interna del sistema (cdigo). Es necesario un
conocimiento explcito del cdigo y la arquitectura
del mismo. Esta tcnica es aplicada por los
desarrolladores.
Testing basado en
modelos o de caja
negra
Validacin
Verificacin
56
REFERENCIAS
BIBLIOGRFICAS
[1]
[2]
[3]
[5]
Organismo
ANSI
Link
http://www.ansi.org
FDA
http://www.fda.gov
IEEE
http://www.ieee.org
ISO
http://www.iso.org
ISPE
http://www.ispe.org
Descripcin
ANSI es una organizacin privada sin
fines
de
lucro,
que
permite
la
estandarizacin de productos, servicios,
procesos, sistemas y personal en Estados
Unidos. Adems, ANSI se coordina con
estndares internacionales para asegurar
que
los
productos
estadounidenses
puedan ser usados a nivel mundial.
FDA es una agencia de US Department of
Health and Human Services responsable
de la proteccin de la sanidad pblica
para asegurar la seguridad, eficacia,
seguridad humana y drogas veterinarias,
productos
biolgicos,
dispositivos
mdicos, cosmticos y productos que
emiten radiacin, y para regular la
manufactura, marketing y distribucin de
productos de tabaco.
IEEE es la ms grande asociacin de
profesionales del mundo dedicada al
avance de la innovacin tecnolgica y
excelencia en beneficio de la humanidad.
IEEE y sus miembros inspiran una gran
comunidad global a travs de las
publicaciones ms citadas del IEEE,
conferencias, estndares de tecnologa,
profesionales y actividades educativas.
ISO (Organizacin Internacional para los
Estndares) es el mayor desarrollador
mundial
y
editor
de
Normas
Internacionales. ISO es una red de los
institutos de normas nacionales de 163
pases, un miembro por pas, con una
Secretara Central en Ginebra, Suiza, que
coordina el sistema.
ISPE, la Sociedad Internacional de la
Ingeniera Farmacutica, es la asociacin
ms grande del mundo sin fines de lucro
dedicada a educar y promover a los
profesionales
farmacuticos
de
fabricacin y su industria. Fundada en
1980, ISPE hoy sirve de 25.000
57
miembros en 90 pases.
PDA
[6]
[7]
http://www.pda.org/
58
59