Metodologia Scrum
Metodologia Scrum
Certifico que el presente trabajo fue realizado en su totalidad por el Sr. Kléber
DIRECTOR
i
LISTADO DE TABLAS
CAPÍTULO 1......................................................................................................... 3
1.1. Introducción..........................................................................................3
1.3. Alcance.................................................................................................9
1.4. Objetivos.............................................................................................11
CAPÍTULO 2.......................................................................................................13
2.5. SCRUM..................................................................................................28
2.5.1. Introducción.....................................................................................28
CAPÍTULO 3.......................................................................................................42
3.1. Metodología...........................................................................................42
3.3.1. Planificación....................................................................................45
3.3.2. Análisis............................................................................................46
3.3.3. Diseño.............................................................................................46
3.4. Herramientas..........................................................................................56
3.4.4. Sprintometer....................................................................................58
3.4.6. Jira...................................................................................................60
CAPÍTULO 4........................................................................................................61
4.1.1. Planificación....................................................................................61
4.1.5. Diseño.............................................................................................72
4.2. Conclusiones........................................................................................131
4.3. Recomendaciones................................................................................139
BIBLIOGRAFÍA..................................................................................................141
Prerrequisitos.................................................................................................175
Instalación......................................................................................................175
Aplicación principal.........................................................................................177
Generalidades.............................................................................................177
Módulo de administración...............................................................................181
Administración de usuarios.........................................................................181
Administración de equipos..........................................................................182
Asignación de equipos................................................................................182
Módulo de Gestión.........................................................................................184
Asignación de lecturas................................................................................186
Aplicación móvil.................................................................................................189
Prerrequisitos.................................................................................................189
Instalación......................................................................................................189
Acceso a la aplicación....................................................................................190
DESBLOQUEO DE LECTURAS....................................................................191
Lecturas Excedentes......................................................................................192
Sincronización en línea..................................................................................192
BIOGRAFÍA.......................................................................................................194
RESUMEN
1
ABSTRACT
The current market is very competitive and always is changing. For this reason
the development of the Software is looking for speed, quality and cost reduction in
agility and flexibility, these characteristics constitute the basis for agile
development methodologies.
there are a lot of alternatives, and the responsible of each project must to select
The project is focused on the study of agile method SCRUM and implementation
1.1. Introducción
Municipio Quito, entre otras a nivel nacional; para las que el levantamiento de
análisis, registro, etc. y para los cuales es necesario una eficiente y oportuna
con funcionalidades bastante limitadas, todo esto sumado a los altos costos de
adquisición y mantenimiento.
difusión, relativos bajos costos, entre otras características, hacen de estos una
Para exponer los factores que justifican la ejecución del presente proyecto,
ASISTECOM
1
Apuntes de Administración. (s.f.). apuntesyama. Recuperado el 10 de 02 de 2012, de
http://apuntesyama.galeon.com/ischikawa.html
1.2.1. Matriz de soluciones
PESO A
1- 10PONDERACIÓN B
CUANTIFICACIÓN
CAUSA
CRITERIOS
SUB CAUSAS
RESUMEN
TOTAL
SOLUCIONES
ACCIONES /
C
Existen nuevas
(1) Nuevas tecnologías, pero Utilización de nuevas
Subutilizados
7
tecnologías la empresa no tecnologías
pude hacer uso de
estas
Existen equipos
(0) Nuevos más eficientes, de
Adquisición de Nuevos
menor costo, pero 4 16 16
Equipos la empresa no
equipos
puede utilizarlos
1
Soporte Técnico
(5)
Técnico
8
Frecuencia soporte técnico del soporte técnico
actual proveedor
Mantenimiento
El actual
(7) proveedor obliga a
Plataforma
Existen procesos
Tiempos de
El software de
(4) Facilidad de Uso
recolección de
datos debe ser de
fácil utilización
Mejorar facilidad de uso 2
para el personal
operativo.
(software)
Administración
Gastos elevados
Reducción de gastos por
11 Excesivo por mantenimiento
soporte técnico.
8
técnico
y soporte técnico.
26 104
Se busca ampliar
(10)
La calidad del
Mejorar calidad para
servicio influye
en la imagen de
mejorar imagen 9
institucional
la empresa.
brindar un mejor servicio así como optimizar el proceso para reducir los gastos
1.3. Alcance
del presente proyecto, así como los alcance del nuevo sistema informático para
permita:
dispositivos móviles.
información de la empresa.
producción.
en sí, sino también los recursos utilizados (usuarios, equipos, etc.), optimizará la
1.4. Objetivos
desarrollo de software.
proyecto.
Analizar el proceso de Recolección de Información Masiva en la empresa
Este capítulo tiene como objetivo, brindar una descripción del marco teórico
términos de formación y costos de herramientas utilizadas. Por otro lado están las
características de los proyectos para los cuales las metodologías ágiles han sido
nuevas tecnologías.
2
(Independent Signatories of The Manifesto for Agile Software Development)
Estas metodologías se centran en el factor humano y el producto software; es
cliente y al desarrollo incremental del software con iteraciones cortas (en tiempo).
computación cada vez más y más complejos, asociado a la inmadurez del propio
presupuestos y fechas estimadas para su ejecución, por lo que las perdidas iban
La importancia adquirida por los sistemas de computación dio lugar a una fuerte
deseada.
3
F. L. Bauer, Primera conferencia de la tecnología de dotación lógica de la OTAN (Garmisch
1968)
Esta etapa de crisis fue superada no únicamente por la mejora en la gestión de
los proyectos sino también por los progresos que se estaban dando en los
Entre las principales metodologías de este tipo se encuentra RUP y MSF, que
Otras características importantes dentro de este enfoque son los altos costos de
entorno es cambiante.
4
RATIONA,31 de enero de 2012 <http://www.rational.com.ar/herramientas/rup.html>
requerimientos de los usuarios finales (respetando cronograma y presupuesto).
Fue desarrollado por Rational Software, y está integrado con toda la suite de
5
MICROSOFT, 31 de enero de 2012
<http://msdn.microsoft.com/es- es/library/ms195024%28v=vs.80%29.aspx>
MSF divide a todo proyecto, separándolo en cinco fases principales:
Visión y Alcances.
Planificación.
Desarrollo.
Estabilización.
Implantación.
2.3.1. Antecedentes
actividades desarrolladas.
Tras esta reunión se creó The Agile Alliance3, una organización, sin fines de
“ágil”.
6
(Independent Signatories of The Manifesto for Agile Software Development)
equipo y que éste configure su propio entorno de desarrollo en base a sus
necesidades.
habilidad de responder a los cambios que puedan surgir a los largo del
Los valores enumerados anteriormente inspiran los doce principios del manifiesto,
estos son:
II. Dar la bienvenida a los cambios. Se capturan los cambios para que el
entregas.
IV. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo
del proyecto.
VI. El diálogo cara a cara es el método más eficiente y efectivo para comunicar
constante.
agilidad.
X. La simplicidad es esencial.
populares han suscrito el manifiesto ágil y coinciden con los principios enunciados
de ellas han siendo utilizadas con éxito en proyectos reales pero disponen de
2.3.3.1. SCRUM7
Figura 4. SCRUM
7
CONTROLCHAOS ,31 de enero de 2012 <http://www.scrum.org/scrumguides/>
Sus principales características se pueden resumir en:
2.3.3.2. ExtremeProgramming8
un conjunto de prácticas que a lo largo de los años han demostrado ser las
8
PROGRAMACIONEXTREMA,31 de enero de 2012 <http://www.programacionextrema.org>
22
2.3.3.3. Crystal Methodologies9
por AlistairCockburn.
factor clave, por lo que se deben invertir esfuerzos en mejorar sus habilidades y
destrezas, así como tener políticas de trabajo en equipo bien definidos. Estas
políticas dependerán del tamaño del equipo, estableciéndose una clasificación por
miembros).
9
CRYSTALMETHODOLOGIES,31 de enero de 2012 <http://ww16.crystalmethodologies.org/>
23
2.3.3.4. Dynamic Systems Development Method (DSDM)10
en 1994 con el objetivo de crear una metodología RAD unificada. Sus principales
características son:
trabajan juntos.
Las tres últimas son iterativas, además de existir realimentación a todas las
fases.
10
DSDM,31 de enero de 2012 <www.dsdm.org>
24
2.3.3.5. Feature -DrivenDevelopment (FDD)11
sistema partiendo de una lista de características que debe reunir el software. Sus
11
FEATUREDRIVENDEVELOPMENT,31 de enero
de 2012<http://www.featuredrivendevelopment.com/>
12
POPPENDIECK,31 de enero de 2012 <http://www.poppendieck.com/>
25
Figura 9. Lean Development
equipos para cumplir sus objetivos, puesto que, unas se adaptan mejor que otras,
metodología escogida por el equipo, ya sea tradicional o ágil, donde los equipos
tiempos establecidos.
proyecto
Proceso menos controlado, con pocos Proceso mucho más controlado, con numerosas
principios políticas/normas
sitio
2.5.1. Introducción
productivos posibles.
SCRUM fue desarrollado por Jeff Sutherland y elaborado más formalmente por
definidos y repetibles. Tomar el cambio como una forma de entregar al final del
desarrollo algo más cercano a la verdadera necesidad del Cliente fue entonces su
solución.
SCRUM no se trata únicamente de un método para desarrollo de software, sino
personas (equipo de trabajo) necesita trabajar junta para lograr una meta común.
software.
gestionar proyectos.
compromiso.
Agiles).
2.5.3. Elementos del SCRUM
Roles
o SCRUM Master
o Team (Equipo)
Poda de requerimientos
Product Backlog
Sprint
o Planificación
o Sprint Backlog
o SCRUM
o Estimaciones
o Builds continuos
o Reunión retrospective
Valores
El nombre de los miembros del equipo y los externos se deriva de una típica
fábula agilista: un cerdo y una gallina discutían qué nombre ponerle a un nuevo
SCRUM diferencia claramente entre estos dos grupos para garantizar que
Comprometido en el Implicados en el
proyecto proyecto
-Equipo -Comercial
SCRUM tiene una estructura muy simple. Todas las responsabilidades del
33
La dimensión del equipo total de SCRUM no debería ser superior a
veinte. El número ideal es diez, más o menos dos. Si hay más, lo más
una revisión para evaluar qué requerimientos son realmente necesarios, cuáles
sistema. Por lo tanto, nunca llega a ser una lista completa y definitiva. Se
2.5.3.4. Sprint
35
Aspectos a tener en cuenta en un Sprint:
Backlog.
razones siguientes:
2.5.3.4.1. Planificación
riesgo.
revisión.
Requerimientos de recursos de infraestructura o logísticos
Dirigir la planificación.
día.
2.5.3.4.3. SCRUM diario
día a la vez”.
idea es que ningún problema quede sin resolver o, por lo menos, sin
su detección.
después de la reunión.
para la reunión.
2.5.3.4.4. Estimaciones
SCRUM diario.
producto.
una nueva versión “estable” del código para usar como base.
en el siguiente Sprint.
durante el Sprint.
futuros Sprints.
2.5.3.5.1. Foco
un proyecto de software.
2.5.3.5.2. Comunicación
2.5.3.5.3. Respeto
interferencias innecesarias.
2.5.3.5.4. Coraje
3.1. Metodología
un producto de calidad.
software.
Una metodología puede seguir uno o varios modelos de ciclo de vida del software
que indican qué es lo que se obtendrá a lo largo del desarrollo del proyecto,
durante este desarrollo, la metodología indica cómo hay que obtener los distintos
documentos escritos que detallan cada etapa del ciclo de vida de desarrollo.
13
Blanco, S. (s.f.). Marble Station. Recuperado el 15 de 03 de 2012, de
http://www.marblestation.com/?p=644
3.2. Desarrollo iterativo e incremental
resultado completo sobre el producto final, para que el cliente pueda obtener los
cada requisito se complete en una única iteración: el equipo debe realizar todas
que esté preparado para ser entregado al cliente con el mínimo esfuerzo
necesario. De esta manera no se deja para el final del proyecto ninguna actividad
requisitos una vez iniciado el desarrollo, así como la validación continua del
este proceso en su libro “How to solve it” seguramente el primero que describe la
(diseño).
En este sentido, cualquier sistema de información pasa por una serie de fases a lo
largo de su vida. Su ciclo de vida comprende una serie de etapas entre las que se
Planificación
Análisis
Diseño
Implementación y Pruebas
Instalación o despliegue
Uso y mantenimiento
Para cada una de las fases del ciclo de vida de un del desarrollo de software se
cada etapa.
3.3.1. Planificación
plazos. Las tareas que se realizarán esta fase inicial del proyecto incluyen
3.3.2. Análisis
que tiene que hacer el sistema. La etapa de análisis en el ciclo de vida del
descripciones.
3.3.3. Diseño
requisitos del usuario desde distintos puntos de vista (¿Qué hacer?), los modelos
debería ser modular en vez de monolítico. Sus módulos deberían ser cohesivos
entre sí (para facilitar el mantenimiento del sistema). Cada módulo debería ofrecer
a los demás unos interfaces bien definidos. Por último, debe ser posible relacionar
las decisiones de diseño tomadas con los requerimientos del sistema que las
ocasionaron.
Objetivo: Generar el modelo de datos para que la solución cumpla con los
obtenidos.
calidad.
que tiene como objetivo detectar los errores que se hayan podido cometer tanto
hacerlo antes de que el usuario final del sistema realice sus pruebas de
funcionamiento.
codificación.
trabajo.
funcionando.
Las pruebas basadas en modelos son definidas como las pruebas de software
donde los casos de pruebas son derivados de un modelo que describe algunos o
todos los aspectos del sistema a probar. El sistema a probar puede ser tan simple
como un método o una clase, o tan complejo como un sistema completo. Para
14
( Zenteno, A. H. (2008). Método de pruebas de sistema basado en modelos navegacionales en
un contexto MDWE. Recuperado el 15 de 03 de 2012, de
www.lsi.us.es/docs/doctorado/.../MemoInvestigArturoHTorres.pdf
15
Zenteno, A. H. (2008). Método de pruebas de sistema basado en modelos navegacionales en un
contexto MDWE. Recuperado el 15 de 03 de 2012, de
www.lsi.us.es/docs/doctorado/.../MemoInvestigArturoHTorres.pdf
Figura 15.Modelo de Pruebas Orientada a Objetos para el Ciclo de Vida Completo.16
ciclo de vida del software, es por ello que se ha decidido utilizar el mencionado
modelo; sin embargo, para el presente proyecto las pruebas serán enfocaran
ASISTECOM, por tanto no serán sometidos a pruebas. Así mismo los modelos
16
(Ambler, 2004)
Las pruebas utilizadas dependerán de las funcionalidades de componente a
probar y estas pueden variar entre los distintos módulos del sistema;
Técnica Descripción
Prueba de Integración Es el acto de asegurar que las clases, y sus instancias, conforman un
de Clases software que cumple con el comportamiento definido.
Una forma de revisión técnica en la que el entregable que se revisa en
Revisión de Código el código fuente.
Es el acto de validar que un componente funciona tal como está
Prueba de Componente definido.
Es el acto de asegurar que toda línea de código es ejercita al menos
Prueba de Cubrimiento una vez.
Una revisión técnica en la cual se inspecciona un modelo de diseño.
Revisión de Diseño
Prueba de Escenarios Una técnica de prueba en la cual una o más personas validan un
de Uso modelo siguiendo la lógica de los escenarios de uso.
Consiste en probar la interfaz de usuario para garantizar que cumple
Prueba de Interfaz los estándares y requerimientos definidos. Usualmente se refiere a la
de Usuario prueba de interfaz de usuario gráfica.
17
Ambler, S. W. (04 de 2004). Ambysoft. Recuperado el 06 de 04 de 2012, de
http://www.ambysoft.com/essays/flootSpanish.html
3.3.5. Implementación
qué es lo que el sistema debe hacer desde el punto de vista del usuario. Por lo
tanto, se considera que los casos de uso proporcionan un modo claro y preciso de
participantes en el proceso.
sistema. Los diagramas de casos de uso sirven para facilitar la comunicación con
los futuros usuarios del sistema, y con el cliente, y resultan especialmente útiles
para determinar las características necesarias que tendrá el sistema. Esto es, los
diagramas de casos de uso describen qué es lo que debe hacer el sistema, pero
no cómo.
Una vez realizados los diagramas de casos de uso, que describen gráficamente lo
que debe hacer el sistema, se detallan los casos de uso, en ellas se explica la
Nombre
ID <Identificados del caso de uso en el diagrama>
Descripción <Descripción del caso de uso>
Precondición <Concisiones que deben presentarse antes de llegar al
caso de uso>
Post condición <Concisiones generadas por el caso de uso>
Flujo Normal <Descripción del flujo normal del caso de uso>
Flujos Alternos <En caso de que el caso de uso puede tener flujos
alternos, describirlos en esta parte>
Excepciones <Las excepciones a los flujos normales también son
importantes>
Notas: <Otros datos que aporten a la implementación.
base de datos.
un sistema de información.
3.4.4. Sprintometer
una aplicación de escritorio que permite alojar en la nube de forma gratuita los
equipo.
Manejar proyectos y definir para cada proyecto los Sprint, las historias de
Observar un gráfico por cada Sprint que indica la velocidad con la que
C++, Visual C#, Visual J#, ASP.NET y Visual Basic .NET, aunque actualmente se
han desarrollado las extensiones necesarias para muchos otros lenguajes como
aplicaciones web, así como servicios web en cualquier entorno que soporte la
dispositivos móviles.
Estas características han hecho que se elija Visual Studio 2010 como la
3.4.6. Jira
pruebas. De esta manera tanto el equipo de desarrollo como los dueños del
desinformado del estado del proyecto y en este caso particular de los errores
reportados.
CAPÍTULO 4
4.1.1. Planificación
analizadas una vez durante el desarrollo de cada Sprint. Sin embargo, antes de
iniciar con las iteraciones, es necesario realizar una definición macro de las
iteraciones, esto es, realizar una planificación inicial, que permita identificar el
ellas, el análisis preliminar de los procesos del negocio, definir los alcances del
lecturas In Situ.
Sincronización de Lecturas:
Recepci ón PK
Entrega PK Supervisor
Selecciona lectura
DB Lecturas
NO Verificación Si ncronización
Sincronizar Gestionadas <<NO>>
Lectura Desbloqueada?
<<SI>> T omar lectura
<<SI>>
Tiene Novedad?
<<NO>>
Ingresa novedades
Reportar Pl an Listo
<<SI>> <<SI>>
Asignación
Recepción Distributivo
Selección Plan
Lectura Ratificada?
<<NO>>
Lecturas Pendientes?
<<NO>>
Plantillas Distributivo Bloquear lectura
Edita Lectura
<<NO>>
Justifica NO Lectura Ti ene Lectura?
Actualizar Lectura
<<SI>>
<<SI>>
<<SI>>
<<SI>>
Edi ta Códigos Códigos bien apli cados
FIN
PROCESO
programa.
información
ejecución de un proceso o
Salida
File_01 generado durante la ejecución
del proceso.
Representa un conjunto de
de
datos.
De los procesos descritos y el respectivo diagrama, de han identificado los
cliente de ASISTECOM.
Funcionales/No Funcionales).
descrito en la tabla 8.
Nota: Kléber Toapanta participa en más de un rol, esto es completamente factible como parte de
la metodología. Esta tabla es una reproducción parcial del acta “AS-AR-PRIEE-001-2011”, en la
cual se estableció el equipo de trabajo. Durante la etapa de planificación (Sprint0). Se conformará
el equipo así y se definirán los roles de cada miembro en la planificación de cada Sprint del
proyecto.
a
Columna que identifica la área de actual de trabajo del participante del proyecto.
cada una de ellas y realizando una estimación del tiempo requerido para su
implementación.
Nota: Esta tabla una reproducción parcial del acta “AS-AR-PRIEE-002-2011”, en la cual se
estableció lista priorizada de requisitos para el presente proyecto.
a
La importancia está estimada de acuerdo a las necesidades del Product Owner y esta
cuantificada con números enteros entre 0 y 1000, de acuerdo a la escala de la Figura 22.
b
El tiempo requerido para el desarrollo está dado principalmente por dos factores: El tiempo
recomendado por SCRUM para la ejecución de cada iteración y la experiencia en la
implementación de componentes de software del equipo de trabajo. En este caso cada módulo
será implementado en una iteración independiente.
de proceso.
acceder a los mismos. Está formada por uno o más gestores de bases de
4.1.6.1. Planificación
Para la planificación del Sprint1, se llevó a cabo una reunión con el Product
implementados.
De la Tabla 7. Requerimientos Funcionales/No Funcionales – Sprint 0, obtenida
El sistema permitirá registrar a los usuarios El sistema brindará seguridad para ser utilizado por
del sistema. usuarios registrados del sistema, con diferentes
niveles de acceso.
Los usuarios no deben ser eliminados del El sistema funcionará en equipos con
sistema para mantener consistencia en S.O. Windows con .Net Framework 3,5
la información histórica.
El sistema permitirá registrar los equipos
utilizados para el procesos de recolección
de datos en campo
El sistema permitirá asignar equipos
registrados a usuarios registrados
del sistema.
Un usuario puede tener más de un equipo
asignado y un equipo solo puede
estar asignado a un usuario.
El sistema debe manejar niveles de
seguridad para diferentes grupos
de
usuarios.
De acuerdo a las funcionalidades identificadas para el módulo de administración,
Importancia
Historia de Importancia
ID Product Descripción
usuario a
Técnicab
Owner
5 Asignación 1000 800 Para que se realice el trabajo de campo, los lecturistas
de equipos utilizan equipos (PK); para ello cada usuario lecturista
deberá tener asignado un PK de los registrados en el
sistema y con el que realizará la gestión de lecturas.
Nota: Esta tabla una reproducción parcial del acta “AS-AR-PRIEE-002-2011”, en la cual se
estableció lista priorizada de requisitos para el Sprint1.
a
La importancia está estimada de acuerdo a las necesidades del Product Owner y está
cuantificada con números enteros entre 0 y 1000, de acuerdo a la escala de la Figura 22.
b
La importancia técnica está basada en las necesidades no funcionales desde el punto de vista
del usuario, pero necesarias para un funcionamiento de la aplicación desde el punto de vista
técnico.
Definición del equipo de trabajo
4.1.6.2. Análisis
La siguiente tabla describe los actores que participan en los casos de uso
Actor Descripción
Usuario Usuario con privilegios de administrador en el sistema. Este
Administrador tipo de usuario, puede gestionar todos los recursos
utilizados por el sistema
Diagramas de casos de uso del módulo de administración
Administración de Usuarios
Gestionar Usuarios
(RF-01)
Usuario Administrador
Administración de Equipos
«extends» «uses»
Gestionar Equipos Asignar/Reasignar
Responsable (RF-03) Seleccionar
(RF-02) Usuario (RF-04)
Usuario Administrador
Administración de Perfiles
Gestionar Pefiles
(RF-06)
Seleccionar
Usuario (RF-04)
«uses»
Definir Usuarios
del perfil (RF-08)
«uses»
Seleccionar Perfil
(RF-10)
«uses»
Usuario Administrador
Definir Formularios
del perfil (RF-09)
«uses»
Seleccionar
Gestionar
Formulario (RF-5)
Formularios (RF-07)
Administración de Catálogos
Gestionar
Catálogos (RF-11)
Usuario Administrador
Los casos de uso de Figura 25 han sido especificados en las siguientes tablas:
ID RF-01
Descripción Proporciona funcionalidades para dar mantenimiento a los usuarios del sistema.
Precondición
ID RF-02
Descripción Proporciona funcionalidades para dar mantenimiento a los equipos (PK)
utilizados para la recolección de información.
Precondición
Postcondición Información actualizada de los equipos móviles disponibles para la gestión de
lecturas.
Flujo Normal
1 El usuario logeado utiliza el formulario para mantenimiento de equipos.
2 Se ingresan los datos del nuevo equipo.
3 El sistema almacena los datos proporcionados.
Flujos Alternos
ID RF-03
Descripción La asignación de equipos y lecturas requieren de la selección de un usuario
registrado en el sistema, por tanto se debe poder seleccionar un usuario
para utilizar en los procesos mencionados.
Precondición
1 Usuarios registrados en el sistema.
Postcondición
? Lecturas asignadas al usuario seleccionado.
? Equipo asignado al usuario seleccionado.
Flujo Normal
1 Consulta de todos los usuarios registrados en el sistema y permite filtrar
de acuerdo a los perfiles existentes.
2 Filtrar información.
3 Seleccionar el usuario para utilizar en la tarea requerida.
Tabla 16.Especificación del caso de uso: Asignar/Reasignar Responsable
ID RF-04
Descripción Proporciona funcionalidades para asignar al usuario responsable de un
equipo (PK).
Precondición
1 Usuarios registrados en el sistema.
2 Equipos registrados en el sistema en estado activo.
Flujo Normal
1 El usuario logeado selecciona un equipo de los registrados en el
sistema.
2 El equipo no tiene un usuario asignado.
3 Se selecciona un usuario del sistema.
4 El sistema registra la asignación del equipo al usuario.
Flujos Alternos
* Reasignación
1 El usuario logeado selecciona un equipo de los registrados en el
sistema y este tiene asignado un usuario.
2 Se selecciona otro usuario del sistema.
3 El sistema actualiza la asignación del equipo al usuario.
* Liberación
1 El usuario logeado selecciona un equipo de los registrados en el
sistema y este tiene asignado un usuario.
2 Se elimina la asignación, dejando el equipo libre para asignar a otro
usuario.
3 Se guardará un log de los eventos (asignación/reasignación).
Notas:
1. Un equipo debe ser asignado únicamente a un usuario.
2. Un usuario puede tener asignado más de un equipo.
3. Debe ser posible exportar a Excel una lista con los detalles de la
asignación.
4. El proceso de asignación debe ser lo más fácil posible, debido a la
alta frecuencia con que los usuarios cambian de equipos.
Tabla 17.Especificación del caso de uso: Seleccionar Perfil
ID RF-05
Descripción Consiste en consultar y seleccionar un perfil determinado, para asignar
usuarios o asignar formularios.
Precondición
1 Perfiles registrados en el sistema.
Postcondición
1 Perfil seleccionado para ser utilizado en diferentes procesos.
Flujo Normal
1 Consulta de todos los perfiles registrados en el sistema.
2 Filtrar información.
3 Seleccionar el perfil para utilizar en la tarea requerida.
ID RF-06
Descripción Consiste en consultar y seleccionar un formulario (s), para asignar a un
determinado perfil.
Precondición
1 Formularios registrados en el sistema.
Postcondición
? Formulario asignado al perfil.
Flujo Normal
1 Consulta de todos los formularios registrados en el sistema.
2 Filtrar información.
3 Seleccionar formularios a asignar a un perfil.
Tabla 19.Especificación del caso de uso: Gestionar Perfiles
ID RF-07
Descripción Proporciona funcionalidades crear, modificar perfiles de usuario, los cuales
proporcionarán diferentes niveles de acceso a la aplicación.
Precondición
Flujo Normal
1 El usuario logeado ingresa los datos de un perfil.
2 El sistema guarda la información de nuevo perfil.
Flujos Alternos
* El perfil ya existe
1 El usuario logeado selecciona un perfil existente
2 Se modifica la información del perfil
3 El sistema actualiza la información del perfil modificado.
* Eliminar perfil
1 El usuario logeado selecciona un perfil existente
2 Se solicita la eliminación del perfil.
3 El sistema elimina de la DB los datos del perfil seleccionado.
Tabla 20.Especificación del caso de uso: Gestionar Formularios
ID RF-08
Descripción Proporciona funcionalidades para registrar información de los formularios
(pantallas) existentes en el sistema. Estas son posteriormente asignadas a
los perfiles existentes, para brindar acceso a las pantallas requeridas en un
perfil.
Precondición
1 Desarrollo de los componentes GUI, con formularios utilizados en el
sistema.
Postcondición Información actualizada con los datos de los formularios (pantallas)
disponibles en el sistema.
Flujo Normal
1 El usuario selecciona un componente GUI (Ejem: RMI.GUI*.DLL)
2 El sistema muestra todos los formularios disponibles en el componente.
3 El usuario selecciona un formulario.
4 El usuario ingresa una descripción que permita identificar la utilizad que
tiene el formulario dentro del sistema, el módulo en el cual es utilizado y
el estado (Activo/Inactivo).
5 El sistema registra el nuevo formulario disponible en el sistema.
Flujos Alternos
* El formulario ya existe
1 El usuario logeado selecciona un formulario existente.
2 Se modifica la información del formulario.
3 El sistema actualiza la información del formulario modificado.
* Eliminar Formulario
1 El usuario logeado selecciona un formulario existente.
2 Se solicita la eliminación del formulario.
3 El sistema elimina de la DB los datos del formulario seleccionado.
Tabla 21.Especificación del caso de uso: Definir Usuarios del perfil
ID RF-09
Descripción Proporciona funcionalidades para asignar usuarios a un determinado perfil.
Precondición
Flujo Normal
1 El usuario logeado selecciona perfil.
2 El usuario selecciona los usuarios para asignarlos al perfil.
3 El sistema alacena la información de los usuarios asignados al perfil.
Flujos Alterno
* Los usuarios ya han sido asignados, se requiere removerlos.
1 El usuario logeado selecciona perfil.
2 El usuario selecciona los usuarios que no deben pertenecer al perfil
3 El sistema alacena la información de los usuarios asignados al perfil.
Tabla 22.Especificación del caso de uso: Definir Formularios del perfil
ID RF-10
Descripción Proporciona funcionalidades para asignar formularios a un determinado perfil.
Precondición
1 Usuarios registrados en el sistema.
2 Formularios registrados en el sistema.
Postcondición Formularios asignados a un perfil de seguridad.
Flujo Normal
1 El usuario logeado selecciona perfil.
2 El usuario consulta los formularios existentes.
3 El usuario selecciona los formularios.
4 El sistema guarda la información de los formularios asignados al perfil.
Flujos Alternos
* Los formularios ya han sido asignados, se requiere removerlos.
1 El usuario logeado selecciona perfil.
2 El usuario consulta los formularios asignados al perfil.
3 El usuario selecciona los formularios que deben ser removidos del perfil
4 El sistema guarda la información de los formularios asignados al perfil.
Tabla 23.Especificación del caso de uso: Gestión de Catálogos
ID RF-11
Descripción Proporciona funcionalidades para crear, modificar catálogos utilizados en el
sistema. Esto permite agregar o eliminar dinámicamente listas de valores
utilizados como catálogos.
Precondición
Postcondición
1 Catálogos Actualizados
2 Detalles de catálogos actualizados.
Flujo Normal
1 Ingresar los datos del catálogo (Descripción de las listas de valores).
2 El sistema guarda los datos del catálogo.
3 Ingresar detalles del catálogo (Los detalles corresponden a la lista de
valores del catálogo).
4 El sistema almacena la lista de detalles del catálogo.
Flujos Alternos
* El catálogo ya existe
1 El usuario logeado selecciona un catálogo existente.
2 Se modifica la información del catálogo y el sistema almacena la
información modificada (opcional)
3 Se actualiza la información de los detalles del catálogo. La
actualización puede incluir la adición, eliminación o actualización de los
detalles (Opcional).
4.1.6.3. Diseño
Modelo de datos
4.1.6.4. Arquitectura
o Administración de Usuarios
o Administración de Equipos
o Administración de perfiles
o Asignación de usuarios al perfil
Formularios comunes
o Principal
o Login
o Mensajes
o Configurar conexión a DB
Administración de recursos
o Administración de Usuarios
o Administración de Equipos
o Administración de perfiles
Lógica común
o Seguridad
o Login
Una vez identificadas las historias de usuario, las cuales se encuentran descritas
Estimado
Story ID Task# Story Name, Task Name Assigned 1 (Horas)
1 Iniciar sesión en el sistema
1 Componentes para Inicio de sesión Kleber Toapanta 8
2 Componentes para conexión DB Kleber Toapanta 8
3 Configuración de conexión a DB Kleber Toapanta 6
4 Componentes base de la aplicación Kleber Toapanta 8
5 Pruebas de desarrollo Kleber Toapanta 2
6 Pruebas unitarias Rubén Ortega 1
2 Administración de usuarios
1 Componentes comunes Kleber Toapanta 8
2 Creación Objetos DB Kleber Toapanta 5
3 Desarrollo GUI Kleber Toapanta 8
4 Pruebas de desarrollo Kleber Toapanta 2
5 Pruebas unitarias Rubén Ortega 1
3 Administración de Equipos
1 Creación Objetos DB Kleber Toapanta 5
2 Desarrollo GUI Kleber Toapanta 5
3 Pruebas de desarrollo Kleber Toapanta 2
4 Pruebas unitarias Rubén Ortega 1
4 Asignación de equipos
1 Creación Objetos DB Kleber Toapanta 3
2 Desarrollo GUI Kleber Toapanta 3
3 Pruebas de desarrollo Kleber Toapanta 1
4 Pruebas unitarias Rubén Ortega 1
5 Creación de perfiles
1 Creación Objetos DB Kleber Toapanta 4
2 Desarrollo GUI Kleber Toapanta 5
3 Pruebas de desarrollo Kleber Toapanta 2
4 Pruebas unitarias Rubén Ortega 1
Nota: Esta tabla una reproducción parcial del reporte exportado desde la herramienta “Sprint to
meter” utilizada para gestionar el presente proyecto.
Para llevar un control integral de los avances de las tareas planteadas para
Pruebas
las pruebas a realizar dependerán del módulo y componentes de los mismos. Los
Blanca)
Blanca)
DAL: Componente para acceso a la capa de datos (DB) -> Pruebas de unidad
requeridas para la gestión planes de lectura, esto es; Cargar planes de trabajo en
4.1.7.1. Planificación
El sistema permitirá cargar los datos de un plan a Este proceso debe ser eficiente, debido a que
la base de datos desde un archivo de texto actualmente toma demasiado tiempo. Es necesario
(Archivo plano separado por comas implementar un método rápido para cargar los datos en
cargado.
para
las historias de usuario que deben ser implementadas durante el desarrollo del
Sprint2.
Importancia
Historia de Importancia
ID Product Descripción
usuario Técnicab
Ownera
1 Carga Plan 900 1000 Permite cargar los datos de las lecturas
campo.
Nota:
a
La importancia está estimada de acuerdo a las necesidades del Product Owner y está
cuantificada con números enteros entre 0 y 1000, de acuerdo a la escala de la Figura 22.
b
La importancia técnica está basada en las necesidades no funcionales desde el punto de vista
del usuario, pero necesarias para un funcionamiento de la aplicación desde el punto de vista
técnico.