peeper implementación del cambio de técnica usada...

Formato modificado de la plantilla IronWorks – Ingeniería de Sistemas PUJ 1

PEEPER

Implementación del cambio de técnica usada para la actualización de datos en los reportes de esfuerzo, usados como métrica de productividad, progreso y costo de los proyectos, de la

compañía de desarrollo de software PSL.

PONTIFICIA UNIVERSIDAD JAVERIANA

FACULTAD DE INGENIERIA

CARRERA DE INGENIERIA DE SISTEMAS

Mayo 2014

Versión 2.1

OSCAR IVAN LÓPEZ PULIDO


Historial de cambios

Versión Fecha Sección del documento modificada

Descripción de cambios (corta)

Responsable (S)

versión 1.0 12 de Marzo de 2014

Adaptación de Plantilla (SRS)

Rediseño de plantilla.

Oscar Iván López Pulido

versión 1.1 30 de Marzo de 2014

Adición sección 3

Se incluye la sección 3 del documento


versión 1.2 15 de Abril de 2014

Correcciones Correcciones en todo el documento.








Versión 2.1 14 de Mayo de 2014

Revisión de documento

Revisión de todo el documento


Tabla 1: Historial de cambios


Tabla de contenido 1 INTRODUCCIÓN ................................................................................................................................... 5

1.1 PROPÓSITO ............................................................................................................................................ 5 1.2 ALCANCE ................................................................................................................................................ 5 1.3 DEFINICIONES, ACRÓNIMOS, Y ABREVIACIONES ............................................................................................. 6 1.4 REFERENCIAS .......................................................................................................................................... 8

2 DESCRIPCIÓN GLOBAL ....................................................................................................................... 10

2.1 PERSPECTIVA DEL PRODUCTO ................................................................................................................... 10 2.1.1 Interfaces con el usuario ........................................................................................................... 10 2.1.2 Interfaces con el Hardware ....................................................................................................... 10 2.1.3 Interfaces con el Software ......................................................................................................... 11 2.1.4 Interfaces de Comunicación ...................................................................................................... 12 2.1.5 Restricciones de Memoria ......................................................................................................... 12 2.1.6 Operaciones .............................................................................................................................. 13 2.1.7 Requerimientos de Adaptación del Sitio.................................................................................... 13

2.2 CARACTERÍSTICAS DEL USUARIO ................................................................................................................ 13 2.3 RESTRICCIONES ..................................................................................................................................... 13 2.4 MODELO DEL DOMINIO .......................................................................................................................... 14 2.5 SUPOSICIONES Y DEPENDENCIAS ............................................................................................................... 16

3 REQUERIMIENTOS ESPECÍFICOS ......................................................................................................... 17

3.1 CARACTERÍSTICAS DEL PRODUCTO DE SOFTWARE ......................................................................................... 17 3.2 REQUERIMIENTOS DE DESEMPEÑO ............................................................................................................ 17 3.3 RESTRICCIONES DE DISEÑO ...................................................................................................................... 17

4 ANEXOS ............................................................................................................................................. 18

Lista de Tablas Tabla 1: Historial de cambios ............................................................................................. 2

Tabla 2: Definiciones y Acrónimos ..................................................................................... 8

Tabla 3: Interfaces con el Hardware ................................................................................ 11

Tabla 4: Interfaces con el Software ................................................................................. 12

Tabla 5: Elemento de Dominio CC01 ............................................................................... 15

Tabla 6: Elemento de Dominio C002 ............................................................................... 15




Lista de Ilustraciones Ilustración 1: Restricciones .............................................................................................. 14

Ilustración 2: Modelo de Dominio ................................................................................... 14

Ilustración 3: Suposiciones y Dependencias .................................................................... 16


1 Introducción

1.1 Propósito

