Universidad Tecnolgica de Durango

Tecnologas de la Informacin y la Comunicacin.

Actividad I: Especificacin de requerimientos de software.

Alumnos:

Armas Daz Jess Alejandro.

Guizar Daz Juan Antonio.

Melndez Martnez Citlalli Gabriela.

Ochoa Andrade Ricardo Enrique.

Vzquez Cortes Lisy Zolu

Grupo: 5 B

Asignatura: Ingeniera de Software II.

Catedrtico: Ing. Ral Ivn Herrera Gonzlez.

Durango, Dgo. 11 de julio de 2017

Contenido
Revisin de la historia: ............................................................................................ 1

Lnea del Tiempo: ................................................................................................ 2

Contenido: ............................................................................................................... 4

1. Introduccin ................................................................................................... 4

1.1 Propsito: ................................................................................................ 4

1.2 Convenciones del documento: ................................................................ 4

1.3 Audiencia objetivo y sugerencias de lectura: .......................................... 5

1.4 Alcance del proyecto: .............................................................................. 5

1.5 Referencias ................................................................................................. 6

2. Descripcin general ....................................................................................... 7

2.1 Perspectiva del producto:........................................................................ 7

2.2 Caractersticas del producto: .................................................................. 7

2.3 Clases y caractersticas del usuario: ....................................................... 8

2.4 Ambiente de operacin: .......................................................................... 9

2.5 Restricciones de diseo e implementacin: ............................................ 9

2.6 Documentacin para el usuario: ........................................................... 10

2.7 Suposiciones y dependencias:.............................................................. 11

3. Caractersticas del sistema ......................................................................... 12

3.1 Caracterstica 1 del sistema: ................................................................. 12

3.2 Caracterstica 2 del sistema: ................................................................. 12

3.3 Caracterstica 2 del sistema: ................................................................. 12

3.4 Caracterstica 4 del sistema: ................................................................. 12

3.5 Caracterstica 5 del sistema: ................................................................. 12

3.6 Caracterstica 6 del sistema: ................................................................. 13

I
 3.7 Caracterstica 7 del sistema: ................................................................. 13

3.8 Caracterstica 8 del sistema: ................................................................. 13

4. Requerimientos de la interfaz externa ......................................................... 14

4.1 Interfaces de usuario: ........................................................................... 14

4.2 Interfaces del hardware:........................................................................ 14

4.3 Interfaces del software: ......................................................................... 15

4.4 Interfaces de las comunicaciones: ........................................................ 15

5. Otros requerimientos no funcionales ........................................................... 16

5.1 Requerimientos de desempeo: ........................................................... 17

5.2 Requerimientos de seguridad: .............................................................. 18

5.3 Requerimientos de estabilidad: ............................................................. 19

5.4 Atributos de calidad del software: ......................................................... 20

6. Otros requerimientos ................................................................................... 22

Apndice A: Glosario: ..................................................................................... 22

Apndice B: Modelos de anlisis: ................................................................... 23

Apndice C: Lista de conceptos: .................................................................... 27

Conclusiones: ........................................................................................................ 28

II
Revisin de la historia:
La donacin de sangre es, sobre todo, un hecho social, presidido por una actitud
cultural determinada, en el que inciden todo tipo convicciones religiosas, solidarias,
de contraprestacin y relaciones econmicas, instrumentalizadas por un sistema
sanitario, el actual, que ha medicalizado la relacin social. Si la sociedad se funda
en el intercambio, y donar supone encadenar tres obligaciones, la de donar, la de
recibir y la de devolver, los donantes de sangre son los guardianes de las esencias
de lo que supone vivir en comunidad amparados por un vnculo de sangre.

Desde tiempo atrs ha existido la donacin de sangre, la cual consiste en extraer

una unidad de esta misma de una persona y despus realizarle una transfusin a
otro individuo para brindarle la oportunidad de seguir viviendo.

