Embed Size (px)
Citation preview
0
ADMINISTRACIÓN DE PROYECTOS DE TI
Integrantes:
Lic. Alondra Marisol RamírezIngeniería TI – 9º C
“SISTEMA AUTOMATIZADOPARA PRUEBAS FUNCIONALES A DISPOSITIVOS CELULARES.”
1
Í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
2
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.
3
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.
1
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.
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.
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)
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).
6
Figura 4. Diagrama de Estándar IEEE 1074.
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.
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.
9
10
6. Estructura de división de trabajo.
Figura. Diagrama EDT
11
7. Diagrama RACI
Proyecto: Sistema Automatizado Para Pruebas Funcionales a Dispositivos Celulares
Área: Software
RACI MIEMBROS DEL EQUIPOActividad Roberto Victoria MoisésEstudio de factibilidadIniciación Aprobable Consultable/Informable Responsible
Exploración de conceptos
Aprobable Consultable/Informable Responsible
Importancia al software
Consultable/Informable
Aprobable Responsible
Análisis de requerimientosAsignación al
sistemaAprobable Responsible Consultable/
InformableRequisitos Aprobable Consultable/Informable Responsible
Monitoreo y control
Aprobable Consultable/Informable Responsible
DiseñoEstructuración de
interfacesConsultable/Informable
Responsible Aprobable
Creación de prototipos
Aprobable
Desarrollo de las interfaces
Responsible Consultable/Informable Aprobable
ImplementaciónInstalación Aprobable Consultable/Informable Responsible
Validación y pruebas
Evaluación Aprobable Consultable/Informable ResponsibleFuncionamiento Responsible Consultable/ Informable Aprobable
Operación y mantenimientoMantenimiento 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
12
8. Ruta Crítica
13
Figura. Ruta crítica.
14
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.
15
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.
16
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.
17
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
PrincipalesActores
secundariosActores 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.
18
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.
19
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.
20
13. Formatos de comunicación
Minuta.
21
22
Seguimiento a proyectos.
Convocatoria de reunion.
23
Acta de reunión.
24
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
25
15. Análisis cualitativo y cuantitativo.
1. Factores a controlar.
2. Programa de contingencia.
26
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.
27
WK21 WK22 WK23 WK24 Mon Tue Wed Thu Fri0%
1%
2%
3%
4%
5%
6%
7%
8%
9%
10%
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
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.
28
LD- D
AÑO LIQUIDO
PD- DAÑO FI
SICO
MD- MICROPROCES
ADOR DEFEC
TUOSO
DF- MEM
ORIA DAÑADA
ED- D
AÑO FISIC
O (Usu
ario)
DC- PEN
DIENTE
POR PARTES
OB- TABLIL
LA SO
BRECALEN
TADA
OP- PIST
AS LEV
ANTADAS
EC- C
OMPONENTE
S VOLA
DOS
OW- E
XCESO DE R
ETRABAJO
S ELEC
TRICOS
0
100
200
300
400
500
600
0%
20%
40%
60%
80%
100%
120%
Top de fallas del mes de Mayo-Junio del S4
Fallas%
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.
29
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.
30