Buscando desarrollar el trabajo de grado de Ingeniería de Sistemas "Peeper: Implementación del cambio de técnica usada para la actualización de datos en los reportes de esfuerzo, usados como métrica de productividad, progreso y costo de los proyectos, de la compañía de desarrollo de software PSL.", con realizar el presente documento se pretende especificar las funcionalidades y características de la implementación de Peeper. El presente formato funcionará como la guía que tendrá el desarrollador del proyecto y sus verificadores como apoyo para el desarrollo, supervisión, verificación y validación de la implementación de Peeper, de forma tal que se encontrarán de forma clara y coherente cada uno de los requerimientos de software especificados de forma técnica, priorizados y situados dentro del flujo normal del proyecto.

De esta forma se busca establecer un marco de entendimiento común del equipo de proyecto de software acerca de los requerimientos que serán abordados con el fin de asegurar que las necesidades instauradas sean satisfechas.

1.2 Alcance

El desarrollo del proyecto Peeper está principalmente dirigido a la empresa PSL, concretamente la Ingeniera María Alejandra Rodas y al estudiante Oscar Iván López Pulido, quienes podrán interactuar con el documento con el fin de revisarlo, adaptarlo y verificarlo durante el desarrollo del proyecto.

La implementación servirá para que PSL pueda integrar la información contenida en la base de datos de la herramienta Jira con el formato utilizado en los Reportes de Esfuerzo que debe ser diligenciado por todos los empleados de la empresa diariamente. De esta forma se pueden optimizar las estrategias establecidas por la empresa para el manejo de métricas y estadísticas de esfuerzo y rendimiento para cada uno de los proyectos y sus participantes.


Las funcionalidad principal que se pretende desarrollar consiste en integrar la información contenida en la base de datos del sistema JIRA, nueva plataforma que permite generar métricas establecidas para el desarrollo de proyectos, con el reporte de esfuerzo (REEE) con el cuál se obtiene información cuantitativa real sobre el esfuerzo invertido en cada una de las actividades constitutivas de los procesos de la compañía, con el fin de conocer la capacidad de los mismos y planear de manera adecuada la ejecución y mejoramiento de los proyectos, logrando obtener información en JIRA diariamente de los reportes de los empleados.

1.3 Definiciones, Acrónimos, y Abreviaciones

ACRÓNIMO O DEFINICIÓN

SIGNIFICADO DESCRIPCIÓN

A

API Application Programming Interface Conjunto de funciones y procedimientos que ofrece una biblioteca para ser utilizada para ser utilizada por otro software

E

Especificador Persona que realiza la especificación de los requerimientos.

Persona encargada de definir en detalle los requerimientos

(casos de uso, especificaciones funcionales, no funcionales,

reglas del negocio, GUI).


Elicitar Conjunto de actividades realizadas para descubrir los requerimientos de un cliente y determinar las necesidades reales.

G

GUI Grafical User Interface Componente de un sistema que soporta el entorno grafico de este.

P

PERT

Program Evaluation and Review Technique

Diagrama de distribución de tareas

PSL Productora de Software S.A. Empresa que hace las veces de cliente del componente PEEPER.

R

RM Administración de Requerimientos Administración de requerimientos (Requirement Management)

S

SCM Software Configuration Management

Administra y gestiona la configuración del Software

SPMP Software Project Management Plan Plan de gestión de proyectos de Software.


Tabla 2: Definiciones y Acrónimos

1.4 Referencias

[25] PSL – Productora de Software S.A.. <<Manual de Procesos. Generalidades sobre administración de requerimientos. RM000-I00>>. Copia controlada. Ene. 2010.

[26] PSL- Productora de Software S.A.. <<Manual de Procesos. Especificación de requerimientos funcionales. RM140-I10>>. Copia controlada. Ene.2010.

[27] IEEE Computer Society. <<IEEE Recommended Practice for Software Requirements Specifications . Std 830-1998>>. Jun. 1998.

[28] PSL- Productora de Software S.A.. <<Tutorial autoestudio guiado Administración requerimientos Ayuda para el estudiante. RRMM>>.

[29] PSL- Productora de Software S.A.. <<Aspectos Importantes Administración de requerimientos>>. Copia controlada.