El proceso al cual se someten los donadores es muy riguroso y muy tardado. Desde
la antigedad distintos pueblos y culturas han atribuido a la sangre innumerables
propiedades, al considerarla como un elemento vital.

Considerando el antiguo concepto de que el ingreso de sangre en nuestro cuerpo

da vida, el antecedente de la transfusin fue la ingesta de sangre, de los enemigos
o de los animales para adquirir fortaleza u otras cualidades.

1
Lnea del Tiempo:
1492 Primer caso conocido de transfusin de sangre
Al papa Inocencio VIII. Cay enfermo y se le administr sangre de tres
nios por la boca. Cost la vida a los nios y no salv la del pontfice.
1628 Circulacin de la sangre
La descubre el fsico ingls William Harvey.
1667 De animales a humanos
Jean Baptiste Denis en Francia y Richard Lower en Inglaterra por
separado documentan la realizacin de transfusiones de animales a
humanos. Los malos resultados ocasionan su prohibicin.
1818 Primeras transfusiones con xito
Las realiza el obstetra britnico James Blundell para tratar
hemorragias postparto. La precariedad de los medios y la coagulacin
hacen que todava sea una prctica peligrosa.
1867 Antispticos
El cirujano ingls Joseph Lister usa antispticos para controlar las
infecciones en las transfusiones.
1900 Grupos sanguneos
Karl Landsteiner descubre que las personas tienen diferentes tipos de
sangre y que las transfusiones no son compatibles entre personas de
distinto grupo sanguneo. En 1901 describe el sistema de ABO y en
1940 el sistema RH.
1914 Anticoagulantes
Varios cientficos consiguen conservar la sangre utilizando citrato
sdico para evitar la coagulacin. Permiti, en la I Guerra Mundial,
trasladar sangre al campo de batalla.
1921 Bancos de donantes
Para solventar los problemas de abastecimiento la Cruz Roja de
Londres crea la primera entidad municipal de donantes de sangre del
mundo. Un servicio gratuito para donante y hospital.

2
 1936 Donaciones en Espaa
Las primeras van aparejadas a necesidades de transfusiones. El
Doctor Elsegui realiz varias transfusiones durante la Guerra Civil.
1940 Fraccionamiento
Edwin Cohn, un profesor de qumica biolgica en la Escuela de
Medicina de Harvard, desarrolla el proceso que divide el plasma en
sus componentes y productos.
1947 Primer servicio en Navarra
Se crea el Servicio Permanente de Transfusiones de Sangre de
Navarra dirigido por el doctor Lucea, que junto con las enfermeras
Pilar Seriola y Julia Bayona realizan la primera transfusin del servicio
en Tafalla.
1961 Plaquetas y cncer
Se reconoce el papel de los concentrados de plaquetas en la
reduccin de la mortalidad por hemorragias en pacientes de cncer.
1970 Donacin voluntaria
Los bancos de sangre se reconducen hacia sistemas de donacin de
sangre basados por completo en el voluntariado.
1980's Era de la transfusin en la medicina
Los hospitales y los bancos de sangre abren esta etapa gracias al
crecimiento de la terapia de componentes, los productos para los
desrdenes de coagulacin y el uso de plasma para los problemas
inmunolgicos.
1984 Vida de los glbulos rojos
Soluciones basadas en aditivos incrementan la duracin de los
hemates almacenados a 42 das.
1985 Tests que detectan el VIH
Se desarrollan y se introducen estas pruebas en los bancos de sangre
para proteger el proceso de donacin.

3
Contenido:
1. Introduccin
1.1 Propsito:
Este documento contiene toda la informacin correspondiente del proyecto
integrador del quinto semestre en la carrera Tecnologas de la Informacin y la
Comunicacin, en el mismo se especifican las descripciones generales, las
caractersticas del sistema, las interfaces de usuario y los requerimientos del
proyecto, todo esto con el fin de ofrecer todo lo relacionado con el mismo para las
personas que deseen conocer a fondo lo desarrollado.

1.2 Convenciones del documento:

Para ayudar a reconocer o identificar la informacin fcilmente en el documento le
incluimos las siguientes convenciones (trminos).

Convenciones: Descripcin:
Son todas las marcar registradas, por ejemplo:
Negrita
Android.
Todas la palabras que podremos encontrar en el
Cursiva
glosario estn el formato de cursiva.

4
 1.3 Audiencia objetivo y sugerencias de lectura:
Audiencia objetivo:
Va a dirigido al pblico en general, ya que no contiene tecnicismos, esto con la
finalidad que sea del entendimiento para la mayora de las personas.

Sugerencias de lectura:
Se le sugiere al lector tener en cuenta todas las convenciones, ya que estas ayudan
a una mayor comprensin del contenido. Tambin se recomienda buscar las
palabras que no comprenda en el Glosario que se anexa al final del documento.

1.4 Alcance del proyecto:

Este proyecto es un pequeo avance a la unificar el sistema de donacin de sangre.
Este se centra en llevar la donacin de sangre con una mayor eficiencia, ya que el
mtodo convencional suele ser demasiado lento e ineficiente y por esto hemos
tomado la iniciativa de realizar un prototipo con Arduino y que esta toma el peso,
altura la presin sangunea del paciente, para despus continuar con la tradicional
encuesta entre el mdico y el donante.

5
 1.5 Referencias

Cuello, J., & Vittone, J. (2013). Diseando apps para mviles. Buenos Aires:
Independiente. Obtenido de
http://appdesignbook.com/es/contenidos/patrones-interaccion-moviles/

Glvez, J. (12 de Noviembre de 2008). UTP Ingeniera del software I. Obtenido de

UTP Ingeniera del software I: http://utpingsof1.blogspot.mx/2008/11/los-
requerimientos-no-funcionales.html

Gbegnedji Castao, G. (02 de Noviembre de 2012). WHAT IS PROJECT

MANAGEMENT? Obtenido de WHAT IS PROJECT MANAGEMENT?:
https://whatisprojectmanagement.wordpress.com/2012/11/02/definir-el-
alcance-del-proyecto/

Jorge. (26 de Febrero de 2016). Aplicarium. Obtenido de Aplicarium:

http://aplicarium.com/blog/usabilidad-en-una-app/

Perez Escobar, C. J. (19 de Abril de 2013). Qu significa CMMI. Obtenido de Qu

significa CMMI: http://asprotech.blogspot.mx/2013/04/atributos-y-medidas-
de-calidad-del.html

pmoinformatica. (21 de Enero de 2013). PMOinformatica. Obtenido de

PMOinformatica: http://www.pmoinformatica.com/2013/01/requerimientos-
no-funcionales-porque.html

6
 2. Descripcin general
2.1 Perspectiva del producto:
El objetivo principal de Save a Life es brindar informacin confiable sobre el proceso
de donacin (requisitos, tiempos y lugares) para ayudar a donadores y receptores
durante su experiencia en los bancos de sangre, as como facilitar y agilizar el
proceso de seleccin de donadores que cumplan con los requisitos de cada banco
de sangre.

2.2 Caractersticas del producto:

Aplicacin mvil (Android) con acceso a base de datos que contendr la
informacin de los bancos de sangre dependiendo la localidad desde la que se
realiza la bsqueda, as como horarios y otra informacin que pueda ser relevante
para la donacin de sangre.

Aplicacin web que permite registrar datos del paciente al realizar su evaluacin en
el banco de sangre, la evaluacin ser realizada por personal capacitado que labore
en el banco de sangre, para agilizar el proceso se podr utilizar el prototipo que
acompaa a la aplicacin y permite medir temperatura, altura y peso del paciente.

Prototipo realizado con una placa Arduino y sensores que permiten al personal
del banco de sangre agilizar el proceso de seleccin mediante el uso de los
sensores para registrar en la aplicacin web la informacin detallada del paciente
de forma segura y confiable con la finalidad de llevar un registro completo para
futuras visitas.

