1. 0
UNIVERSIDAD TECNOLÓGICA
DE TAMAULIPAS NORTE
ADMINISTRACIÓNDE PROYECTOS DE TI
Integrantes:
Victoria Jiménez | RobertoRibera | Moisés Gonzaga
Lic. Alondra Marisol Ramírez
Ingeniería TI – 9º C
3. 2
ÍNDICE
Introducción
Descripción del problema ............................................................................1
Diagrama de pescado..................................................................................2
Objetivo .................................................................................................... 3
Estándar aplicable ...................................................................................... 4
Ciclo de vida ............................................................................................. 7
Estructura de división del trabajo .................................................................9
Diagrama RACI.......................................................................................... 10
Ruta crítica ................................................................................................ 11
Presupuesto............................................................................................... 12
Posibles problemas..................................................................................... 13
Documentación técnica................................................................................ 14
Análisis de actores...................................................................................... 15
Formatos de comunicación ..........................................................................18
Redacción de perfiles/roles..........................................................................22
Análisis cualitativo y cuantitativo ..................................................................23
4. 3
Introducción
El progreso de la tecnología avanza cada vez más rápido, las empresas deben de
estar actualizadas en cuanto a sus procesos de producción, manufactura,
estabilidad y efectividad. Pero para lograr que todo sea satisfactorio, debe de
haber una buena administración de los recursos tecnológicos, un buen manejo de
las tecnologías y un conocimiento actualizado.
El desarrollo de software se ha vuelto una de las tareas críticas, pero que traen
consigo seguridad, siempre y cuando cumplan con los requisitos necesarios,
proveyendo accesibilidad a la información de la empresa cuando se necesite y sea
como se necesite. Buenas prácticas de programación junto con la aplicación de
estándares y normas para su sustentabilidad hacen de este proyecto de
investigación y aplicación, una oportunidad necesaria para comprar estos temas.
5. 1
1. Descripción del problema.
El proceso en el área de equipos de prueba de la Empresa Maquiladora “iQor
Global Services” consiste en que los equipos se someten a pruebas que evalúan las
funcionalidades de cada dispositivo, por ejemplo: Touch screen, audio speaker,
headset etc. De las cuales se corrobora el correcto funcionamiento, así como
también el monitoreo de las fallas más frecuentes y recurrentes.
Todo este proceso hace que se genere un reporte gráfico, el cual sirve para tener
un registro de fallas y establecer prioridad en la fase de solución, correspondiendo
al modelo correcto del dispositivo (teléfono celular), y programándolo con los
parámetros específicos por medio de las pruebas funcionales. Cada equipo de
prueba, establecido en las líneas de operación, están controlados por personas
especializadas (técnicos); cuando hay una detección de un error en estos equipos,
ellos (técnicos) son capaces de atender el reporte, pero para llevar esto acabo,
tienen que realizar una serie de actividades previas, localizar al supervisor de la
línea, preguntar detalles acerca del error. Todo este proceso conlleva tiempo, pero
aunado a eso, la línea de producción y operación de las pruebas a los dispositivos
celulares está detenida; y mientras más tiempo pierda el técnico investigando, más
tiempo permanecerá estática la línea de producción.
Es de suma importancia realizar un análisis y determinar en donde está
precisamente el problema, en la etapa de detección de errores, en la etapa de
análisis e investigación de los errores, o en la etapa de la solución de errores. El
proceso de pruebas a equipos de celulares tiene la posibilidad de mejorar, en
tiempo y forma, además de garantizar la efectividad de todo el sistema.
6. 2
2. Diagrama de pescado.
Figura. Diagrama de pescado.
En la figura anterior se muestra el diagrama de pescado, representando las áreas más importantes en cuando al
desenvolvimiento del departamento de equipos de pruebas de la empresa. El desarrollo de esta investigación e
implementación se centra en la espina de Software.
7. 3
3. Objetivo.
Objetivo general.
Analizar e implementar un sistema de detección de fallas en dispositivos celulares,
en la empresa “iQor Global Services”, con la finalidad de incrementar en un 70%
el rendimiento del proceso de pruebas funcionales de Radiofrecuencia, en un
periodo de cuatro meses.
Específicos.
Analizar el área de producción de equipos celulares para determinar las mejoras al
proceso de pruebas funcionales concernientes a señales de radio frecuencia con la
finalidad de proponer una solución, en un lapso de un mes.
Implementar un sistema automatizado el cual detecte y reporte las fallas en el
área de equipos de prueba, que dará como resultado la disminución en un 70% de
retrabajo en dispositivos celulares, cumpliendo con los objetivos generales, en un
lapso de tres meses.
8. 4
4. Estándar aplicable.
Norma IEEE 1074.
Es un estándar desarrollado por la IEEE para determinar el conjunto de actividades
esenciales que deben ser incorporadas en el desarrollo de un producto de
software, sin recomendar un ciclo de vida específico. La IEEE-1074 requiere
adaptarse a cada proyecto. Las actividades que no se incluyan deben de
justificarse.
La IEEE 1074 contempla 17 grupos de actividades y 64 actividades en total. Los
grupos de actividades son:
De Gestión del Proyecto (17 actividades)
o Iniciación (4 actividades)
o Planificación (8)
o Monitoreo y control (5)
De pre-desarrollo (11)
o Exploración de conceptos (4)
o Asignación al Sistema (3)
o Importación al software (4)
De desarrollo (10)
o Requisitos (3)
o Diseño (4)
o Implementación (3)
De post-desarrollo (12)
o Instalación (3)
o Operación y soporte (3)
o Mantenimiento (3)
9. 5
o Retiro (3)
Integrales (15)
o Evaluación (7)
o Gestión de configuración (3)
o Desarrollo de documentación (2)
o Capacitación (3)
Figura 3. Actividades del Estándar IEEE 1074
Define las actividades que constituyen los procesos necesarios para el desarrollo y
el mantenimiento de software, ya sea parte de un sistema mayor o autónomo. Se
deben revisar las actividades del proyecto para ver si son aplicables y establecer
un orden.
Cada organización debe asociar las actividades definidas en el estándar a su propio
ciclo de vida del software (IEEE Computer Society, 2006).
11. 7
5. Ciclo de vida.
Figura. Esquema del ciclo de vida.
Justificación de las actividades del ciclo de vida.
Estudio de factibilidad.
La factibilidad toma un rol muy importante, ya que se le considera como una de
las bases para el éxito del proyecto, ya que si no hay disponibilidad de recursos
para llevar a cabo el objetivo puede llevar al fracaso del proyecto.
Análisis de requerimientos.
Se brindan las propuestas e ideas; se evalúan y se aceptan, en otras palabras, este
proceso nos ayuda a definir el proyecto especificando las características
operacionales del software y establecer las restricciones del mismo.
12. 8
Diseño.
Se realizan bocetos para la interfaz del software, en el cual pueden surgir varias
propuestas para la siguiente etapa de creación de prototipos, pero definiendo el
más correcto para el ambiente en donde la aplicación será instalada.
Creación de prototipos.
En base al proceso anterior del diseño, se procede a crear el prototipo a partir del
diseño. La creación de prototipos se puede considerar una de las etapas más
importantes del proceso en general, ya que en ella se realizaran los cambios y
ajustes necesarios el que nos llevaran a la interfaz final de la aplicación.
Implementación.
Se aplican los resultados finales, el cual puede tender a aplicar modificaciones o
breves ajustes al programa para una mejor eficiencia.
Validación y pruebas.
El software se somete a una serie de pruebas funcionales y de stress para verificar
su comportamiento y funcionamiento, descartando así, posibles fallas en el
sistema, y si son detectadas, trabajar en una solución lo más pronto posible.
Operación y mantenimiento.
El proyecto es llevado a la aplicación el área a desempeñar, brindando eficiencia y
eficacia en el proceso del área de pruebas, el cual se verá reflejado en los
resultados. También en esta etapa se establece y programa el mantenimiento
preventivo para aplicación, cada lapso de tiempo.
14. 10
7. Diagrama RACI
Proyecto: Sistema Automatizado Para
Pruebas Funcionales a Dispositivos Celulares
Área:Software
RACI MIEMBROS DEL EQUIPO
Actividad Roberto Victoria Moisés
Estudio de
factibilidad
Iniciación Aprobable Consultable/Informable Responsible
Exploración de
conceptos
Aprobable Consultable/Informable Responsible
Importancia al
software
Consultable/
Informable
Aprobable Responsible
Análisis de
requerimientos
Asignación al
sistema
Aprobable Responsible Consultable/
Informable
Requisitos Aprobable Consultable/Informable Responsible
Monitoreo y control Aprobable Consultable/Informable Responsible
Diseño
Estructuración de
interfaces
Consultable/
Informable
Responsible Aprobable
Creación de
prototipos
Aprobable
Desarrollo de las
interfaces
Responsible Consultable/Informable Aprobable
Implementación
Instalación Aprobable Consultable/Informable Responsible
Validación y pruebas
Evaluación Aprobable Consultable/Informable Responsible
Funcionamiento Responsible Consultable/ Informable Aprobable
Operación y
mantenimiento
Mantenimiento Aprobable Consultable/Informable Responsible
Operación y soporte Aprobable Consultable/Informable Responsible
Desarrollo de
documentación
Responsible Consultable/Informable Aprobable
Capacitación Aprobable Consultable/Informable Responsible
16. 12
9. Presupuesto
Figura. Presupuesto de proyecto.
Informe del presupuesto realizado por la empresa “Automic Systems” (equipo de
trabajo actual). Es un presupuesto detallando la mayoría de las áreas que se
invertirá: recursos humanos, materiales, tiempo, etc. Cabe mencionar y aclarar,
que este prepuesto es para todo el proyecto en un lapso de 3 – 4 meses. Los
tiempos y precios pueden ajustarse.
17. 13
10. Posibles problemas y el impacto que tendrá en
el proyecto de TI
Algunos de los problemas que puedan surgir es el consumo excesivo de recursos
locales por parte de la computadora, como por ejemplo, memoria RAM, el cual
tendría una consecuencia de error en la aplicación y por lo tanto dejara de
funcionar. Otro de los aspectos a considerar como probables problemas o riegos es
si se interrumpe la conexión al servidor, provocando datos corruptos (no
garantizados) para la base de dato, generando una abertura en la actualización de
la información para ciertos equipos.
También algunas fallas serian en la incompatibilidad de los exploradores como
Internet Explorer, Chrome, Firefox, entre otros, que necesitan algunas script para
su correcta visualización.
Impacto que tendrán en el mismo.
Pues el impacto será negativo, y es que creará controversia con la aplicación ya
que estas posibles fallas afectarían el funcionamiento de ella, por lo tanto hay que
tener en cuenta cada una de las fallas antes mencionadas, para así contrarrestar
las vulnerabilidades que puedan existir en un futuro.
18. 14
11. Documentación técnica y registros históricos del
proyecto de TI.
Toda la información del proyecto será recaba en una de las 4 siguientes
categorías. La elección dependerá de la calidad de la información y de la
importancia.
Categorías para la documentación:
1. Informe Técnico. En esta sección se presenta el contenido básico que debe
poseer el informe técnico de un proyecto.
2. Bitácora o Cuaderno de Bitácora. En esta sección se describe qué es una
Bitácora y como puede ser organizada.
3. Cronograma del Proyecto. En esta sección se muestra una breve descripción de
los métodos más empleados para la generación de cronogramas de proyectos.
4. Documentación de Programas. En esta sección se presenta una referencia de la
información que deben contener los archivos de programas generados durante la
elaboración de un proyecto, de manera que permita rápidamente identificar ciertos
parámetros de programación y facilitar su lectura e interacción con todos los
programas de dicho proyecto.
19. 15
12. Análisis de actores.
Hay varios pasos que se deben seguir para hacer un análisis de los actores:
A. Dibujar un “cuadro de actores”;
B. Hacer una evaluación de la importancia de cada actor en el éxito del
proyecto y su relativo poder/influencia; e
C. Identificar riesgos y presunciones que afectarán el diseño y éxito del
proyecto.
A. Dibujo del cuadro de actores
Autores:
Autores
Principales
Actores
secundarios
Actores
Claves
Jefe de proyecto Jefe de proyecto Victoria Roberto
Roberto Roberto Moises
Moises
Victoria
Actividades Actividades Actividades Actividades
Presentar problema Analisar el problema
Realizar el
Proyecto
Dar requerimientos
Analizar
requerimientos
Dar solucion al
problema
Intereses Intereses Intereses Intereses
Dar soluciones Terminar el Proyecto Analizar un problema
Brindar
soluciones
Planear soluciones Mejorar el proceso Proponer soluciones
Ejecutar
soluciones
Ejecutar soluciones
Incrementar la
operación de
producción.
Implementar alguna
solución
Solucionar un
problema
Tabla. Cuadro de actores.
20. 16
B. Evaluación del impacto probable.
El impacto del proyecto tiene una relación estrecha con los actores principales, en
este caso el Jefe de Proyecto y Roberto Ribera. Ellos tienen la autoridad y la
jerarquía para tomar decisiones con respecto a la implementación de la solución.
El éxito recae sobre estos dos pilares, ya que ellos conocen de cerca el problema,
sabiéndolo identificar, saben cuánto les afecta, tanto a ellos como a la empresa,
razón por la que buscan implementar la solución.
C. Identificaciones de suposiciones y riesgos sobre los actores.
El éxito del proyecto depende en parte de la validez de las suposiciones hechas
sobre los actores que intervienen. ¿Cómo reaccionara el actor clave si se llega a
implementar satisfactoriamente? ¿Es posible que alguno de los actores ponga en
peligro la terminación del proyecto?
Después de presentar las teorías acerca de los riesgos de los actores y que puedan
influir en la realización del proyecto, hay que presentar soluciones o medidas para
aplicar.
2. Identificación del papel de los socios
Cada socio puede jugar papeles diferentes en una alianza. Los más comunes son:
Capacitadores:
Automic system. Encargados de capacitar acerca del uso y manejo del software.
Además de declarar las instrucciones, y en caso de presentarse, soluciones a
problemas.
21. 17
Proveedores:
Steren, Microsoft, AutoSystem. Son las empresas encargadas de suministrar los
recursos primarios para la realización de la investigación y el proyecto. Forman
parte de los socios en segundo plano, ya que de ellos depende en gran parte el
éxito o fracaso del mismo.
Usuarios:
Empresa. Son los encargados de hacer uso del sistema, por lo tanto son los
principales consumidores del producto/servicio, los principales socios.
Supervisores:
Victoria y Moises. Encargados de la supervisión del proyecto. Que todo vaya
conforme a lo planeado, y si es necesario corregir algo, tienen la autoridad para
hacerlo.
26. 22
14. Redacción de perfiles/roles
IMPLEMENTADOR (ID) (Roberto Ribera).
Los Implementadores eran necesarios para planificar estrategias prácticas y
factibles y llevarlas a cabo tan eficientemente como fuera posible.
ESPECIALISTA (ES) (Victoria Jiménez).
Una vez concluida la investigación inicial surgió el noveno rol, el Especialista. En el
mundo real el valor del conocimiento profundo en áreas clave se reconoció como
otra contribución esencial al equipo.
COORDINADOR (CO) (Moisés Gonzaga).
Los Coordinadores se necesitaban para centrar al equipo en los objetivos, hacer
participar a sus miembros y delegar el trabajo de manera apropiada
28. 24
3. Monitoreo y control del plan de riesgo.
15.1 Análisis Cualitativo.
Las fallas en los dispositivos celulares es el principal reto al cual se enfrenta la empresa, y
el proceso de equipos de prueba, o detección de fallas, tiene una doble responsabilidad de
hacer bien su trabajo.
En un mes normal, ¿Cuántas fallas se presentan? Para contestar a esta pregunta, se
muestra la información recopilada en el siguiente gráfico, que representa a solo un tipo de
modelo de celular, y de un solo proveedor.
29. 25
Gráfico de fallas.
Conforme a la información en la gráfica se concluye que el 9% de las fallas en un solo
mes corresponder daños líquidos en el dispositivo, mientras que con un 0.1% corresponde
a componentes perdidos.
15.2 Análisis cualitativo.
Enfocando el problema y los riesgos en esta área en específico, y después de una
investigación interna, se concluye que se realizó las pruebas debido a que presenta
disponibilidad de hacer uso de las tablillas además es factible eliminar las fallas de este
modelo porque es el modelo con mayor frecuencia de daño liquido en comparación de los
demás modelos debido a su gran demanda.
0%
1%
2%
3%
4%
5%
6%
7%
8%
9%
10%
WK21 WK22 WK23 WK24 Mon Tue Wed Thu Fri
Fallas del mes de Mayo-Junio
Liquid Damage
Physical Damage
Defective
Microprocessor
Defective Memory
Extreme Abuse
Parts not available
Overheating Board
Lifted Pad
Missing Components
Overrework Board
30. 26
Gráfico de fallas en un mes.
Pero, ¿De dónde proviene el problema? Esa es una de las preguntas principales para la
empresa. La pérdida de dinero es diaria, y mientras mayores sean las fallas, mayor será la
cantidad de dinero a perder.
0%
20%
40%
60%
80%
100%
120%
0
100
200
300
400
500
600
Top de fallas del mes de Mayo-Junio del S4
Fallas
%
31. 27
Figura. Diagrama de pescado del análisis.
Se elaboró un diagrama de Ishikawa el cual nos indicaba la raíz del problema; al analizar
cada una de las categorías encontramos “Mano de obra”, en el cual el personal no tiene
conocimiento de la tablilla acerca si es posible recuperar este componente; esto provoca
que se enviara a scrap.
En “Equipo” se refiere a la existencia de herramienta adecuada, si no cuenta con equipo
no es posible realizar un método para re-trabajarla. En la categoría “Material” menciona
que son las unidades como dicho material a re-trabajar, en este caso son las unidades que
llegan con corrosión provocando que las envíen a scrap. Y finalmente en la categoría
“Método” se presentó la falta de un procedimiento; a causa de esto se implementó un
proceso en el cual se pueda recuperar las tablillas.