[30] PSL- Productora de Software S.A.. <<Administración de requerimientos en PSL>>. Copia controlada.

[31] G. S. Marliss, «Review of “Systems Modeling & Requirements Specification Using ECSAM: An Analysis Method for Embedded and Computer-Based Systems by Jonah Z. Lavi and Joseph Kudish”, Dorset House Publishing Co. Inc., 2005, ISBN 0-932633-45-5», SIGSOFT Softw. Eng. Notes, vol. 30, no. 4, pp. 83–84, jul. 2005.

[32] P. Lamb, R. Power, G. Walker, y M. Compton, «Role-based access control for data service integration», in Proceedings of the 3rd ACM workshop on Secure web services, New York, NY, USA, 2006, pp. 3–12.

[33] B. Pôssas, N. Ziviani, W. Meira,Jr., y B. Ribeiro-Neto, «Set-based vector model: An efficient approach for correlation-based ranking», ACM Trans. Inf. Syst., vol. 23, no. 4, pp. 397–429, oct. 2005.

V

VAF Value Adjustment Factor Factor de Complejidad Técnica


[34] K. Periyasamy y J. Chidambaram, «Software reuse using formal specification of requirements», in Proceedings of the 1996 conference of the Centre for Advanced Studies on Collaborative research, 1996, p. 31–.

[35] T. Ahmed y A. R. Tripathi, «Specification and verification of security requirements in a programming model for decentralized CSCW systems», ACM Trans. Inf. Syst. Secur., vol. 10, no. 2, may 2007.

[36] X. (Frank) Liu, M. Azmoodeh, y N. Georgalas, «Specification of Non-functional Requirements for Contract Specification in the NGOSS Framework for Quality Management and Product Evaluation», in Proceedings of the 5th International Workshop on Software Quality, Washington, DC, USA, 2007, p. 7–.

[37] L. Yang, «Teaching system and network administration using virtual PC», J. Comput. Sci. Coll., vol. 23, no. 2, pp. 137–142, dic. 2007.

[38] J. Martínez-Miranda, A. Aldea, R. Bañares-Alcántara, y M. Alvarado, «TEAKS: simulation of human performance at work to support team configuration», in Proceedings of the fifth international joint conference on Autonomous agents and multiagent systems, New York, NY, USA, 2006, pp. 114–116.

[39] K. Lauenroth y K. Pohl, «Towards automated consistency checks of product line requirements specifications», in Proceedings of the twenty-second IEEE/ACM international conference on Automated software engineering, New York, NY, USA, 2007, pp. 373–376.

[40] E. Luque, T. Sorribes, y A. Ripoll, «Tuning architecture at run-time», SIGMICRO Newsl., vol. 19, no. 1–2, pp. 12–16, jun. 1988.

[41] C. Casagni, C. D. Francescomarino, M. Dragoni, L. Fiorentini, L. Franci, M. Gerosa, C. Ghidini, F. Rizzoli, M. Rospocher, A. Rovella, L. Serafini, S. Sparaco, y A. Tabarroni, «Wiki-based conceptual modeling: an experience with the public administration», in Proceedings of the 10th international conference on The semantic web - Volume Part II, Berlin, Heidelberg, 2011, pp. 17–32.


2 Descripción Global

2.1 Perspectiva del Producto

PEEPER es una implementación que pretende establecer una metodología de comunicación entre los datos alojados en la plataforma JIRA y los reportes de esfuerzo establecidos por la empresa PSL y diligenciados por sus empleados diariamente.

Se considera a PEEPER como un producto que actuará como un componente nuevo, el cual no dependerá de ningún otro sistema, debido a que el nivel de detalle que se maneja dentro de las métricas usadas por PSL tanto en JIRA como en los reportes de esfuerzo no es manejado por algún tipo de sistema o implementación previa.

A continuación se describen el requerimiento esencial:

Persistencia: JIRA utiliza una base de datos en un motor SQL Server 2008. La comunicación, actualización de datos y consultas se establecerán a esta base de datos desde los reportes de esfuerzo REEE.

En contexto, PEEPER será un sistema de muy fácil uso, buscando la mayor facilidad para los usuarios, de forma tal que se cumplan parámetros y atributos de calidad de software.

2.1.1 Interfaces con el usuario

Para el correcto uso de PEEPER es importante garantizar la usabilidad del producto. Cumplir con las características que espera el usuario frente a un componente de este tipo no hace necesario la utilización de interfaces especiales que deban ser utilizadas por el usuario, lo que nos permite utilizar interfaces comunes:

Teclado Mouse Pantalla

2.1.2 Interfaces con el Hardware

De la misma forma, se establecen las interfaces con el hardware. Para el uso de PEEPER sólo se hace necesario verificar las mismas interfaces que comúnmente usan los empleados de PSL en sus actividades diarias:


Justificación

Protocolos de comunicación TCP/IP

Permite el acceso a un a un host remoto en la red, tal como si la terminal fuese local a ese host.

Permite la transferencia, administración y consulta de archivos y directorios en la red.

Protocolo TCP Protocolo de comunicaciones de red.

Cables y Conexiones

Cable UTP. Cables utilizados dentro de la estructura física de PSL.

Tabla 3: Interfaces con el Hardware

2.1.3 Interfaces con el Software

Interfaz Software

Descripción Propósito de Uso Versión Fuente

WINDOWS XP o superior

Sistema Operativo PEEPER utilizará este sistema operativo aprovechando la facilidad de uso. De esta forma se evitará algún tipo de capacitación o entrenamiento del usuario.

Service Pack 3

Soporte en:

http://www.microsoft.com

/windows/windows-xp/

Microsoft Conjunto de productos que Permite realizar el reporte de Información en:


Office 2010 combina varios tipos de software para crear documentos, hojas de cálculo y presentaciones, y para administrar el correo electrónico.

esfuerzo establecido por la empresa PSL para sus empleados.

http://office.microsoft.com/es-es/

Tabla 4: Interfaces con el Software

2.1.4 Interfaces de Comunicación

PEEPER utilizará el protocolo TCP/IP, el cual garantiza una entrega correcta de datos para la prevención y ejecución de errores. La especificación del RFC para el protocolo IP es el 791 y para TCP es el 793.

2.1.5 Restricciones de Memoria

Las restricciones de memoria que se deben tener en cuenta para el correcto uso de PEPPER son:

Procesador: Velocidad 1.3 GHz Memoria RAM: 512 Mb

.




2.1.6 Operaciones

PEEPER no utilizará operaciones especiales de ningún tipo para los diferentes usuarios, no se utilizarán o implementarán periodos de inactividad ni operaciones de respaldo no especificadas en este documento.

2.1.7 Requerimientos de Adaptación del Sitio

Para el ejercicio adecuado de PEEPER, se debe considerar que su funcionamiento está establecido para los segmentos de red que componen el dominio interno de PSL en todas sus sedes, por tal motivo todos los componentes de software (ver sección 2.1.4 Interfaces con el Software) necesarios para la ejecución de la aplicación estarán instalados en los equipos de uso interno de la empresa o en el paquete de instalación incluido en la entrega final de PEEPER. Dentro de este paquete se contará con un manual de instalación el cual podrá hacer efectivo en el momento que así lo requiera el usuario. )

2.2 Características del Usuario

El usuario de PEEPER debe poseer como habilidades mínimas para poder llevar a cabo un buen manejo de la aplicación:

Debe poseer un conocimiento mínimo en computadores (Sistema operativo Windows XP – Windows 7). Debe poseer un conocimiento mínimo en herramientas Office ( conocimiento básico de Excel 2007 o superior ).

2.3 Restricciones

Las restricciones generales de PEEPER se declaran en la siguiente ilustración:


Ilustración 1: Restricciones

2.4 Modelo del Dominio