7
 2.3 Clases y caractersticas del usuario:
Usuario estndar:
Cualquier usuario que descargue la aplicacin mvil, puede realizar un registro en
la aplicacin para ser donador o receptor.

Usuario experto:
Usuario que tendr conocimiento completo sobre la aplicacin, el prototipo y la
plataforma, para esta ltima deber contar con un usuario y contrasea que le ser
proporcionado por un administrador, podr hacer uso de la aplicacin y el prototipo
para atender a nuevos donadores.

Usuario administrador:
Sera encargado de autorizar el uso de la plataforma de evaluacin al paciente,
otorgara un usuario y contrasea a quien utilice el prototipo en los centros de
transfusin sangunea, adems de contar con acceso total a la informacin de
donadores y receptores.

Sper administrador:
Tiene el control y conocimiento total de la plataforma, prototipo y aplicacin, se
encarga de mantener los servicios activos y realizar el mantenimiento en caso de
ser necesario.

Sper-
Tarea Estndar Experto Administrador
Administrador
Registro de usuario x x x X
Inicio de sesin x x x X
Aplicacin web x x X
Registro de enfermeras x X
Uso de prototipo x X
Acceso a cdigo x

8
 2.4 Ambiente de operacin:
La aplicacin mvil funcionar sobre la plataforma Android a partir de la versin
4.0 Ice Cream Sandwich utilizando pocos requerimientos con lo que ya cuenta
cualquier equipo actualmente (Pantalla tctil, conexin wifi o red de datos y sensor
de localizacin) por lo que ser soportada por la mayora de los equipos utilizados
actualmente por parte del pblico a quien va dirigido.

La aplicacin web podr ser visitada desde los navegadores ms populares

(Chrome, Firefox y Edge) y contar solo con versin de escritorio para que en
los centros de transfusin se puede utilizar como complemento al prototipo y ayude
a registrar los datos de los donadores de manera rpida y sencilla.

El prototipo Arduino que ayudara a la seleccin mediante el uso de sensores ser

utilizado solo en los centros den transfusin y ser manejado mediante la interface
de la aplicacin web.

2.5 Restricciones de diseo e implementacin:

La aplicacin mvil ser desarrollada solo para el sistema operativo Android en
su primera fase, se tiene planeado evaluar la aceptacin de los usuarios para
ampliar el campo de la aplicacin a otros sistemas operativos.

La aplicacin web contar solo con una versin de escritorio ya que su principal
funcin ser el uso en los bancos de sangre y en conjunto con el prototipo Arduino
para la evaluacin y el registro de los datos del paciente.

El prototipo Arduino no tendr una carcasa que cubra la placa y los sensores lo
que dar un aspecto austero y solo ser probado o utilizado en los centros de
transfusin sin ser de acceso al pblico en general.

9
 2.6 Documentacin para el usuario:
Tanto la aplicacin mvil como de escritorio contaran con una seccin de ayuda
destinada a guiar al usuario en las tareas cotidianas, utilizando una serie de
imgenes para orientarlos en la primera visita o para resolver cualquier duda que
se pueda presentar mientras se utiliza el software.

Se realizar un manual de usuario que estar destinado a los centros de transfusin

y permitir conocer el objetivo principal de la plataforma y la utilidad de tener la
informacin en una base de datos para garantizar el acceso desde cualquier equipo
en otros centros.

Los centros de transfusin que utilicen el prototipo Arduino contaran con un

manual tcnico que ayudara a interpretar los datos que el dispositivo arroje y
adems tendr informacin sobre los posibles errores o fallos comunes en los
sensores y los pasos a seguir para corregirlo.

10
 2.7 Suposiciones y dependencias:
Los requerimientos y objetivos del proyecto se mantendrn sin modificaciones a
menos que se encuentre una manera ms ptima de cumplir con los objetivos
principales de la misma.

Las dependencias de la aplicacin mvil y web son las siguientes:

Acceso a internet.
Servidor con base de datos y alojamiento de la aplicacin web disponible al
momento de utilizarlas.

Las dependencias del prototipo Arduino son:

Conexin a un equipo de cmputo en el que se est trabajando con la

aplicacin web.

Se asume que los usuarios del sistema deben poseer conocimiento y habilidades
en el mbito de sus funciones: conocimiento de los procedimientos definidos por la
institucin.

11
 3. Caractersticas del sistema
3.1 Caracterstica 1 del sistema:
El sistema ofrece una interfaz para registrarse. Al hacer esto se ofrece una mayor
seguridad, ya que con ello permite resguardar los datos personales, pudiendo as
proteger la identidad de cada uno de los usuarios de la aplicacin. Adems, con
esta funcin es posible reconocer a los usuarios y con ello evitar el tener que
introducir los datos generales cada vez que haga uso de la aplicacin.

3.2 Caracterstica 2 del sistema:

Otra caracterstica importante es que la aplicacin ofrece la opcin de registrarse
como donador o registrar a alguna persona que necesite sangre. Con ello
incrementa al doble la utilidad y a su vez duplica la cantidad de usuarios de la
aplicacin.

3.3 Caracterstica 2 del sistema:

Al registrarse como donante ofrece la opcin de agendar una cita para acudir a
algn banco de sangre a que le realicen la extraccin de una unidad.

3.4 Caracterstica 4 del sistema:

Una de las caractersticas ms importantes que ofrece el sistema es que cuenta con
un apartado para consultar la informacin necesaria sobre los requisitos que debe
reunir un donante para poder realizar esta buena obra. En este mismo apartado
muestra la informacin sobre los bancos de sangre, tales como horarios, telfonos,
etc.

3.5 Caracterstica 5 del sistema:

Al ser una aplicacin tan eficiente y til se espera que se incremente el porcentaje
de donadores altruistas ya que actualmente solo un 3% de las donaciones son de
este tipo.

12
 3.6 Caracterstica 6 del sistema:
La aplicacin cuenta con un sistema de localizacin, con ello ofrece la posibilidad
de ubicar los bancos de sangre con facilidad, incitando con ello a la gente a acudir
a realizar donaciones.

3.7 Caracterstica 7 del sistema:

En la aplicacin hay una interfaz la cual muestra una gota de sangre, la cual se va
llenando conforme se van realizando donaciones. Con esto se trata de persuadir a
los usuarios para que realicen ms donaciones cada que les es posible.

3.8 Caracterstica 8 del sistema:

Al registrarse como donador la aplicacin cuenta con una funcionalidad la cual
manda una notificacin cuando hay algn paciente que necesite el tipo de sangre
que tiene la persona registrada. Al contar con esta caracterstica se espera ayudar
a los pacientes con los donadores y con ello salvar vidas.

13
 4. Requerimientos de la interfaz externa
4.1 Interfaces de usuario:
Por parte de la aplicacin mvil el uso de
una interfaz sencilla ser primordial ya que
estar disponible para todo tipo de personas
y necesitar ser entendible e intuitiva. Lo
primero que ser visible en pantalla para el
usuario ser una pantalla de inicio de sesin
por medio de correo electrnico o
Facebook para que el usuario pueda
entrar en contacto con el resto de la
aplicacin.

De ah pasar al men principal en el cual podr escoger que es lo que desea hacer
como es el donar sangre, revisar su perfil, su historial de donaciones, o buscar un
donador.

Por otro lado, la aplicacin web servir de mano de las enfermeras para que puedan
llevar el registro de los donadores, de igual manera tendr una pantalla para inicio
de sesin.

4.2 Interfaces del hardware:

Por parte del uso del sensor de temperatura, el de altura y el alcoholmetro, estos
estarn conectados al Arduino y este a su vez se conectar por medio de un cable
USB a una computadora. El uso de estos componentes ser exclusivo del personal
del hospital.

14
 4.3 Interfaces del software:
La aplicacin web, por su parte, utilizar una conexin a una base de datos donde
se llevar el registro de los donantes y los resultados que se obtengan del Arduino
sobre los sensores, cuyos resultados sern enviados primero a la aplicacin web
para despus ser guardados en la base de datos si estos son correctos.

4.4 Interfaces de las comunicaciones:

La aplicacin web se comunicar por medio de Wifi y la aplicacin mvil tambin
podr comunicarse por medio de datos. A la base de datos se tendr acceso por
medio de un servidor.

15
 5. Otros requerimientos no funcionales
Se definen requerimientos no funcionales como las caractersticas que el sistema
debe tener para asegurar la calidad de los servicios presentados por el mismo.

La adecuada definicin de estos requerimientos sirve como gua durante el proceso

de desarrollo y garantiza que el sistema cumpla con las expectativas de tipo no
funcional requeridas por el cliente.

Es importante tener en claro dichos requerimientos ya que esto permite el efectivo

diseo y desarrollo de una solucin adecuada a las necesidades reales del cliente.

A continuacin, se muestran los requerimientos no funcionales con los que cuenta

la aplicacin Save a Life.

16
 5.1 Requerimientos de desempeo:
No muchas aplicaciones requieren realmente un elevado desempeo, pero es un
atributo muy solicitado, parece ser porque es fcilmente cuantificable y validable.
Pero cuando realmente es importante, se convierte en algo crtico que puede hacer
viable o no un determinado proyecto.

Por desempeo se hace referencia a la habilidad del sistema de procesar las

operaciones de un usuario individual dentro de unos tiempos de respuesta
deseados.

En seguida, se muestra una tabla con estas operaciones y los tiempos de respuesta
promedio esperados por el usuario para los mismos.

Proceso realizado Tiempo de respuesta

Abrir/Cargar la aplicacin:
Confirmacin de datos
enviados:
Validacin de datos enviados.
Presentacin de pantallas de
informacin y de formularios
5 segundos
3 segundos
Tiene un lmite de 3 segundos, se realiza la peticin de datos al
servidor y si no hay respuesta en ese tiempo estimado se
marcar como error de comunicacin y se mostrar la opcin
para reintentar.
3 segundos (La carga de pantalla ser del mnimo requerido
dependiendo de la potencia del equipo en el que se est
usando, es decir no se pondr ningn tipo de tiempo mnimo u
obligatorio de espera para el usuario).

17
 5.2 Requerimientos de seguridad:
Por seguridad se hace referencia a la habilidad del sistema de controlar el acceso
a los datos, servicios e informacin; as como la capacidad de detectar, aislar y
restablecer continuidad ante una falla de seguridad.

La aplicacin debe cumplir con unos requisitos mnimos de seguridad, los cuales se
describen a continuacin:

Los permisos de acceso al sistema podrn ser cambiados solamente

por el administrador de acceso a datos.
De acuerdo al nivel de seguridad, la aplicacin permitir a los usuarios
registrados en el sistema el ingreso hacia las diversas funcionalidades,
permitiendo el filtrado de datos de acuerdo al rol o perfil del usuario.
Asegurar que los contenidos de los mensajes no son alterados durante
su trnsito por la red.
El usuario solo podr navegar entre las pginas del sistema a travs
de las opciones que le presenta la aplicacin y solo podr acceder a
aquellas autorizadas para el rol correspondiente.
Todas las comunicaciones externas entre servidores de datos,
aplicacin y cliente del sistema deben estar encriptadas y as hacer
ilegibles para terceros los mensajes enviados hacia/desde la
aplicacin.
El sistema debe proporcionar las funcionalidades de autenticacin.
Para tal fin debe proveer las interfaces de usuario necesarias para
permitir las siguientes funcionalidades:
o Pantalla para autenticacin de usuarios en el sistema (usuario y
contrasea).
o Pantalla para cambio de contrasea del usuario. Debe pedir la
contrasea anterior y la nueva contrasea.

18
 5.3 Requerimientos de estabilidad:
Se le llama estabilidad a la propiedad de algunos sistemas que no poseen tantos
fallos, o aquellos que su nivel de fallos es escaso o bajo.

A menos fallos, mayor estabilidad, y viceversa:

La aplicacin cuenta con la facilidad de evitar efectos inesperados a causa

de modificaciones del software.
Gracias a que utilizamos el hardware que todo equipo tiene actualmente, es
poco probable que tengamos alguna falla por compatibilidad, adems de que
la versin en la que est desarrollada la aplicacin permite que se ejecute sin
problemas en ms del 97% de dispositivos a nivel mundial.
La informacin de la base de datos se tendr en un servidor que nos
garantice el 99% de disponibilidad por lo que la conexin en inicio de sesin,
consultas o actualizacin de datos ser estable y con pocas probabilidades
de errores.

19
 5.4 Atributos de calidad del software:
Un atributo es una propiedad del producto, que cuando es asociada con la calidad
se relaciona con los elementos que considera el cliente para aceptar o rechazar el
producto. Estos atributos de calidad deben ser medidos para poder ser comparados.

Son las cualidades o propiedades de calidad que la aplicacin debe satisfacer. La

calidad de una aplicacin se mide en funcin de sus atributos de calidad.

Enseguida se presentan con los que cuenta la aplicacin:

Fiabilidad:
La aplicacin lleva a cabo las operaciones especificadas con la precisin requerida
y se verifica mediante pruebas que cumpla con los requerimientos.

Eficiencia:
Hace buen uso de los recursos que manipula. Indicadores de eficiencia incluyen el
tiempo de finalizacin de tareas y tiempo de aprendizaje. A menor cantidad de
esfuerzo o recursos, mayor eficiencia.

Usabilidad:
Ofrecer al usuario lo que busca de una manera rpida y sencilla, as como tambin
satisface las necesidades en el menor tiempo posible y sin necesidad de que el
usuario tenga grandes conocimientos de su uso o requiera un largo proceso de
aprendizaje.

Simplicidad:
Est directamente relacionada con la usabilidad. Ser simple implica en cierta medida
ser mnimo, contar con pocos elementos, pero, sobre todo, que aquellos presentes
en la interfaz tengan una funcin bien definida que contribuya a cumplir el objetivo
de la app y ayude al usuario.

Robustez:
Reacciona apropiadamente ante condiciones excepcionales, se comprob por
medio de pruebas al introducir datos reales y errneos, as como tambin mediante
la verificacin del envo de las alertas correctas.

20
 Consistencia:
Save a Life tiene diferentes pantallas que la componen y al mismo tiempo, est
dentro de un sistema operativo que propone un determinado aspecto visual e
interaccin. La relacin existente entre apariencia y comportamiento tambin tiene
que ser consistente, esto favorece el uso intuitivo de la app, ya que el usuario puede
prever su comportamiento sin demasiado esfuerzo.

Compatibilidad:
Cuenta con este atributo ya que es fcil de combinar diferentes elementos de
software con el fin de ejecutar una labor en conjunto, en este caso la aplicacin
cuenta con la posibilidad de que el usuario inicie sesin con una cuenta de
Facebook o de Google, as como tambin podr activar el dictado por voz y ste
ser compatible con la aplicacin.

Extensibilidad:
El software puede adaptarse a cambios en la especificacin de requerimientos
sugeridos por el cliente.

Navegacin:
Una navegacin simple y consistente entre las interfaces con las que cuenta es un
componente esencial en la experiencia de uso de la app.

Accesibilidad:
Consideraciones tenidas en cuenta por posibles limitaciones fsicas, visuales,
auditivas o de otra ndole de los usuarios, tanto para una persona con discapacidad,
como para cualquier otra persona que se encuentre bajo circunstancias externas
que dificulten su acceso a la informacin (en caso de ruidos externos, en situaciones
donde nuestra atencin visual y auditiva no estn disponibles, pantallas con
visibilidad reducida, etc.).