Ilustración 2: Modelo de Dominio

•PEEPER no tendrá tolerancia a fallos.

•PEEPER no está contemplado, inicialmente para establecer comunicación fuera del dominio de red que contempla PSL en sus diferentes sedes.

Restricciones generales

•Es necesario contar con las diferentes herramientas de software que provee PSL a sus empleados sin distinción (Office)

Restricciones de Software

•Es necesario contar con una conexión de red al dominio de PSL para establecer la comunicación con la base de datos. Restricciones

de Hardware


ID PEEPER Elemento del Dominio CC01

Descripción Peeper representa el componente intermedio de comunicación establecido entre los reportes de esfuerzo y la base de datos de JIRA

Atributos

Nombre Descripción

Controller Entidad que se encarga de controlar el evento generado por el reporte de esfuerzo

Service Entidad que se encarga de interpretar y realizar las operaciones que cumplen las reglas de negocio establecidas en los métricas.

Tabla 5: Elemento de Dominio CC01

ID Reporte de Esfuerzo REEE

Elemento del Dominio CC02

Descripción El reporte de Esfuerzo representa la plantilla utilizada por PSL para diligenciar el esfuerzo realizado en diferentes actividades

Atributos

Nombre Descripción

Listas Dependientes Listas generadas por las métricas instituidas dentro de los análisis de esfuerzo establecido para PSL.

Tabla 6: Elemento de Dominio C002

ID Base de Datos JIRA

Elemento del Dominio CC03

Descripción Unidad donde se realiza la persistencia de los datos asociados entre el reporte de esfuerzo y la plataforma JIRA

Atributos

Nombre Descripción


ID JIRA Elemento del Dominio CC04

Descripción Es la plataforma a la cual se reliza la migración de información de las diferentes métricas establecidas para PSL.

Atributos

Nombre Descripción



2.5 Suposiciones y Dependencias

Ilustración 3: Suposiciones y Dependencias

• Desde el inicio del proyecto el cliente describe y aprueba los requerimientos del sistema sin modificarlos o agregar nuevos requerimientos.

• PSL garantiza que los usuarios podrán contar con los requerimientos de Hadrware y Software descritos en las secciones 2.1.3 Interfaces con el Hardware, 2.1.4 Interfaces con el Software, 2.1.6 Restricciones de Memoria.

• Los usuarios deben contar con una conexión a la red permanente dentro del dominio de red de PSL en cualquiera de sus diferentes sedes.

Suposiciones

• Contar con el Software actualizado, permitirá el establecimiento de una conexión satisafctoria entre los diferentes componentes.

Dependencias


3 Requerimientos Específicos

Los requerimientos específicos se encuentran detallados en las historias de usuario anexos al presente documento en la sección 4.

3.1 Características del Producto de Software

PEEPER es una herramienta que permite la correcta manipulación de datos alojados en la base de datos de la plataforma JIRA por medio de los reportes de esfuerzo de los empleados de la empresa PSL. La principal funcionalidad que se busca es la posibilidad de visualizar en dichos reportes de esfuerzo todos los datos actualizados en JIRA, y de la misma forma mantener actualizada la información diaria de los reportes de esfuerzo.

3.2 Requerimientos de Desempeño

PEEPER debe contar con la capacidad actualizar las listas dependientes de los reportes de esfuerzo en tiempos de menos de 15 segundos y actualizar la información en tiempos de hasta 20 segundos.

3.3 Restricciones De Diseño

El tiempo con el que se cuenta para implementar y realizar pruebas de usabilidad, es de aproximadamente 12 semanas. Por esta restricción el proyecto tiene que estar bien delimitado, y no se puede apuntar a metas demasiado ambiciosas. No se hace necesario tener en cuenta restricciones de seguridad ya que no se hará uso fuera de la red corporativa de PSL.


4 Anexos

_Plantilla Historias Usuario.xls

_Plantilla%20Historias%20Usuario.xls

peeper implementación del cambio de técnica usada...

Documents