Internacionalizacin:
Se preparar para ser traducida a varios idiomas, y usar distintos formatos de fecha
modo tal que permita una fcil localizacin con destino a audiencias de diferentes
culturas, regiones o idiomas.

21
 6. Otros requerimientos
Apndice A: Glosario:
Software:

Conjunto de programas, instrucciones y reglas informticas para ejecutar ciertas

tareas en una computadora.

Hardware:

Conjunto de elementos fsicos o materiales que constituyen una computadora o un

sistema informtico.

Convenciones:

Norma o prctica admitida por costumbre, acuerdo o tradicin.

Presidido:

Predominar, tener principal influjo.

Prototipo:

Ejemplar original o primer molde en que se fabrica una figura u otra cosa.

22
 Apndice B: Modelos de anlisis:
En el mbito tcnico, la ingeniera de software comienza con una serie de tareas de
modelado que conducen a una especificaci6n de requisitos y a una representacin
completa del diseo del software que se construir. EI modelo de anlisis, que en
realidad es una serie de modelos, es la primera representacin tcnica de un
sistema.

EI modelo de anlisis debe cumplir tres objetivos primarios:

1. Describir lo que requiere el cliente

2. Establecer una base para la creacin de un diseo de software
3. Definir un conjunto de requisitos que puedan validarse una vez construido el
software.

EI modelo de anlisis llena el vaco entre una descripci6n al nivel de sistema que
detalla la funcionalidad general del sistema, la cual se logra al aplicar software,
hardware, datos, humanos y otros elementos del sistema y del diseo de software
que detallan la arquitectura de aplicacin del software, la interfaz con el usuario y la
estructura en el nivel de componentes.

23
 Casos de Uso

que necesitas

registro de cita
haz una cita

direccion
contacto

inicio de sesion
llamada al hospital
informacion del usuario

usuario

historial
menu perfil

registro con facebook regstro del donante

donar

registro
solicitar
buscar tipo de sangre
registro con correo electronico

acerca de

opciones
ayuda

terminos y condiciones

configuracion

salir

cerrar sesion

24
 Clases

Actividades

registrarse
menu inicial

registrate registrarse registrate registo fal...

con google con facebook con email

iniciar sesion regitro exitoso

...
opciones

contacto cerrar sesion

que necesitas haz una cita

entrar al perfil donar solicitar ajustes salir

registra una
cita

direccion llamar al
hospital

25
 Estados
Inicio del sistema Nuevo Es Registrado Registrado Asigna consultorio Entra
Donante consultorio

Llega al consultorio

Final de Actividades Unidad Aprovado Toma de

Donada muestra
Realiza Donacion Resultado

26
 Apndice C: Lista de conceptos:
Chrome. Es un navegador web desarrollado por Google y compilado con base
en varios componentes e infraestructuras de desarrollo de aplicaciones de cdigo
abierto.

Firefox. Es un navegador web libre y de cdigo abierto desarrollado para Linux,

Android, IOS OS X y Microsoft Windows coordinado por la Corporacin
Mozilla y la Fundacin Mozilla.

Edge. Es un navegador web desarrollado por Microsoft, que se encuentra

incluido en Windows 10, reemplazando a Internet Explorer como navegador
web preestablecido.

Android. Es un sistema operativo basado en el ncleo Linux. Fue diseado

principalmente para dispositivos mviles con pantalla tctil, como telfonos
inteligentes, tablets o tablfonos; y tambin para relojes inteligentes, televisores y
automviles. Inicialmente fue desarrollado por Android Inc.

Arduino. Es una compaa de hardware libre y una comunidad tecnolgica que

disea y manufactura placas computadora de desarrollo de hardware y software,
compuesta respectivamente por circuitos impresos que integran un
microcontrolador y un entorno de desarrollo (IDE), en donde se programa cada
placa.

27
Conclusiones:

28