tesis guia para desarrollo de software en las pymes · 4 agradecimientos a mis padres, por ser...

1

INSTITUTO POLITÉCNICO NACIONAL

UNIDAD PROFESIONAL INTERDISCIPLINARIA DE INGENIERIA Y CIENCIAS SOCIALES Y ADMINISTRATIVAS

SECCION DE ESTUDIOS DE POSGRADO E INVESTIGACIÓN

Guía para el Desarrollo de Software en las PyMEs

T E S T E S T E S T E S I S I S I S I S

PARA OBTENER EL GRADO DE

MAESTRO EN CIENCIAS EN INFORMÁTICA

P R E S E N T A

ROBERTO CRUZ DOMÍNGUEZ

DIRECTOR: GUILLERMO PÉREZ VÁZQUEZ

MÉXICO, D.F. 2009

3

INSTITUTO POLITÉCNICO NACIONAL

SECRETARIA DE INVESTIGACIÓN Y POSGRADO

CARTA CESION DE DERECHOS

En la Ciudad de México D.F. el día 20 del mes de Noviembre del año 2009, el que suscribe

Roberto Cruz Domínguez alumno del Programa de Maestría en Ciencias en Informática

con numero de registro B051213, adscrito a la Sección de Estudios de Posgrado e

Investigación de la UPIICSA-IPN, manifiesta que es autor intelectual del presente trabajo

de Tesis bajo la dirección del M.C. Guillermo Pérez Vázquez y cede los derechos del

trabajo intitulado Guía para el Desarrollo de Software para las PyMEs, al Instituto

Politécnico Nacional para su difusión, con fines académicos y de investigación.

Los usuarios de la información no deben reproducir el contenido textual, gráficas o datos

del trabajo sin el permiso expreso del autor y/o director del trabajo. Este puede ser

obtenido escribiendo a la siguiente dirección [email protected] Si el permiso se otorga,

el usuario deberá dar el agradecimiento correspondiente y citar la fuente del mismo.

Lic. Roberto Cruz Domínguez

4

AGRADECIMIENTOS A mis PadresA mis PadresA mis PadresA mis Padres, por ser siempre una fuente de inspiración, un apoyo y un motivo para

seguir adelante, y por darme lo mas valioso que es la vida.

A mis hermanos, fA mis hermanos, fA mis hermanos, fA mis hermanos, familiares, amigos, compañerosamiliares, amigos, compañerosamiliares, amigos, compañerosamiliares, amigos, compañeros, de quienes siempre recibí un apoyo

para culminar este reto, por ese granito de arena que cada uno deposito, y por esos

buenos momentos vividos en este viaje.

Al INSTITUTO POLITÉCNICO NACIONALAl INSTITUTO POLITÉCNICO NACIONALAl INSTITUTO POLITÉCNICO NACIONALAl INSTITUTO POLITÉCNICO NACIONAL, por ser una gran institución que día a día forma

gente de calidad, con valores y por el orgullo de ser Politécnico.

A mis ProfesoresA mis ProfesoresA mis ProfesoresA mis Profesores, por ser mis guías y por compartir todo ese valioso conocimiento.

A la vidaA la vidaA la vidaA la vida, por permitirme cumplir un nuevo reto, y demostrarme que a pesar de lo sinuoso

del camino es posible disfrutarlo para finalmente alcanzar la meta.

“Este es el día que has estado esperando. Este es el

día por el que has estado bregando. Este día es la

culminación de todo lo que alguna vez hayas

hecho, dicho, pensado, soñado, anhelado o

planificado. Está aquí, es real y ahora es tuyo.”

5

Guía para el Desarrollo de Software en las PyMEs Índice

Resumen................................................................................................................................10 Introducción..........................................................................................................................11 1. Las PyMEs en México

1.1. Caracterización general de las pequeñas y medianas empresas...............................14 1.2. Determinantes de la competitividad de las PyMEs en México................................27 1.3. Microempresa y PYME...........................................................................................37 1.4. Identificación de las necesidades y problemáticas de las PyMEs............................40 1.5. Entorno de las PyMEs desarrolladoras de software.................................................45

2. La Informática y la Administración de Proyectos.

2.1. Administración Informática.....................................................................................58 2.2. Ingeniería de Software............................................................................................58 2.3. Administración de Proyectos Informáticos.............................................................61 2.4. RUP (Rational Unified Process)……………………………………………….…66 2.5. UML (Unified Modeling Language)……………………………………………..69

3. Administración de Proyectos Informáticos en las organizaciones.

3.1. Metodologías y Modelos actuales utilizados en las organizaciones........................73 3.2. Tendencias en la Administración de Proyectos.......................................................81 3.3. Beneficios principales del uso de metodologías de desarrollo de software.............85 3.4 PyMEs que se adaptan a la Guía para el Desarrollo de Software............................87

4. Guía para el Desarrollo de Software en las PyMEs

4.1. Definición de Etapas................................................................................................91 4.2. Resumen de Etapas................................................................................................129

5. Caso Practico

5.1. Implementación de la guía en una PYME.............................................................131

Conclusiones...................................................................................................................163 Bibliografía......................................................................................................................164 Anexo A. Símbolos utilizados para diagramas de procesos y actividades....................167

6

Lista de Tablas. PaginaPaginaPaginaPagina

Tabla 1 Tabla 1 Tabla 1 Tabla 1 –––– Clasificación del tamaño de las empresas. Fuente: Juan Pablo Clasificación del tamaño de las empresas. Fuente: Juan Pablo Clasificación del tamaño de las empresas. Fuente: Juan Pablo Clasificación del tamaño de las empresas. Fuente: Juan Pablo

Zorrilla con base de Rodríguez (1996)Zorrilla con base de Rodríguez (1996)Zorrilla con base de Rodríguez (1996)Zorrilla con base de Rodríguez (1996)

16

Tabla 2 Tabla 2 Tabla 2 Tabla 2 –––– Estratificación de las empresas según su actividad productiva. Estratificación de las empresas según su actividad productiva. Estratificación de las empresas según su actividad productiva. Estratificación de las empresas según su actividad productiva.

Fuente: Secretaria de Economía.Fuente: Secretaria de Economía.Fuente: Secretaria de Economía.Fuente: Secretaria de Economía.

17

Tabla 3 Tabla 3 Tabla 3 Tabla 3 ---- Criterios de Clasificación (variables por tamaño y sector). Fuente: Criterios de Clasificación (variables por tamaño y sector). Fuente: Criterios de Clasificación (variables por tamaño y sector). Fuente: Criterios de Clasificación (variables por tamaño y sector). Fuente:

Encuesta del Observatorio PyME 2002.Encuesta del Observatorio PyME 2002.Encuesta del Observatorio PyME 2002.Encuesta del Observatorio PyME 2002.

18

Tabla 4 Tabla 4 Tabla 4 Tabla 4 ---- Estratificación de empresas Estratificación de empresas Estratificación de empresas Estratificación de empresas por tamaño. Fuente: Diario Oficial de por tamaño. Fuente: Diario Oficial de por tamaño. Fuente: Diario Oficial de por tamaño. Fuente: Diario Oficial de

la Federación, (30 Dic 2002)la Federación, (30 Dic 2002)la Federación, (30 Dic 2002)la Federación, (30 Dic 2002)

18

Tabla 5 Tabla 5 Tabla 5 Tabla 5 –––– Características de los responsables de las PyMEs Características de los responsables de las PyMEs Características de los responsables de las PyMEs Características de los responsables de las PyMEs (socios por rango (socios por rango (socios por rango (socios por rango

de edad y sexo, total de sectores manufacturero, comercial y servicios)de edad y sexo, total de sectores manufacturero, comercial y servicios)de edad y sexo, total de sectores manufacturero, comercial y servicios)de edad y sexo, total de sectores manufacturero, comercial y servicios). . . .

Fuente: Encuesta del Observatorio PFuente: Encuesta del Observatorio PFuente: Encuesta del Observatorio PFuente: Encuesta del Observatorio PyME 2002.yME 2002.yME 2002.yME 2002.

19

Tabla 6 Tabla 6 Tabla 6 Tabla 6 –––– Indicadores de educación Indicadores de educación Indicadores de educación Indicadores de educación (socios por nivel de formación y sexo, (socios por nivel de formación y sexo, (socios por nivel de formación y sexo, (socios por nivel de formación y sexo,

suma total de los sectores manufacturero, comercio y servicios)suma total de los sectores manufacturero, comercio y servicios)suma total de los sectores manufacturero, comercio y servicios)suma total de los sectores manufacturero, comercio y servicios). Fuente: . Fuente: . Fuente: . Fuente:


20

Tabla 7 Tabla 7 Tabla 7 Tabla 7 –––– Porcentaje de conclusión de estudios Porcentaje de conclusión de estudios Porcentaje de conclusión de estudios Porcentaje de conclusión de estudios (por ni(por ni(por ni(por nivel de formación y vel de formación y vel de formación y vel de formación y

sexo, total de los sectores manufacturero, comercio y servicios)sexo, total de los sectores manufacturero, comercio y servicios)sexo, total de los sectores manufacturero, comercio y servicios)sexo, total de los sectores manufacturero, comercio y servicios). Fuente: . Fuente: . Fuente: . Fuente:


21

Tabla 8 Tabla 8 Tabla 8 Tabla 8 ---- Participación de las unidades económicas en el sector Participación de las unidades económicas en el sector Participación de las unidades económicas en el sector Participación de las unidades económicas en el sector

manufacturero (establecimientos por tamaño, porcentajes demanufacturero (establecimientos por tamaño, porcentajes demanufacturero (establecimientos por tamaño, porcentajes demanufacturero (establecimientos por tamaño, porcentajes de participación). participación). participación). participación).

Fuente: INEGI, Censos Económicos 1999.Fuente: INEGI, Censos Económicos 1999.Fuente: INEGI, Censos Económicos 1999.Fuente: INEGI, Censos Económicos 1999.

23

Tabla 9 Tabla 9 Tabla 9 Tabla 9 ---- Temas con mayor demanda para capacitación Temas con mayor demanda para capacitación Temas con mayor demanda para capacitación Temas con mayor demanda para capacitación (porcentaje de (porcentaje de (porcentaje de (porcentaje de

empresas que requirieron cursos en el tema)empresas que requirieron cursos en el tema)empresas que requirieron cursos en el tema)empresas que requirieron cursos en el tema). Fuente: Encuesta del . Fuente: Encuesta del . Fuente: Encuesta del . Fuente: Encuesta del

Observatorio PyME 2002.Observatorio PyME 2002.Observatorio PyME 2002.Observatorio PyME 2002.

30

Tabla 10 Tabla 10 Tabla 10 Tabla 10 ---- Destino de inversión en Destino de inversión en Destino de inversión en Destino de inversión en maquinaria y equipo (porcentaje de maquinaria y equipo (porcentaje de maquinaria y equipo (porcentaje de maquinaria y equipo (porcentaje de

empresas que destinaron recursos a cada concepto, sector manufacturero) empresas que destinaron recursos a cada concepto, sector manufacturero) empresas que destinaron recursos a cada concepto, sector manufacturero) empresas que destinaron recursos a cada concepto, sector manufacturero)

Fuente: Encuesta del Observatorio PyME 2002.Fuente: Encuesta del Observatorio PyME 2002.Fuente: Encuesta del Observatorio PyME 2002.Fuente: Encuesta del Observatorio PyME 2002.

31

Tabla 11 Tabla 11 Tabla 11 Tabla 11 ---- Destino de inversión en equipamiento e instalaciones Destino de inversión en equipamiento e instalaciones Destino de inversión en equipamiento e instalaciones Destino de inversión en equipamiento e instalaciones

(porcentaje de empresas que destina(porcentaje de empresas que destina(porcentaje de empresas que destina(porcentaje de empresas que destinaron recursos a cada concepto, sector ron recursos a cada concepto, sector ron recursos a cada concepto, sector ron recursos a cada concepto, sector

comercio). Fuente: Encuesta del Observatorio PyME 2002.comercio). Fuente: Encuesta del Observatorio PyME 2002.comercio). Fuente: Encuesta del Observatorio PyME 2002.comercio). Fuente: Encuesta del Observatorio PyME 2002.

31

Tabla 12 Tabla 12 Tabla 12 Tabla 12 ---- Principales motivos de las PyMEs para utilizar Internet Principales motivos de las PyMEs para utilizar Internet Principales motivos de las PyMEs para utilizar Internet Principales motivos de las PyMEs para utilizar Internet

(porcentaje de empresas). Fuente: Encuesta del Observatorio PyME 2002.(porcentaje de empresas). Fuente: Encuesta del Observatorio PyME 2002.(porcentaje de empresas). Fuente: Encuesta del Observatorio PyME 2002.(porcentaje de empresas). Fuente: Encuesta del Observatorio PyME 2002.

34

Tabla 13 Tabla 13 Tabla 13 Tabla 13 ---- Vent Vent Vent Ventajas y desventajas que presentan las pequeñas empresas. ajas y desventajas que presentan las pequeñas empresas. ajas y desventajas que presentan las pequeñas empresas. ajas y desventajas que presentan las pequeñas empresas.

Fuente: Rodríguez (1996)Fuente: Rodríguez (1996)Fuente: Rodríguez (1996)Fuente: Rodríguez (1996)

42

Tabla 14 Tabla 14 Tabla 14 Tabla 14 ---- Ventajas y desventajas que presentan las medianas empresas. Ventajas y desventajas que presentan las medianas empresas. Ventajas y desventajas que presentan las medianas empresas. Ventajas y desventajas que presentan las medianas empresas.

Fuente: Rodríguez (1996)Fuente: Rodríguez (1996)Fuente: Rodríguez (1996)Fuente: Rodríguez (1996)

43

Tabla 15 Tabla 15 Tabla 15 Tabla 15 –––– Definición General de Etapas. Fuente: Elaboración Propia Definición General de Etapas. Fuente: Elaboración Propia Definición General de Etapas. Fuente: Elaboración Propia Definición General de Etapas. Fuente: Elaboración Propia 130

7

Lista de Gráficos. PaginaPaginaPaginaPagina

Grafica 1Grafica 1Grafica 1Grafica 1---- Permanencia en el mercado Permanencia en el mercado Permanencia en el mercado Permanencia en el mercado (años con la misma razón social, (años con la misma razón social, (años con la misma razón social, (años con la misma razón social,

promedio de sectores manufacturero, comercial y servicios)promedio de sectores manufacturero, comercial y servicios)promedio de sectores manufacturero, comercial y servicios)promedio de sectores manufacturero, comercial y servicios). Fuente: . Fuente: . Fuente: . Fuente:


19191919

Grafica 2 Grafica 2 Grafica 2 Grafica 2 ---- Composición de las empresas en Méx Composición de las empresas en Méx Composición de las empresas en Méx Composición de las empresas en México, por tamaño y por ico, por tamaño y por ico, por tamaño y por ico, por tamaño y por

sector (total de establecimientos y participación porcentual). Fuente: INEGI, sector (total de establecimientos y participación porcentual). Fuente: INEGI, sector (total de establecimientos y participación porcentual). Fuente: INEGI, sector (total de establecimientos y participación porcentual). Fuente: INEGI,

Censos Económicos 1999.Censos Económicos 1999.Censos Económicos 1999.Censos Económicos 1999.

22222222

Grafica 3 Grafica 3 Grafica 3 Grafica 3 ----Concentración geográfica de empresas en México (estados Concentración geográfica de empresas en México (estados Concentración geográfica de empresas en México (estados Concentración geográfica de empresas en México (estados

seleccionados, porcentajes de participación). Fuente: INEGI, seleccionados, porcentajes de participación). Fuente: INEGI, seleccionados, porcentajes de participación). Fuente: INEGI, seleccionados, porcentajes de participación). Fuente: INEGI, Censos Censos Censos Censos

Económicos 1999.Económicos 1999.Económicos 1999.Económicos 1999.

24242424

Grafica 4 Grafica 4 Grafica 4 Grafica 4 ---- Producto Interno Bruto por entidad federativa (estados Producto Interno Bruto por entidad federativa (estados Producto Interno Bruto por entidad federativa (estados Producto Interno Bruto por entidad federativa (estados

seleccionados, porcentajes de participación) . Fuente: INEGI, Banco de seleccionados, porcentajes de participación) . Fuente: INEGI, Banco de seleccionados, porcentajes de participación) . Fuente: INEGI, Banco de seleccionados, porcentajes de participación) . Fuente: INEGI, Banco de

Información Económica.Información Económica.Información Económica.Información Económica.

25252525

Gráfica 5 Gráfica 5 Gráfica 5 Gráfica 5 ---- Relación de empresas grandes Relación de empresas grandes Relación de empresas grandes Relación de empresas grandes––––medianas y pequeñasmedianas y pequeñasmedianas y pequeñasmedianas y pequeñas––––mimimimicro, por cro, por cro, por cro, por

estado (cociente entre grupos de empresas). estado (cociente entre grupos de empresas). estado (cociente entre grupos de empresas). estado (cociente entre grupos de empresas). Fuente: Encuesta del Fuente: Encuesta del Fuente: Encuesta del Fuente: Encuesta del


26262626

Gráfica 6 Gráfica 6 Gráfica 6 Gráfica 6 ---- Auto evaluación del desempeño de las PyMEs durante 2000 Auto evaluación del desempeño de las PyMEs durante 2000 Auto evaluación del desempeño de las PyMEs durante 2000 Auto evaluación del desempeño de las PyMEs durante 2000 ––––

2001. Fuente: Encuesta del Observatorio PyME 2002.2001. Fuente: Encuesta del Observatorio PyME 2002.2001. Fuente: Encuesta del Observatorio PyME 2002.2001. Fuente: Encuesta del Observatorio PyME 2002.

27272727

Grafica 7 Grafica 7 Grafica 7 Grafica 7 ---- Nivel de instrucc Nivel de instrucc Nivel de instrucc Nivel de instrucción del personal ocupado en las PyMEs ión del personal ocupado en las PyMEs ión del personal ocupado en las PyMEs ión del personal ocupado en las PyMEs

(promedio de los sectores manufacturero, comercial y servicios)(promedio de los sectores manufacturero, comercial y servicios)(promedio de los sectores manufacturero, comercial y servicios)(promedio de los sectores manufacturero, comercial y servicios). Fuente: . Fuente: . Fuente: . Fuente:


28282828

Grafico 8 Grafico 8 Grafico 8 Grafico 8 ---- Grado de dificultad para contratar personal según su tipo Grado de dificultad para contratar personal según su tipo Grado de dificultad para contratar personal según su tipo Grado de dificultad para contratar personal según su tipo

(basado en el juicio de los empres(basado en el juicio de los empres(basado en el juicio de los empres(basado en el juicio de los empresarios, promedio de los sectores arios, promedio de los sectores arios, promedio de los sectores arios, promedio de los sectores

manufacturero, comercial y servicios)manufacturero, comercial y servicios)manufacturero, comercial y servicios)manufacturero, comercial y servicios). Fuente: Encuesta del Observatorio . Fuente: Encuesta del Observatorio . Fuente: Encuesta del Observatorio . Fuente: Encuesta del Observatorio

PyME 2002.PyME 2002.PyME 2002.PyME 2002.

29292929

Grafico 9 Grafico 9 Grafico 9 Grafico 9 ---- Comportamiento de las inversiones en 2001 (evolución con Comportamiento de las inversiones en 2001 (evolución con Comportamiento de las inversiones en 2001 (evolución con Comportamiento de las inversiones en 2001 (evolución con

respecto al gasto de inversión en 2000). Fuente: Encuesta del Obserespecto al gasto de inversión en 2000). Fuente: Encuesta del Obserespecto al gasto de inversión en 2000). Fuente: Encuesta del Obserespecto al gasto de inversión en 2000). Fuente: Encuesta del Observatorio rvatorio rvatorio rvatorio

PyME 2002.PyME 2002.PyME 2002.PyME 2002.

30303030

Grafico 10 Grafico 10 Grafico 10 Grafico 10 ---- Estado de la maquinaria involucrada en el proceso de Estado de la maquinaria involucrada en el proceso de Estado de la maquinaria involucrada en el proceso de Estado de la maquinaria involucrada en el proceso de

producción (basado en el juicio de los empresarios, sector manufacturero). producción (basado en el juicio de los empresarios, sector manufacturero). producción (basado en el juicio de los empresarios, sector manufacturero). producción (basado en el juicio de los empresarios, sector manufacturero).

Fuente: Encuesta del Observatorio PyME 2002.Fuente: Encuesta del Observatorio PyME 2002.Fuente: Encuesta del Observatorio PyME 2002.Fuente: Encuesta del Observatorio PyME 2002.

32323232

Grafico 11Grafico 11Grafico 11Grafico 11---- Personal que habitualmente op Personal que habitualmente op Personal que habitualmente op Personal que habitualmente opera con equipo de cómputo era con equipo de cómputo era con equipo de cómputo era con equipo de cómputo

(porcentaje de empresas por rango de empleados). Fuente: Encuesta del (porcentaje de empresas por rango de empleados). Fuente: Encuesta del (porcentaje de empresas por rango de empleados). Fuente: Encuesta del (porcentaje de empresas por rango de empleados). Fuente: Encuesta del


33333333

Grafico 12 Grafico 12 Grafico 12 Grafico 12 ---- PyMEs con acceso a Internet (porcentaje de empresas). Fuente: PyMEs con acceso a Internet (porcentaje de empresas). Fuente: PyMEs con acceso a Internet (porcentaje de empresas). Fuente: PyMEs con acceso a Internet (porcentaje de empresas). Fuente:


34343434

Grafico 13 Grafico 13 Grafico 13 Grafico 13 ---- P P P PyMEs que cuentan con página web. (reales y planeadas, yMEs que cuentan con página web. (reales y planeadas, yMEs que cuentan con página web. (reales y planeadas, yMEs que cuentan con página web. (reales y planeadas, 35353535

8

porcentaje de empresas). Fuente: Encuesta del Observatorio PyME 2002.porcentaje de empresas). Fuente: Encuesta del Observatorio PyME 2002.porcentaje de empresas). Fuente: Encuesta del Observatorio PyME 2002.porcentaje de empresas). Fuente: Encuesta del Observatorio PyME 2002.

Grafico 14 Grafico 14 Grafico 14 Grafico 14 ---- PyMEs que comercializan sus productos en Internet y ventas en PyMEs que comercializan sus productos en Internet y ventas en PyMEs que comercializan sus productos en Internet y ventas en PyMEs que comercializan sus productos en Internet y ventas en

línea (reales y planeadas, porcentaje de empresas; velínea (reales y planeadas, porcentaje de empresas; velínea (reales y planeadas, porcentaje de empresas; velínea (reales y planeadas, porcentaje de empresas; ventas en línea como ntas en línea como ntas en línea como ntas en línea como

porcentaje del total). Fuente: Encuesta del Observatorio PyME 2002.porcentaje del total). Fuente: Encuesta del Observatorio PyME 2002.porcentaje del total). Fuente: Encuesta del Observatorio PyME 2002.porcentaje del total). Fuente: Encuesta del Observatorio PyME 2002.

36363636

Grafico 15. Historia de UML. Fuente: Desarrollo de Software Orientado a Grafico 15. Historia de UML. Fuente: Desarrollo de Software Orientado a Grafico 15. Historia de UML. Fuente: Desarrollo de Software Orientado a Grafico 15. Historia de UML. Fuente: Desarrollo de Software Orientado a

Objetos usando UML.Objetos usando UML.Objetos usando UML.Objetos usando UML.

70707070

Grafico 16. Proceso de Desarrollo y UML Fuente: Larman, Craig.Grafico 16. Proceso de Desarrollo y UML Fuente: Larman, Craig.Grafico 16. Proceso de Desarrollo y UML Fuente: Larman, Craig.Grafico 16. Proceso de Desarrollo y UML Fuente: Larman, Craig. 72727272

GGGGrafico 17. Diagrama de Clases Fuente: Metodología de Boochrafico 17. Diagrama de Clases Fuente: Metodología de Boochrafico 17. Diagrama de Clases Fuente: Metodología de Boochrafico 17. Diagrama de Clases Fuente: Metodología de Booch 76767676

Grafico 18. Tarjeta CRC Fuente: Pender, 2002Grafico 18. Tarjeta CRC Fuente: Pender, 2002Grafico 18. Tarjeta CRC Fuente: Pender, 2002Grafico 18. Tarjeta CRC Fuente: Pender, 2002 79797979

Grafico 19. Verdades Obsoletas y Nuevos Enfoques de la Administración de Grafico 19. Verdades Obsoletas y Nuevos Enfoques de la Administración de Grafico 19. Verdades Obsoletas y Nuevos Enfoques de la Administración de Grafico 19. Verdades Obsoletas y Nuevos Enfoques de la Administración de

Proyectos Fuente: Volkswagen Coaching GMBH, 2002Proyectos Fuente: Volkswagen Coaching GMBH, 2002Proyectos Fuente: Volkswagen Coaching GMBH, 2002Proyectos Fuente: Volkswagen Coaching GMBH, 2002

81818181

Grafico 20. Fases Grafico 20. Fases Grafico 20. Fases Grafico 20. Fases Proyecto Fuente: LiderProyecto PMBOK, 2008Proyecto Fuente: LiderProyecto PMBOK, 2008Proyecto Fuente: LiderProyecto PMBOK, 2008Proyecto Fuente: LiderProyecto PMBOK, 2008 82828282

Grafico 21. Áreas de ConocimientoGrafico 21. Áreas de ConocimientoGrafico 21. Áreas de ConocimientoGrafico 21. Áreas de Conocimiento Fuente: LiderProyecto PMBOK, 2008Fuente: LiderProyecto PMBOK, 2008Fuente: LiderProyecto PMBOK, 2008Fuente: LiderProyecto PMBOK, 2008 83838383

Grafico 22. Etapas de la Guía de Desarrollo de Software Fuente: Syple Grafico 22. Etapas de la Guía de Desarrollo de Software Fuente: Syple Grafico 22. Etapas de la Guía de Desarrollo de Software Fuente: Syple Grafico 22. Etapas de la Guía de Desarrollo de Software Fuente: Syple

TechnologiesTechnologiesTechnologiesTechnologies

90909090

Grafico 23. Definición del Proyecto. Fuente: ElaboGrafico 23. Definición del Proyecto. Fuente: ElaboGrafico 23. Definición del Proyecto. Fuente: ElaboGrafico 23. Definición del Proyecto. Fuente: Elaboración Propiaración Propiaración Propiaración Propia 133133133133

Grafico 24. Etapas y Artefactos. Fuente: Elaboración PropiaGrafico 24. Etapas y Artefactos. Fuente: Elaboración PropiaGrafico 24. Etapas y Artefactos. Fuente: Elaboración PropiaGrafico 24. Etapas y Artefactos. Fuente: Elaboración Propia 134134134134

Grafico 25. Cuestionario. Fuente: Elaboración PropiaGrafico 25. Cuestionario. Fuente: Elaboración PropiaGrafico 25. Cuestionario. Fuente: Elaboración PropiaGrafico 25. Cuestionario. Fuente: Elaboración Propia 135135135135

Grafico 26. Puntos CríticosGrafico 26. Puntos CríticosGrafico 26. Puntos CríticosGrafico 26. Puntos Críticos. Fuente: Elaboración PropiaFuente: Elaboración PropiaFuente: Elaboración PropiaFuente: Elaboración Propia 136136136136

Grafico 27. Lista de InvolucradosGrafico 27. Lista de InvolucradosGrafico 27. Lista de InvolucradosGrafico 27. Lista de Involucrados. Fuente: ElaboracióFuente: ElaboracióFuente: ElaboracióFuente: Elaboración Propian Propian Propian Propia 137137137137

Grafico 28. Presentación de DifusiónGrafico 28. Presentación de DifusiónGrafico 28. Presentación de DifusiónGrafico 28. Presentación de Difusión. Fuente: Elaboración PropiaFuente: Elaboración PropiaFuente: Elaboración PropiaFuente: Elaboración Propia 138138138138

Grafico 29. Procedimiento Actual. Grafico 29. Procedimiento Actual. Grafico 29. Procedimiento Actual. Grafico 29. Procedimiento Actual. . Fuente: Elaboración PropiaFuente: Elaboración PropiaFuente: Elaboración PropiaFuente: Elaboración Propia 139139139139

Grafico 30. Proceso ActualGrafico 30. Proceso ActualGrafico 30. Proceso ActualGrafico 30. Proceso Actual. Fuente: Elaboración PropiaFuente: Elaboración PropiaFuente: Elaboración PropiaFuente: Elaboración Propia 140140140140

Grafico 31. Requerimientos de UsuarioGrafico 31. Requerimientos de UsuarioGrafico 31. Requerimientos de UsuarioGrafico 31. Requerimientos de Usuario. FuentFuentFuentFuente: Elaboración Propiae: Elaboración Propiae: Elaboración Propiae: Elaboración Propia 141141141141

Grafico 32. Procedimiento NuevoGrafico 32. Procedimiento NuevoGrafico 32. Procedimiento NuevoGrafico 32. Procedimiento Nuevo. Fuente: Elaboración PropiaFuente: Elaboración PropiaFuente: Elaboración PropiaFuente: Elaboración Propia 143143143143

Grafico 33. Proceso Nuevo. Grafico 33. Proceso Nuevo. Grafico 33. Proceso Nuevo. Grafico 33. Proceso Nuevo. Fuente: Elaboración PropiaFuente: Elaboración PropiaFuente: Elaboración PropiaFuente: Elaboración Propia 143143143143

Grafico 34. Reglas de Negocio. Grafico 34. Reglas de Negocio. Grafico 34. Reglas de Negocio. Grafico 34. Reglas de Negocio. Fuente: Elaboración PropiaFuente: Elaboración PropiaFuente: Elaboración PropiaFuente: Elaboración Propia 144144144144

Grafico 35. ConsultasGrafico 35. ConsultasGrafico 35. ConsultasGrafico 35. Consultas. Fuente: ElaboraciónFuente: ElaboraciónFuente: ElaboraciónFuente: Elaboración Propia Propia Propia Propia 146146146146

Grafico 36. Diagrama Entidad RelaciónGrafico 36. Diagrama Entidad RelaciónGrafico 36. Diagrama Entidad RelaciónGrafico 36. Diagrama Entidad Relación. Fuente: Elaboración PropiaFuente: Elaboración PropiaFuente: Elaboración PropiaFuente: Elaboración Propia 146146146146

Grafico 37. Diccionario de DatosGrafico 37. Diccionario de DatosGrafico 37. Diccionario de DatosGrafico 37. Diccionario de Datos. Fuente: Elaboración PropiaFuente: Elaboración PropiaFuente: Elaboración PropiaFuente: Elaboración Propia 147147147147

Grafico 38. Lista de SalidasGrafico 38. Lista de SalidasGrafico 38. Lista de SalidasGrafico 38. Lista de Salidas. Fuente: Elaboración PropiaFuente: Elaboración PropiaFuente: Elaboración PropiaFuente: Elaboración Propia 147147147147

Grafico 39. PrototipoGrafico 39. PrototipoGrafico 39. PrototipoGrafico 39. Prototipo. Fuente: Elaboración PFuente: Elaboración PFuente: Elaboración PFuente: Elaboración Propiaropiaropiaropia 148148148148

Grafico 40. ReportesGrafico 40. ReportesGrafico 40. ReportesGrafico 40. Reportes. Fuente: Elaboración PropiaFuente: Elaboración PropiaFuente: Elaboración PropiaFuente: Elaboración Propia 150150150150

Grafico 41. Cambios a ProgramasGrafico 41. Cambios a ProgramasGrafico 41. Cambios a ProgramasGrafico 41. Cambios a Programas. Fuente: Elaboración PropiaFuente: Elaboración PropiaFuente: Elaboración PropiaFuente: Elaboración Propia 151151151151

Grafico 42. Matriz PruebasGrafico 42. Matriz PruebasGrafico 42. Matriz PruebasGrafico 42. Matriz Pruebas. Fuente: Elaboración PropiaFuente: Elaboración PropiaFuente: Elaboración PropiaFuente: Elaboración Propia 152152152152

Grafico 43. Matriz de RolesGrafico 43. Matriz de RolesGrafico 43. Matriz de RolesGrafico 43. Matriz de Roles. Fuente: Elaboración PropiaFuente: Elaboración PropiaFuente: Elaboración PropiaFuente: Elaboración Propia 152152152152

GrafiGrafiGrafiGrafico 44. Manual de Usuarioco 44. Manual de Usuarioco 44. Manual de Usuarioco 44. Manual de Usuario. Fuente: Elaboración PropiaFuente: Elaboración PropiaFuente: Elaboración PropiaFuente: Elaboración Propia 153153153153

9

Grafico 45. MigraciónGrafico 45. MigraciónGrafico 45. MigraciónGrafico 45. Migración. Fuente: Elaboración PropiaFuente: Elaboración PropiaFuente: Elaboración PropiaFuente: Elaboración Propia 154154154154

Grafico 46. Check List de PruebasGrafico 46. Check List de PruebasGrafico 46. Check List de PruebasGrafico 46. Check List de Pruebas. Fuente: Elaboración PropiaFuente: Elaboración PropiaFuente: Elaboración PropiaFuente: Elaboración Propia 155155155155

Grafico 47. Correcciones y MejorasGrafico 47. Correcciones y MejorasGrafico 47. Correcciones y MejorasGrafico 47. Correcciones y Mejoras. Fuente: Elaboración PropiaFuente: Elaboración PropiaFuente: Elaboración PropiaFuente: Elaboración Propia 156156156156

Grafico Grafico Grafico Grafico 48. Presentación de Difusión48. Presentación de Difusión48. Presentación de Difusión48. Presentación de Difusión. Fuente: Elaboración PropiaFuente: Elaboración PropiaFuente: Elaboración PropiaFuente: Elaboración Propia 158158158158

Grafico 49. Plan de LiberaciónGrafico 49. Plan de LiberaciónGrafico 49. Plan de LiberaciónGrafico 49. Plan de Liberación. Fuente: Elaboración PropiaFuente: Elaboración PropiaFuente: Elaboración PropiaFuente: Elaboración Propia 159159159159

Grafico 50. Lista de RiesgosGrafico 50. Lista de RiesgosGrafico 50. Lista de RiesgosGrafico 50. Lista de Riesgos. Fuente: Elaboración PropiaFuente: Elaboración PropiaFuente: Elaboración PropiaFuente: Elaboración Propia 160160160160

Grafico 51. Plan GeneralGrafico 51. Plan GeneralGrafico 51. Plan GeneralGrafico 51. Plan General. Fuente: Elaboración PropiaFuente: Elaboración PropiaFuente: Elaboración PropiaFuente: Elaboración Propia 161161161161

Grafico 52Grafico 52Grafico 52Grafico 52. Bitácora de Asuntos. Bitácora de Asuntos. Bitácora de Asuntos. Bitácora de Asuntos. Fuente: Elaboración PropiaFuente: Elaboración PropiaFuente: Elaboración PropiaFuente: Elaboración Propia 162162162162

10

RESUMENRESUMENRESUMENRESUMEN

Actualmente existen diversas metodologías para desarrollo de sistemas en el mundo,

muchas de ellas son complejas, y extensas, además de estar enfocadas a grandes

departamentos de Tecnologías de Información, la desventaja que tienen es que no están

enfocadas a las pequeñas y medianas empresas que existen en el país.

Este trabajo se enfoca a las pequeñas y medianas empresas del país, que cuentan con

recursos limitados y buscan una guía para el desarrollo de software con calidad y fácil de

implementar.

En este trabajo exploramos lo que son las PyMEs en México, cual es su definición, que

factores influyen para determinar la competitividad de las mismas, así como las

diferencias que existen entre las Microempresas y las PyMEs.

Las PyMEs se enfrentan día a día a una serie de problemáticas las cuales se puntualizan,

también se muestran las necesidades que estas tienen y el ambiente en el que se

desenvuelven las PyMEs desarrolladoras de Software.

Para poder desarrollar una guía de desarrollo de software es necesario tener ciertas bases

teóricas o conocer la definición de ciertos conceptos, la Administración Informática

maneja varios de estos conceptos, la Ingeniería de Software, Administración de Proyectos

y herramientas como RUP o UML.

También se muestran ciertos aspectos que le dan ventaja competitiva a las PyMEs cuando

usan una metodología para el desarrollo de sus proyectos.

Esta guía se compone de 11 etapas, cada una de ellas con un objetivo y una secuencia

lógica definida, también se indica la documentación que se recomienda utilizar para el

control de cada etapa, cubriendo de esta manera todo el ciclo de desarrollo de software,

desde la planeación, hasta las pruebas, capacitación y puesta en marcha.

La guía de desarrollo de software esta orientada a pequeñas y medianas empresas que no

cuenten con una metodología para el desarrollo de software o métodos formales para

desarrollo de software, sin embargo también puede ser utilizada como un modelos de

desarrollo para departamentos de software con recurso limitados que desean llevar un

control de sus proyectos con resultados óptimos.

11

INTRODUCCIÓN

Actualmente las empresas del mundo viven cambios constantes con el objetivo de

competir y tener la preferencia de los consumidores, para ello se apoyan de muchas

metodologías, procesos, normas, etc, que brinden un soporte confiable en el desarrollo

de herramientas de software para las organizaciones, y con ello obtener productos y

resultados de calidad.

Desafortunadamente la gran mayoría de esas herramientas, metodologías, procesos y

normas se orientan a grandes organizaciones que cuentan con suficiente capital

económico, material y humano, logrando que la aplicación de ellas se adapte fácilmente y

comúnmente se logren los objetivos planeados.

Uno de los principales retos que enfrentan las áreas de Informática en los departamentos

de desarrollo de software de la mayoría de las empresas, es la administración de los

proyectos de sistemas de información, de acuerdo a la forma como se lleve esta

administración se pueden desprender problemas de diversos niveles, en temas como,

seguimiento a tareas, cumplimiento en tiempo, mala administración de recursos,

resultados no planeados, entre otros.

Actualmente escuchamos hablar sobre las PyMEs de México, sobre patrones externos que

afectan fuerte y directamente a este tipo de empresas (como las crisis económicas),

aunado a estos factores el no tener implementado un método o guía que sirva como

directriz del desarrollo de productos de software puede llevar al fracaso total de una PyME

orientada al desarrollo de software.

Siendo pesimistas, en empresas que inician en el desarrollo de software ( o simplemente

en departamentos informáticos pequeños), clasificadas dentro de las PyMEs es altamente

probable que no se lleven controles y documentación para el desarrollo de software,

debido a que las herramientas o metodologías que hay en el mercado se enfocan o fueron

diseñadas para grandes organizaciones que disponen de muchos recursos, y que su uso

es muy complejo, esto puede obligar a las PyMEs a no poder adquirir herramientas

comerciales, ya que esas herramientas podrían quedar grandes para la administración de

los proyectos, es por eso, que comúnmente la administración y desarrollo de software se

llega hacer de manera empírica (en el mejor de los casos) o incluso abstenerse de utilizar

una metodología en este tipo de empresas, obteniendo como resultado, una deficiente

administración del desarrollo de software que conlleva a retrasos en entregas, generación

de software de baja calidad, la no existencia de documentación, entre otras.

12

A través de la Guía podrán ver cada una de las etapas en las que se divide el proceso para

el desarrollo de software, cada etapa esta delimitada y cuenta con sus documentos que la

soportan, y los entregables que sirven de insumo para la siguiente etapa, también

tenemos una etapa que cubre a las demás y se encarga de llevar el control del proyecto,

permitiendo ver los avances y verificar que el proyecto se lleve a cabo de la manera en que

fue planeado y en caso de no ser así implementar las medidas preventivas o correctivas

necesarias para que el proyecto llegue a su fin de manera exitosa en los tiempos y con los

recursos planeados.

La ventaja que tiene esta guía a diferencia de una metodología es que su manejo, así

como la cantidad de documentos que se ocupan son los básicos, haciéndola muy sencilla

de seguir e implementar, los costos se verán reducidos ya que el control del proyecto

puede ser llevado con herramientas de software comunes, y los resultados son palpables

para los integrantes del proyecto.

OBJETIVOOBJETIVOOBJETIVOOBJETIVO

La Guía para el Desarrollo de Software en las PyMEs se enfoca en diseñar un modelo que

cubra todas las necesidades que se deben tomar en cuenta para el desarrollo de software

en las PyMEs, brindando un control y administración del proyecto de la manera mas

elemental, pero cubriendo los aspectos necesarios de éxito que manejan otras

metodologías y que concluyen con un producto de software con calidad.

METODOLOGIAMETODOLOGIAMETODOLOGIAMETODOLOGIA

El presente trabajo fue desarrollado bajo la siguiente metodología:

1. Observación y experiencia profesional.

2. Investigación teórica.

3. Síntesis y propuestas.

CONTENIDOCONTENIDOCONTENIDOCONTENIDO

Capitulo 1. Las PyMEs en México

Aquí se identifican las características que tienen las PyMEs en México, las diferencias entre

Microempresa y PyME, los factores que determinan la competitividad en una PyME, así

como los problemas y las necesidades a las que comúnmente se enfrentan, finalmente se

describe el ambiente que viven las PyMEs desarrolladoras de software en México.

Capitulo 2. La Informática y la Administración de Proyectos.

13

En este capitulo se trabaja con diversos temas relacionados con las metodologías y

herramientas que nos ayudan para administrar un proyecto de software, se tocan puntos

que van desde la definición de la Administración Informática, la Ingeniería de Software

hasta las metodologías actuales como RUP y UML

Capitulo 3. Administración de Proyectos Informáticos.

En este capitulo se aterrizan los conceptos y se le da un enfoque hacia las empresas que

actualmente utilizan metodologías y modelos para el desarrollo de software, se analizan

también las tendencias en la administración de los proyectos, cuales son los principales

beneficios que obtenemos al usar metodologías y finalmente, un resumen del tipo de

PyMEs que pueden adaptarse a este trabajo.

Capitulo 4. Guía para el Desarrollo de Software en las PyMEs

En este capitulo se encuentra el núcleo del trabajo de la tesis, aquí se definen cada una de

las etapas que componen la guía y una definición de las mismas, además de los

entregables y documentos que se manejan en cada una de las etapas.

Capitulo 5. Caso Practico

Finalmente, aquí se desarrolla la aplicación de la metodología, se basa en un caso ficticio

pero el objetivo es ilustrar la aplicación de la guía, el manejos de los documentos y la

aplicación funcional en cada etapa.

14

1. LAS PyMEs EN MEXICO Las pequeñas y medianas empresas (PyMEs) son de gran importancia para la economía

nacional, ya que estas son generadoras de empleo y riquezas.

Desafortunadamente la información estadística que se tiene de las mismas sobre el papel

económico y el desempeño en nuestro país es escasa y por lo tanto difícil de comparar

con la información que generan nuestros principales socios comerciales.

En este capitulo se verán las características que definen una pequeña y mediana empresa,

es decir los factores que lo determinan incluso en diferentes países, también los factores

de competitividad en las PyMEs de México, las principales características y diferencias

entre la Microempresa y la PyME, los problemas que afectan a las PyMEs y las necesidades

de las mismas y concluimos con un breve análisis de las PyMEs desarrolladoras de

Software.

1.11.11.11.1 Caracterización general de las pequeñas y medianas empresas.Caracterización general de las pequeñas y medianas empresas.Caracterización general de las pequeñas y medianas empresas.Caracterización general de las pequeñas y medianas empresas. Comenzaremos definiendo lo que es una empresa, la definición de una empresa sin

importar su tamaño, o su lugar de origen, es igual en cualquier parte del mundo, ya que

dentro de su definición, siempre gozará de los mismos componentes necesarios para que

pueda decirse que es una empresa.

Por consiguiente, una empresa se define como:

“Unidad económico-social, integrada por elementos humanos, materiales y técnicos, que

tienen el objetivo de obtener utilidades a través de su participación en el mercado de

bienes y servicios. Para esto, hace uso de los factores productivos (trabajo, tierra y

capital)”1

Ya definida la empresa ahora nos enfocaremos a sus características, observando la

relación que esta tiene con su definición.

Las empresas poseen características comunes como son:

• Recursos humanos, de capital, técnicos y financieros.

• Realizan actividades económicas referentes a la producción, distribución de bienes

y servicios que satisfacen necesidades humanas.

• Combinan factores de producción a través de los procesos de trabajo, de las

relaciones técnicas y sociales de la producción.

• Planean sus actividades de acuerdo a los objetivos que desean alcanzar.

1 “Definición de Empresa”, http://definicion.de/empresa/, [21Septiembre09].

15

• Son una organización social muy importante que forman parte del ambiente

económico y social de un país.

• Son un instrumento muy importante del proceso de crecimiento y desarrollo

económico y social.

• Para sobrevivir debe de competir con otras empresas, lo que exige:

modernización, racionalización, programación y mejora continua.

• El modelo de desarrollo empresarial reposa sobre las nociones de riesgo, beneficio

y mercado.

• Es el lugar donde se desarrollan y combinan el capital y el trabajo, mediante la

administración, coordinación e integración, que es una función de la organización.

• La competencia y la evolución industrial promueven el funcionamiento eficiente de

la empresa.

• Se encuentran influenciadas por todo lo que suceda en el medio ambiente natural,

social, económico y político, al mismo tiempo que su actividad repercute en la

propia dinámica social. 2

Clasificaciones del tamaño de las empresas. Para clasificar el tamaño de una empresa comenzaremos por la clasificación más sencilla,

por el numero de trabajadores que laboran en ella, tomaremos como referencia las

siguientes instituciones las cuales están dedicadas al fomento y desarrollo de las

empresas en cada uno de sus países:

• Instituto Nacional de Estadística y Estudios Económicos en Francia (INSEE) 3

• Small Business Administrations de Estados Unidos (SBA) 4 • Comisión Económica para América Latina (CEPAL) 5

• Revista Mexicana de Ejecutivos de Finanzas (EDF) 6

• Secretaría de Economía de México (SE) 7

2 Méndez, Morales José Silvestre, 1996. “Economía y la Empresa”. Editorial McGraw-Hill, México. 3 Institut National de la Statistique et des Études Économiques: INSEE, http://www.insee.fr/en/insee-statistique-publique/default.asp 4 “United States Small Business Administration”, http://www.sba.gov/, [06Julio2008] 5 “Comisión Económica para América Latina y el Caribe”, http://www.eclac.org/, [06Julio2008] 6 “Revista Mexicana de Ejecutivos de Finanzas”, http://ejecutivosdefinanzas.org.mx/, [06Julio2008] 7 “Secretaría de Economía”, http://www.economia.gob.mx/, [06Julio2008]

16

Institución Institución Institución Institución Tamaño de la empresa Tamaño de la empresa Tamaño de la empresa Tamaño de la empresa Número de Número de Número de Número de

trabajadores trabajadores trabajadores trabajadores

Pequeña De 50 a 250 INSEE INSEE INSEE INSEE

Mediana De 250 a 1000

Pequeña Hasta 250 SBA SBA SBA SBA


Pequeña Entre 5 y 49 Comisión Comisión Comisión Comisión

Económica para Económica para Económica para Económica para

América Latina América Latina América Latina América Latina Mediana De 50 a 250

Pequeña Menos de 25 EDF EDF EDF EDF

Mediana Entre 50 y 250

Pequeña De 16 a 100 SecretSecretSecretSecretaría de aría de aría de aría de

Economía Economía Economía Economía


Tabla 1 Tabla 1 Tabla 1 Tabla 1 –––– Clasificación del tamaño de las empresas. Fuente: Clasificación del tamaño de las empresas. Fuente: Clasificación del tamaño de las empresas. Fuente: Clasificación del tamaño de las empresas. Fuente:

Juan Pablo Zorrilla con base de Rodríguez (1996) Juan Pablo Zorrilla con base de Rodríguez (1996) Juan Pablo Zorrilla con base de Rodríguez (1996) Juan Pablo Zorrilla con base de Rodríguez (1996) 8888

Podemos observar que el número de trabajadores en países desarrollados como Francia y

EE.UU., es mucho mayor en comparación del número de trabajadores para poder clasificar

el tamaño de las empresas, ya sea, pequeña o mediana, por lo tanto no sería correcto

tomar en cuenta estos criterios, ya que no se aplican a la realidad económica de nuestro

país; en cambio las clasificaciones de la CEPAL, EDF y la SE, son más apegadas a la

realidad de nuestro país, para poder determinar el tamaño de una empresa por su número

de trabajadores.

8 “La importancia de las PYMES en México y para el mundo”, http://www.gestiopolis.com/canales2/economia/pymmex.htm [06Julio2008]

17

La SE presenta también, un criterio más particular, donde estratifica a las empresas según

sea su actividad productiva, como se muestra a continuación:

Actividad Actividad Actividad Actividad

Productiva Productiva Productiva Productiva

Tamaño de Tamaño de Tamaño de Tamaño de

la empresa la empresa la empresa la empresa

Industriales Industriales Industriales Industriales Comerciales Comerciales Comerciales Comerciales Servicios Servicios Servicios Servicios

Pequeña De 25 o

menos, hasta

100 empleados

De 25 o menos

empleados

De 21 a 50

empleados


empleados

De 21 a 100

empleados

De 51 a 100

empleados

Tabla 2 Tabla 2 Tabla 2 Tabla 2 –––– Estratificación de las empresas según su actividad productiva. Estratificación de las empresas según su actividad productiva. Estratificación de las empresas según su actividad productiva. Estratificación de las empresas según su actividad productiva. 9999

Nótese que las empresas dedicadas al comercio son las que poseen menor número de

trabajadores, según sea su tamaño, seguida por las empresas dedicadas a brindar

cualquier tipo de servicio, y finalmente las industriales, ya que absorben mayor mano de

obra, para poder llevar a cabo sus procesos productivos.

Durante el año 2002, la Secretaría de Economía (SE) junto con el Banco Interamericano de

Desarrollo (BID) 10, la Universidad de Bolonia en Argentina 11 y el INEGI 12, levantaron la

Encuesta del Observatorio PyME 13.

Esta encuesta agrupa a un panel de mil pequeñas y medianas empresas mexicanas de los

sectores manufacturas, comercio y servicios.

Los resultados de la encuesta (al provenir de una muestra estadísticamente significativa)

pueden ser expandidos posteriormente para el total de PyMEs del país, permitiendo

obtener información oportuna y de calidad sobre su situación actual y la cual es tomada

en este capitulo como principal referencia.

9 “Secretaría de Economía”, http://www.economia.gob.mx/, [06Julio2008] 10 “Banco Interamericano de Desarrollo”, http://www.iadb.org/?lang=es, [06Julio2008] 11 “Universidad de Bolonia en Argentina”, http://www.ba.unibo.it/BuenosAires/default.htm, [15Julio2008] 12 “Instituto Nacional de Estadística y Geografía”, http://www.inegi.gob.mx/inegi/default.aspx, [15Julio2008] 13 “Observatorio PyME”, http://www.cipi.gob.mx/html/observatorio.html, [15Julio2008].

18

De acuerdo a la encuesta del Observatorio de PYME 2002 la tabla siguiente muestra una

clasificación de las empresas bajo el criterio de tamaño y sector.

PEQUEÑA Y MEDIANA EMPRESA

SECTOR PERSONAL OCUPADO

VENTAS ANUALES (DÓLARES)

Manufacturero 10 a 200 500,000 a 24,000,000

Comercio 5 a 100 1,000,000 a 48,000,000

Servicios 5 a 100 250,000 a 12,000,000

Tabla 3 Tabla 3 Tabla 3 Tabla 3 –––– Criterios de Clasificación (variables por tamaño y sector). Fuente: Encuesta del Criterios de Clasificación (variables por tamaño y sector). Fuente: Encuesta del Criterios de Clasificación (variables por tamaño y sector). Fuente: Encuesta del Criterios de Clasificación (variables por tamaño y sector). Fuente: Encuesta del


En el país la estratificación de empresas por tamaño se establece con base en el sector

económico y el número de empleados.

SECTOR

TAMAÑO MANUFACTURERO COMERCIO SERVICIOS

Micro 0-10 0-10 0-10 Pequeña 11-50 11-30 11-50 Mediana 51-250 31-100 51-100

Grande 251 en adelante 101 en adelante 101 en adelante

Tabla 4Tabla 4Tabla 4Tabla 4 – Estratificación de empresas por tamaño. Fuente: Diario Oficial de la Federación, Estratificación de empresas por tamaño. Fuente: Diario Oficial de la Federación, Estratificación de empresas por tamaño. Fuente: Diario Oficial de la Federación, Estratificación de empresas por tamaño. Fuente: Diario Oficial de la Federación,

(30 Dic. 2002).(30 Dic. 2002).(30 Dic. 2002).(30 Dic. 2002). Podemos observar que cada una de las empresas requiere atención diferenciada en

función de su tamaño y su edad en el mercado.

El gran porcentaje de microempresas posee su propia problemática, la cual es distinta a la

de las PyMEs y la gran empresa.

19

Creación y desarrollo de las PYMEs

De acuerdo al observatorio 14, las PyMEs en México cuentan con presencia y experiencia

en el mercado, considerando que casi el 50 por ciento de éstas tiene más de 12 años con

la misma razón social, y cerca del 90 por ciento ha estado más de 5 años en el mercado.

Grafica 1Grafica 1Grafica 1Grafica 1---- Permanencia en el mercado Permanencia en el mercado Permanencia en el mercado Permanencia en el mercado (años con la misma razón social, promedio de (años con la misma razón social, promedio de (años con la misma razón social, promedio de (años con la misma razón social, promedio de

sectoresectoresectoresectores manufacturero, comercial y servicios)s manufacturero, comercial y servicios)s manufacturero, comercial y servicios)s manufacturero, comercial y servicios). Fuente: Encuesta del Observatorio PyME . Fuente: Encuesta del Observatorio PyME . Fuente: Encuesta del Observatorio PyME . Fuente: Encuesta del Observatorio PyME

2002.2002.2002.2002.

Principales características de los responsables de la empresa

Al considerar a los socios que participan en la gestión y dirección de las PyMEs, es posible

distinguir entre rangos de edad y sexo, identificando las características de los encargados

de la gestión empresarial:

Tabla 5 Tabla 5 Tabla 5 Tabla 5 –––– Características de los responsables de las PyMEs Características de los responsables de las PyMEs Características de los responsables de las PyMEs Características de los responsables de las PyMEs (socios por rango de edad y (socios por rango de edad y (socios por rango de edad y (socios por rango de edad y

sexo, total de sectores manufacturero, sexo, total de sectores manufacturero, sexo, total de sectores manufacturero, sexo, total de sectores manufacturero, comercial y servicios)comercial y servicios)comercial y servicios)comercial y servicios). Fuente: Encuesta del . Fuente: Encuesta del . Fuente: Encuesta del . Fuente: Encuesta del


14 “Observatorio PyME”, http://www.cipi.gob.mx/html/observatorio.html, [15Julio2008].

20

El cuadro anterior muestra que aún existe una dispersión muy amplia entre empresarios y

empresarias en México. En principio, más del 50 por ciento de los empresarios del país se

ubica en el rango entre 40 y 59 años, seguido por aquellos propietarios con edades entre

26 y 39 años (un 30 por ciento del total). Estos patrones son homogéneos entre hombres

y mujeres.

Asimismo, al analizar la información, se desprende que existen cerca de 3 socios del sexo

masculino por cada socio del sexo femenino (dispersión de 2.7, considerando el total de

socios). El indicador de dispersión 15151515 toma su valor más pequeño en el rango de

responsables menores a 20 años (presentándose 2.3 socios del sexo masculino por cada

socio del sexo femenino); por el contrario, el rango es más alto entre los empresarios

mayores a 60 años (dispersión de casi 4 puntos).

El nivel de educación de los socios es también una variable importante del análisis:

TTTT

abla 6 abla 6 abla 6 abla 6 –––– Indicadores de educación Indicadores de educación Indicadores de educación Indicadores de educación (socios por nivel de formación y sexo, suma total de los (socios por nivel de formación y sexo, suma total de los (socios por nivel de formación y sexo, suma total de los (socios por nivel de formación y sexo, suma total de los

sectores manufacturero, comercio y servicios)sectores manufacturero, comercio y servicios)sectores manufacturero, comercio y servicios)sectores manufacturero, comercio y servicios). Fuente: Encuesta del Observatorio PyME . Fuente: Encuesta del Observatorio PyME . Fuente: Encuesta del Observatorio PyME . Fuente: Encuesta del Observatorio PyME

2002.2002.2002.2002.

Los empresarios con licenciatura completa son cerca del 50 por ciento del total (para cada

sexo y el universo de establecimientos). En segundo lugar se ubican los propietarios con

preparatoria o profesional técnico completo. El tercer lugar es diferenciado: maestría

completa en el caso de los socios de sexo masculino, y secundaria completa para el caso

de los socios de sexo femenino.

15 Dispersión significa el grado de distanciamiento de un conjunto de valores respecto a su valor medio

21

Es interesante analizar el porcentaje de conclusión de estudios, por nivel de formación y

por sexo.

Tabla 7 Tabla 7 Tabla 7 Tabla 7 –––– Porcentaje de conclusión de estudios Porcentaje de conclusión de estudios Porcentaje de conclusión de estudios Porcentaje de conclusión de estudios (por nivel de for(por nivel de for(por nivel de for(por nivel de formación y sexo, total de los mación y sexo, total de los mación y sexo, total de los mación y sexo, total de los

sectores manufacturero, comercio y servicios)sectores manufacturero, comercio y servicios)sectores manufacturero, comercio y servicios)sectores manufacturero, comercio y servicios). Fuente: Encuesta del Observatorio PyME . Fuente: Encuesta del Observatorio PyME . Fuente: Encuesta del Observatorio PyME . Fuente: Encuesta del Observatorio PyME

2002.2002.2002.2002.

Es posible observar que los porcentajes de conclusión de estudios son similares entre

ambos sexos. La diferencia más significativa se encuentra en el nivel de primaria, que es

concluida por el 80 por ciento de los socios de sexo masculino, a diferencia del 56 por

ciento para los socios de sexo femenino. Para los niveles de secundaria y bachillerato, el

porcentaje es ligeramente superior para los socios femeninos, mientras que para

licenciatura y maestría, éste es superior para los socios del sexo masculino.

Es también interesante que el porcentaje de conclusión para el grado de doctorado es del

100 por ciento, para ambos sexos.

22

Distribución Sectorial de las EmpresasDistribución Sectorial de las EmpresasDistribución Sectorial de las EmpresasDistribución Sectorial de las Empresas

Siguiendo los resultados de los Censos Económicos 1999 de INEGI, el 52 por ciento del

total de las empresas se ocupan en el sector comercio, 36 por ciento en el sector servicios

y 12 por ciento en el manufacturero.

De este total, las PyMEs orientan sus actividades en 63.4 por ciento al comercio, 19.4 por

ciento a los servicios y 17.2 por ciento a las manufacturas. Esta información se presenta

en la siguiente figura:

Grafica 2 Grafica 2 Grafica 2 Grafica 2 ---- Composici Composici Composici Composición de las empresas en México, por tamaño y por sector (total de ón de las empresas en México, por tamaño y por sector (total de ón de las empresas en México, por tamaño y por sector (total de ón de las empresas en México, por tamaño y por sector (total de

establecimientos y participación porcentual). Fuente: INEGI, Censos Económicos 1999.establecimientos y participación porcentual). Fuente: INEGI, Censos Económicos 1999.establecimientos y participación porcentual). Fuente: INEGI, Censos Económicos 1999.establecimientos y participación porcentual). Fuente: INEGI, Censos Económicos 1999.

Al interior del sector manufacturero, la actividad que agrupa el mayor número de

unidades empresariales es la división I (productos alimenticios, bebidas y tabaco), en

donde se concentra casi una de cada tres empresas del sector. Por el contrario, la división

VII (industria metálica básica) ocupa apenas el 0.1 por ciento del total de

establecimientos. Esto se muestra en el siguiente cuadro:

23

Tabla 8 Tabla 8 Tabla 8 Tabla 8 ---- Participación de las unidades económicas en el sector manufacturero Participación de las unidades económicas en el sector manufacturero Participación de las unidades económicas en el sector manufacturero Participación de las unidades económicas en el sector manufacturero

(establecimientos por tamaño, porcentajes de participación). Fuente: INEGI, Censos (establecimientos por tamaño, porcentajes de participación). Fuente: INEGI, Censos (establecimientos por tamaño, porcentajes de participación). Fuente: INEGI, Censos (establecimientos por tamaño, porcentajes de participación). Fuente: INEGI, Censos

Económicos 1999.Económicos 1999.Económicos 1999.Económicos 1999.

Del cuadro se observa que las PyMEs participan con cerca del 4 por ciento del total de

establecimientos del sector manufacturero. Al interior del segmento, éstas poseen una

amplia participación dentro de las divisiones VII y V (sustancias químicas, derivados del

petróleo, productos de caucho y plástico). De hecho, para la división VII las PyMEs

conforman cerca del 50 por ciento del total de establecimientos, y en el caso de la división

V esta cifra es cercana al 20 por ciento. La división con menor participación de PyMEs es la

I, con un porcentaje muy similar al de la división III (industria de la madera y productos de

madera). En ambos casos, las PyMEs contribuyen con cerca del 2 por ciento del total de la

división.

24

Distribución Regional de las empresasDistribución Regional de las empresasDistribución Regional de las empresasDistribución Regional de las empresas

Geográficamente, las empresas se encuentran concentradas en un pequeño número de

estados: el Distrito Federal, el Estado de México, Jalisco, Veracruz y Puebla concentran

más del 40 por ciento del total de unidades productivas. En contraste, Nayarit, Quintana

Roo, Campeche, Colima y Baja California Sur, agrupan sólo el 3.7 por ciento del total de

las unidades empresariales:

Grafica 3 Grafica 3 Grafica 3 Grafica 3 ----Concentración geográfica de empresas en México (estados seleccionados, Concentración geográfica de empresas en México (estados seleccionados, Concentración geográfica de empresas en México (estados seleccionados, Concentración geográfica de empresas en México (estados seleccionados,

porcentajes de participación). Fuente: INEporcentajes de participación). Fuente: INEporcentajes de participación). Fuente: INEporcentajes de participación). Fuente: INEGI, Censos Económicos 1999.GI, Censos Económicos 1999.GI, Censos Económicos 1999.GI, Censos Económicos 1999.

Los efectos de esta concentración se ven reflejados en términos del producto interno

bruto (PIB) por entidad federativa: el Distrito Federal, Estado de México, Nuevo León,

Jalisco y Chihuahua generan más del 50 por ciento de la producción nacional de bienes y

servicios, mientras que las cinco entidades con menor participación generan tan solo el 3

por ciento del PIB nacional, como se muestra a continuación:

25

Grafica 4 Grafica 4 Grafica 4 Grafica 4 ---- Producto Interno Bruto por entidad fede Producto Interno Bruto por entidad fede Producto Interno Bruto por entidad fede Producto Interno Bruto por entidad federativa (estados seleccionados, rativa (estados seleccionados, rativa (estados seleccionados, rativa (estados seleccionados,

porcentajes de participación). Fuente: INEGI, Banco de Información Económica.porcentajes de participación). Fuente: INEGI, Banco de Información Económica.porcentajes de participación). Fuente: INEGI, Banco de Información Económica.porcentajes de participación). Fuente: INEGI, Banco de Información Económica.

Por otro lado, es conveniente señalar que el efecto sobre el PIB estatal va más allá de la

concentración de unidades productivas: está relacionado con la distribución relativa de

empresas grandes y medianas en relación con las micro y pequeñas. Las empresas, según

su tamaño, se distribuyen a lo largo del país de la siguiente manera: los estados en dónde

prevalecen las medianas y grandes empresas con relación a las pequeñas y micro son

Nuevo León, Baja California y el Distrito Federal, entre otros. Por el contrario, en los

estados del sur del país, como Chiapas, Guerrero y Oaxaca, predomina la micro y pequeña

empresa, en relación con la grande y mediana.

26

La siguiente gráfica muestra que entidades como Nuevo León y Baja California poseen

entre 1.6 y 2.1 medianas y grandes empresas por cada 100 micro y pequeñas empresas,

mientras que estados como Chiapas y Oaxaca tienen entre 0.3 y 0.8 medianas y grandes

empresas por cada 100 micro y pequeñas:

Gráfica 5 Gráfica 5 Gráfica 5 Gráfica 5 ---- Relación de empresas grandes Relación de empresas grandes Relación de empresas grandes Relación de empresas grandes––––medianas y pequeñasmedianas y pequeñasmedianas y pequeñasmedianas y pequeñas––––micro, por estado micro, por estado micro, por estado micro, por estado

(cociente entre grupos de empresas). (cociente entre grupos de empresas). (cociente entre grupos de empresas). (cociente entre grupos de empresas). Fuente: Encuesta del Observatorio PyME 2002.Fuente: Encuesta del Observatorio PyME 2002.Fuente: Encuesta del Observatorio PyME 2002.Fuente: Encuesta del Observatorio PyME 2002.

De manera muy general todas las pequeñas y medianas empresas comparten casi siempre

las mismas características, por lo tanto, se podría decir, que estas son las características

generales con las que cuentan las PyMEs 16:

• El capital es proporcionado por una o dos personas que establecen una sociedad.

• Los propios dueños dirigen la marcha de la empresa; su administración es

empírica.

• Su número de trabajadores empleados en el negocio crece y va de 16 hasta 250

personas.

• Utilizan más maquinaria y equipo, aunque se sigan basando más en el trabajo que

en el capital.

• Dominan y abastecen un mercado más amplio, aunque no necesariamente tiene

que ser local o regional, ya que muchas veces llegan a producir para el mercado

nacional e incluso para el mercado internacional.

• Está en proceso de crecimiento, la pequeña tiende a ser mediana y está aspira a

ser grande.

16 Méndez, Morales José Silvestre, 1996, “Economía y la Empresa”, Editorial McGraw-Hill, México.

27

• Obtienen algunas ventajas fiscales por parte del Estado que algunas veces las

considera causantes menores dependiendo de sus ventas y utilidades.

• Su tamaño es pequeño o mediano en relación con las otras empresas que operan

en el ramo.

1.2 Determinantes de la competitividad de las PyMEs en México

La situación particular de las PyMEs refleja el entorno macroeconómico vigente, lo cual

puede observarse en su auto evaluación del desempeño durante 2000 y 2001:

Gráfica 6 Gráfica 6 Gráfica 6 Gráfica 6 ---- Auto evaluación del desempeño de las PyMEs durante 2000 Auto evaluación del desempeño de las PyMEs durante 2000 Auto evaluación del desempeño de las PyMEs durante 2000 Auto evaluación del desempeño de las PyMEs durante 2000 –––– 2001. Fuente: 2001. Fuente: 2001. Fuente: 2001. Fuente:


De la gráfica debe resaltarse que aunque una de cada seis empresas consideró tener un

crecimiento normal en los años de referencia, las cuatro restantes manifestaron estar

estancadas o haber empeorado su desempeño. Solamente un porcentaje mínimo señaló

haber experimentado un crecimiento acelerado.

Además de la situación macroeconómica, existen factores internos que afectan

directamente el desempeño de las PyMEs en México.

28

Personal ocupado y políticas de capacitación Personal ocupado y políticas de capacitación Personal ocupado y políticas de capacitación Personal ocupado y políticas de capacitación

Características del personal ocupado en las PyMEs Características del personal ocupado en las PyMEs Características del personal ocupado en las PyMEs Características del personal ocupado en las PyMEs

El nivel de instrucción del personal ocupado en las empresas (personal de planta y

eventual) posee tendencias encontradas, como se muestra a continuación:

Grafica 7 Grafica 7 Grafica 7 Grafica 7 ---- Nivel de instrucción del personal ocupado en las PyMEs Nivel de instrucción del personal ocupado en las PyMEs Nivel de instrucción del personal ocupado en las PyMEs Nivel de instrucción del personal ocupado en las PyMEs (promedio de los (promedio de los (promedio de los (promedio de los

sectores manufacturero, comercial y servicios)sectores manufacturero, comercial y servicios)sectores manufacturero, comercial y servicios)sectores manufacturero, comercial y servicios). Fuente: E. Fuente: E. Fuente: E. Fuente: Encuesta del Observatorio PyME ncuesta del Observatorio PyME ncuesta del Observatorio PyME ncuesta del Observatorio PyME

2002.2002.2002.2002. El personal del sector manufacturero está instruido principalmente en primaria y

secundaria, contrario al sector servicios donde la mayor parte de los empleados cuentan

con bachillerato o licenciatura. La mayoría del personal asociado al sector comercio

cuenta con secundaria o bachillerato. Asimismo, el grado de instrucción está relacionado

con la dificultad que los empresarios enfrentan para contratar personal. En promedio, los empresarios consideran que es relativamente sencillo encontrar mano de

obra directa sin calificación (MOD – SC) 17; únicamente un 14 por ciento señala que es un

proceso difícil. Por el contrario, cerca del 60 por ciento de los empresarios de los tres

sectores menciona que es medianamente difícil encontrar mano de obra directa calificada

(MOD – C) 18. El porcentaje es similar para los profesionales con licenciatura.

17 MOD-SC, Mano de Obra Directa sin Calificar. 18 MOD-C, Mano de Obra Directa Calificada.

29

Las opiniones sobre la dificultad para contratar personal con postgrado (maestría o

doctorado) se distribuyen uniformemente, aunque al interior del sector comercio, casi el

50 por ciento de los empresarios lo considera sencillo. Asimismo, el 40 por ciento de los

empresarios consideran el encontrar personal jerárquico un proceso fácil; sin embargo, al

interior de los sectores esto no es así.

Grafico 8 Grafico 8 Grafico 8 Grafico 8 ---- Grado de dificultad para contratar personal según su tipo Grado de dificultad para contratar personal según su tipo Grado de dificultad para contratar personal según su tipo Grado de dificultad para contratar personal según su tipo (basado en el juicio (basado en el juicio (basado en el juicio (basado en el juicio

de los empresarios, promedio de los sectores manufacturero, comercial y servicios)de los empresarios, promedio de los sectores manufacturero, comercial y servicios)de los empresarios, promedio de los sectores manufacturero, comercial y servicios)de los empresarios, promedio de los sectores manufacturero, comercial y servicios). . . .

Fuente: Encuesta del Observatorio PyME 2002.Fuente: Encuesta del Observatorio PyME 2002.Fuente: Encuesta del Observatorio PyME 2002.Fuente: Encuesta del Observatorio PyME 2002. PolPolPolPolítica de capacitación al personal ítica de capacitación al personal ítica de capacitación al personal ítica de capacitación al personal

La demanda de personal por parte de las empresas y el grado de especialización

requerido se complementa con información sobre capacitación. En general, el 60 por

ciento de las PyMEs mexicanas ofreció capacitación a sus empleados durante 2000 y

2001.

La capacitación se ofrece en su mayoría al personal de planta, y en menor proporción a

los propietarios y socios.

30

Es de interés el identificar las áreas con mayor y menor demanda para capacitación

empresarial, las cuales se detallan a continuación. El siguiente cuadro presenta el

porcentaje de empresas que realizaron capacitación por área temática:

Tabla 9 Tabla 9 Tabla 9 Tabla 9 ---- Temas con mayor demanda para capacitación Temas con mayor demanda para capacitación Temas con mayor demanda para capacitación Temas con mayor demanda para capacitación (porcentaje de empresas que (porcentaje de empresas que (porcentaje de empresas que (porcentaje de empresas que

requirieron cursos requirieron cursos requirieron cursos requirieron cursos en el tema, ien el tema, ien el tema, ien el tema, inversión, maquinaria y tecnologíanversión, maquinaria y tecnologíanversión, maquinaria y tecnologíanversión, maquinaria y tecnología)))). Fuente: Encuesta del . Fuente: Encuesta del . Fuente: Encuesta del . Fuente: Encuesta del

Observatorio PyME 2002.Observatorio PyME 2002.Observatorio PyME 2002.Observatorio PyME 2002. Comportamiento de la inversión en las empresas Comportamiento de la inversión en las empresas Comportamiento de la inversión en las empresas Comportamiento de la inversión en las empresas

El gasto de inversión realizado por las empresas refleja sus esfuerzos por modernizarse e

incrementar su competitividad. Esta variable tuvo un comportamiento mixto en 2001:

GGGG

rafico 9 rafico 9 rafico 9 rafico 9 ---- Comportamiento de las inversiones en 2001 (evolución con respecto al gasto de Comportamiento de las inversiones en 2001 (evolución con respecto al gasto de Comportamiento de las inversiones en 2001 (evolución con respecto al gasto de Comportamiento de las inversiones en 2001 (evolución con respecto al gasto de

inversión en 2000). inversión en 2000). inversión en 2000). inversión en 2000). Fuente: Encuesta del Observatorio PyME 2002.Fuente: Encuesta del Observatorio PyME 2002.Fuente: Encuesta del Observatorio PyME 2002.Fuente: Encuesta del Observatorio PyME 2002.

31

Los sectores comercio y servicios en general mantuvieron o incrementaron su gasto de

inversión: cerca del 75 por ciento de las empresas de estos sectores tuvieron un gasto

mayor o igual al de 2000. La situación es contraria en el sector manufacturero, donde más

de la mitad de las empresas reportan que su gasto de inversión fue menor.

Adicionalmente es necesario señalar que el 35 por ciento de las empresas del sector no

invirtieron durante 2001.

En términos generales, las empresas destinan su gasto de inversión hacia dos áreas: la de

maquinaria, equipo e instalaciones y la comercial. En particular, las empresas del sector

manufacturero que canalizaron recursos hacia la adquisición de maquinaria y equipo,

destinaron la inversión para los siguientes fines

Tabla 10 Tabla 10 Tabla 10 Tabla 10 ---- Destino de inversión en maquinaria y equipo (porcentaje de empresas que Destino de inversión en maquinaria y equipo (porcentaje de empresas que Destino de inversión en maquinaria y equipo (porcentaje de empresas que Destino de inversión en maquinaria y equipo (porcentaje de empresas que

destinaron recursos a cada concepto, sector manufacturero) Fuente: Encuesta del destinaron recursos a cada concepto, sector manufacturero) Fuente: Encuesta del destinaron recursos a cada concepto, sector manufacturero) Fuente: Encuesta del destinaron recursos a cada concepto, sector manufacturero) Fuente: Encuesta del

Observatorio PyME 2002.Observatorio PyME 2002.Observatorio PyME 2002.Observatorio PyME 2002. Del cuadro es notable resaltar que casi el 40 por ciento de las empresas que invirtieron en

maquinaria y equipo lo hicieron para expandir su planta productiva, mientras que un 30

por ciento planeaba reducir costos. Asimismo, una de cada cinco empresas realizó

inversiones para automatizar su proceso productivo.

Las empresas del sector comercio que invirtieron en equipamiento e instalaciones durante

2001, canalizaron sus recursos para obtener los siguientes resultados:

Tabla 11 Tabla 11 Tabla 11 Tabla 11 ---- Destino de inversión en equipamiento e instalaciones (porcentaje de em Destino de inversión en equipamiento e instalaciones (porcentaje de em Destino de inversión en equipamiento e instalaciones (porcentaje de em Destino de inversión en equipamiento e instalaciones (porcentaje de empresas presas presas presas

que destinaron recursos a cada concepto, sector comercio). Fuente: Encuesta del que destinaron recursos a cada concepto, sector comercio). Fuente: Encuesta del que destinaron recursos a cada concepto, sector comercio). Fuente: Encuesta del que destinaron recursos a cada concepto, sector comercio). Fuente: Encuesta del

Observatorio PyME 2002.Observatorio PyME 2002.Observatorio PyME 2002.Observatorio PyME 2002. La información del cuadro señala que un 40 por ciento de las empresas destinó recursos

para incrementar sus ventas, mientras que una de cada tres incorporó nuevas tecnologías

a su empresa. Un 15 por ciento realizó inversiones para reducir costos.

32

Maquinaria y tecnología de las PyMEs manufactureras Maquinaria y tecnología de las PyMEs manufactureras Maquinaria y tecnología de las PyMEs manufactureras Maquinaria y tecnología de las PyMEs manufactureras

Al interior del sector manufacturero, más del 60 por ciento de las empresas considera que

operan con maquinaria moderna, aunque un porcentaje también significativo (38 por

ciento) indica que su equipo es antiguo o muy antiguo:

Grafico 10 Grafico 10 Grafico 10 Grafico 10 ---- Estado de la maquinaria involucrada en el proceso de producción Estado de la maquinaria involucrada en el proceso de producción Estado de la maquinaria involucrada en el proceso de producción Estado de la maquinaria involucrada en el proceso de producción

(basado en el juicio de lo(basado en el juicio de lo(basado en el juicio de lo(basado en el juicio de los empresarios, sector manufacturero). Fuente: Encuesta del s empresarios, sector manufacturero). Fuente: Encuesta del s empresarios, sector manufacturero). Fuente: Encuesta del s empresarios, sector manufacturero). Fuente: Encuesta del

Observatorio PyME 2002.Observatorio PyME 2002.Observatorio PyME 2002.Observatorio PyME 2002. Esta polaridad entre las PyMEs del sector se complementa con la información sobre la

tecnología que éstas integran en su proceso de producción. En este caso particular, la

definición de tecnología es de espectro amplio y abarca temas como certificaciones,

políticas de mejora de calidad y productividad, así como el uso de licencias y patentes.

33

Tecnologías de información Tecnologías de información Tecnologías de información Tecnologías de información

Una parte importante de la modernización de las empresas proviene del incremento en el

uso de computadoras e internet. En este sentido, las PyMEs muestran una tendencia

favorable, que podría consolidarse en los próximos años.

El personal de las empresas que habitualmente utiliza equipo de cómputo en sus labores

se presenta en la siguiente gráfica:

Grafico 11Grafico 11Grafico 11Grafico 11---- Personal que habitualmente opera con equipo de cómputo Personal que habitualmente opera con equipo de cómputo Personal que habitualmente opera con equipo de cómputo Personal que habitualmente opera con equipo de cómputo

(porcentaje de empresas por rango de empleados). Fuente: Encuesta del Observatorio (porcentaje de empresas por rango de empleados). Fuente: Encuesta del Observatorio (porcentaje de empresas por rango de empleados). Fuente: Encuesta del Observatorio (porcentaje de empresas por rango de empleados). Fuente: Encuesta del Observatorio

PyME 2002PyME 2002PyME 2002PyME 2002 De ésta se observa que la gran mayoría de las empresas tienen entre 1 y 5 personas

laborando con equipo de cómputo. Asimismo es importante resaltar que cerca del 15 por

ciento de las empresas manufactureras y de comercio no tienen a ninguna persona

operando este tipo de equipo. El porcentaje es mucho menor para el sector servicios (5

por ciento), del cual casi una de cada cuatro empresas posee más de 11 personas

trabajando operando con computadoras.

34

En promedio, más del 70 por ciento de las empresas cuenta con acceso a internet, como

muestra la gráfica:

Grafico 12 Grafico 12 Grafico 12 Grafico 12 ---- PyMEs con acceso a Internet (porcentaje de empresas). Fuente: Encuesta del PyMEs con acceso a Internet (porcentaje de empresas). Fuente: Encuesta del PyMEs con acceso a Internet (porcentaje de empresas). Fuente: Encuesta del PyMEs con acceso a Internet (porcentaje de empresas). Fuente: Encuesta del

Observatorio PyME 2002.Observatorio PyME 2002.Observatorio PyME 2002.Observatorio PyME 2002. El acceso a internet es utilizado por las empresas principalmente con fines de información

y difusión de su negocio y productos:

Tabla 12 Tabla 12 Tabla 12 Tabla 12 ---- Principales motivos de las PyMEs para utilizar Internet (porcentaje de Principales motivos de las PyMEs para utilizar Internet (porcentaje de Principales motivos de las PyMEs para utilizar Internet (porcentaje de Principales motivos de las PyMEs para utilizar Internet (porcentaje de

empresas). Fuente: Encuesta del Observatorio PyME 2002.empresas). Fuente: Encuesta del Observatorio PyME 2002.empresas). Fuente: Encuesta del Observatorio PyME 2002.empresas). Fuente: Encuesta del Observatorio PyME 2002. Las similitudes entre sectores son notables: los primeros dos motivos señalados por las

empresas son el recopilar información del sector y dar a conocer su empresa y sus

productos respectivamente. Asimismo, la compra de insumos y productos es compartida

por los tres sectores, y la comercialización de productos es común a comercio y servicios

(aunque en menor medida a este último).

35

La difusión de la empresa y sus productos, así como la comercialización de estos últimos,

parte de la disponibilidad de una página web en la que las PyMEs presenten su oferta e

incluso pongan a la venta directa sus productos. El porcentaje de empresas que poseen

este instrumento es significativo, como se puede ver a continuación:

Grafico 13 Grafico 13 Grafico 13 Grafico 13 ---- PyMEs que cuentan con página web (reales y planeadas PyMEs que cuentan con página web (reales y planeadas PyMEs que cuentan con página web (reales y planeadas PyMEs que cuentan con página web (reales y planeadas, porcentaje de , porcentaje de , porcentaje de , porcentaje de

empresas). Fuente: Encuesta del Observatorio PyME 2002.empresas). Fuente: Encuesta del Observatorio PyME 2002.empresas). Fuente: Encuesta del Observatorio PyME 2002.empresas). Fuente: Encuesta del Observatorio PyME 2002.

Aunque el promedio de los tres sectores es cercano al 30 por ciento, los sectores

manufacturero y comercio rondan el 40 por ciento, mientras que para el sector servicios

el porcentaje se reduce hasta casi 20 por ciento. Sin embargo, el factor dinámico entra a

consideración cuando se pregunta a las empresas sobre si tienen contemplado contar con

un sitio web en los próximos 12 meses: el porcentaje promedio es de 40 por ciento. Con

este dato se podría esperar que en promedio, más de la mitad de las PyMEs en el país

tuvieran difusión en internet, pero debe tomarse en cuenta que las diferencias entre

sectores se mantienen (el porcentaje varía de casi 50 por ciento en el sector

manufacturero, a 30 por ciento en el sector servicios).

36

Además de la difusión de las empresas, las actividades de comercialización en internet

representan un canal importante para las ventas. Cerca del 40 por ciento (promedio) de

las PyMEs en México comercializan sus productos en internet, como muestra la gráfica:

Grafico 14 Grafico 14 Grafico 14 Grafico 14 ---- PyMEs que comercializan sus productos en internet y ventas en línea PyMEs que comercializan sus productos en internet y ventas en línea PyMEs que comercializan sus productos en internet y ventas en línea PyMEs que comercializan sus productos en internet y ventas en línea

(reales y planeadas, porcentaje de empresas; ventas en línea como porcentaje del total). (reales y planeadas, porcentaje de empresas; ventas en línea como porcentaje del total). (reales y planeadas, porcentaje de empresas; ventas en línea como porcentaje del total). (reales y planeadas, porcentaje de empresas; ventas en línea como porcentaje del total).

FuenFuenFuenFuente: Encuesta del Observatorio PyME 2002.te: Encuesta del Observatorio PyME 2002.te: Encuesta del Observatorio PyME 2002.te: Encuesta del Observatorio PyME 2002. El porcentaje de empresas que actualmente comercializa en internet es homogéneo entre

los sectores, aunque las ventas en línea como porcentaje del total si presentan

variaciones: de casi 8 por ciento (sector manufacturero) hasta un 15 por ciento (sector

servicios). De nuevo, el factor dinámico señala una alta preferencia a comercializar los

productos en internet en un futuro: cerca del 60 por ciento de las PyMEs tiene planeado

realizar esta acción.

37

1.3 Microempresa y PYME

MicroempresaMicroempresaMicroempresaMicroempresa

Una microempresa entra dentro del conjunto de las PYMES, aunque la definición exacta

dependerá de la legislación de cada país. Por ejemplo, en la Unión Europea (y por tanto en

todos los países que la forman), se entiende por «microempresa» a aquellas empresas que

presentan como mínimo dos de los tres criterios siguientes 19:

• Número de empleados igual o inferior a 10 personas.

• Volumen de negocio anual (facturación) igual o inferior a 2 millones de euros.

• Volumen de activos del año (balance general anual) igual o inferior a 2 millones de

euros.

En México se define como Microempresa, a las empresas que ocuparan hasta 15 personas

y el valor de sus ventas netas fueran hasta 30 millones de pesos al año.20

Modelos de la MicroempresaModelos de la MicroempresaModelos de la MicroempresaModelos de la Microempresa

El trabajador autónomo y la microempresa son los principales (y en ocasiones los únicos)

modelos que eligen los emprendedores a la hora de organizarse e intentar alcanzar sus

metas y objetivos. Esto se debe principalmente a que, en líneas generales, se cuenta con

poca financiación para empezar los proyectos empresariales 21.

Ventajas e Inconvenientes de la MicroempresaVentajas e Inconvenientes de la MicroempresaVentajas e Inconvenientes de la MicroempresaVentajas e Inconvenientes de la Microempresa

Las principales ventajas del modelo microempresa son la flexibilidad con la que actúan,

tanto a nivel del personal, que suele ser multidisciplinar, como a otros niveles

(disponibilidad geográfica, adaptabilidad del producto al mercado, transformación rápida,

toma rápida de decisiones, etc.), ventajas que deben aprovechar para poder hacerse con

un hueco en el mercado, muchas veces muy competitivo y maduro, al igual que la

pequeña y mediana empresa es una fuente generadora de empleos, se transforman con

gran facilidad por no poseer una estructura rígida.

El principal escollo contra el que deben luchar es la falta de financiación, lo que incurre en

muchas ocasiones en no poder marcarse objetivos más altos en un plazo más corto de

tiempo y que limita las posibilidades de expansión, tanto tecnológica como geográfica,

creándose un círculo vicioso donde la microempresa encuentra problemas de

19 “Microempresa”, http://es.wikipedia.org/wiki/Microempresa, [15Julio2008] 20 “Microempresa en México”, http://www.inegi.gob.mx/prod_serv/contenidos/espanol/bvinegi/productos/censos/economicos/2004/industrial/estratifica2004.pdf, [22Septiembre2009] 21 “Formas de Microempresario”, http://es.wikipedia.org/wiki/Microempresa, [15Julio2008]

38

competitividad y se ve obligada en gran número de ocasiones a limitar su mercado al

consumo interno 22.

Incentivos a la creación de microempresasIncentivos a la creación de microempresasIncentivos a la creación de microempresasIncentivos a la creación de microempresas

Un aspecto muy importante a valorar a la hora de crear o gestionar una microempresa es

que existen sistemas de financiación creados especialmente para este tipo de empresas,

tanto por parte de Bancos (Créditos con condiciones especiales) como por parte del

Gobierno (Subvenciones), de las que la microempresa se puede beneficiar en mayor

medida si los propietarios entran dentro del perfil de joven emprendedor (en general

menor de 35 años).

En muchos países existe una posibilidad económica llamada capital de riesgo, que sirve

para financiar, a menudo con grandes recursos, empresas que empiezan a funcionar o

que disponen, incluso a nivel teórico, de ideas o tecnologías con un futuro prometedor y

donde se esperan que grandes beneficios reviertan a medio plazo en los inversores de la

sociedad de capital riesgo, además de a las personas que forman la empresa.

Normalmente se debe ceder un número significativo de acciones de la empresa, sin llegar

a perder el control de la misma, a cambio de este sistema de financiación. Muchas

empresas punto com han crecido y prosperado con este procedimiento.

Existen también instituciones dedicadas al apoyo de los emprendedores de escasos

recursos. El ejemplo más famoso es el Banco de los pobres de Bangladesh. En Ecuador el

FEPP y CESA dedican parte de sus esfuerzos a fomentar la creación y consolidación de

microempresas rurales, familiares y grupales. Otros casos son Fondo Esperanza y Seve,

ONG que construye páginas web gratuitas para microempresarios de escasos recursos 23.

PYMEPYMEPYMEPYME

Es el acrónimo de pequeñas y medianas empresas.

Es casi un hecho que podemos afirmar que existe una definición de PYME para cada país,

sumémosle a ellas las de los organismos internacionales, instituciones varias, congresos y

convenciones, etc. No ha sido posible aún unificar criterios globales, esto es en parte

lógico dado los diferentes escenarios en cada país, región, economías, significación y

dimensiones de empresas a confrontar.

Una definición general, aunque poco precisa de PYME es: Un tipo de empresa con un

número reducido de trabajadores (generalmente entre 50 y 120 trabajadores) , y cuya

facturación es moderada.

En México, el concepto de "número reducido de trabajadores" pierde sentido ya que las

PYME pueden emplear hasta 499 trabajadores y aún ser consideradas PYME.

22 “Ventajas e Inconvenientes”, http://es.wikipedia.org/wiki/Microempresa, [15Julio2008] 23 “Incentivos a la creación de microempresas”, http://es.wikipedia.org/wiki/Microempresa, [15Julio2008]

39

En México, la PyME representa el 94% de las empresas; por esta razón, es vital su

permanencia. Al respecto la Secretaría de Economía (SE) ha creado diversos programas

para apoyarlas. Uno de ellos es la "Aceleración de Negocios" 24, que consiste en facilitar a

las micro, pequeñas y medianas empresas la utilización de esquemas de negocio que

integren canales comerciales, optimización de procesos, desarrollo de productos y

capacidad experta, que las prepare para competir en el mercado global.

Dicho apoyo consiste en facultar a organismos capacitados para ayudar a la PYME

buscando aquellos aspectos que impiden su crecimiento. El CEPii (Centro Panamericano

de Investigación e Innovación) 25, perteneciente a la Universidad Panamericana y el IPADE 26, es una de las principales aceleradoras de negocios mexicanas.

Del análisis de esta información, se desprende que las empresas requieren atención

diferenciada, en función de su tamaño y de su edad en el mercado. El gran porcentaje de

microempresas posee su propia problemática, la cual es distinta a la de las PyMEs y la

gran empresa. Esta atención diferenciada debe ser la base para el diseño y planeación de

políticas públicas en apoyo a las empresas del país.

Confusión entre los conceptos de microempresa y PyME Confusión entre los conceptos de microempresa y PyME Confusión entre los conceptos de microempresa y PyME Confusión entre los conceptos de microempresa y PyME

Esta confusión se manifiesta desde una inadecuada planeación de los programas de apoyo

(se considera que los problemas y necesidades de las microempresas son también

generalizables hacia las PyMEs, cuando esto no necesariamente es el caso). El resultado de

esta confusión es una baja respuesta a las necesidades del sector de pequeñas y

medianas empresas. Lo anterior justifica la necesidad de diseñar y ejecutar programas

diferenciados, destinados específicamente para las PyMEs.

Atención efectiva a microempresas: cantidad sobre calidad Atención efectiva a microempresas: cantidad sobre calidad Atención efectiva a microempresas: cantidad sobre calidad Atención efectiva a microempresas: cantidad sobre calidad

La atención se centra sobre microempresas, ya que para muchos programas de apoyo, el

principal indicador de eficiencia es el número de empresas atendidas, que genera un

incentivo negativo por atender a microempresas en lugar de PyMEs. Por ejemplo, es

mucho más fácil ofrecer una capacitación a una empresa micro que a una pequeña, por lo

que se prefiere atender a la primera.

24 “Aceleradora de Negocios”, http://www.economia.gob.mx/?P=7060, [03Agosto2008] 25 “Centro Panamericano de Investigación e Innovación, http://www.cepii.biz/, [13Agosto2008] 26 “Instituto Panamericano de Alta Dirección de Empresa”, http://www.ipade.mx/html/home.html, [20Agosto2008]

40

Por lo anterior, los indicadores óptimos para los programas no deben ser únicamente de

gestión, sino también contemplar los siguientes aspectos (entre otros): eficiencia,

impacto, cobertura y transparencia. Asimismo, este nuevo conjunto de indicadores debe

estar estrechamente relacionada con una metodología que permita la comparación directa

entre éstos, para rediseñar actividades y reasignar presupuesto entre los programas,

favoreciendo siempre a los mejores esfuerzos de atención. 1.4 Identificación de las necesidades y problemáticas de las

PyMEs

Una de las principales causas por las que una PyME fracasa en sus primeros años es por

no contar con información actual confiable y en segundos, que les permita tomar

decisiones correctas y a tiempo, les resulta imposible concentrarse en hacer dinero.

Además, no manejan de forma eficiente su Flujo de Efectivo y así, nunca alcanzan la

Libertad Financiera. Es importante cambiar la cultura laboral, es decir, el entender que los

empleados y los clientes representan recursos valiosos y por tanto, contar con

conocimientos y herramientas que permitan aprovecharles y mantenerlos, es básico para

competir hoy en día.

Hoy es más fácil acceder a esos conocimientos y herramientas, que antes solo estaban

disponibles a corporaciones. Conocimientos de recursos humanos, tributación eficiente,

gestión de clientes y herramientas como tecnologías de internet, programas de gestión y

administración contable; son un ejemplo de las armas que tienen las PyME para crecer.

Hay que entender que para competir con corporaciones, la clave ya no es siendo una, más

bien comportándose como una. La ventaja de los grandes es que son grandes, la de los

pequeños, es que se mueven más rápido, de forma casi invisible y pueden aprovechar las

armas de los grandes a su favor.

Si bien hoy en día hay muchas más posibilidades de negocios que hace diez años,

también es alto el riesgo de equivocarse; al desconocer esto, la mayoría de las PyMEs,

dedican valiosos años en contestar tenazmente y correctamente las preguntas

equivocadas. Un ejemplo típico, es cuando las PyMEs se endeudan, basadas en una

proyección de ventas y apuestan casi todos sus recursos en un posible negocio futuro.

Aparentemente esto no es malo, pero la PyME considera que sus ingresos se duplicarán o

más y se endeuda con base en ese factor. La corporación en cambio sabe que la vida de

una empresa no es un carrera de 100 m, es un maratón, por ello en cada decisión

analizan "el peor escenario posible", manejan índices de crecimiento prudentes (entre 1% y

10%), y así se endeudan sabiamente y disminuyen su riesgo.

41

Las empresas jóvenes son las más vulnerables a los vaivenes de la economía, por lo que

los esfuerzos gubernamentales deberían ser dirigidos hacia este segmento, reforzando

sus habilidades administrativas y de producción.

Ventajas y desventajas de las PyMEsVentajas y desventajas de las PyMEsVentajas y desventajas de las PyMEsVentajas y desventajas de las PyMEs

En este apartado, se muestran las ventajas y desventajas que normalmente presentan las

PyMEs, ya que es de vital importancia conocer las fuerzas y debilidades que muestran este

tipo de empresas, que según su tamaño determinan algunas de sus ventajas o

desventajas para su desarrollo como empresa.

Para esto analicemos el siguiente cuadro que nos muestra de una manera global y

simplificada las ventajas y desventajas de las PyMEs:

VENTAJASVENTAJASVENTAJASVENTAJAS DESVENTAJAS DESVENTAJAS DESVENTAJAS DESVENTAJAS

Capacidad de generación de empleos

(absorben una parte importante de la

PEA27).

Asimilación y adaptación de

tecnología.

Producción local y de consumo básico.

Contribuyen al desarrollo regional

(por su establecimiento en diversas

regiones).

Flexibilidad al tamaño de mercado

(aumento o disminución de su oferta

cuando se hace necesario).

Fácil conocimiento de empleados y

trabajadores, facilitando resolver los

problemas que se presentan (por la baja

ocupación de personal).

La planeación y organización no

requiere de mucho capital.

Les afecta con mayor facilidad los

problemas que se suscitan en el entorno

económico como la inflación y la

devaluación.

Viven al día y no pueden soportar

períodos largos de crisis en los cuales

disminuyen las ventas.

Son más vulnerables a la fiscalización

y control gubernamental, siempre se

encuentran temerosos de las visitas de

los inspectores.

La falta de recursos financieros los

limita, ya que no tienen fácil acceso a

las fuentes de financiamiento.

Tienen pocas o nulas posibilidades de

fusionarse o absorber a otras empresas;

es muy difícil que pasen al rango de

medianas empresas.

Mantienen una gran tensión política

ya que los grandes empresarios tratan

27 Población Económicamente Activa

42

Mantiene una unidad de mando

permitiendo una adecuada vinculación

entre las funciones administrativas y

operativas.

Producen y venden artículos a precios

competitivos (ya que sus gastos no son

muy grandes y sus ganancias no son

excesivas).

por todos los medios de eliminar a

estas empresas, por lo que la libre

competencia se limita o de plano

desaparece.

Su administración no es especializada,

es empírica y por lo general la llevan a

cabo los propios dueños.

Por la propia inexperiencia

administrativa del dueño, éste dedica un

número mayor de horas al trabajo,

aunque su rendimiento no es muy alto.

Tabla 13 Tabla 13 Tabla 13 Tabla 13 ---- Ventajas y desventajas que presentan las pequeñas empresas. Fuente: Ventajas y desventajas que presentan las pequeñas empresas. Fuente: Ventajas y desventajas que presentan las pequeñas empresas. Fuente: Ventajas y desventajas que presentan las pequeñas empresas. Fuente:

Rodríguez (1996)Rodríguez (1996)Rodríguez (1996)Rodríguez (1996)

VENTAJAS VENTAJAS VENTAJAS VENTAJAS DESVENTAJAS DESVENTAJAS DESVENTAJAS DESVENTAJAS

Cuentan con buena organización,

permitiéndoles ampliarse y adaptarse a

las condiciones del mercado.

Tienen una gran movilidad,

permitiéndoles ampliar o disminuir el

tamaño de la planta, así como cambiar

los procesos técnicos necesarios.

Por su dinamismo tienen posibilidad

de crecimiento y de llegar a convertirse

en una empresa grande.

Absorben una porción importante de

la PEA, debido a su gran capacidad de

generar empleos.

Asimilan y adaptan nuevas

tecnologías con relativa facilidad.

Se establecen en diversas regiones del

Mantienen altos costos de operación.

No se reinvierten las utilidades para

mejorar el equipo y las técnicas de

producción.

Sus ganancias no son elevadas; por lo

cual, muchas veces se mantienen en el

margen de operación y con muchas

posibilidades de abandonar el mercado.

No se contrata personal especializado

y capacitado debido a que no se pueden

pagar altos salarios.

La calidad de la producción no

siempre es la mejor, muchas veces es

deficiente porque los controles de

calidad son mínimos o no existen.

No pueden absorber los gastos de

43

país y contribuyen al desarrollo local y

regional por sus efectos

multiplicadores.

Cuentan con una buena

administración, aunque en muchos

casos influenciada por la opinión

personal de o los dueños del negocio.

capacitación y actualización del

personal, pero cuando lo hacen,

enfrentan el problema de la fuga de

personal capacitado.

Sus posibilidades de fusión y

absorción de empresas son reducidas o

nulas.

Algunos otros problemas como:

ventas insuficientes, debilidad

competitiva, mal servicio, mala atención

al público, precios altos o calidad mala,

activos fijos excesivos, mala ubicación,

descontrol de inventarios, problemas de

impuestos, y falta de financiamiento

adecuado y oportuno.

Tabla 14 Tabla 14 Tabla 14 Tabla 14 ---- Ventajas y desventajas que presentan las medianas empresas. Fuente: Ventajas y desventajas que presentan las medianas empresas. Fuente: Ventajas y desventajas que presentan las medianas empresas. Fuente: Ventajas y desventajas que presentan las medianas empresas. Fuente:

Rodríguez (1996)Rodríguez (1996)Rodríguez (1996)Rodríguez (1996)

De lo siguiente podemos observar que, las ventajas de las pequeñas empresas se

caracterizan por su facilidad administrativa, pero, sus desventajas, se debe a razones de

tipo económico, como son la inflación y devaluaciones; viven al día de sus ingresos, le

temen al fisco, falta de recursos financieros, por lo tanto se les dificulta crecer, y estas

mismas razones ponen en peligro su existencia.

Todo esto resultado de una administración empírica por parte del dueño, que afecta el

rendimiento general de la empresa.

Para el caso de las medianas empresas, podemos darnos cuenta que padecen los mismos

problemas que las pequeñas empresas, pero, a niveles más complicados, por ejemplo, en

el caso de sus ventajas, estas son de mejor calidad administrativa, pero, sus desventajas,

también son de tipo económicas, como; altos costos de operación, falta de reinvención en

el equipo y maquinaria, no obtiene ganancias extraordinarias, por sus altos costos, no

pueden pagar altos salarios, por lo tanto, no cuentan con personal especializado, no

cuentan con controles de calidad óptimos, etc.

Todo esto derivado de su problema de altos costos, debido a su tamaño.

44

Todo lo antes mencionado, también se aplica a las PyMEs que se dedican a exportar, ya

que, el hecho de que estas empresas exporten, no cambia su entorno general, sólo

cambia su entorno en los procesos productivos, ya que se exigen ciertas normas para la

exportación de mercancías, como lo es la calidad, pero, en cuestión de características

generales, ventajas y desventajas, son aplicables a todo tipo de empresa 28.

Identificación de las necesidades y problemática específica de PyMEs Identificación de las necesidades y problemática específica de PyMEs Identificación de las necesidades y problemática específica de PyMEs Identificación de las necesidades y problemática específica de PyMEs

Gracias al estudio hecho por el Observatorio29, nos ha permitido identificar las principales

necesidades y problemática de las PyMEs, en sus aspectos más importantes. Entre éstas,

destacan las siguientes:

• Un gran porcentaje de las PyMEs en México tiene una estructura de empresa

familiar, por lo que sus necesidades en cuestiones de dirección y administración

de la empresa son diferentes a las de un negocio “tradicional”;

• Cerca del 90 por ciento de las empresas de este estrato no cuenta con algún tipo

de certificación de calidad (ISO)30, lo cual conlleva efectos negativos sobre su

integración a cadenas productivas y su posibilidad de exportar. Lo mismo aplica

para metodologías de mejora de calidad y productividad, como el “just in time”31 y

los equipos de control numérico;

• Tres de cada cuatro PyMEs cuentan con acceso a internet. Asimismo, un promedio

de 40 por ciento de éstas cuenta o planeaba contar con un sitio web para el año

2002, y un porcentaje similar ya opera ventas de sus productos en línea;

• La estructura de ventas de las empresas está altamente concentrada. Primero,

cerca del 50 por ciento de las ventas está concentrada en los cuatro clientes más

importantes, y segundo, casi el 65 por ciento de la demanda se comercializa en un

radio menor a 100 kilómetros de la empresa. Lo anterior pone a las PyMEs en una

posición endeble, al considerar que un gran porcentaje de sus ventas depende en

un reducido número de empresas (y ámbito regional);

• La estructura de proveeduría posee la misma problemática, aunque un tanto más

concentrada: el 75 por ciento de las ventas está concentrada en los cuatro clientes

más importantes (la distribución espacial de la proveeduría es variable entre

sectores);

28 “La importancia de las PYMES en México y para el mundo”, http://www.gestiopolis.com/canales2/economia/pymmex.htm [06Julio2008] 29 “Observatorio PyME”, http://www.cipi.gob.mx/html/observatorio.html, [15Julio2008] 30 “International Organization for Standardization”, http://www.iso.org/iso/home.htm, [15Julio2008] 31 El método Justo a Tiempo es un sistema de organización de producción para las fábricas, de origen japonés.

45

• La tasa de aprobación de créditos por parte de la banca comercial es relativamente

alta en las PyMEs, cercana al 75 por ciento en promedio. Aquellos empresarios que

no recibieron el crédito, aducen que una de las razones principales es la falta de

garantías.

• Apenas el 9 por ciento de las PyMEs está involucrado en la actividad exportadora

(la distribución entre sectores es variable, ya que para el sector manufacturero, el

21 por ciento de las empresas si exporta). Sin embargo, al cuestionar los motivos

(ajenos a la empresa) por los que no se exporta, los empresarios señalan la

lentitud y el exceso de trámites aduaneros, así como la lentitud en el reembolso de

impuestos.

En resumen, el reto que tienen las PyME es: "Gastar menos de lo que ganan", ó

"Endeudarse menos de lo creen que van a ganar".

1.5 Entorno de las PYME’s desarrolladoras de software

Comenzaremos hablando un poco sobre algunos conceptos de calidad, a lo largo del

tiempo el concepto de calidad ha adquirido un carácter multidimensional, debido a que

los diferentes autores (conocidos como los gurús del tema) lo han enfocado desde puntos

de vistas diferentes: Deming32, como el grado predecible de uniformidad y conformidad a

un bajo costo que se ajuste a las necesidades del mercado; Crosby33, como cumplir con

los requisitos; Feigenbaum34, como el conjunto total de las características del producto de

marketing, ingeniería, fabricación y mantenimiento a través del cual el producto en uso

satisfará las expectativas del cliente y Jurán35, como la idoneidad o aptitud para el uso.

En todas estas definiciones se valoran elementos comunes como la satisfacción de

necesidades o perspectivas del cliente y la existencia de rasgos o requisitos para

satisfacerlas.

32 William Edwards Deming, estadístico estadounidense profesor universitario, autor de textos, consultor y difusor del concepto de calidad total. 33 Philip B. Crosby, pensador que desarrolló el tema de la calidad en años muy recientes. 34 Armad V. Feigenbaum, creador del concepto control total de calidad. 35 Joseph M. Jurán, una de las figuras más importantes en el Control de la Calidad y la Administración moderna.

46

Para alcanzarla se han desarrollado diversos estudios, comenzando con la verificación y

terminando en el concepto de calidad total, pasando por el control y el aseguramiento de

la calidad. Actualmente la tendencia internacional está fundamentada en la aplicación y

certificación sobre la base de las normas ISO 9001:200836 que suponen un lenguaje

común, adoptado ya por un elevado número de países.

De ahí, que se pueda considerar como el concepto más actual de calidad el definido por la

ISO 9001:2008 , que la define como “grado en el que un conjunto de características

inherentes cumplen con los requisitos.”

Además de las normas ISO 9001:2008, para lograr una efectiva gestión de la calidad en

determinados sectores es necesario compatibilizarlas con otras normas específicas

adecuadas al tipo de actividad que desarrollan. Tal es el caso de las empresas de la

industria del software donde se usan metodologías tan extendidas como el CMM37 y la ISO

SPICE38, entre otros modelos.

Finalmente, la naturaleza intangible de este negocio y el hecho de que el software

constituye un producto del conocimiento de difícil estandarización, hace necesaria la

aplicación de otros modelos que prevén la inclusión de la gestión del conocimiento y su

integración a los modelos de calidad, como es el caso del EFQM39 de Excelencia, base del

Premio Europeo de Calidad.

Ante esta abundancia de modelos teóricos y de normas de certificación las pequeñas

empresas de software o las principiantes se ven ante el dilema de cuál es el mejor camino

a escoger, el más rápido y menos costoso que le permita asegurar la calidad de su

productos.

En este capitulo se pretende esclarecer los conceptos de calidad y trazar un camino para

este tipo de empresas en aras de alcanzar la difícil meta de la calidad. 36 “Son normas de calidad y gestión continua de calidad establecidas por ISO que pueden aplicar en cualquier tipo de organización o actividad sistemática, que esta orientada a la producción de bienes o servicios.” http://es.wikipedia.org/wiki/Caracter%C3%ADsticas_de_la_serie_de_normas_ISO_9000, [12Septiembre2008] 37 “Modelo de Capacidad y Madurez (Capability Maturity Model), es un modelo de evaluación de los procesos de una organización”, http://es.wikipedia.org/wiki/Modelo_de_Capacidad_y_Madurez, [12 Septiembre2008] 38 “Programa de trabajo para el desarrollo de un estándar internacional para la evaluación de los procesos de software”, http://www.usm.edu.ec/abedini/spice/spicess.htm, [04Octubre2008] 39 “Fundación Europea para la Gestión de la Calidad, La Fundación asume su papel como clave en el incremento de la eficacia y la eficiencia de las organizaciones europeas, reforzando la Calidad en todos los aspectos de sus actividades, así como estimulando y asistiendo el desarrollo de la mejora de la Calidad”, http://es.wikipedia.org/wiki/Fundaci%C3%B3n_Europea_para_la_Gesti%C3%B3n_de_la_Calidad, [04Octubre2008]

47

Gestión de calidad del software. Gestión de calidad del software. Gestión de calidad del software. Gestión de calidad del software.

La calidad del software es definida como la concordancia con los requisitos funcionales y

de rendimiento explícitamente establecidos, con los estándares de desarrollo

explícitamente documentados y con las características implícitas que se esperan de todo

software desarrollado profesionalmente40.

A partir de esta definición vale la pena señalar que no sólo afecta la calidad el

incumplimiento de los requisitos del cliente y los explícitamente definidos por la

ingeniería de software, sino que los requisitos implícitos también deben ser considerados.

Téngase en cuenta que pocas veces el cliente está en condiciones reales de explicitar todo

lo que se puede esperar del producto, muchas veces por desconocimiento y otras por la

asunción tácita de muchas funcionalidades.

La gestión de la calidad se puede entender como el conjunto de actividades y medios

necesarios para definir e implementar un sistema de la calidad, por una parte y

responsabilizarse de su control, aseguramiento y mejora continua, por otra41. El control

está dirigido al cumplimiento de requisitos, el aseguramiento a inspirar confianza en que

se cumplirá el requisito pertinente y el mejoramiento al aumento de su eficiencia y

eficacia.

La gestión de calidad a nivel de la organización en entidades de software ha seguido dos

líneas que pueden perfectamente complementarse entre sí. Por una parte, se ha seguido

la línea marcada por las entidades internacionales de estandarización para todos los

productos y servicios a través de las normas ISO 9001:2008 y por otra, el mundo del

software ha creado su propia línea de trabajo en la gestión de la calidad, trabajando sobre

los procesos de producción de software como medio de asegurar la calidad del producto

final.

Cuando los estándares de calidad se orientaban sobre todo al control, en las

organizaciones dedicadas al software aparecen un grupo de modelos específicos con ese

fin: Modelo de Boehm42, Modelo FCM43, Marco ISO 912644, Paradigma GQM45, Modelo de

Gilb46.

40 Pressman, R. S., 1993 , “Ingeniería del software. Un enfoque practico”, Editorial McGraw-Hill. 41 Fernández & Alarcón, “Necesidades de medición en la gestión y el aseguramiento de calidad del Software”, http://www.sc.ehu.es/jiwdocoj/remis/docs/aseguracal.htm, [19Octubre2008] 42 “Modelo de Boehm (espiral)”, http://es.wikipedia.org/wiki/Desarrollo_en_espiral, [22Octubre2008] 43 McCall et al., 1977, “Factor/Criteria/Metrics FCM” 44 ISO/IEC, 1991, “Marco ISO 9126” 45 Basili & Rombach, 1988, “Goal-Question-Metric” 46 Gilb, 1988, “Modelo de Gilb”

48

En los últimos años en que los estándares de calidad internacionales se han reorientado

hacia el aseguramiento de la calidad, han aparecido en la industria del software dos

importantes modelos de referencia que tienen en común la evaluación de la capacidad de

los procesos en niveles de desarrollo o madurez: Modelo CMM47, Modelo SPICE48

Estadísticas del Software Engineering Institute (SEI)49 reportan que del total de empresas

que aplican CMM el 81 % se encuentra en el nivel 1, el 12 % en el nivel 2 y el 7 % en el

nivel 3. Ninguna ha alcanzado los niveles 4 y 550. Esto da cuenta de la rigurosidad del

modelo y de las pocas posibilidades que tendría las PYMES de ubicarse en los niveles

superiores.

Las grandes empresas ya consolidadas pueden disponer a su voluntad, y de hecho lo

hacen, la implantación de otras metodologías o esquemas propios para lograr la calidad y

la mejora continua de sus procesos productivos, sin embargo, para las pequeñas y

medianas empresas de software la implantación de sistemas de la calidad basados en la

norma ISO 9001:2008 puede constituir el mejor camino a seguir pues estas normas

definen los requisitos básicos de la organización y por otro lado la certificación le confiere

un prestigio importante ante sus clientes.

La solución ideal para los que comienzan es integrar ambos enfoques en la medida de lo

posible bajo el principio de especificar en ISO 9001:2008 todas aquellas características

propias del producto de software que se contemplan en las otras metodologías.

Las norma ISO. Las norma ISO. Las norma ISO. Las norma ISO.

En 1947 se creó la International Organization for Standartization51, que es una federación

mundial de organismos nacionales de normalización, cuya sede actual está en Ginebra.

En 1987 se publicaron por primera vez la familia de normas ISO 9000 para el

aseguramiento de la calidad, compuesta por la norma ISO 840252: Vocabulario, la norma

ISO 900053: Directrices para la selección de los modelos para el aseguramiento de la

calidad y los tres modelos ISO 9001, 9002 y 900354 que planteaban los requisitos para los

47 “Modelo de Capacidad y Madurez (Capability Maturity Model), es un modelo de evaluación de los procesos de una organización”, http://es.wikipedia.org/wiki/Modelo_de_Capacidad_y_Madurez, [12 Septiembre2008] 48 “Programa de trabajo para el desarrollo de un estándar internacional para la evaluación de los procesos de software”, http://www.usm.edu.ec/abedini/spice/spicess.htm, [04Octubre2008] 49 “Software Engineering Institute”, http://www.sei.cmu.edu/, [22Octubre2008] 50 Tinnirello, Paul C., 11 Mayo 1998, “How's Your IT: Teetering Or Leading-Edge PC Week” v15 n19 p77. 51 “International Organization for Standardization”, http://www.iso.org/iso/home.htm, [15Julio2008] 52 “Normas ISO 9000”, http://www.pilar.com.ar/industrias/temasgenerales/normas.htm, [14Noviembre2008] 53 “Normas ISO 9000”, http://www.pilar.com.ar/industrias/temasgenerales/normas.htm, [14Noviembre2008] 54 “Normas ISO 9000”, http://www.pilar.com.ar/industrias/temasgenerales/normas.htm, [14Noviembre2008]

49

sistemas de calidad aplicables a empresas cuya actividad se enmarcaba en determinadas

etapas del ciclo de vida del producto. Además apareció el modelo ISO 900455 dirigido al

aseguramiento de la calidad en el orden interno.

En el año 1994 se realizó una revisión de estas normas y se introdujeron algunos cambios

que no variaron de manera sustancial la estructura original de la familia del año 1987 , y

en el año 2000 apareció la última versión (vigente en la actualidad) en la cual se introdujo

el enfoque de procesos y los tres modelos (ISO 9001, ISO 9002 e ISO 9003) se unieron en

el modelo ISO 9001:2000 aplicable a cualquier organización. Además la norma ISO 8402

se sustituyó por la ISO 9000: Vocabulario y la ISO 9004 se convirtió en el modelo para la

mejora del desempeño. La otra integrante de la familia ISO 9000 (norma ISO 1901156 para

Auditorias de los sistemas de gestión de la calidad y medioambientales) amplió su alcance

y se compatibilizó con las ISO 14 00057.

¿Qué son las normas ISO?¿Qué son las normas ISO?¿Qué son las normas ISO?¿Qué son las normas ISO?

Existen diversas fuentes para definir estas normas, pero podemos definirlas como un

conjunto de normas internacionales genéricas que establecen sistemas de gestión de la

calidad los cuales son aplicados por organizaciones de cualquier tipo o tamaño que

fabrican productos o componentes (hardware) ,fabrican software, fabrican materiales

procesados, ofrecen servicios, o desempeñan funciones de administración pública.

¿Qué NO son las normas ISO?¿Qué NO son las normas ISO?¿Qué NO son las normas ISO?¿Qué NO son las normas ISO?

No son Especificaciones de Calidad de Productos.

No son obligatorias.

No es un programa de corta duración.

No es el punto final de la mejora continua

El modelo de un sistema de gestión de la calidad basado en procesos ha servido a las

organizaciones para enfocar sus esfuerzos en aquellos procesos que aportan valor al

cliente y garantizan la satisfacción de sus necesidades declaradas e implícitas.

El proceso de responsabilidad de la Dirección se identifica con los procesos estratégicos

que aportan directivas al resto de los procesos, tales como la definición de políticas,

objetivos, responsabilidad y autoridad, comunicación, así como el compromiso de la

dirección y la revisión del sistema por parte de ésta.

55 “Normas ISO 9000”, http://www.pilar.com.ar/industrias/temasgenerales/normas.htm, [14Noviembre2008] 56 “ISO 9001 Auditing Practices Group Directriz”, http://www.inlac.org/documentos/Uso%20eficaz%20de%20la%20norma%20%20ISO%2019011%20rev.1.pdf, [14Noviembre2008] 57 “ISO 14000 Wikipedia”, http://es.wikipedia.org/wiki/ISO_14000, [14Noviembre2008]

50

La gestión de recursos se refiere a la infraestructura y los recursos humanos, materiales y

financieros que se identifica con los procesos de apoyo que soportan los procesos de

realización, donde se manifiesta la cadena de valor que transforma las necesidades y

expectativas de los clientes en productos que satisfagan sus expectativas.

Luego la medición, análisis y mejora permitirá determinar la eficacia, eficiencia y

efectividad del resto de los procesos, y aportará la información necesaria para la toma de

decisiones y la mejora continua del producto, los procesos y el sistema.

No hay que considerar estos procesos en orden cronológico, ni como correspondientes a

diferentes partes de la estructura de la organización, sino que son procesos simultáneos,

íntimamente relacionados y extensivos a toda la organización.

Estrategia para la aplicación de la ISO 9001:2008 aplicada a PyMEs de SoftwareEstrategia para la aplicación de la ISO 9001:2008 aplicada a PyMEs de SoftwareEstrategia para la aplicación de la ISO 9001:2008 aplicada a PyMEs de SoftwareEstrategia para la aplicación de la ISO 9001:2008 aplicada a PyMEs de Software58585858. . . .

Es común que las empresas que acometen la implantación de sistemas de calidad ISO

9000 se enfrenten a las siguientes situaciones:

• Se contratan consultores externos que aunque conozcan la calidad a nivel

gerencial desconocen las especificidades de los procesos de software. Esto

dificulta la adaptación eficaz de la norma a la organización y afecta la eficiencia del

proceso de implantación.

• El exceso de documentación provoca un rechazo general a la aplicación de la

norma.

• Se pretende comenzar la implantación de arriba hacia abajo, de modo que

transcurre mucho tiempo en llegar al proceso concreto de realización del

producto. Esto hace que no se vean resultados a corto plazo.

• Se da más importancia a las cuestiones organizativas de la administración que a

las del propio proyecto.

• No se consideran las especificidades del proceso productivo como proceso de

conocimiento: difícil estandarización, intervención del cliente prácticamente

durante todo el proceso, mayor importancia del servicio posventa.

58 “Estrategias de calidad para PYMES de desarrollo de Software”, http://www.monografias.com/trabajos16/calidad-sw-pymes/calidad-sw-pymes.shtml, [23 Agosto2008]

51

Para acometer la gestión de la calidad con resultados intermedios que permitan a la

empresa ir obteniendo madurez en la medida en que avanza la implantación de las

normas, se plantean 5 niveles, ya no específicos al proceso de desarrollo del producto

como da cuenta el CMM59, sino referentes a la gestión de la calidad a nivel de toda la

organización:

Nivel inicial

Nivel de proyecto.

Nivel de gestión total de calidad

Nivel de certificación

Nivel de referencia

Nivel inicialNivel inicialNivel inicialNivel inicial

Toda empresa de software aplica al menos un mínimo control de la calidad de sus

productos y establece algunos parámetros mínimos como requisitos del producto.

Las empresas que trabajan a este nivel se caracterizan por:

• Definición de políticas elementales de contratación.

• Obtención de las especificaciones de los clientes.

• Formación empírica de equipos de trabajo de acuerdo a la disponibilidad de

personal que se tenga.

• Compromisos de plazos de entrega sin criterios bien fundamentados.

• Uso de herramientas de ingeniería de software a voluntad de los desarrolladores.

• Empleo de los lenguajes de programación en que se tiene experiencia, al no ser

que el cliente exija lo contrario.

• Mínima documentación.

• Acta de aceptación del cliente quien generalmente no está en condiciones de

evaluar adecuadamente el producto.

• Deficiente organización del mantenimiento posventa del producto.

59 “Modelo de Capacidad y Madurez (Capability Maturity Model), es un modelo de evaluación de los procesos de una organización”, http://es.wikipedia.org/wiki/Modelo_de_Capacidad_y_Madurez, [12 Septiembre2008]

52

Nivel de proyecto Nivel de proyecto Nivel de proyecto Nivel de proyecto

En este nivel se incluyen: evaluaciones, revisiones y auditorias, normas, procedimientos de

control y seguimiento de errores, así como el registro de la información como vía de

retroalimentación para la calidad del proyecto. Algunas acciones importantes que no

pueden dejar de realizarse son:

• Asegurar que los procesos de Ingeniería de Software sean usados durante todo el

ciclo de vida del proyecto.

• Evaluar mediante métricas, los requerimientos de calidad de los productos

• Chequear mediante métricas las condiciones anormales en los procesos y

eliminarlas antes de terminar el producto.

• Analizar las pérdidas de calidad para definir acciones para el mejoramiento

continuo del proceso de desarrollo de software.

El Modelo de Pressman60 muestra fehacientemente como asegurar a nivel de proyecto la

calidad de proceso de desarrollo de software:

Es necesario partir de un pequeño número de actividades del marco de trabajo que son

aplicables a todos los proyectos de software, con independencia de su tamaño y

complejidad. Un conjunto de tareas que permiten que las actividades del marco de trabajo

se adapten a las características del proceso de software y a los requisitos del equipo de

proyecto. Finalmente las actividades de protección tales como la gestión de la calidad del

software, gestión de configuración del software y la medición. Estas actividades serán

independientes de cualquier actividad del marco de trabajo y deben aparecer durante todo

el proceso.

A este nivel pudiera organizarse la actividad de la forma siguiente:

1. Establecer políticas y procedimientos generales para: negociación del proyecto,

decisión de plazos de entrega, formación del equipo de proyecto, decisión de

plataformas de trabajo y lenguajes de programación, documentación mínima

necesaria, herramientas comunes e imagen corporativa implícita en el software a

desarrollar.

2. Planificar y organizar las tareas a ejecutar, definiendo las métricas del proyecto, los

hitos, las pruebas a realizar en cada uno.

3. Ejecución del proyecto.

60 Pressman, Roger S., 1998, “Ingeniería de software. Un enfoque práctico”, Editorial McGraw-Hill Interamericana de España.

53

4. Control de calidad en cada uno de los hitos definidos y al final. (el control incluye la

verificación y corrección).

Políticas y procedimientos generales.

Se definirán políticas en aquellos aspectos donde se requiera un alto nivel de flexibilidad

como la negociación del proyecto y la decisión de plataformas de trabajo y lenguajes de

programación.

Pudiera definirse por ejemplo política de precios, requisitos de los contratos y todo lo que

se relacione con el contacto directo con el cliente, de modo que no se establezcan

camisas de fuerza que atenten finalmente contra su satisfacción con el servicio que se le

ofrece.

Se definirán procedimientos en aquellos aspectos donde sea posible regular cada uno de

los pasos a dar y las alternativas posibles a evaluar.

Para la definición de plazos de entrega pudiera trabajarse con rutas críticas o con las

herramientas del Microsoft Project61, por ejemplo. Para la formación del equipo de

proyecto sería necesario establecer un procedimiento que permita establecer las

competencias que requiere el proyecto de sus especialistas, la evaluación de esas

competencias en el personal del que se pueda disponer y las métricas de medición de la

inteligencia emocional del equipo. Los documentos mínimos pueden establecerse sobre la

base de depurar las metodologías de análisis de sistema conocidas y definir lo que la

organización considera necesario y con qué estructura. La imagen corporativa implícita en

el software debe establecerse como criterio inicial que facilite los diseños de las diferentes

interfaces. Las herramientas serán definidas con el objetivo de lograr una estandarización

a nivel de la organización.

Para desarrollar este marco de trabajo pueden crearse grupos de especialistas donde la

experiencia cuente en primer lugar y obtenerse las políticas y procedimientos a partir de

sesiones de trabajo. El Consejo Técnico Asesor de la Gerencia puede ser una vía propicia.

Planificación y organización de las tareas.

Se definirán cada una de las tareas del proyecto, se asignarán responsables, participantes,

plazos y formas de control. Las formas de control se determinan a partir de definir las

métricas en cada etapa.

Es importante que los controles se realicen en los hitos previamente definidos de manera

que no se entorpezca el desarrollo del proyecto. 61 “Microsoft Project es un programa de la suite de Microsoft Office usado para la gestión de proyectos”, http://es.wikipedia.org/wiki/Microsoft_Project, [25Noviembre2008]

54

Los períodos de control y corrección deben preverse en el cronograma de desarrollo del

proyecto.

Ejecución del proyecto.

Además de cumplir con las políticas y procedimientos trazados así como con la

planificación realizada, es importante tener en cuenta dos aspectos: la ingeniería del

software y la documentación.

La ingeniería del software establece los requerimientos tecnológicos del diseño. Debe

lograrse en la organización que todos sus especialistas dominen las técnicas y

herramientas necesarias.

Teniendo en cuenta las diferencias profesionales y de experiencia de los especialistas, es

importante realizar acciones de gestión del conocimiento y seguir, al menos, los

principios básicos que garanticen la continua conversión del conocimiento tácito en

explícito y viceversa.

Par ese fin se recomiendan algunas acciones de fácil implementación:

• Integrar los equipos con personal de diferente nivel de experiencia de modo que

se trasmitan los conocimientos por la mejor vía posible que es la práctica.

• Formar equipos multidisciplinarios en relación con el proyecto, de manera que se

compartan conocimientos de acuerdo al know how no informático que se requiere.

• Estimular por diferentes vías el intercambio de conocimientos, el desarrollo de

clases y objetos para uso común y conformar una biblioteca compartida.

• Discusiones en equipo de las soluciones informáticas complejas y su desarrollo

por escrito, de modo que no se requiera reinventar la rueda.

• Formación inicial de los especialistas de reciente incorporación con políticas,

procedimientos, soluciones técnicas documentadas.

• Formación del cliente y empatía de modo que se incorpore como un miembro del

equipo, en posición constructiva y proactiva.

Un aspecto vital tanto para la calidad del proyecto como para ir sentando una cultura con

vistas a la futura implantación de sistemas de calidad a nivel organizacional, es la

documentación de cada una de las etapas en paralelo al desarrollo, de forma que se eviten

omisiones o que la documentación sea una carga a realizar una vez terminado el software.

55

Es necesario insistir en que a este nivel debe establecerse la documentación mínima

necesaria que garantice la trazabilidad del proceso de desarrollo y que deje constancia,

sobre todo, de todos los contactos con el cliente. Debe tenerse presente que en esta

industria, a diferencia de la mayoría, la interacción con el cliente se da a todo lo largo del

proceso.

Control de calidad.

El control de calidad en cada uno de los hitos debe realizarse por personal especialmente

dedicado a esta función. Debe escogerse los técnicos de mayor experiencia.

El control de calidad al final se recomienda lo realicen círculos de calidad creados ad hoc

para cada proyecto.

La separación de las actividades de análisis, programación e implantación es de gran

ayuda al permitir lograr de forma natural una contrapartida permanente que sirva de

retroalimentación durante todo el proceso de desarrollo. Sin mencionar otros beneficios

como el incremento de los niveles de productividad.

Nivel de gestión total de calidad.Nivel de gestión total de calidad.Nivel de gestión total de calidad.Nivel de gestión total de calidad.

Una vez superada la etapa de lograr la calidad en los proyectos, la empresa estará en

condiciones de revisar las normas ISO 900162 de manera detallada y comenzar a adecuar

sus actividades y procesos a los requisitos mínimos que ellas establecen.

Aquí es importante tener en cuenta:

• Como la norma admite que la documentación puede estar en cualquier formato o

tipo de medio, revisar los diseños de la intranet y de los sistemas de información

digital que minimicen la burocracia del exceso de documentación con el que

generalmente se acompaña la implantación de estas normas.

• Dentro de la gestión de recursos, prestar la máxima atención a la gestión del

capital humano (gestión del conocimiento a nivel de toda la organización y control

de indicadores de capital intelectual).

• Revisar el proceso de materialización del producto que se definió a nivel de

proyecto a la luz de la norma.

• Conceder especial importancia dentro de la revisión de requisitos relacionados con

el producto a los no explícitos por parte del cliente y a los de ingeniería de

software.

62 “Son normas de calidad y gestión continua de calidad establecidas por ISO que pueden aplicar en cualquier tipo de organización o actividad sistemática, que esta orientada a la producción de bienes o servicios.” http://es.wikipedia.org/wiki/Caracter%C3%ADsticas_de_la_serie_de_normas_ISO_9000, [12Septiembre2008]

56

• El control de cambios de diseño y desarrollo mediante los registros adecuados

garantizará la calidad del proceso de mantenimiento del software.

• La identificación y trazabilidad que establece la norma se garantizará con una

adecuada gestión de la configuración.

La propiedad del cliente requiere un respeto riguroso: habrá que precisar la

confidencialidad de la información que se maneja y hasta donde llega la participación del

cliente en el know how63 no informático del producto.

En la preservación de producto orientarse específicamente al control de versiones.

La medición, análisis y mejora se da en dos etapas: durante el desarrollo del software

utilizando las métricas que proporcionan los múltiples modelos existentes y el

seguimiento y medición posterior.

Se requiere implementar adecuados sistemas de satisfacción del cliente que permita

retroalimentarse con el desempeño posterior del producto. Debe tenerse en cuenta que

estos productos demuestran su eficacia sobre todo en momentos posteriores a su

implementación cuando se requieren cambios de su configuración o cuando el volumen

de datos procesados se hace significativamente grande.

Es importante implementar que la liberación del producto la realice personal distinto al

encargado de su desarrollo.

Nivel de certificación.Nivel de certificación.Nivel de certificación.Nivel de certificación.

Por la gran variabilidad de los procesos de desarrollo de software, es importante buscar

una estabilidad del nivel anterior antes de pasar a este nivel.

Por otro lado, los procesos de desarrollo de software ocurren en plazos mucho mayores

que los procesos productivos y de servicios convencionales, de ahí que para demostrar

resultados con vistas a la certificación hay que esperar un tiempo mayor.

Una vez certificada la entidad tendrá que ser capaz en el tiempo de demostrar su aptitud

para mantener la certificación otorgada en las auditorias recurrentes que establecen las

normas.

63 “Know-How (saber-como) El término está relacionado a los conocimientos prácticos, técnicas o criterios que han sido utilizados en la elaboración o diseño de un proyecto y que se pueden reutilizar al momento de realizar otros proyectos similares”, http://es.wikipedia.org/wiki/Know_how, [01Diciembre2008]

57

Nivel de referencia.Nivel de referencia.Nivel de referencia.Nivel de referencia.

Existe una tendencia a considerar el proceso de desarrollo de software como un proceso

de investigación y desarrollo lo que no se considera exacto. El verdadero proceso de

investigación y desarrollo se da en el software cuando se trabaja en nuevas herramientas

de ingeniería y en nuevos métodos de trabajo que permitan obtener resultados

superiores.

Las empresas de alto desempeño se convierten en referencia para otras que comienzan a

partir de convertir sus métodos y experiencias en estándares de trabajo.

Por otro lado, el desarrollo de software propicia la producción de herramientas de

ingeniería y de codificación que hacen más efectivos y productivos los procesos.

Muchas empresas prestigiosas de software implementan sus propios modelos de calidad,

para las pequeñas y medianas empresas de software la implantación de sistemas de la

calidad basados en las normas ISO 9001 puede constituir el mejor camino a seguir pues

estas normas definen los requisitos básicos de la organización y por otro lado la

certificación le confiere un prestigio importante ante sus clientes.

La solución ideal para empresas principiantes es integrar en la ISO 9001 todas aquellas

características propias del producto de software que se contemplan en las otras

metodologías.

El nivel de proyecto constituye el núcleo de la gestión de calidad en empresas de software

ya que cada proyecto es a su vez una empresa.

La inclusión de la gestión del conocimiento dentro del sistema de calidad es un requisito

básico para las empresas de software.

58

2. LA INFORMATICA Y LA ADMINISTRACION DE PROYECTOS En este capitulo se analizan diversas metodologías para el desarrollo de Software, como

por ejemplo RUP y UML, métodos internacionales para el desarrollo de Software con

calidad, pero antes se analizan temas como la Administración Informática, la Ingeniería

de Software y la Administración de Proyectos, esto con el fin de tener las bases teóricas

para el desarrollo de software y el proceso que se lleva a cabo en la administración de

proyectos y los puntos a considerar dentro del mismo.

2.1 Administración Informática.

La Administración Informática utiliza los procedimientos más eficientes y productivos

apoyándose en las nuevas tecnologías, se analizan los procesos correctos con los que se

debe administrar la información a través de los medios computacionales, con la finalidad

de tomar decisiones oportunas en un mundo informático dinámico.

Actualmente el rol del profesionista informático esta totalmente ligado a la Administración

Informática, mostrando su labor interdisciplinaria día a día, entre las tareas que realiza

están la administración de recursos de la empresa, la planeación de los objetivos de TI

basados en el negocio utilizando las herramientas de tecnología de información, alinear el

área informática a la organización, lo relacionado con recursos humanos, presupuestos,

adquisición de recursos computacionales, trato con usuarios finales entre otras.

2.2 Ingeniería de Software

La Ingeniería del Software se considera trascendental para el éxito de los proyectos, así

como para satisfacer las expectativas del cliente relativas al resultado y a las fechas de

entrega.

La Ingeniería de Software es una práctica que requiere aprendizaje específico y práctica.

Son ingenieros de software las personas que cuentan con la formación y práctica

adecuadas, y se mantienen al día en la evolución de la tecnología, los métodos y las

aplicaciones.

Hemos tomado de algunas definiciones lo que es la Ingeniería de Software, esta designa el

conjunto de técnicas destinadas a la producción de un programa de computadora, es

59

decir, esta actividad va mas allá de la simple actividad de programación, también esta

apoyada por la administración de proyectos, de la misma manera, la Ingeniería de

Software implica niveles de rigor y pruebas de procesos 64

En la construcción y desarrollo de proyectos se aplican técnicas y métodos para resolver

los problemas, la informática por su parte nos aporta herramientas y procedimientos

sobre los que se apoya la Ingeniería de Software, entre los objetivos que tiene la

Ingeniería de Software tenemos los siguientes: 65

• Mejorar la calidad de los productos de software.

• Aumentar la productividad de los Ingenieros de Software

• Facilitar el control en el ciclo de desarrollo de software

• Suministrar a los desarrolladores las bases para construir software de alta calidad

en una forma eficiente.

• Definir una disciplina que garantice la producción y el mantenimiento de los

productos de software desarrollados en el plazo fijado y dentro del costo

estimado.

La Ingeniería de Software comúnmente lleva a cabo las siguientes tareas: 66

Análisis de requisitos

Para generar un producto de software es necesario es necesario extraer los requisitos

sobre el mismo, a pesar de que nuestros usuarios o clientes nos dictan lo que el software

debe hacer es necesario tener la habilidad y experiencia en la Ingeniería de Software para

reconocer aquellos requerimientos incompletos, ambiguos o contradictorios.

Los resultados del análisis de requerimientos se plasma en un documento conocido como

Especificación de Requerimientos del Sistema donde la estructura puede venir definida por

varios estándares como CMM-I 67, aquí también se define el diagrama Entidad-Relación

que participan en el desarrollo del software.

64 “Ingeniería de Software”, http://es.wikipedia.org/wiki/Desarrollo_de_software, [22Diciembre2008]. 65 “Ingeniería de Software”, http://www.monografias.com/trabajos5/inso/inso.shtml, [22Diciembre08] 66 “Ingeniería de Software”, http://es.wikipedia.org/wiki/Desarrollo_de_software, [22Diciembre2008]. 67 Capability Maturity Model Integration (CMMI) es un modelo para la mejora de procesos que proporciona a las organizaciones los elementos esenciales para procesos eficaces.

60

Especificación.

A través de ella se describe detalladamente el software que será desarrollado, tenemos

que ser muy rigurosos en ello, dependiendo de esto nos sirve para entender y afinar

aplicaciones que ya han sido desarrolladas, se utilizan en gran medida para la interfaces

externas las cuales deben permanecer estables.

Diseño y Arquitectura

Determinamos como funcionará de manera general la aplicación sin entrar en detalles, se

incorporan consideraciones de la implementación tecnológica (hardware, red, etc.), se

definen los escenarios sobre los cuales se ejecutará la aplicación o mejor conocidos como

casos de uso, y se transforman las entidades definidas en el análisis de requisitos en

entidades físicas.

Programación.

Se transforma el diseño a código, quizás sea la parte más obvia de la Ingeniería de

Software pero en la mayoría de los casos no la más larga habiendo implementado un buen

diseño.

Prueba.

Proceso para comprobar que el software realice correctamente las especificaciones

hechas, actualmente se va probando modulo por modulo, finalmente se prueba la

interacción de estos módulos a través de una prueba integral.

Documentación.

Generación de información documental sobre el proyecto, se realiza el manual de usuario,

manual técnico con el fin de optimizar en un futuro las modificaciones o ampliaciones al

sistema de software.

Mantenimiento.

Actividad para mantener y mejorar el software de acuerdo a los errores descubiertos y a

los nuevos requerimientos, esta actividad puede llevar mas tiempo que el desarrollo del

software mismo, el trabajo aquí consiste en arreglar errores o extender el sistema para

que adquiera nuevas características.

61

2.3 Administración de Proyectos Informáticos

Comenzaremos definiendo lo que es un proyecto, podríamos definirlo como un conjunto

de actividades interconectadas y ejecutadas de manera organizada, con puntos de inicio y

fin claramente determinados para lograr resultados específicos, que satisfagan las

estrategias de la organización en un tiempo delimitado 68.

Podríamos decir que un proyecto es un trabajo que se ejecuta por una sola vez, tiene un

inicio y un final, un objetivo establecido con claridad, un presupuesto establecido y una

organización (puede ser temporal y muere al final del proyecto)69.

Ahora pasamos a una definición de la Administración de Proyectos, la cual es un proceso

dinámico, que utiliza recursos adecuados de la organización de un modo estructurado y

controlado, con el fin de lograr los objetivos que fueron definidos, y que son catalogados

como necesidades estratégicas, nótese que siempre se ejecuta bajo un conjunto de

restricciones.

Según el ciclo de vida de la administración de proyectos (basado en el PMI70 ) este se

compone de un Inicio, una Planeación, una Ejecución, un Control y Cierre, donde las

etapas intermedias interactúan entre si constantemente.

En las organizaciones existen diferentes niveles para la administración de proyectos, los

cuales podríamos determinar de la siguiente manera71:

• Nivel 0: No es conocido el concepto de Administración de Proyectos

• Nivel 1: Aplicación empírica de manera individual por personal de la organización.

• Nivel 2: Se lleva a través de una metodología.

• Nivel 3: Se monitorea el cumplimiento del proceso.

• Nivel 4: Proceso de mejora continua.

68 Cervantes, Gustavo. “Seminario Administración de Proyectos en Informática”, http://www.amereiaf.org.mx/pdf/seminario_administracion.pdf. [Marzo2008] 69 Cervantes, Gustavo. “Seminario Administración de Proyectos en Informática”, http://www.amereiaf.org.mx/pdf/seminario_administracion.pdf. [Marzo2008]. 70 Project Management Institute 71 Cervantes, Gustavo. “Seminario Administración de Proyectos en Informática”, http://www.amereiaf.org.mx/pdf/seminario_administracion.pdf. [Marzo2008].

62

La Administración de Proyectos esta compuesta de diversas ramas “administrativas” las

cuales mencionaremos a continuación:

Administración del Alcance del Proyecto

Se encarga de los procesos requeridos para asegurar que el proyecto incluya todo el

trabajo requerido, y solamente el trabajo requerido para terminar el proyecto

exitosamente.

Administración del Programa del Proyecto

Incluye los procesos requeridos para asegurar la terminación a tiempo del proyecto.

Administración del Presupuesto.

Se encarga de los procesos requeridos para asegurar que el proyecto termine dentro del

presupuesto aprobado.

Administración de la Calidad del Proyecto.

Procesos requeridos para asegurar que el proyecto satisfaga las necesidades para lo cual

fue requerido.

Administración de los Recursos Humanos

Incluye los procesos requeridos para lograr el uso más efectivo de las personas

involucradas en el proyecto.

Administración de las comunicaciones

Se encarga de los procesos para asegurar la puntual y apropiada generación, recolección,

diseminación, archivo, y ultima disposición de la información del proyecto.

Administración del Riesgo del Proyecto.

Incluye los procesos concernientes con la identificación, análisis y respuesta al riesgo del

proyecto. Incluye el maximizar los resultados de eventos positivos y minimizar las

consecuencias de eventos adversos.

Administración de los Abastecimientos.

Se encarga de los procesos para la adquisición de bienes y servicios externos a la

organización.

Los elementos de los cuales se compone el Sistema de Administración de Proyectos son

los siguientes:

63

• Humano

o Negociación

o Comunicación

o Motivación

o Liderazgo

o Trabajo en Equipo

• Técnicas y Metodologías.

o Modelado

o Costeo

o Programación.

• Planeación.

o Objetivos.

o Metas.

o Estrategias.

• Información

o Desempeño

o Dinero

o Tiempo

• Organización.

o Autoridad

o Responsabilidad

• Cultura

o Valores

o Actitudes

o Creencias

o Tradiciones

• Control

o Estándares

o Sensores

o Comparativos

o Acciones

Podríamos también considerar que el éxito de la Administración de un Proyecto estaría

definida por el logro del objetivo, en tiempo, apegado a la visión, y teniendo al usuario

satisfecho.

Todo proyecto debe iniciar con una junta de inicialización, en la cual se traten temas

como los antecedentes del problema a solucionar, los resultados esperados (objetivo),

establecer la metodología de trabajo (participación del usuario, comunicación de avances,

control y comunicación de cambios), organización (roles), y un plan general del proyecto.

64

Respecto a los requerimientos podemos definirlos en dos, los explícitos y los implícitos,

los explícitos son aquellos claramente definidos por el cliente, los Implícitos son aquellos

que son identificados como obvios por alguna de las partes (usuarios o analistas), el

problema lo tenemos con los implícitos.

En la Administración de Proyectos tenemos algo que se llama el Concepto del Proyecto,

que es la definición del proyecto es decir el propósito, define también el alcance y el

marco de referencia, se debe definir al inicio del proyecto ya que muchos proyectos

inician con necesidades difusas o poco claras, en esta etapa se analiza la factibilidad del

proyecto y nos permite un análisis organizado de la idea de un proyecto.

Vamos hablar de una de las etapas de la Administración de Proyectos la cual es la

Planeación, es la definición clara y precisa de objetivos (y las actividades que se ejecutaran

para lograrlos), de manera que se logre una meta final. La meta puede ser la solución

de un problema o el logro de un estado o condición diferente al estado actual.

Planear es identificar las actividades del proyecto, estimar el tiempo y costo, definir la

secuencia de actividades del proyecto, identificar las actividades críticas y preparar la

propuesta del proyecto es decir el plan.

Uno de los puntos más difíciles de trabajar es la estimación del tiempo, esto se debe a

diversas situaciones como la distribución de tiempo de los desarrolladores, definición de

las tareas de los mismos, planear bajo un esquema optimista, y sobre supuestos como el

considerar que la gente dedica el 100% del tiempo en la oficina a su trabajo.

Respecto a la estimación del tiempo se basa en su mayoría a la experiencia, y las

variaciones en la estimación pueden deberse al nivel de habilidades de las personas,

disponibilidad de los recursos materiales y a eventos inesperados.

Pasando ahora a la fase de Control, a esta actividad podríamos definirla como el proceso

de comparar los avances/resultados con respecto a los planes, con el fin de tomar

medidas correctivas cuando existan desviaciones, se miden principalmente los siguientes

factores, planes, resultados, información y motivación, y cabe hacer mención que el

control en proyectos no esta relacionado al ejercicio del poder.

En algunas ocasiones tendemos a confundir al monitoreo con el control, pero el

monitoreo es obtener información relevante para tener una foto del estado del proyecto

en un momento en particular, y el control es ejercer acciones oportunas derivadas del

monitoreo.

65

El monitoreo nos ayuda bastante para el control, pero una pregunta clave es, como ejercer

el monitoreo?, esto se puede llevar a cabo preguntando como va el proyecto, así como los

problemas que ha enfrentado, traducción de información en términos de impacto al plan

del proyecto, preguntar que falta hacer y no el que han hecho, preguntar que recursos

requieren y para cuando, y la identificación sobre la comunicación del equipo.

Cambiando un poco el tema pasamos ahora a la cuestión humana, y una actividad muy

importante es definir a la persona adecuada para cierto tipo de actividad, es decir, la

definición de quien hace el trabajo, definir como se hace el trabajo, el enfoque debe ser

el conseguir a las personas adecuadas, y darles libertad. Una regla en la selección es no

basarse en la apariencia si no mas bien en la experiencia y la capacidad, tomando en

cuenta que experiencia es haber hecho en la practica que es muy diferente a tomar cursos

o trabajos escolares, la capacidad es otro punto a considerar, la cual es el talento de la

persona para aprender y aplicar lo aprendido y finalmente, la edad no debería de ser un

factor de peso para las actividades de sistemas.

Dentro del entorno que se vive dentro de la Administración de Proyectos hay que

demostrar la habilidad del liderazgo efectivo, cumplir con las practicas establecidas, se

trabaja con lo desconocido e imprescindible, hay que demostrar la habilidad para trabajar

y aplicar las herramientas, métodos y técnicas de administración de proyectos, apegarse a

los tiempos establecidos

Acabamos de mencionar los puntos básicos, pero también tenemos puntos deseables

como la flexibilidad y adaptabilidad de entornos dinámicos, tener iniciativa, ser asertivos,

entusiastas y creativos sobre el proyecto, bien organizado y disciplinado en el manejo del

tiempo. Ambicioso (energía, empuje, compromiso), consciente de la tecnología, capaz de

facilitar la solución de problemas y conflictos, tomar decisiones, y que este capacitado en

la técnica y metodologías de la Administración de Proyectos.

Finalmente hablaremos sobre las características de un Administrador de Proyectos, y estas

son la habilidad para resolver problemas, su curva de aprendizaje, la constancia y

compromiso, el trabajo colaborativo y cooperativo, la experiencia y visión del negocio,

experiencia técnica, experiencia en administración de proyectos y administrativa, es un

integrador y facilitador, usa la autoridad natural por influencia, toma la responsabilidad

por los problemas del equipo, tiene confianza en las personas, toma riesgos con su

equipo, y es creativo e innovador.

66

2.4 RUP (Rational Unified Process)

El Proceso Unificado Rational comúnmente conocido como RUP, es un proceso de

desarrollo de software, junto con el Lenguaje Unificado de Modelado (UML), constituyen

una metodología estándar más utilizada para el análisis, la implementación y

documentación de sistemas orientados a objetos 72

Una de las características que tiene RUP es que no es un sistema con pasos firmemente

establecidos, sino un conjunto de metodologías adaptables al contexto y a las

necesidades de cada organización.

Existe una versión comercial desarrollada por la empresa Rational, la cual es propiedad

del gigante IBM, el cual a través de un producto de software permite incluir información y

entrelazarla, basada en diferentes artefactos (documentación relacionada con el proceso

de diseño) y descripciones de diversas actividades de un proceso.

El RUP está basado en 5 principios clave que son:

Adaptar el proceso

El proceso deberá adaptarse a las características propias del proyecto u organización. El

tamaño del mismo, así como su tipo o las regulaciones que lo condicionen, influirán en su

diseño específico. También se deberá tener en cuenta el alcance del proyecto.

Balancear prioridades

Los requerimientos de los diversos inversores pueden ser diferentes, contradictorios o

disputarse recursos limitados. ''Debe encontrarse un balance que satisfaga los deseos de

todos''.

Demostrar valor iterativamente

Los proyectos se entregan, aunque sea de un modo interno, en '''etapas iteradas'''. En cada

iteración se analiza la opinión de los inversores, la estabilidad y calidad del producto, y se

refina la dirección del proyecto así como también los riesgos involucrados

72 “RUP”, http://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational, [Marzo2008]

67

Elevar el nivel de abstracción

Este principio dominante motiva el uso de conceptos reutilizables tales como patrón del

software, lenguajes 4GL73 o esquemas (frameworks)74 por nombrar algunos. Esto previene

a los ingenieros de software el ir directamente de los requisitos a la codificación de

software a la medida del cliente. Un nivel alto de abstracción también permite discusiones

sobre diversos niveles arquitectónicos. Éstos se pueden acompañar por las

representaciones visuales de la arquitectura, por ejemplo con UML75.

Enfocarse en la calidad

El control de calidad no debe realizarse al final de cada iteración, sino en '''todos''' los

aspectos de la producción. El aseguramiento de la calidad forma parte del proceso de

desarrollo y no de un grupo independiente.

Ciclo de Vida

El ciclo de vida organiza las tareas en fases e iteraciones, RUP divide el proceso de

desarrollo en ciclos, teniendo un producto final al culminar cada uno de ellos, estos a la

vez se dividen en fases que finalizan con un hito donde se debe tomar una decisión

importante:

Concepción

Se hace un plan de fases, se identifican los principales casos de uso y se identifican los

riesgos.

Elaboración

Se hace un plan de proyecto, se completan los casos de uso y se eliminan los riesgos.

Construcción

Se concentra en la elaboración de un producto totalmente operativo y eficiente, se

desarrolla el manual de usuario.

Transición

Se Instala el producto en el cliente y se entrena a los usuarios. Como consecuencia de esto

suelen surgir nuevos requisitos a ser analizados.

73 “Lenguaje de programación avanzado, donde el programador no incorpora el procedimiento a seguir , ya que el propio lenguaje es capaz de indicar a la computadora como debe ejecutar el programa”, http://www.mastermagazine.info/termino/3671.php, [13Octubre2008]. 74 “Es una estructura de soporte definida mediante la cual otro proyecto de software puede ser organizado y desarrollado”, http://es.wikipedia.org/wiki/Framework, [17Octubre2008]. 75 Unified Modeling Language, Lenguaje Unificado de Modelado

68

Mantenimiento

Una vez instalado el producto, el usuario realiza requerimientos de ajuste, esto se hace de

acuerdo a solicitudes generadas como consecuencia del interactuar con el producto.

Principales características

• Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo

y cómo)

• Pretende implementar las mejores prácticas en Ingeniería de Software.

• Desarrollo iterativo.

• Administración de requisitos.

• Uso de arquitectura basada en componentes

• Control de cambios

• Modelado visual del software

• Verificación de la calidad del software

RUP es un producto de Rational76. Se caracteriza por ser iterativo e incremental, estar

centrado en la arquitectura y guiado por los casos de uso.

Incluye artefactos (que son los productos tangibles del proceso como por ejemplo, el

modelo de caso de uso, el código fuente, etc.) y los roles (papel que desempeña una

persona en un determinado momento, una persona puede desempeñar distintos roles a lo

largo del proceso).

Comentarios sobre Alcance del RUP

La metodología RUP es más apropiada para proyectos grandes, dado que requiere un

equipo de trabajo capaz de administrar un proceso complejo en varias etapas. En

proyectos pequeños, es posible que no sea posible cubrir los costos de dedicación del

equipo de profesionales necesarios.

76 “Rational Software es actualmente conocida como una familia de software de IBM para el despliegue, diseño, construcción, pruebas y administración de proyectos en el proceso desarrollo de software.”, http://es.wikipedia.org/wiki/Rational_Software, [Noviembre2008].

69

2.5 UML (Unified Modeling Languaje)

Metodología Orientada a Datos (DFD’s)

El análisis y diseño se basaban principalmente en métodos que consideraban

primordialmente a los procesos y los flujos de información que existían entre cada uno de

ellos, estos métodos fueron desarrollados por personas como Tom de Marco, Edward

Yourdon y otros mas. Incluso antecesoras a esta metodología teníamos la HIPO y Warnier

las cuales se enfocaban mas a los datos 77.

Los sistemas a lo largo de la historia se han vuelto cada vez mas complejos, para

controlar esa complejidad se utilizo la programación estructurada, donde la programación

se basaba en una secuencia esperada de instrucciones de ejecución, el diseñar y depurar

programas a manera de cómo lo hace la computadora terminaba creando software que no

era del todo entendible.

En el mundo de las técnicas OO78 el diseñador piensa en términos de objetos y el

comportamiento de estos, las técnicas OO nos brindan un conjunto de clases reutilizables

donde la mayor parte del proceso de construcción de software consiste en el ensamblaje

de clases ya existente y probadas, el paradigma de programación OO cambia la forma de

pensar sobre los sistemas, y es más sencillo de comprenderlo debido a que todo en

nuestra vida diaria lo relacionamos con objetos.

Debido a la modernización y actualización de los conceptos de programación orientada a

objetos, la fase de análisis requería una modernización hacia esta nueva tendencia, ahí es

donde autores como James Rumbaugh, Grady Booch y Jacobson trabajaron para elaborar

metodologías orientadas a objetos.

UML es un estándar para construir modelos orientados a objetos. Nació en 1994 por

iniciativa de Grady Booch y Jim Rumbaugh para combinar sus dos famosos métodos: el de

Booch y el OMT (Object Modeling Technique, Técnica de Modelado de Objetos). Más tarde

se les unió Ivar Jacobson, creador del método OOSE (Object-Oriented Software

Engineering, Ingeniería de Software Orientada a Objetos). En respuesta a una petición del

OMG (Object Management Group, Grupo de Administración de Objetos) para definir un

lenguaje y una notación estándar del lenguaje de construcción de modelos, en 1997

propusieron el UML como candidato79

77 Martín, James, 1994. “Análisis y Diseño Orientado a Objetos”, Editorial Prentice Hispanoamérica, México. 78 Orientadas a Objetos 79 Larman, Craig. 1999. “UML y Patrones. Introducción al análisis y diseño orientado a objetos” Editorial Pearson Educación. México.

70

Grafico 15. Historia de UML Grafico 15. Historia de UML Grafico 15. Historia de UML Grafico 15. Historia de UML 80808080

Cabe mencionar que el modelado es independiente del lenguaje de programación, y

ofrece diferentes vistas dependiendo del aspecto del sistema que se quiera resaltar.

MODELO VISUAL

Es el modelado de una aplicación usando notaciones graficas, en ocasiones nos

preguntamos que tan importante es el modelar, cuando decidimos construir una casa si

se cuenta con el modelo es más sencillo y satisfactorio el resultado.

El modelado visual de software ayuda a capturar las partes esenciales de un sistema 81:

• Para capturar los procesos de negocio desde la perspectiva del usuario.

• Para analizar y diseñar una aplicación, distinguiendo entre los dominios del

negocio y los dominios de la computadora.

• Ayuda a reducir la complejidad.

• Independencia con el lenguaje de programación.

• Promueve el re uso de componentes.

80 Letelier, Patricio. 2002. “Desarrollo de software Orientado a Objetos usando UML”, http://www.dsic.upv.es/~uml/ 81 Universidad Tecnológica de la Mixteca, “Modelado Visual con UML”, http://www.utm.mx/~temas/temas-docs/nfnotas516.pdf, [Marzo2008]

71

UML es un lenguaje de modelado, y es independiente del proceso, por lo cual no se

considera una metodología, un lenguaje de modelado define la notación que es utilizada

por los métodos para representar los diseños.

Cuando hablamos de un método o proceso estamos hablando de los pasos a seguir para

llevar a cabo el análisis y el diseño, una de las características principales de UML es que

no incluye un proceso como parte de su propuesta.

Los modelos se componen de otros modelos, de diagramas y documentos que describen

detalles del sistema. El UML especifica varios diagramas, si queremos caracterizar los

modelos, podemos poner de manifiesto la información estática o dinámica de un sistema.

Un modelo estático describe las propiedades estructurales del sistema; en cambio un

modelo dinámico describe las propiedades de comportamiento de un sistema. Es

importante mencionar que UML es un lenguaje para construir modelos, no guía al

desarrollador en la forma de cómo realizar el análisis y el diseño OO ni tampoco indica

cual proceso de desarrollo adoptar82

Para modelar basta con utilizar una parte de UML “el 80 por ciento de la mayoría de los

problemas pueden modelarse usando alrededor del 20 por ciento de UML”.

UML se define como un “lenguaje que permite especificar, visualizar y construir los

artefactos de los sistemas de software”. En la construcción de software usando UML

existen 5 vistas para visualizar, especificar, construir y documentar la arquitectura del

software. UML permite representar cada vista mediante un conjunto de diagramas, las

vistas son las siguientes83:

a. Vista de Casos de Uso: Muestra la funcionalidad del sistema desde el punto

de vista de un actor externo que interactúa con él. Esta vista es útil a

clientes, diseñadores y desarrolladores.

b. Vista de diseño: Muestra la funcionalidad del diseño dentro del sistema en

términos de la estructura estática y comportamiento dinámico del sistema.

Esta vista es útil a diseñadores y desarrolladores. Se definen propiedades

tales como: persistencia, concurrencia, interfaces y estructuras internas a

las clases.

c. Vista de Procesos: Muestra la concurrencia del sistema, comunicación y

sincronización, útil a desarrolladores e integradores.

82 Larman, Craig. 1999. “UML y Patrones. Introducción al análisis y diseño orientado a objetos” Editorial Pearson Educación. México. 83 Grady Booch, James Rambaugh, Ivar Jacobson, 1997. “The UML specification documents”, Rational Software Corp. USA.

72

d. Vista de Implementación: Muestra la organización de los componentes de

código. Útil a los desarrolladores.

e. Vista de Implantación o Vista de Despliegue: Muestra la implantación del

sistema en la arquitectura física. Útil a desarrolladores, integradores y

verificadores.

UML es un leguaje notacional, un elemento primordial son los diagramas los cuales nos

permiten modelar los sistemas. Un diagrama es una representación grafica de una

colección de elementos de modelado, comúnmente mostrando como un grafo convexo de

vértices en el cual se representas los objetos y un conjunto de arcos que representan las

relaciones. El objetivo de los diagramas es hacer más comprensible el sistema que se esta

desarrollando y por lo tanto más cercano a los objetivos.

Se reconoce que un proceso de desarrollo de software es un método de organizar las

actividades relacionadas con la creación, presentación y mantenimiento de los sistemas de

software. Como se comento, UML no define un proceso de desarrollo, mas bien es una

herramienta que se puede utilizar durante el proceso de desarrollo.

Craig Larman da un par de razones que explican esto84:

1. Aumentar la posibilidad de una aceptación generalizada de la notación estándar

del modelado, sin la obligación de adoptar un proceso oficial.

2. La esencia de un proceso apropiado admite mucha variación y depende de las

habilidades del personal, de la razón investigación desarrollo, de la naturaleza del

problema y de las herramientas.

Requerimientos

Proceso

U M L

Producto

Grafico 16. Proceso de Desarrollo y UMLGrafico 16. Proceso de Desarrollo y UMLGrafico 16. Proceso de Desarrollo y UMLGrafico 16. Proceso de Desarrollo y UML85858585

84 Larman, Craig. 1999. “UML y Patrones. Introducción al análisis y diseño orientado a objetos” Editorial Pearson Educación. México. 85 Larman, Craig. 1999. “UML y Patrones. Introducción al análisis y diseño orientado a objetos” Editorial Pearson Educación. México

73

3. ADMINISTRACIÓN DE PROYECTOS INFORMATICOS EN LAS ORGANIZACIONES.

En este capitulo veremos algunas metodologías para el desarrollo de software comercial,

sus principales características de cada una de ellas, posteriormente las tendencias en la

administración de proyectos así como metodologías actuales en las que se basa la

administración de proyectos, también las ventajas o beneficios de utilizar una

metodología y finalmente nos enfocamos a las PyMEs que se pueden adaptar a la guía

propuesta.

3.1 Metodologías y Modelos Actuales utilizados en las

organizaciones. DESARROLLO ÁGIL DE SOFTWARE (DAS)DESARROLLO ÁGIL DE SOFTWARE (DAS)DESARROLLO ÁGIL DE SOFTWARE (DAS)DESARROLLO ÁGIL DE SOFTWARE (DAS)

Es un paradigma de Desarrollo de Software basado en procesos ágiles, anteriormente

estos procesos ágiles se les llamaban metodologías livianas o suaves, e intentan evitar los

tortuosos y burocráticos caminos de las metodologías tradicionales enfocándose a la

gente y a los resultados86.

Es un marco de trabajo conceptual de la ingeniería de software que promueve iteraciones

en el desarrollo a lo largo de todo el ciclo de vida del proyecto. Existen muchos métodos

de desarrollo ágil; la mayoría minimiza riesgos desarrollando software en cortos lapsos de

tiempo. El software desarrollado en una unidad de tiempo es llamado una iteración, la

cual debe durar de una a cuatro semanas. Cada iteración un proyecto de software entero:

incluye planeación, análisis de requerimientos, diseño, codificación, revisión y

documentación. Una iteración no debe agregar demasiada funcionalidad para justificar el

lanzamiento del producto al mercado, pero la meta es tener un demo (sin errores) al final

de cada iteración. Al final de cada iteración el equipo vuelve a evaluar las prioridades del

proyecto87.

86 Wikipedia la Enciclopedia Libre, “Desarrollo Agil de Software”, http://es.wikipedia.org/wiki/Desarrollo_%C3%A1gil_de_software, [Marzo2008] 87 Wikipedia la Enciclopedia Libre, “Desarrollo Ágil de Software”, http://es.wikipedia.org/wiki/Desarrollo_%C3%A1gil_de_software, [Marzo2008]

74

Los métodos ágiles enfatizan las comunicaciones cara a cara a través de la

documentación. La mayoría de los equipos ágiles están localizados en una simple oficina

abierta, a veces llamadas "plataformas de lanzamiento" (bullpen en inglés). La oficina debe

incluir revisores, diseñadores de iteración, escritores de documentación y ayuda y

directores de proyecto. Los métodos ágiles también enfatizan que el software funcional es

la primera medida del progreso. Combinado con la preferencia por las comunicaciones

cara a cara, generalmente los métodos ágiles son criticados y tratados como

"indisciplinados" por la falta de documentación técnica.

AUTOWEBAUTOWEBAUTOWEBAUTOWEB

Autoweb es una metodología para el desarrollo de aplicaciones web. La metodología está

basada en modelos y técnicas utilizados anteriormente en hipermedia88, en los sistemas

de información y en la ingeniería del software; todos ellos adaptados y unidos para formar

una técnica original.

El proyecto Autoweb propone una metodología y también un entorno de diseño para

páginas web con gran cantidad de datos. Las principales características del sistema son89:

• Adaptarse a los modelos actuales de hipermedia para desarrollo web y a las

necesidades de la generación automática de software.

• Utilizar la tecnología de las bases de datos no sólo para almacenar el contenido de

una aplicación web sino para almacenar una descripción de su estructura,

navegabilidad y presentación, para que se permita la implementación automática y

una evolución mejor.

• Definir un proceso de desarrollo software para construir nuevas aplicaciones web y

para poder practicar ingeniería inversa sobre aplicaciones basadas en base de

datos ya existentes.

• Dar soporte a estos procesos mediante herramientas sencillas.

88 “Es el término con que se designa al conjunto de métodos o procedimientos para escribir, diseñar, o componer contenidos que tengan texto, video, audio, mapas u otros medios, y que además tenga la posibilidad de interactuar con los usuarios.”, http://es.wikipedia.org/wiki/Hipermedia 89 Wikipedia la Enciclopedia Libre, “Autoweb”, http://es.wikipedia.org/wiki/Autoweb , [Marzo2008]

75

DERCASDERCASDERCASDERCAS

Son las siglas en idioma español para "Documento de Especificaciones, Requerimientos y

Criterios". El DERCAS es una metodología de la Ingeniería de software que permite definir

los pasos esenciales para el análisis y desarrollo de un proyecto de software.

Generalmente se realiza al principio del proyecto, e involucra tanto al arquitecto de

software, al administrador del proyecto y a otros miembros del staff, que harán diversas

visitas a los clientes para levantado de requerimientos y así enmarcar en un contexto la

solución a desarrollar.

En la metodología no se centra únicamente en el software, sino en mejorar los procesos

de trabajo actuales de la organización y las prácticas en las que se trabaja en el área

donde será implementado el sistema.

Su equivalente en el idioma inglés es "Analysis and Requirements Specifications", que se

traduce como Especificaciones de Análisis y Requerimientos90.

ISO/IEC 12207ISO/IEC 12207ISO/IEC 12207ISO/IEC 12207

Establece un proceso de ciclo de vida para el software que incluye procesos y actividades

que se aplican desde la definición de requisitos, pasando por la adquisición y

configuración de los servicios del sistema, hasta la finalización de su uso. Este estándar

tiene como objetivo principal proporcionar una estructura común para que compradores,

proveedores, desarrolladores, personal de mantenimiento, operadores, gestores y

técnicos involucrados en el desarrollo de software usen un lenguaje común. Este lenguaje

común se establece en forma de procesos bien definidos.

La estructura del estándar ha sido concebida de manera flexible y modular de manera que

pueda ser adaptada a las necesidades de cualquiera que lo use. Para conseguirlo, el

estándar se basa en dos principios fundamentales: Modularidad y Responsabilidad. Con la

Modularidad se pretende conseguir procesos con un mínimo acoplamiento y una máxima

cohesión. En cuanto a la Responsabilidad, se busca establecer un responsable para cada

proceso, facilitando la aplicación del estándar en proyectos en los que pueden existir

distintas personas u organizaciones involucradas91.

90 Wikipedia la Enciclopedia Libre, “DERCAS”, http://es.wikipedia.org/wiki/DERCAS, [Marzo2008] 91 Wikipedia la Enciclopedia Libre, “ISO/IEC 12207”, http://es.wikipedia.org/wiki/ ISO/IEC 12207, [Marzo2008]

76

METODOLOGIA DE BOOCHMETODOLOGIA DE BOOCHMETODOLOGIA DE BOOCHMETODOLOGIA DE BOOCH

La Metodología de Booch es una técnica usada en Ingeniería de Software. Es un lenguaje

de modelado de objetos y una metodología ampliamente usada en el diseño de software

orientado a objetos. Fue desarrollada por Grady Booch mientras trabajaba para Rational

Software (hoy parte de IBM).

Los aspectos notables de la metodología de Booch han sido superados por el Lenguaje

Unificado de Modelado, que combina elementos gráficos de la metodología de Booch

junto a elementos de la técnica de modelado de objetos y la Ingeniería de Software

orientada a objetos

Los aspectos metodológicos de la metodología de Booch fueron incorporados en varias

metodologías y procesos, siendo la principal de ellas el Proceso Racional Unificado

(RUP)92.

Grafico 17.Grafico 17.Grafico 17.Grafico 17. Diagrama de ClasesDiagrama de ClasesDiagrama de ClasesDiagrama de Clases

92 Wikipedia la Enciclopedia Libre, “Metodología de Booch”, http://es.wikipedia.org/wiki/Metodolog%C3%Ada_de_Booch, [Marzo2008]

77

METODOLOGIA SHLAERMETODOLOGIA SHLAERMETODOLOGIA SHLAERMETODOLOGIA SHLAER----MELLORMELLORMELLORMELLOR

Se basa en un conjunto integrado de modelos que pueden ser ejecutados para

verificación, y en un enfoque innovador de diseño que produce un sistema a través de la

traducción de los modelos de análisis. Este método esta construido sobre un

conjunto de reglas bien definidas para la construcción de los diagramas, y la traducción

de dichos diagramas del análisis al diseño y finalmente a la implementación. De hecho,

herramientas de modelado como BridgePoint, tienen la habilidad de generar 100 por

ciento del código. Este logro esta por encima de la mayoría de las otras metodologías que

generan la declaración de operación pero que no pueden proporcionar el código de los

métodos, la implementación de la operación.

Este riguroso conjunto de reglas también soporta verificación mediante simulación, los

diagramas pueden ser ejecutados para comprobar si trabajan adecuadamente.

Un dominio es un área de asunto, y es uno de los conceptos primarios de Shlaer-Mellor,

tenemos tres tipos básicos de dominios: El dominio de aplicación, el dominio de servicio,

y el dominio arquitectural. Cada dominio tiene sus propios tipos de requerimientos únicos

y diagramas. Ellos representan juntos la especificación completa del sistema.

El proceso se descompone en los siguientes pasos:

1. Particionar el sistema en dominios.

2. Analizar el dominio de la aplicación usando modelos de objetos de información,

modelos de estado, y especificaciones de acciones (diagramas de flujo de acciones

)

3. Confirmar el análisis mediante verificación estática y verificación dinámica

(simulación)

4. Extraer los requerimientos del dominio de servicio.

5. Analizar el dominio del servicio.

6. Especificar los componentes del dominio arquitectural.

7. Construir los componentes arquitecturales.

8. Traducir los modelos para cada dominio usando los componentes arquitecturales.

La manera de controlarlo paso a paso se apoya de un conjunto de reglas que va guiando

el paso de una versión a la siguiente, el proceso marca que hay que ir construyendo poco

a poco, probarlo y seguir avanzando, con esto evitamos que surjan problemas

inesperados cuando ya se tiene un avance considerable.

78

Este modelo hace referencia al proceso iterativo e incremental, pero a diferencia de otras

metodologías esta reduce y controla las iteraciones en el análisis confinándolas a un solo

dominio a la vez, las iteraciones en el diseño son controladas de manera similar,

modificaciones en el diseño se hacen de manera arquitectural y se propagan mediante

diagramas estandarizados.

La reutilización es de alta prioridad debido a que los dominios son conservados en forma

completamente separada uno de otro hasta que se llega a la construcción final, y podrán

ser transportados intactos a otros sistemas, esto aplica al dominio arquitectural ya que es

reutilizado por otros sistemas que tienen básicamente las mismas características de

cargado y ejecución.

CRCCRCCRCCRC

Esta metodología proviene de Clases, Responsabilidades y Colaboradores. Esta

metodología se desarrollo como una herramienta de aprendizaje cuando la época de la

programación orientada a objetos era nueva, y muchos de los programadores

procedurales necesitaron ayuda para lograr el pensamiento OO, la meta era la

introducción a este nuevo paradigma de la manera más simple.

La clave de esta metodología consistía en una tarjeta CRC, la cual estaba rayada y su

tamaño era de 3x5” o 4x6”, esta tarjeta enfatiza la división de responsabilidades a través

de los objetos, el tamaño físico ayuda establecer los limites de la complejidad de la clase,

esta técnica no utiliza UML, pero se utilizan para obtener información acerca de las clases

que luego son colocadas dentro de los diagramas de clases UML.

A continuación se muestra una tarjeta CRC:

79

Grafico 18Grafico 18Grafico 18Grafico 18. Tarjeta CRCTarjeta CRCTarjeta CRCTarjeta CRC93939393

CRC requiere de un equipo que juegue dos roles, uno como expertos del dominio los

cuales proporcionan el conocimiento del negocio y los facilitadotes de tecnología OO94

que dirige al equipo a través del desarrollo de tarjetas y el eventual modelo.

El CRC trabaja con escenarios y el proceso se divide en cuatro etapas:

1. Antes de la ejecución del escenario

a. El problema. Todos están de acuerdo en la definición del problema.

b. Lluvias de ideas para clases. Basado en la oración del problema el equipo

identifica las clases candidatas usando el vocabulario del problema.

c. Filtrado de clases. Se trabaja en definiciones para cada clase, elimina los

sinónimos y conflictos.

d. Asignación de tarjetas. A cada miembro del equipo se le asigna la

responsabilidad de una o más clases.

2. Ejecución de Escenario

a. Cada escenario expresa algo que se supone debe hacer el sistema. El

equipo viaja a través del escenario identificando las responsabilidades para

cada clase en el escenario.

b. Cada responsabilidad descubierta se registra en la tarjeta correspondiente

de la clase.

93 Pender, Thomas A. 2002, “UML Weekend Crash Course”, Editorial: Wiley. 94 Orientada a Objetos

80

3. Durante la ejecución del escenario.

a. Agrupando las tarjetas. El equipo identifica las clases similares.

b. Lista del escenario. El equipo revisa la cobertura y nivel de avance del

escenario.

c. Diagramas de colaboración. Las tarjetas son combinadas en una pared para

mostrar la forma en que interactúan en la ejecución de los escenarios.

4. Después de la ejecución de los escenarios.

a. El equipo revisa el modelo resultante y planea su implementación.

PROGRAMACIÓN EXTREMA (XP)PROGRAMACIÓN EXTREMA (XP)PROGRAMACIÓN EXTREMA (XP)PROGRAMACIÓN EXTREMA (XP)

La persona quien generó a esta metodología, Kent Beck, fue también instrumentador del

método CRC, es por ello que esta metodología trata de ser muy simple, cabe mencionar

que XP no se apega a UML.

XP se esfuerza en quitar cualquier cosa que no sea esencial, requiere también un

compromiso fuerte con los clientes a trabajar lado a lado con los programadores,

trabajando a través de escenarios de cómo debe funcionar el sistema, aquí cada iteración

que suele durar de una a cuatro semanas se entregan algo funcional, lo mínimo

entregable es un conjunto de pruebas.

Para XP el código es lo principal y por lo tanto hay demasiado énfasis en estándares de

codificación y principios de diseño, el proceso incluye numerosas reuniones para

mantener al equipo informado, además, los programadores trabajan en parejas de modo

que pueden aprender uno del otro, proporcionar ideas, compartir alternativas de diseño y

ayuda mutua.

81

3.2 Tendencias en la Administración de Proyectos

Existen diversos documentos que hablan sobre el futuro en la Administración de

Proyectos, de los cuales tomamos parte de ellos para presentar las tendencias:

• El rol de Administrador de Proyectos tendrá mayor influencia y se incrementará

para la planeación estratégica de las compañías, ya que los proyectos tienen el

potencial para cambiar el futuro y el propósito de las organizaciones y por lo tanto

son parte de la creación de la estrategia.

• Jugdev et al95, hace una distinción entre una aproximación a la Administración de

Proyectos desde una verdad obsoleta a un nuevo enfoque, como se muestra en la

sig. Figura:

Grafico 19. Verdades Obsoletas y Nuevos Enfoques de la AGrafico 19. Verdades Obsoletas y Nuevos Enfoques de la AGrafico 19. Verdades Obsoletas y Nuevos Enfoques de la AGrafico 19. Verdades Obsoletas y Nuevos Enfoques de la Administración de Proyectosdministración de Proyectosdministración de Proyectosdministración de Proyectos96969696

95 Jugdev, K & Thomas, Diciembre 2002, “J. Project Management Maturity Models: The Silver Bullets of Competitive Advantage.”, Editorial Project Management Journal. 96 “Volkswagen coaching Gmbh Project Management in co-operation with: IPMI University of Bremen. Project Management in Germany.” Editorial State&trenes, [2002].

82

PMBOKPMBOKPMBOKPMBOK

Se conoce como la guía de los fundamentos de la dirección de proyectos y es el estándar

más ampliamente reconocido para manejar y administrar proyectos, el PMBOK deja muy

claro su carácter y finalidad: el conjunto de conocimientos (the body of knowledge) para

dirigir un proyecto “residen en los practicantes y académicos que los aplican y los

desarrollan”.

La finalidad del PMBOK no es exponer disciplinas, técnicas y experiencias aplicables a la

dirección de proyectos, sino solamente de identificar el subconjunto de estas que se

reconoce comúnmente como buenas prácticas.

Para que estas buenas prácticas sean asequibles, el PMBOK divide el conjunto de

conocimientos para la dirección de proyectos en cuatro grupos de procesos: todo

proyecto (así como sus distintas fases e iteraciones) tiene que transitar por una serie de

actividades de inicio, de planeación, de ejecución y cierre, bajo el gobierno de un grupo

de procesos más general de supervisión y cierre97.

Estos grupos de proceso no se presentan como recetas de cocina sino que se dividen en

planear, hacer, revisar y actuar.

Grafico 20. Fases ProyectoGrafico 20. Fases ProyectoGrafico 20. Fases ProyectoGrafico 20. Fases Proyecto98989898

El PMBOK nos presenta nueve áreas de conocimiento las cuales contienen las técnicas para

poder realizar proyectos, las cuales se muestran en la sig. Figura:

97 LiderDeProyecto.com, “Manual de Administración de Proyectos.” http://www.liderdeproyecto.com/manual/que_es_el_pmbok.html, [Primavera2008]. 98 LiderDeProyecto.com, “Manual de Administración de Proyectos.” http://www.liderdeproyecto.com/manual/que_es_el_pmbok.html, [Primavera2008].

83

Grafico 21. Áreas de ConocimientoGrafico 21. Áreas de ConocimientoGrafico 21. Áreas de ConocimientoGrafico 21. Áreas de Conocimiento99999999

Por cada área de conocimiento se recomienda una serie de procesos que se desprenden

del principal, en las cuales se sugieren una serie de entradas, técnicas y salidas. Muchas

de las descripciones de los procesos contienen valiosas observaciones no se deben

considerar como un manual de técnicas sino más bien como la descripción del estándar

para manejo de proyectos.

PROCESOS ÁGILESPROCESOS ÁGILESPROCESOS ÁGILESPROCESOS ÁGILES

Uno de los principales obstáculos para adoptar una metodología es la complejidad

burocrática, y las numerosas actividades a desempeñar cuando contamos con recursos

limitados y poco tiempo para realizar el proyecto.

Los Procesos Ágiles plantean una forma sencilla de adoptar un proceso, entre ellos

tenemos algunos mencionados en este documento como XP100, Scrum101, hasta el

Microsoft Solution Framework102, etc. como se dijo, estas alternativas son fáciles de

adoptar pero el siguiente nivel de complejidad es la barrera de la diversidad, es decir, cual

de todos estos procesos es el mejor para mi proyecto.

99 LiderDeProyecto.com, “Manual de Administración de Proyectos.” http://www.liderdeproyecto.com/manual/que_es_el_pmbok.html, [Primavera2008]. 100 Programación Extrema o eXtreme Programming, http://es.wikipedia.org/wiki/Programaci%C3%B3n_Extrema, [Enero2009] 101 “Es un proceso de desarrollo de software iterativo e incremental utilizado comúnmente en entornos basado en la metodología Agile de desarrollo de software.”, http://es.wikipedia.org/wiki/Scrum, [Enero2009] 102 “Microsoft Solutions Framework (MSF) es una flexible e interrelacionada serie de conceptos, modelos y prácticas de uso que controlan la planificación, el desarrollo y la gestión de proyectos tecnológicos.”, http://www.microsoft.com/spanish/MSDN/estudiantes/ingsoft/planificacion/msf.mspx, [Enero2009]

84

Los procesos de desarrollo se encuentran en una etapa de fragmentación con varios

procesos existentes, esto quiere decir que nos falta una estandarización de los mismos,

posteriormente entraríamos a una etapa de unificación y aquí proceso ágil es una buena

opción mostrándonos lo que es más valioso en un proceso de desarrollo sin importar la

metodología elegida.

MOPROSOFTMOPROSOFTMOPROSOFTMOPROSOFT

Es un modelo para la mejora y evaluación de los procesos de desarrollo y mantenimiento

de sistemas y productos de software (desarrollada por la Asociación Mexicana para la

Calidad en Ingeniería de Software), cabe señalar que el origen de este modelo es similar al

presentado en este trabajo por las siguientes razones, primera, por que es un modelo de

origen nacional, segunda, surge a partir de un análisis de normas internacionales

buscando aquellas que pudieran adaptarse a las PyMEs de México pero de las cuales

ninguna cumplió con los requerimientos.

Este modelo esta diseñado para medir la capacidad de los procesos que siguen las

empresas y para garantizar una calidad constante en los desarrollos y mantenimientos de

software103.

El Modelo de Procesos para la Industria de Software (MOPOSOFT) tiene por objetivo

proporcionar a la industria mexicana y a las áreas internas dedicadas al desarrollo y

mantenimiento de Software un conjunto integrado de las mejores practicas basadas en los

modelos y estándares reconocidos internacionalmente, tales como ISO 9000:2000, CMM-

SW, ISO/IEC 15504, PMBOK, SWEBOK entre otros104

Algunas de las ventajas de implementar MOPROSOFT en las organizaciones son las

siguientes:

• Al tener practicas integradas, que van desde la gestión de negocio hasta el

desarrollo y mantenimiento de software, las empresas tendrían mayor control

sobre su desempeño en el mercado.

• Disminución de costos de incorporación de nuevo personal, si la capacitación se

enfoca a un modelo único y estándar.

• PyMES que usen procesos similares, podrían asociarse con mayor facilidad para

afrontar proyectos de mayor envergadura.

103 Itera-Moprosoft “Moprosoft” http://www.iteraprocess.com/index.php?option=com_content&task=view&id=23&Itemid=44 [Noviembre2009] 104 “Moprosoft: el nuevo modelo que impondrá una norma mexicana para la calidad en la industria del software”, http://www.iie.org.mx/boletin032003/ind.pdf, [Noviembre2009]

85

• La exportación de servicios de software de las empresas mexicanas sería mas

factible, incluso se podría disminuir la participación de intermediarios

transnacionales, dado que se consideran practicas reconocidas

internacionalmente.

3.3 Beneficios principales del uso de metodologías de

desarrollo de software

Guías para estimar costos.Guías para estimar costos.Guías para estimar costos.Guías para estimar costos.

Dado que las metodologías nos guían en el desarrollo de un proyecto, estas son una

herramienta para poder proyectar los costos que implica el desarrollo de un proyecto,

considerando, sino todos, la mayoría de los factores que intervienen durante el desarrollo

de un proyecto.

Guías para estimar tiempos.Guías para estimar tiempos.Guías para estimar tiempos.Guías para estimar tiempos.

De la misma manera que nos ayudan a estimar costos, también nos ayudan a estimar

tiempos, ya que se presentan las actividades que deberán desarrollarse durante el

proyecto, proyectando la duración aproximada de cada actividad y estableciendo fechas

de entrega pro ejemplo.

Incrementar la calidad del productoIncrementar la calidad del productoIncrementar la calidad del productoIncrementar la calidad del producto

A través de estándares, políticas y procedimientos podemos garantizar la calidad del

software a desarrollar, ya que estos vienen de otros proyectos ya finalizados, siendo de

gran utilidad en la mayoría de los casos caminar sobre terreno antes recorrido.

Aumentar la velocidad de deAumentar la velocidad de deAumentar la velocidad de deAumentar la velocidad de desarrollosarrollosarrollosarrollo

Dado que cada una de las etapas tiene un objetivo, cuando se llega a la etapa de

construcción ya se tiene armado un diseño que hace muy fácil el desarrollo del mismo,

incluso con algunas herramientas es posible después del diseño generar gran parte del

software, siempre y cuando se haya diseñado correctamente.

Control y seguimiento al sistemaControl y seguimiento al sistemaControl y seguimiento al sistemaControl y seguimiento al sistema

El apoyo documental sobre el proyecto, como los planes de trabajo, minutas, diagramas,

entre otros, hacen que se tenga un control del proyecto absoluto, y a su vez podemos

darle seguimiento sobre el avance del mismo en cualquier momento, esto es muy útil

cuando se preparan juntas para presentar avances del proyecto.

86

Minimizar GastosMinimizar GastosMinimizar GastosMinimizar Gastos

Las metodologías nos muestran la ruta a seguir y nos permiten tener la visibilidad de lo

que viene, y con ello podemos planear ciertas actividades, de manera que podemos

disminuir gastos como por ejemplo en re-trabajos, o tiempos muertos.

Reducir RiesgosReducir RiesgosReducir RiesgosReducir Riesgos

Dado que las metodologías permiten ver mas allá, se pueden vislumbrar los riesgos con la

suficiente anticipación para disiparlos. En algunas metodologías que desarrollan los

procesos iterativamente, tenemos la ventaja de que cuando se presenta algún riesgo este

no afecte considerablemente el proyecto.

Conocimiento de negocio y relConocimiento de negocio y relConocimiento de negocio y relConocimiento de negocio y relación con usuariosación con usuariosación con usuariosación con usuarios

Las metodologías marcan un momento en el que hay que conocer el negocio, cuales son

sus características del proceso, sus riesgos, puntos a mejorar y objetivos del proyecto

entre otros, esto nos permite tener un amplio conocimiento de diversas áreas de negocio

entre diferentes empresas, facilitando la propuesta de nuevas soluciones, esto va de la

mano con la relación que se tiene con los usuarios que nos permiten conocer como

funciona el negocio.

Definen roles y perfilesDefinen roles y perfilesDefinen roles y perfilesDefinen roles y perfiles

Ya que dentro del proyecto intervienen varias personas, tanto del equipo de desarrollo

como los usuarios mismos, es muy importante definir que rol juega cada uno, esto con el

fin de delimitar responsabilidades y evitar ambigüedades.

Maximización de recursos limitados.Maximización de recursos limitados.Maximización de recursos limitados.Maximización de recursos limitados.

Cuando hablamos de recursos limitados estamos hablando principalmente de recursos

humanos y financieros, a través de una metodología garantizamos que los mismos se

están aprovechando al máximo, se evitan gastos innecesarios dada la planeación tanto de

capital como de horas hombre.

EstandarizaciónEstandarizaciónEstandarizaciónEstandarización

El desarrollo del proyecto se lleva a cabo bajo los límites definidos por un estándar, este

nos marca el camino por el que debe pasar el proyecto, y del cual no debemos salirnos, ya

que los estándares son definidos desde la organización así como para el desarrollo de

software.

87

Conjunto de ideas practicas ya probadasConjunto de ideas practicas ya probadasConjunto de ideas practicas ya probadasConjunto de ideas practicas ya probadas

Las metodologías no nacen de la teoría, mas bien nacen de un conjunto de practicas

puestas sobre el papel, estas practicas ya han sido utilizadas y han sido perfeccionadas

dando resultados exitosos a diversos proyectos, es por eso que podemos garantizar que

el proyecto puede llegar a un final exitoso también.

Precisión de cada fasePrecisión de cada fasePrecisión de cada fasePrecisión de cada fase

Cada fase de la metodología tiene sus límites y sus objetivos a alcanzar, con esto

podemos dar una secuencia al desarrollo del proyecto, y la etapa anterior marca la base

para continuar con la siguiente.

3.4 PyMEs que se adaptan a la Guía para el Desarrollo de

Software.

Primero retomaremos un poco el tema de las PyMEs, es difícil catalogar o definir una

PyME, pero en general todas concuerdan que son empresas que funcionan con poco

personal, sus ingresos o utilidades no son tan altas (comparado con una empresa

tradicional), también tiene ventajas, como el moverse mas rápidamente, organizarse más

fácilmente, pueden aprovechar el camino trazado por las grandes compañías, entre otros

beneficios, pero la principal desventaja de una PyME que se dedique al desarrollo de

software, es al inicio de sus operaciones la falta de recursos económicos para poder

adquirir licencias, capacitación, y otros gastos implícitos al desarrollo, hablando de

metodologías de desarrollo encontramos que las que se encuentran en el mercado están

enfocadas a grandes empresas y que por lo tanto no se adapta fácilmente a las PyMEs.

Actualmente existen diversas PyMEs encargadas del desarrollo de productos de software,

empresas que van desde un empleado, donde el mismo es el analista, diseñador,

programador, tester, etc. hasta equipos de trabajo limitados, pero bien definidos, que se

encargan de desempeñar roles de acuerdo a su perfil, esta guía se inicia pensando en

todas esas PyMEs.

Esta guía se adapta a PyMEs que se encargan del desarrollo de software a través de

proyectos, ya que nos presenta un proceso que marca los puntos clave a desarrollar en un

proyecto de software, también los documentos de control que pueden apoyar el proceso y

la secuencia que este debe tener, con el objetivo de generar software de calidad y adquirir

los beneficios que nos dan algunas metodologías marcadas en esta tesis.

88

Cabe mencionar que esta guía también se adapta a empresas donde sus departamentos

de sistemas no cuentan con una metodología o guía para los desarrollos de software, no

importa el tamaño o clasificación de la empresa, sino más bien, factores como cantidad de

gente para el desarrollo de software, también para aquellos departamentos de sistemas

donde la curva de aprendizaje para el desarrollo de software mediante una metodología

es lenta, por ejemplo, algunas empresas grandes tienen departamentos de sistemas

pequeños, los cuales desarrollan proyectos de manera empírica, aquí aplica esta guía, la

cual se adapta a las necesidades de desarrollo para generar software organizado y de

calidad, con pocos recursos, o también para aquellos que nunca han trabajado con una

metodología para sus desarrollos.

Dado que esta guía se basa en la síntesis de una metodología mucho más grande, es muy

fácil entenderla y aplicarla, la simple lectura del documento bastará para poder comenzar

a trabajar con ella y obtener resultados inmediatos.

Esta guía puede ser utilizada por instituciones educativas para llevar a cabo proyectos de

desarrollo de software, considerando que es muy sencilla y los recursos empleados son

pocos, pudiendo ser un primer escalón para comprender el funcionamiento de

metodologías mas complejas.

En resumen, esta guía puede ser utilizada por PyMEs que se dediquen al desarrollo de

proyectos de software, también se puede aplicar para organizaciones donde el

departamento de sistemas desarrolla proyectos de software pero no cuentan con una

metodología para el desarrollo de los mismos, finalmente, también se puede aplicar a

desarrollos académicos o como modelo inicial para entender mejor las metodologías

comerciales y complejas que existen en el mercado .

89

4. Guía para el Desarrollo de Software en las PyMEs.

Con el fin de llevar una correcta administración y documentación en el desarrollo de un

proyecto de Software, se ha elaborado una guía que contiene las etapas y una serie de

formatos que proveerán un control adecuado de estos proyectos, organizados en una

serie de etapas lógicas, roles y artefactos, que en conjunto definen la metodología de

desarrollo de software y permiten visualizar en cualquier momento el estatus del mismo.

Esta guía toma como base teórica el Proceso de Desarrollo Unificado Rational (RUP)105 y

utiliza algunos símbolos definidos en UML, la razón de basarse en RUP es por que se le

considera una gran metodología, se apoya en las mejores prácticas de Ingeniería de

Software, y contempla la administración de grandes proyectos, es decir, RUP es

completamente un modelo a seguir, pero la principal diferencia que esta guía hace es

enfocarse en el pequeño talón de Aquiles que esta metodología posee, la cual consiste en

que la metodología RUP esta enfocada a proyectos grandes, es compleja y requiere de un

gran equipo de trabajo capaz de administrar el proceso en diversas etapas, y para

aquellos proyectos pequeños o limitados en recursos es muy probable que no puedan

cubrirse los costos que implica la dedicación de un equipo de profesionales necesarios.

La simbología UML se considero dada la relación que tiene RUP con UML, sin embargo en

esta guía se apoya en esta simbología solamente para mostrar los procesos en los que se

divide cada fase y las actividades que involucra y no precisamente en la definición de un

sistema.

En resumen, cabe mencionar que esta guía es una versión ligera de una metodología más

amplia, la cual busca que su seguimiento e implantación sea muy practica y sencilla para

quien la ejecuta, pero a su vez sea completa y útil en el ciclo de desarrollo de un sistema,

a continuación veremos cada una de las etapas en las que se compone la guía.

105 “RUP”, http://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational, [Marzo2008]

90

Las etapas en las que se definirá esta guía serán las siguientes:

Grafico 22. Etapas de la Guía de Desarrollo de SoftwareGrafico 22. Etapas de la Guía de Desarrollo de SoftwareGrafico 22. Etapas de la Guía de Desarrollo de SoftwareGrafico 22. Etapas de la Guía de Desarrollo de Software106106106106

106 Syple Technologies. ”Etapas proceso RUP”, http://www.syple.com.au/images/rup.gif, [Primavera2008].

Adm

inistración de Pro

yecto

s

Diseño

Requerimientos de Usuario

Análisis y

Pruebas

Liberación

Ambiente

Administrativo

PlaneaciónArranque y

Ambiente

Modelado de Negocio

Construcción y

Implantación y

91

4.1 Definición de Etapas.

1. Arranque Todo proyecto inicia con una definición del camino a seguir, de las herramientas y

recursos que se tienen y de la definición de la meta a alcanzar, en esta etapa definimos

estos puntos.

Objetivo • Identificar los roles y responsabilidades de los integrantes del equipo de TI que

participarán en el proyecto.

• Comunicar el alcance del proyecto a desarrollar.

Una vez reconocida la existencia de un proyecto, comunicar a todo el equipo de trabajo

de tecnología de información asignado, la necesidad de negocio que será satisfecha, el

producto o servicio que se desarrollará.

Proceso

Definición delproyecto

Reunión deArranque

92

Definición del Definición del Definición del Definición del

prprprproyectooyectooyectooyecto

Presenta el objetivo a cubrir en el nuevo proyecto, los departamentos

involucrados y beneficios que se van a obtener para que todo el

personal de Tecnología de Información involucrado esté comunicado y

en el mismo contexto.

Actividades

Definir en forma clara y breve el objetivo inicial del proyecto.

Notificar lugar, fecha, hora y objetivo de la reunión a todo el personal

del área de Tecnología de Información involucrado en el proyecto.

Reunión de Reunión de Reunión de Reunión de

ArranqueArranqueArranqueArranque

Reunión interna del área de Tecnología de Información para formalizar

el alcance del proyecto, rol y responsabilidad de cada uno de los

participantes en el proyecto.

Actividades

Comunicar y obtener el mismo entendimiento del alcance del proyecto.

Comunicar quien participará en el proyecto, roles y responsabilidades

(personal del área).

Nombrar Líder de Proyecto.

Definir fecha de entrega del plan de trabajo inicial.

93

2. Ambiente Cuando se ha definido las personas que conforman el equipo para trabajar en el proyecto

y el alcance del mismo, es hora de definir que herramientas necesitaremos para lograr el

objetivo pero lo mas importante, cuales serán nuestros artefactos entregables durante el

proyecto.

Objetivo • Establecer los entregables del proyecto.

Esta etapa consiste en identificar los artefactos107 que se deben realizar para el proyecto

en función del tipo de proyecto y asegurar que se cuenten con las herramientas necesarias

para el desarrollo de los mismos.

Proceso

107107107107 Un artefacto es un trabajo producto de un proceso. Las actividades tienen artefactos de entrada y salida. Los artefactos capturan y transportan información a lo largo del proyecto, es considerado como un entregable para usuarios de proyecto o usuarios finales y puede tomar varias formas. Los roles usan los artefactos para realizar actividades que a su vez pueden producir nuevos artefactos.

DefinirArtefactos

Configurar

94

Definir Artefactos Definir Artefactos Definir Artefactos Definir Artefactos

En función del tipo de proyecto a desarrollar, se deben definir las

etapas y artefactos a utilizar.

Actividades

Definir etapas del proyecto.

Definir artefactos - entregables del proyecto.

ConfigurarConfigurarConfigurarConfigurar Solicitar creación de proyecto para depositar la documentación del

mismo así como verificar que todos los integrantes del equipo cuenten

con las herramientas de trabajo y versiones necesarias.

Actividades

Enviar un correo electrónico solicitando la creación de la carpeta que

contendrá la documentación del proyecto.

Enviar un correo electrónico solicitando las herramientas de software

necesarias para el desarrollo del proyecto indicando el nombre del

solicitante, herramienta(s) y versión(es)

95

3. Modelado de Negocio Para poder desarrollar un buen proyecto es necesario primero conocer el negocio, es por

eso que esta etapa de análisis se encuentra al inicio del proyecto, esta etapa es clave por

que permite al equipo conocer como opera actualmente el negocio y se sensibiliza al

equipo de la situación actual.

Objetivo

• Obtener un entendimiento total del proceso de negocio actual en la organización.

• Identificar la problemática actual y oportunidades de implementación.

• Asegurar que todos los participantes del proyecto tengan el mismo conocimiento

del proceso de la organización.

Para poder generar una solución es necesario conocer como funciona el negocioconocer como funciona el negocioconocer como funciona el negocioconocer como funciona el negocio

actualmenteactualmenteactualmenteactualmente, es decir, ver y documentar la operación, identificar quienes son los actores

del proceso, determinar las fronteras del proceso, identificar procesos críticos, que

herramientas utilizan, que información entregan, etc. Es de suma importancia dejar claro

a que proceso de negocio se va a enfocar.

96

Proceso

[ Cambio enel Proceso ]

Reunión deDifusión

Puntos de análisis yEntrevista con Involucrados

RevisarProceso Actual

Documentarproceso actual

ValidarProceso Actual

[ ProcesoAceptado ]

PuntosPendientes

RedefinirRoles

AprobarProceso Actual

AdministrarAlcance

97

Reunión de DifusiónReunión de DifusiónReunión de DifusiónReunión de Difusión A través de una junta con todos los involucrados, usuarios y personal de

TI, se da a conocer el objetivo del proyecto, necesidades a cubrir, tiempo

estimado del proyecto y principales beneficios. Esto permitirá una mejor

comunicación entre las áreas participantes en el proyecto.

Actividades

Identificar todo el personal que va a participar en el proyecto directa o

indirectamente.

Convocar a reunión estableciendo fecha, lugar y horario.

Comunicar en que consiste el proyecto. Presentar beneficios.

Formalizar objetivos

Puntos de Análisis y Puntos de Análisis y Puntos de Análisis y Puntos de Análisis y

Entrevista con Entrevista con Entrevista con Entrevista con

InvolucradosInvolucradosInvolucradosInvolucrados

Se debe ir bosquejando de un nivel general a uno particular como

funciona el negocio, y de ahí tomamos los puntos críticos que se

desconocen, se aplicarán cuestionarios, lista de puntos a aclarar con el

usuario, permitiéndonos conocer mas la operación y el entorno del

negocio a trabajar, el objetivo de estos documentos es llegar con puntos

específicos a ser aclarados con el usuario.

Actividades

Platicar con los involucrados para obtener una visión general del proceso

y las fronteras que se tienen.

Identificar cuales son los procesos críticos y las fronteras que se tienen.

Aplicar cuestionario a involucrado.

Revisar Proceso Revisar Proceso Revisar Proceso Revisar Proceso

Actual Actual Actual Actual

Esta actividad es primordial, se debe obtener en su totalidad la

información del proceso de negocio, para ello se debe tomar como

apoyo la lista de puntos críticos, cuestionarios y todos los documentos

creados anteriormente, es sobre estos puntos donde se debe obtener

mayor información por parte del usuario.

Actividades

Complementar con el usuario la información generada hasta el

momento.

Validar que el proceso descrito en la documentación sea el correcto.

Asegurar el entendimiento del proceso de negocio, tanto por el usuario

como por el equipo de TI.

98

Validar Proceso Validar Proceso Validar Proceso Validar Proceso

ActualActualActualActual

Una vez realizada la entrevista, aplicados los cuestionarios y con la

información recabada en la entrevista , se debe documentar el diagrama

del proceso que se sigue actualmente. Si es necesario describir mayor

detalle, se deberán elaborar sub-diagramas de actividad con todo

aquello que intervenga en el proyecto que se está realizando.

Actividades

Elaborar diagramas de actividades con el detalle de los procesos críticos.

Elaborar documentos descriptivos de los diagramas.

Aprobar Proceso Aprobar Proceso Aprobar Proceso Aprobar Proceso

ActualActualActualActual

Dada la importancia de adquirir un conocimiento claro de la situación

actual del negocio, y de que no existan puntos ambiguos, el paso final

es obtener el visto bueno del usuario sobre el flujo del proceso actual.

Presentar al usuario toda la información generada para que este

determine si es correcta, con base en esta revisión obtendremos nuevas

observaciones, estas se documentan, hasta que finalmente el proceso

sea aprobado por el usuario.

Actividades

Verificar diagramas y descripción de proceso con usuario.

Documentar las observaciones y cambios identificados por el usuario.

Obtener firma de aceptación en diagramas de flujo y documentos de

proceso.

99

Puntos PendientesPuntos PendientesPuntos PendientesPuntos Pendientes Una vez que se ha realizado la revisión con el usuario existen puntos

pendientes por definir se deberán documentar, para que se les de el

seguimiento correspondiente.

Actividades

Capturar en bitácora todas las actividades pendientes (definición,

revisión, etc).

Redefinir RolesRedefinir RolesRedefinir RolesRedefinir Roles Como el proceso ya ha sido aprobado por el usuario, es posible

determinar si está faltando considerar algún involucrado en el proyecto.

Actividades

Actualizar el artefacto lista de involucrados.

Verificar que el cambio se represente en todos los otros artefactos que

se vean impactados por la inclusión del nuevo rol.

Administrar AlcanceAdministrar AlcanceAdministrar AlcanceAdministrar Alcance Asegurar las actividades y los entregables del proyecto, éstos deben ser

formalmente aceptados por el usuario, su modificación debe ser

cuidadosamente controlada y reflejada en los planes de trabajo

correspondientes.

Actividades

Evaluar el avance del proyecto y si todas las actividades están reflejadas

en la planeación de no ser así actualizar el plan de trabajo

correspondiente y documentarlo en la bitácora de asuntos.

100

4. Requerimientos de Usuario Para esta fase ya conocemos como opera el proceso con el cual trabajaremos, y ahora

viene la parte de identificar lo que nuestro cliente o usuario requiere, puede ser una

mejora, actualización o un desarrollo completamente nuevo que resuelva una

problemática.

Objetivo • Proporcionar un mejor entendimiento de las necesidades de usuario.

• Establecer y mantener un acuerdo con el involucrado sobre lo que el sistema debe

hacer.

• Identificar las fronteras del sistema.

• Identificar las interfases con otros sistemas, desde el punto de vista del usuario.

En esta etapa se documenta la necesidad o requerimiento del usuario, esté deberá estar

muy bien delimitado, se debe tener muy claro el objetivo, requerimiento o necesidad del

proyecto. Como resultado obtendremos un documento con la lista de requerimientos.

101

Proceso

EntrevistaUsuarios

Necesidades deUsuario

[ VoBoRequerimientos ]

[ RequerimientosIncorrecto ]

Tipificarnecesidad

ValidarRequerimiento

AdministrarAlcance

102

Entrevista UsEntrevista UsEntrevista UsEntrevista Usuariosuariosuariosuarios Platica con el usuario (operativo, jefaturas, gerencias, presidencias,

etc.) para identificar todas las necesidades que el usuario pueda tener,

ya sean del sistema, cambio en operación, infraestructura, etc. Para

obtener la lista de lo que se debe hacer desde la perspectiva de los

involucrados. Algunas técnicas a aplicar son:

• Visitas con usuarios en sitio.

• Reunión con usuarios para lluvia de ideas.

• Aplicar cuestionarios.

• Solicitar al usuario lista de “carta a Santa Claus”.

Actividades

Identificar la técnica a aplicar para el levantamiento de requerimientos

de usuario.

Llevar a cabo el levantamiento de requerimientos

Necesidades de Necesidades de Necesidades de Necesidades de

UsuarioUsuarioUsuarioUsuario

Una vez realizadas las entrevistas, encuestas, etc. Se debe documentar

la información identificada. Todos los requerimientos aquí descritos

deberán ser claros y precisos para que cualquier persona pueda

entender la necesidad, evitando cualquier tipo de ambigüedad en la

redacción de los mismos, estos se convertirán en diferentes objetivos a

cubrir a lo largo del desarrollo del proyecto.

Actividades

Documentar todos los requerimientos de usuario.

103

Validar Validar Validar Validar

RequerimientoRequerimientoRequerimientoRequerimiento

Asegurar que las necesidades identificadas son correctas, una vez

realizado el documento de lista de requerimientos se deberá acudir

nuevamente con el usuario para que éste apruebe la documentación

generada.

Actividades

Validar todos los requerimientos de usuario.

Tipificar NecesidadTipificar NecesidadTipificar NecesidadTipificar Necesidad

Identificar el requerimiento del usuario de que tipo es, es decir, si es

un requerimiento de hardware, de software, cambio operativo, de

comunicaciones, de sistema, nuevas adquisiciones, comunicación entre

departamentos, etc. Es muy importante clasificar todas las necesidades

para definir quienes serán los responsables de las mismas

Actividades

Asignar un tipo a todos los requerimientos de usuario.

Administrar AlcanceAdministrar AlcanceAdministrar AlcanceAdministrar Alcance Asegurar las actividades y los entregables del proyecto, éstos deben

ser formalmente aceptados por el usuario, su modificación debe ser


correspondientes.

Actividades

Evaluar el avance del proyecto y verificar que todas las actividades

estén reflejadas en la planeación, de no ser así, actualizar el plan de

trabajo correspondiente y documentarlo en la bitácora de asuntos.

104

5. Análisis En esta etapa ya conocemos como opera el proceso y ademas conocemos el requerimiento

de nuestro usuario, ahora toca llevar a cabo ese análisis para determinar como dar

solución al problema.

Objetivo • Evaluar la viabilidad de requerimientos.

• Realizar análisis técnico.

• Asignar funciones al software, hardware, involucrados, bases de datos y otros

elementos del sistema.

• Crear una definición inicial del sistema que sea la base para todo el trabajo

posterior de ingeniería.

Definir el objetivo de un sistema es parte esencial del análisis ya que éste determinará las

áreas de acción del sistema y la interrelación que existe con otros sistemas. Para poder

definirlo de una forma más fácil, es necesario preguntarse ¿qué es lo que se quiere cubrir

con el sistema? ó ¿qué es lo que el sistema va a hacer?

En esta etapa se identifican todos los elementos que deben considerarse para bosquejar

soluciones a las problemáticas de negocio identificadas, ya sea en operación, reglas de

negocio, sistema, tecnológicos, capacitación, etc.

105

Proceso

RealizarAnálisis

ElaborarProceso Nuevo

AdministrarAlcance

[ VoBo Proceso ][ Problema Proceso ]

LevantarInformación

Evaluar Reglasde Negocio y

Requerimientos

ValidarProceso Nuevo

AdministrarAlcance

106

Realizar AnálisisRealizar AnálisisRealizar AnálisisRealizar Análisis Una vez que se ha adquirido el conocimiento del proceso y la

identificación de los requerimientos de usuario, estos deberán ser

revisados uno a uno para establecer reglas de negocio, políticas,

infraestructura, necesidades de sistema, etc., es decir, identificar todo lo

que se debe establecer para que el requerimiento sea atendido. Esto

dará como resultado la lista de requerimientos de sistema que se deben

desarrollar, los cambios en la operación que se deben realizar, nuevas

adquisiciones, capacitaciones y cuales requerimientos no son viables de

atender. En caso de que no sean validos, se deberá justificar el por que.

Actividades

Identificar los objetivos de negocio para el proceso que se está

analizando.

Identificar todas aquellas declaraciones, políticas o condiciones que se

deben cumplir (reglas de negocio).

Levantar InformaciónLevantar InformaciónLevantar InformaciónLevantar Información Esta etapa permite al analista del sistema conocer mejor el entorno y el

ambiente de trabajo del usuario. Asimismo le permite conocer a detalle

el ó los procesos, en otras palabras “hablar el mismo idioma” del usuario

solicitante.

Actividades

La participación activa del usuario y la retroalimentación con el analista

proveerá de información relevante:

• Ejemplos de cálculos o procesos

• Formatos de impresión

• Papeles de trabajo

• Impresiones finales

Elaborar Proceso Elaborar Proceso Elaborar Proceso Elaborar Proceso

NuevoNuevoNuevoNuevo

Es necesario definir el nuevo flujo del proceso, para ello se deberá

elaborar un diagrama que muestre como va a funcionar la operación en

conjunto con el sistema, este flujo se debe validar contra las reglas de

negocio.

Actividades

Elaborar el nuevo diagrama operativo, el cual provee de información

gráfica sobre la interacción de los diferentes elementos involucrados en

el proceso, y de como fluye la información entre ellos, esta información

grafica deberá entenderla nuestro usuario, con el objeto de permitir que

tanto el usuario como el analista entiendan y establezcan el contexto del

sistema.

107

Documentar todas las validaciones que delimitan nuestro desarrollo así

como las reglas que debemos tomar en cuenta para el desarrollo del

sistema.

Elaborar el documento descriptivo que acompaña al flujo del proceso, en

el cual se detalla cada una de las actividades.

Administrar Administrar Administrar Administrar

AlcanceAlcanceAlcanceAlcance

Asegurar las actividades y los entregables del proyecto, éstos deben ser



correspondientes.

Un entregable es un resultado medible y tangible que el área de sistemas

de información se compromete a desarrollar. Para definirlo es necesario

preguntarse ¿hasta dónde va a cubrir el sistema? ó ¿qué es lo que el

sistema va a cubrir cuando se encuentre funcionando?

Actividades




Validar Proceso Validar Proceso Validar Proceso Validar Proceso

NuevoNuevoNuevoNuevo

Para continuar con el proyecto es necesario que los documentos del

Proceso Nuevo y Procedimiento Nuevo cuenten con las firmas de

autorización correspondientes. En caso de existir observaciones que

estén fuera del alcance de los puntos anteriormente definidos, se

documentarán en la bitácora.

Actividades

Obtener el visto bueno del usuario sobre la validación de que el proceso

propuesto con el nuevo sistema cubre todo lo que se necesita tanto para

su operación como para la información que se entrega.

Evaluar Reglas de Evaluar Reglas de Evaluar Reglas de Evaluar Reglas de

Negocio y Negocio y Negocio y Negocio y

RequerimientosRequerimientosRequerimientosRequerimientos

Asegurar que en el proceso y procedimiento nuevo, se estén

considerando todas las reglas de negocio y requerimientos de usuario

identificados en procesos anteriores.

Actividades

Analizar que se cumplan todos los requerimientos de usuario viables y las

reglas de negocio en el proceso y procedimiento nuevo.

108




correspondientes.

Actividades

Evaluar el avance del proyecto y verificar que todas las actividades estén

reflejadas en la planeación, de no ser así actualizar el plan de trabajo


109

6. Diseño. Esta etapa le da un toque técnico a la solución, es decir, ya tenemos un análisis que nos

marca que es lo que se busca pero falta aterrizar la solución con la visión técnica.

Objetivo • Transformar los requerimientos en un diseño de lo que el sistema debe hacer.

• Establecer una arquitectura robusta para el sistema

• Construir prototipos o modelos que representen físicamente la nueva operación

desde el diseño de la Base de Datos hasta las interfaces.

El diseño es una parte importante del ciclo de vida de un sistema y deben tomarse en

cuenta todos los procedimientos y reglas que se deben cumplir para que éste sea lo más

flexible posible y cubra todas las necesidades del usuario analizadas previamente.

La participación y retroalimentación por parte del usuario será determinante para el éxito

del proyecto, ya que él conoce reglas de negocio y la metodología de los procesos de

negocio involucrados en el sistema.

Proceso

Diseñar Sistema

ElaborarPrototipo

[ VoBo Prototipo ]

[ ProblemaPrototipo ]

AdministrarAlcance

ValidarPrototipo

110

Diseñar SistemaDiseñar SistemaDiseñar SistemaDiseñar Sistema El propósito de esta actividad es traducir los requerimientos de alto nivel de

usuario, requerimientos, necesidades, etc. En lo que el sistema debe hacer para

cumplirlos.

Actividades

Obtener una propuesta de sistema inicial de lo que el sistema debe hacer.

El storyboard108 podrá ser validado por el usuario.

Generar la información necesaria para garantizar que la Base de Datos del

sistema sea integra y confiable.

Elaborar Elaborar Elaborar Elaborar

PrototipoPrototipoPrototipoPrototipo Esta actividad consiste en construir el modelo físico que será presentado al

usuario con la finalidad de que valide si lo que se construirá es lo que el usuario

realmente necesita.

Los prototipos trataremos que sean de tipo evolutivo, lo cual nos debe de servir

para la etapa de desarrollo, con esto evitaremos la recaptura de diseño.

Actividades

La participación activa del usuario y la retroalimentación con el analista proveerá

de información relevante

Validar PrototipoValidar PrototipoValidar PrototipoValidar Prototipo Una vez elaborado el prototipo del sistema, será revisado por el usuario responsable para determinar posibles omisiones, como resultado de esta

revisión se realizarán las correcciones necesarias volviéndose a presentar al

usuario responsable hasta que esté de acuerdo y firme de conformidad.

Una vez aprobado el prototipo del sistema por parte del usuario, servirá como

base para la programación del nuevo sistema.

Actividades

Obtener la aprobación del usuario del prototipo diseñado.


AlcanceAlcanceAlcanceAlcance Asegurar las actividades y los entregables del proyecto, éstos deben ser

formalmente aceptado por el usuario, su modificación debe ser cuidadosamente

controlada y reflejada en los planes de trabajo correspondientes.

Actividades

Evaluar el avance del proyecto y si todas las actividades están reflejadas en la

planeación de no ser así actualizar el plan de trabajo correspondiente y

documentarlo en la bitácora de asuntos. 108 Storyboard, secuencia de ilustraciones mostradas en secuencia con el objetivo de servir de guía para entender un proceso.

111

7. Construcción Definido ya el diseño, la construcción se basa en poner en marcha ese diseño, es decir,

arrancar los desarrollos o configuraciones necesarias para que funcione nuestra solucion

tal y como se planeo.

Objetivo • Transformar los elementos de diseño en elementos de implementación (código

fuente).

• Definir la organización y estandarización del código

• Realizar prueba unitarias

En esta etapa se toma toda la información de la etapa de Diseño y se inicia la construcción

del código de los procesos definidos y la Base de datos, se aplican algoritmos, y otras

formulas, se deben realizar pruebas unitarias por el programador hasta que se tiene

completo el desarrollo.

Proceso.

RealizarProgramación

Realizar PruebasUnitarias

[ VoBoPruebas ]

[ ProblemaPruebas ]

AdministrarAlcance

112

Realizar Realizar Realizar Realizar

ProgramaciónProgramaciónProgramaciónProgramación

La construcción consiste en la versión operacional del sistema o de una

parte del sistema, que presente el subconjunto de funcionalidad de la

aplicación.

Al generar el código se debe alinear al documento de estándares

definidos para el desarrollo del mismo, la documentación de los

procesos se hace dentro del código a través de comentarios.

Se tienen que registrar los cambios a los programas actuales, los

programas nuevos y las relaciones que existen en la bases de datos.

Actividades

Documentar el código fuente.

Documentar la programación realizada.

Realizar Pruebas Realizar Pruebas Realizar Pruebas Realizar Pruebas

UnitariUnitariUnitariUnitariasasasas

Tomando como base una matriz de pruebas, deberán ser revisadas una

por una las funciones y opciones del sistema, detectando si existe algún

tipo de problema para documentarla, también en este documento se

deberán describir las observaciones pertinentes que se encontraron en

el sistema.

Actividades

Realizar matriz de pruebas.




correspondientes.

Actividades




113

8. Implantación Esta es una etapa de integración, cuando se tiene todo el desarrollo listo se arma cada

una de las partes para llevar a cabo las pruebas integrales.

Objetivo • Preparar las pruebas integrales de la aplicación.

• Preparar e integrar los elementos necesarios para la liberación de la aplicación.

Esta etapa se enfocada integrar lo necesario para que las pruebas integrales, paralelo y

liberación se realicen sin ningún problema de datos, conocimiento de proceso o

aplicación.

Proceso.

IdentificarRoles

Elaborar ManualUsuario

ImpartirCapacitación Tester

RealizarMigración

AdministrarAlcance

114

Identificar RolesIdentificar RolesIdentificar RolesIdentificar Roles

Con base en las características de cada usuario para la operación del

sistema, es necesario definirlos, y por cada uno también definir su

seguridad dentro del sistema, estos roles y sus permisos deberán ser

documentados en una matriz.

Actividades

Realizar matriz de perfiles/roles.

Elaborar Manual de Elaborar Manual de Elaborar Manual de Elaborar Manual de

UsuarioUsuarioUsuarioUsuario Generar los manuales de usuario de acuerdo a los Roles

Actividades

Elaborar manuales de usuario.

Impartir Capacitación Impartir Capacitación Impartir Capacitación Impartir Capacitación

TesterTesterTesterTester

Con los manuales y con el flujo general el tester(probador) deberá de

conocer el sistema completamente.

Actividades

Capacitar a tester.

Realizar MigraciónRealizar MigraciónRealizar MigraciónRealizar Migración La migración de datos del sistema es el comienzo del aprovechamiento

del nuevo sistema. Incluye la transferencia de información desde el

origen hasta las tablas del nuevo sistema. La información a transferir

puede involucrar desde catálogos hasta archivos transaccionales y

estadísticos.

Aún cuando se haya seguido un adecuado análisis y diseño, en muchas

ocasiones la nueva aplicación puede sustituir a uno o varios sistemas, y

la información puede estar almacenada en diferentes medios y

ubicaciones (hoja de cálculo, procesador de palabras, AS/400, etc.)

La migración de datos contempla la identificación de los medios de

almacenamiento existentes, el análisis de la información, la definición y

construcción de procesos de transferencias y ejecución de los mismos.

Actividades

Poblar la base de datos del nuevo sistema con información almacenada

electrónicamente por las herramientas utilizadas hasta antes de esta

instalación.

Identificar la información destino y origen, considerando que ésta

puede estar almacenada en diferentes medios y con diferentes

115

estructuras, es decir asegurar la información que conformará el destino,

como la información origen, considerando que ésta puede estar

almacenada en diferentes medios y con diferentes estructuras.

Una vez conocido el formato y ubicación se determina el tipo de

proceso que se va a ejecutar para poder incorporar la información al

destino (File Transfer, Programa de Transferencia, SQL, etc.)

Una vez identificadas las fuentes de información y llenado el formato

para el mapeo de información, se debe analizar la estructura de la

información origen y compararla con la estructura de las tablas destino.

Identificación de la formación de campos destino a partir de los datos

origen.

Verificar si los tipos de datos son compatibles para poder realizar

exitosamente la transferencia. En caso contrario se analizará si la

información puede hacerse compatible mediante algún proceso.

Verificar si es posible almacenar la información origen en los nuevos

campos sin que se pierda total o parcialmente, y en caso contrario se

deberá revisar con el usuario

Se debe contemplar el llenado de lo campos destino en los que no se

tenga la posibilidad de extraer la información origen. Este análisis se

deberá llevar de manera conjunta con el usuario, definiendo los valores

que contendrán dichos campos, pudiendo ser nulo, valor por omisión

del tipo de dato ó valor asignado como resultado de una operación o

una constante.

Elaborar un plan de transferencia en el que deberá definir con el usuario

los procesos que se van a realizar para llevar a cabo la migración de

datos, la frecuencia con la que se deberán ejecutar dichos procesos de

migración, incluyendo la hora en la que se ejecutarán, así como los

requerimientos tanto por parte del área de TI, como del usuario, para

llevar a cabo dichas transferencias(desactivar triggers (disparadores),

que ningún usuario ingrese al sistema durante la ejecución de los

procesos, limpiar determinados archivos antes de correr el proceso, que

la transferencia no sea interrumpida por otro proceso, etc.).

Una vez transferida la información se debe revisar con el usuario para

verificar que la información generada sea la requerida. Cabe mencionar

que en este paso puede haber diversas modificaciones en la

116

programación de los procesos de migración dado que es muy común

que exista información inconsistente en los campos origen.


AlcanceAlcanceAlcanceAlcance Asegurar las actividades y los entregables del proyecto, éstos deben ser



correspondientes.

Actividades




117

9. Pruebas En todo proyecto existe una etapa de calidad a la cual llamamos pruebas, en ella se

desarrollan diversos tipos de pruebas para verificar que la aplicación cumpla para lo que

fue diseñada y además con la funcionalidad básica de cualquier desarrollo de software.

Objetivo • Encontrar defectos en la calidad de la aplicación.

• Advertir sobre la calidad con la que se está entregando el producto.

• Validar que la aplicación funciona conforme la especificación de diseño aprobada

por el usuario.

• Validar que los requerimientos se han implementado correctamente.

Una vez que se ha terminado de desarrollar la aplicación y preparado el ambiente en la

implementación, sigue la fase de pruebas integrales, en la etapa de construcción se

realizaron pruebas unitarias, es por eso que en esta etapa es necesario que otra persona

se encargue de esta actividad, esta persona deberá conocer cual es el proceso y dedicarse

a asumir cada uno de los roles que se encuentran dentro de ese proceso, así como

detectar las fallas tanto técnicas como operacionales e irlas documentando.

Las pruebas del Sistema aseguran el correcto funcionamiento del mismo. En esta fase se

prueba la integración de cada módulo del Sistema, se buscan las diferencias entre el

sistema y su objetivo general. Esta tarea es pretende asegurar que el sistema cubre los

requerimientos. Durante la fase de las pruebas del Sistema se deben identificar que

pruebas corresponden a personal de sistemas, cuales al usuario y cuales se deberán

realizar en conjunto.

118

Proceso.

Entradade Datos

Procesos

[ VoBoPruebas ]

[ ProblemaPruebas ]

Salidas

IntegridadReferencial

Concurrencia

Estándares

Validar Pruebas

Valores

119

Entrada de DatosEntrada de DatosEntrada de DatosEntrada de Datos En esta prueba se determina si el ingreso de datos cumple con las

especificaciones del diseño. En las pruebas de entrada de datos, se

debe verificar que el tipo y longitud de dato satisfagan las necesidades

del usuario, además se deben revisar todas las validaciones de los

campos de entrada, por ejemplo, al teclear un dato de catalogo que no

exista, intentar crear un registro incompleto, dar de alta una cotización

con un proveedor que no exista, etc.

El usuario también debe revisar las reglas de negocio definidas durante

la fase de diseño, por ejemplo, los tiempos de entrega no pueden ser

negativos, que la fecha de la requisición sea menor a la del pedido, que

la cantidad pedida no exceda a la cantidad requerida, etc.

Actividades

Realizar pruebas de entrada de datos del sistema.

ProcesosProcesosProcesosProcesos La prueba de los procesos consiste en verificar que se haga lo que se

debe hacer, es decir que éstos se ejecuten de manera correcta,

cumpliendo con el objetivo mismo del proceso. La revisión consiste en

que las afectaciones a la base de datos se lleven de manera correcta.

Al igual que las entradas, también se deberá revisar que se cumplan las

reglas de negocio definidas, por ejemplo, para el cálculo de la nómina,

se debe descontar el o los días a aquellos empleados que tengan faltas.

En este punto es muy importante identificar las posibles afectaciones a

otros sistemas.

Actividades

Realizar prueba de procesos del sistema.

SalidasSalidasSalidasSalidas Una prueba substancial de las salidas no involucra otra cosa que la

visualización de todos los reportes y pantallas del sistema para

determinar si se satisfacen las necesidades de información de los

usuarios.

Las pruebas incluyen la verificación de encabezados correctos,

cantidades editadas, supresión de ceros iniciales, signos de pesos,

secuencia correcta de numero de página, indicadores claros de fin de

reporte, fechas correctas, etc. tomando en cuenta que se hayan seguido

120

los estándares definidos.

Actividades

Realizar prueba de todas las salidas del sistema.

Integridad Integridad Integridad Integridad

ReferencialReferencialReferencialReferencial Verificar la correcta afectación a las tablas correspondientes a una

operación determinada (inserción, modificación, borrado).

En las pruebas de integridad referencial, se deberá indicar si se están

cumpliendo o no las reglas de negocio.

Actividades

Realizar prueba de Integridad Referencial.

ValoresValoresValoresValores Esta prueba consiste en verificar que la información almacenada en los

campos corresponda al universo de valores asignados a dicho campo.

Por ejemplo, si el universo de valores para un campo es “S” o “N”, se

deberá verificar que mediante la utilización del sistema dicho campo no

permita la captura de ningún otro carácter diferente a los señalados.

Actividades

Realizar prueba de valores de sistema.

ConcurrenciaConcurrenciaConcurrenciaConcurrencia Esta prueba permite conocer de manera real los tiempos de proceso

para cada una de las aplicaciones que se están revisando y es posible

determinar si existen problemas de bloqueo de registros entre

diferentes usuarios.

Existen tiempos críticos en muchos sistemas, particularmente en los

sistemas transaccionales. Para llevar a cabo estas pruebas es necesario

que varios usuarios accedan al mismo tiempo el mismo programa y se

lleven a cabo las mismas operaciones de crear, modificar, borrar, etc.,

por ejemplo, en el sistema de compras interesa saber que pasaría si

todos los usuarios habilitados quisieran dar de alta solicitudes de

compras al mismo tiempo.

Actividades

Realizar prueba de concurrencia del sistema.

121

EstándaresEstándaresEstándaresEstándares Esta actividad se lleva a cabo por personal de TI (tester), consiste en

verificar que el sistema esté desarrollado siguiendo las políticas de

estandarización definidas.

Actividades

Asegurar que el sistema se apega a los estándares definidos por TI para

la organización.

Validar PruebasValidar PruebasValidar PruebasValidar Pruebas Esta actividad consiste obtener el visto bueno formal por parte del líder

de proyecto de que se han cubierto las pruebas requeridas por el

proyecto.

Actividades

Obtener la firma de aceptación del proceso de pruebas.

122

10. Liberación Ultima etapa de nuestra guia, después de un exhaustivo proceso de pruebas y con el visto

bueno del equipo que se encargo de las pruebas del desarrollo podemos pasar a definir

todo aquello para dejar en productivo nuestro desarrollo.

Objetivo • Integrar todos los componentes requeridos para que la aplicación sea utilizada por

el usuario final.

Finalmente, cuando el tester aprueba el sistema y no existen mas observaciones, se

genera un plan de liberación con el fin de que el sistema se ponga en marcha.

123

Proceso

PrepararLiberación

ReuniónComunicación TI

[ VoBoParalelo ]

[ ProblemaParalelo ]

Asignar Roles

PrepararCapacitación

PasarProducción

PrepararParalelo

Término Paralelo

124

Preparar LiberaciónPreparar LiberaciónPreparar LiberaciónPreparar Liberación A través de una herramienta como Microsoft Project109 hacemos un

plan de las actividades y fechas para liberar el sistema.

Actividades

Realizar plan de trabajo de liberación del sistema considerando las

siguientes actividades.

Reunión de Reunión de Reunión de Reunión de

Comunicación TIComunicación TIComunicación TIComunicación TI Mostrar de manera general a las Jefaturas y Gerencias involucradas el

resultado del proyecto, el objetivo es que conozcan el trabajo hecho

por el área de TI.

Actividades

Comunicar el alcance cubierto del sistema.

Asignar Roles Asignar Roles Asignar Roles Asignar Roles

Obtener una lista final de los usuarios y clasificarlos en los roles que

asumirán al momento de liberar el sistema, esta lista será una guía

para generar los grupos de capacitación y para configurar el sistema.

Actividades

Asignar roles/ usuarios de aplicación.

Preparar CapacitaciónPreparar CapacitaciónPreparar CapacitaciónPreparar Capacitación Definir los grupos a capacitar siguiendo las políticas del área de capacitación y llenando la lista de asistencia el día de la capacitación,

posteriormente la lista de personas que tomaron la capacitación nos

servirá como evidencia de quienes si asistieron y quienes no.

Actividades

Notificar al departamento de Capacitación.

Pasar a ProducciónPasar a ProducciónPasar a ProducciónPasar a Producción Se definirá una fecha para pasar todos los programas a Producción,

generar todo el ambiente para que pueda funcionar el sistema

apoyándonos en el documento que contenga la relación de los

programas modificados y/o creados, este será nuestra guía para

realizar esta actividad. También se tendrá que configurar los perfiles

de los usuarios con base a los roles definidos.

Actividades

Solicitar al área de Operación la instalación de la aplicación en el 109 “Microsoft Project es un programa de la suite de Microsoft Office usado para la gestión de proyectos”, http://es.wikipedia.org/wiki/Microsoft_Project, [25Noviembre2008]

125

equipo de producción.

Se deberá notificar cuando la instalación se haya concluido.

Preparar ParaleloPreparar ParaleloPreparar ParaleloPreparar Paralelo Cuando todo el sistema este listo para operar, realizar el paralelo, el

cual consiste en continuar con la operación normal y además llevar el

nuevo proceso el cual se apoya del nuevo sistema, la duración de este

paralelo no debe excederse ya que durante este tiempo el usuario esta

haciendo doble trabajo. En caso de que existan errores se resolverán

de inmediato. En caso de ser observaciones o mejoras, deberán ser

analizadas y se les dará la atención correspondiente dependiendo del

caso ya que a veces serán mejoras que no entran dentro de el alcance

inicial y pudieran ser desarrolladas en una versión posterior.

Actividades

Analizar si en función del plan de liberación se puede llevar a cabo el

Paralelo del Sistema.

Evaluar el funcionamiento del sistema vs. la operación real de los

usuarios.

Término de ParaleloTérmino de ParaleloTérmino de ParaleloTérmino de Paralelo

Como ultimo paso después de estabilizar el paralelo debemos retirar la

operación anterior y solo dejar la nueva operación que se apoya con el

nuevo sistema. La fecha del liberación se deberá definir en

conjunto con el usuario estableciendo cuando se empezará a trabajar

solamente con el nuevo sistema.

Actividades

Definir fecha de liberación.

126

0. Administración de Proyectos La administración del proyecto se lleva a cabo durante todo el proceso de esta guía, es

una etapa de control que permite identificar puntos críticos, llevar un plan y dejar

registrado todos aquellos pendientes que surgen durante el desarrollo del mismo.

Objetivo • Anticiparse a todo aquello que ponga en riesgo el proyecto

• Administrar tiempo y recurso para el proyecto

• Proporcionar una guía para planear, ejecutar y monitorear el proyecto

Esta etapa debe estar presente a lo largo del proyecto y todos los artefactos generados se

deberán actualizar durante el ciclo de vida de desarrollo.

Proceso

ElaborarLista deRiesgos

ElaborarPlanesTrabajo

AdministrarBitácoraAsuntos

127

Elaborar Lista de Elaborar Lista de Elaborar Lista de Elaborar Lista de

RiesgosRiesgosRiesgosRiesgos Elaborar una lista con todos aquellos elementos que puedan poner en

riesgo la conclusión exitosa del proyecto, tales como problemas

operativos, capacitación, entendimiento de usuario, resistencia al

cambio, tecnológicos, huelga, falta de compromiso de usuario, etc. Este

artefacto nos permite identificarlos para ver de que manera se mitigan

(disminuye el riesgo) o se elimina.

Actividades

Identificar Riesgos.

Elaborar Plan de Elaborar Plan de Elaborar Plan de Elaborar Plan de

TrabajoTrabajoTrabajoTrabajo Para cada una de las etapas del proyecto se deberá elaborar un plan de

trabajo que presente las actividades a realizar dentro de cada una de

estas.

Los planes se deberán actualizar semanalmente y no deberán contener

actividades mayores a 6 meses, en caso de ser así separar el plan para

que los entregables sean a menor plazo.

Con el fin de interpretar mejor el plan de trabajo e identificar las

actividades del proyecto se ha establecido un estándar de colores el

cual se muestra a continuación.

Finalmente se deberá elaborar el plan general de todo el proyecto, con

ligas a los planes de trabajo por etapa.

128

Actividades

Establecer los puntos de revisión del proyecto.

Establecer las reuniones de comunicación que se deberán llevar a cabo

a lo largo del proyecto.

Se recomienda que los planes de trabajo sean revisados por el Líder de

Proyecto de la siguiente manera:

Rol Fecha

Usuario Fechas establecidas en conjunto.

Coordinador Fechas establecidas en conjunto.

Jefatura de Unidad Quincenalmente.

Gerencia de Sistemas Quincenalmente o Por demanda

Administrar Bitácora Administrar Bitácora Administrar Bitácora Administrar Bitácora

de Asuntosde Asuntosde Asuntosde Asuntos Dar seguimiento a todos los asuntos que se generen durante el

transcurso del proyecto. El líder de proyecto deberá administrar esta

bitácora así como apoyarse en el Coordinador, Jefatura de Unidad y

Gerencia de Sistemas para resolver aquellos pendientes que se

presenten a lo largo del desarrollo.

Actividades

Mantener el seguimiento de todos los asuntos que se presenten a lo

largo del proyecto.

129

4.2 Resumen de Etapas.

A continuación veremos una tabla con la descripción de cada etapa y el objetivo de las

mismas.

Nombre Descripción Objetivo Arranque Comunica a todo el equipo de tecnología de

información sobre el trabajo asignado, la necesidad de negocio que será satisfecha, o el producto/servicio que se desarrollará.

• Identificar los roles y responsabilidades de los integrantes del equipo de TI110 que participarán en el proyecto

• Comunicar el alcance del proyecto a desarrollar.

Ambiente Identifica los artefactos que se entregarán durante el ciclo de vida del proyecto, con el fin de asegurar que se cuenten con las herramientas necesarias para el desarrollo de los mismos

• Definir las etapas del proyecto. • Establecer los entregables del

proyecto.

Modelado de Negocio Obtiene pleno conocimiento del proceso de negocio actual, por lo tanto se deberá ver y documentar la operación, identificar quienes son los actores del proceso, determinar las fronteras del proceso, identificar procesos críticos, que herramientas utilizan, que información entregan, etc.

• Obtener un entendimiento total del proceso de negocio actual en la organización

• Identificar la problemática actual y oportunidades de implementación.

• Asegurar que todos los participantes del proyecto tengan el mismo conocimiento del proceso de la organización.

Requerimientos Documenta la necesidad o requerimiento de viva voz de todos y cada uno de los usuarios que intervienen en el proceso, se debe obtener el documento que incluya todo lo que el usuario necesite.

• Proporcionar un mejor entendimiento de las necesidades de usuario

• Establecer y mantener un acuerdo con el involucrado de lo que el sistema debe hacer.

• La necesidad queda documentada Análisis Identifica todos los elementos que se deben

considerar para diseñar la mejor solución a las problemáticas o necesidades de negocio identificadas, ya sea en operación, reglas de negocio, sistema, tecnológicos, capacitación, etc.

• Evaluar viabilidad de requerimientos • Realizar análisis técnico • Asignar funciones al software,

hardware, involucrados, bases de datos y otros elementos del sistema

• Crear una definición inicial del sistema que sea la base para todo el trabajo posterior de ingeniería

• Encontrar las fronteras del sistema.

110 Tecnologías de Información

130

Diseño Traduce los requerimientos de usuario en funcionalidades de sistema, identifica cambios operativos, define nuevos procesos, define capacitación requerida, etc. Es decir presenta la solución de negocio con todo lo que esta requiere. El diseño debe ser totalmente flexible y cubrir todas las necesidades del usuario analizadas previamente.

• Transformar los requerimientos en un diseño de lo que el sistema debe hacer

• Establecer una arquitectura robusta para el sistema

• Construir prototipos o modelos que representen físicamente la nueva operación desde las interfaces hasta el diseño de la Base de Datos.

Construcción Desarrollo del código de las interfaces, procesos, reportes, base de datos, algoritmos, etc. Se implementan todos los elementos descritos en el diseño.

• Transformar los elementos de diseño en elementos de implementación (código fuente)

• Definir la organización y estandarización del código

• Realizar prueba unitarias

Implantación Prepara el ambiente para que las pruebas integrales, se puedan llevar a cabo sin ningún problema.

• Preparar las pruebas integrales de la aplicación

• Preparar e integrar los elementos necesarios para la liberación de la aplicación.

Pruebas Asegura el correcto funcionamiento de todo el s istema, se buscan las diferencias entre el sistema y los objetivos. Se debe identificar que pruebas corresponden a personal de sistemas, cuales al usuario y cuales se deberán realizar en conjunto.

• Encontrar defectos en la calidad de la aplicación

• Advertir sobre la calidad con la que se está entregando el producto

• Validar que la aplicación funciona conforme la especificación de diseño aprobada por el usuario

• Validar que los requerimientos se han implementado correctamente.

Liberación Integra todos los componentes requeridos para la liberación del sistema desde personal, capacitación, hardware, software, etc.

• Integrar todos los componentes requeridos para que la aplicación sea utilizada en un ambiente de producción por el usuario final.

Administración de Proyectos

Esta etapa debe estar presente a lo largo del proyecto y todos los artefactos generados se deberán actualizar durante el ciclo de vida de desarrollo.

• Anticiparse a todo aquello que ponga en riesgo el proyecto

• Administrar tiempo y recurso para el proyecto

• Proporcionar una guía para planear, ejecutar y monitorear el proyecto

Tabla 15 – Definición General de Etapas. Fuente: Elaboración Propia

131

5. Caso Práctico En este capitulo se mostrará la guía enfocada a un proyecto y apoyada por diversos

formatos que se generaron para controlar cada una de las etapas, con el fin de que se

visualice la aplicación práctica de esta guía.

Cabe mencionar que el proyecto es ficticio, al igual que los nombres, imágenes y logos

utilizados y que los formatos aquí mostrados son simplemente los sugeridos para el

desarrollo de un proyecto, pudiéndose crear mas artefactos o eliminando alguno de

acuerdo a las necesidades del proyecto.

El objetivo de este caso practico es mostrar de manera simple como se tendría que

desarrollar cada una de las etapas, así como los documentos propuestos para llevar a

cabo el control y entregables del proyecto, sin embargo esta guía no obliga a utilizar

exactamente los formatos tal como se muestran.

132

5.1. Implementación de la guía en una PYME.

1. Arranque En esta etapa inicial, el equipo encargado del proyecto presenta a la organización el

proyecto, a las personas involucradas en el mismo, se da difusión del alcance y objetivos

buscados, así como las responsabilidades de los mismos, haciendo mucho énfasis en los

beneficios que se obtendrán al finalizar el proyecto.

El equipo programa una reunión con usuarios claves y se apoya de presentación y

documento de definición del proyecto.

FmtdefProyecto

A través de un documento como el que se presenta a continuación, se hace la difusión en

una junta inicial del proyecto, como podemos ver se detalla el objetivo del proyecto, se

mencionan las áreas estarán involucradas, las personas involucradas y los principales

beneficios que trae consigo el proyecto, el tipo de proyecto identifica si se trata de un

desarrollo local o corporativo, y en la parte inferior se tiene una sección de firmas que

queda abierta a los principales responsables del proyecto.

Definición del proyecto

Fecha de Elaboración 22 Febrero 2009

Tipo de proyecto: Local 1. Objetivo del proyecto Manejar la información principal de las entidades principales relacionadas con la compañía así como de particulares para poder mantener una mejor comunicación interna y tomar las decisiones correctas de atención que en su momento se requieran. Las entidades principales relacionadas con la compañía son: Compañías, Personas y Vehículos. La información principal según sea el caso debe de cubrir:

• Identificación de la entidad. • Medios de comunicación. • Documentos. • Fechas importantes para las entidades. • Contactos. • Observaciones médicas.

Se necesita de una aplicación que permita la consulta a la misma información con la gestión correspondiente para todos los empleados de la compañía. 2. Áreas involucradas Aplica para todas las áreas departamentales que deseen tener y consultar información de las entidades requeridas y permitidas. 3. Principales involucrados

Involucrados Departamento Unidad de negocio Rol Lic. Arturo Medrano Gerencia General TE Usuario, Administrador CP Omar Chavez Contabilidad TE Usuario CP Oscar Toledano Contabilidad TE Usuario

4. Principales beneficios

• Consulta de Información principal de la entidad.

133

• Atención requerida a los contactos personales y de la compañía. • Gestión de documentos relacionados con la compañía. • Recordatorios de fechas al cumplirse el vencimiento o el recordatorio. • Acceso a la información principal de la entidad. • Consulta restringida a la información de entidades por usuario. • Responsabilidad de gestión de entidades por usuario. • Eliminar las consultas manuales a expedientes y archivo, sustituyéndola por consultas en tiempo real • Establecer una base de información para todos los departamentos de Compañías, Personas y

Vehículos. Jefe de Unidad Gerencia Sistemas: Asignado a: Firma Firma

Firma

Grafico 23. Definición del ProyectoGrafico 23. Definición del ProyectoGrafico 23. Definición del ProyectoGrafico 23. Definición del Proyecto

2. Ambiente En esta etapa el equipo define todos aquellos entregables para el proyecto, con el objetivo

de que los usuarios cuenten con las herramientas necesarias para la ejecución de las

tareas asignadas, como por ejemplo herramientas Office, correo electrónico, entre otras.

El equipo solicita la creación de una carpeta para depositar toda la documentación del

mismo, también solicita que todos los integrantes del equipo cuenten con las

herramientas de trabajo necesarias así como las versiones correctas.

La solicitud de estas herramientas se hace a través de un correo electrónico dirigido al

área correspondiente de tecnología de información.

Para identificar los artefactos que se entregaran en cada etapa del proyecto el equipo

utiliza en siguiente formato:

FmtEtapasyArtefactos

Este “check list” fue creado por el equipo para definir los entregables del proyecto o

artefactos que se planean desarrollar durante el proyecto, con el fin de ir marcando cuales

ya se han generado y entregado. El check incluye el nombre del artefacto (plantilla), la

etapa del proceso en la cual se tienen, el nombre del artefacto como se manejara en

nuestro proyecto, un check box que indica si se ocupara para este proyecto y finalmente

un porcentaje de avance del documento.

134

Grafico 24. Etapas y ArtefactosGrafico 24. Etapas y ArtefactosGrafico 24. Etapas y ArtefactosGrafico 24. Etapas y Artefactos

3. Modelado de Negocio En esta etapa el equipo requiere conocer el proceso completamente, para ello se basa en

diversos artefactos que ayudaran para esta tarea, a continuación describimos cada uno de

los utilizados por el equipo.

FmtCuestionario

A través de una entrevista apoyada de un cuestionario podemos obtener gran parte del

modelado de negocio, además podemos identificar quienes son los actores principales del

proceso y las actividades que desempeñan en el mismo.

El formato del Cuestionario definido por el equipo como podrá verse es abierto, lo

importante es el contenido de las preguntas, deberán ser claras.

135

Si es necesario el entrevistador se puede apoyar de grabadoras, sin embargo, es

importante notificar esto al entrevistado antes de iniciar la entrevista para obtener su visto

bueno.

Cuestionario

Fecha de Elaboración

1. Establecer Perfiles de Involucrado o Usuario

a. Nombre. b. Compañía / Industria. c. Cargo. d. Principales responsabilidades. e. ¿Cuáles son sus principales entregables? y ¿Para quién? f. ¿Cómo se mide el éxito en sus resultados? g. ¿Qué problemas (carácter o índole) interfieren con su éxito? h. ¿Que puede hacer su trabajo más fácil o más difícil?

2. Determinación del Problema a. ¿Cuáles son los problemas que interfieren con su operación? b. ¿Para cuales problemas (tipo de aplicación) se carece de buenas soluciones? c. ¿Cuáles son ellos? ¿porque? ¿causas?

3. Para cada problema anterior: a. ¿Porqué existe este problema? b. ¿Cómo se resuelve actualmente? c. ¿Cómo le gustaría resolverlo?

4. Entender el Ambiente de Usuario a. ¿Cuál es su nivel académico? b. ¿Cuál es su nivel en computadoras? (Nociones – Principiante – Medio – Avanzado – Experto). c. ¿Qué experiencia con aplicaciones software tiene? ¿Qué otras aplicaciones utiliza y si se requiere alguna interfase/vinculo con ellas? ¿Cuáles son las expectativas de utilidad con el producto a entregar? ¿Cuáles son las expectativas de capacitación? ¿Qué clase de documentación en línea usted necesita?

5. Determinando su Solución (si aplica) a. ¿Qué haría si usted podría dar la solución? [propuesta] ¿Cómo? ¿Cuándo? ¿Porqué? ... b. ¿Cómo usted organizaría la prioridad de éstos? Otros Requerimientos a. ¿Cuáles son, si existen, los requerimientos regulatorios, de ambiente o estándares que deban ser soportados? b . ¿Puede haber cualquier otro requerimiento que nosotros necesitemos conocer?

6. Involucrando a. ¿Existe alguna otro comentario u observación?

Grafico 25. CuestionarioGrafico 25. CuestionarioGrafico 25. CuestionarioGrafico 25. Cuestionario

136

FmtPuntosCriticos

En este momento el equipo ha detectado puntos críticos del proceso actual, el equipo

elabora un formato para identificar los puntos que hay que profundizar, el objetivo del

mismo es dejarlos plasmados y darle seguimiento para entender en su totalidad el

proceso.

Puntos Críticos

Fecha de Elaboración

• No hay procedimientos concretos de operación establecidos con información organizada

para el giro del negocio. Documentos Porte

• La Remisión-Carta Porte es el documento principal por el cual se generan los documentos. • Proceso origen para generar seguimiento de documentos por egresos por Caja Chica y

Caja General-Dirección. • Se necesita conocer la disponibilidad de Recursos ( Operador – Equipo de Transporte )

para realizar la Proyección de Viajes para emitir los Documentos Porte en grupo o individual.

• La Unidad de Negocio se encarga de cumplir con la asignación de fletes y tener disponibles los recursos principales para los fletes. Otras Unidades de Negocio del Grupo que la dirigen realizan la Logística. La Logística del negocio depende de:

Causa Unidad Relación El movimiento uniforme del negocio TRANSPA Transportista Logística Gerencia Planta MODELO Cliente Logística Jefe Producto Terminado MODELO Cliente Logística Director Investigación y Desarrollo MODELO Cliente Gerente General TRANSPA Transportista Mecánico TRANSPA Transportista

• Los vales deben ser controlados por folios únicos con la facilidad para relacionar con las Remisiones-Carta Porte.

• Todos y cada uno de los documentos llevan el número de Remisión-Carta Porte. • La Proyección de Viajes (Programa Diario) debe ser autorizada por Gerencia. • El Vale por Viáticos es firmado por el operador y lo deja al Vigilante al momento de recibir

los Documentos de Porte. • El resto de Vales son firmados por el operador al momento de recibir el servicio por el

proveedor respectivo: Combustible y Peajes. Además firma el comprobante del movimiento o transacción del proveedor.

• El operador no puede salir de viaje si no tiene documentos elaborados para viaje. • Vigilancia entrega Documentos de Porte y concilia entrega por viáticos. • Caja Chica (Gerencia) deposita efectivo para viáticos hasta que entrega la remesa de

Documentos Porte Remisor.

Grafico 26. Puntos CríticosGrafico 26. Puntos CríticosGrafico 26. Puntos CríticosGrafico 26. Puntos Críticos

137

FmtlstInvolucrados Durante el modelado el equipo de trabajo tiene interacción con usuarios de otras áreas

del negocio (involucrados), para tener una referencia se genera una relación de los

mismos con su información para futuras referencias.

El formato consta de la Unidad de Negocio a la cual pertenece (UN), el nombre, su

departamento, el puesto, clasificación del usuario con base en la interacción con el

proceso, nivel de conocimiento del negocio, extensión telefónica, las responsabilidades

del proceso actual y el nombre del perfil que tiene en el proceso.

Este control será utilizado en una etapa posterior para la definición de perfiles.

Grafico 27. Lista de InvGrafico 27. Lista de InvGrafico 27. Lista de InvGrafico 27. Lista de Involucradosolucradosolucradosolucrados

138

FmtPreDifusion El equipo propone desarrollar una presentación en la cual se muestre de manera general

en lo que consistirá el proyecto, con esta presentación los involucrados estarán enterados

del desarrollo del proyecto y de la participación que ellos tendrán en el mismo. Esta

presentación es abierta pero con un formato ejecutivo.

Grafico 28. Presentación de DifusiónGrafico 28. Presentación de DifusiónGrafico 28. Presentación de DifusiónGrafico 28. Presentación de Difusión

139

FmtProcedimientoActual Ya que el equipo detecta como se lleva a cabo el proceso actual, es necesario plasmarlo,

para ello nos apoyamos del procedimiento. Este formato describe el proceso actual del

negocio, y podríamos decir que es el entregable principal del modelado de negocio, aquí

se describe el proceso a detalle, las actividades y los actores involucrados.

El documento se divide por procesos y subprocesos, y dentro de los mismos se manejan

dos columnas, una indicando el rol o puesto que ejecuta la acción, y en la segunda

columna tenemos la acción ordenada en puntos secuenciales. DESARROLLO Control de Viajes.

Tráfico 4.1.1 Realiza un Control de Viajes del área registrando la información en Excel. Nota: Archivo de Excel para control de viajes llamado “Maniobras semanal”. Léase procedimiento TR-TI-001-1, en referencias externas.

Mantenimiento 4.1.2 Revisa “Fallas de Unidades” y registra movimientos en Bitácora. Nota: Archivo de Excel para bitácora de mantenimientos “MES-9999”.

Gerencia (Tráfico) 4.1.3 Indica las “Faltas de Operadores”. Nota: Se utiliza el mismo archivo para Control de Viajes.

Documentos Porte

Tráfico

Tráfico

Gerencia (Tráfico) Tráfico

Gerencia-Tráfico

Vigilancia

4.2.1 Realiza una Programación de Viajes en Excel. Nota: Archivo de Excel para Programación de Viajes llamado “Tráfico Diario”. Léase procedimiento TR-TI-001-2, en referencias externas.

4.2.2 Imprime la hoja de “Programa Diario”. Nota: Hoja impresa de archivo de Excel “Tráfico Diario”.

4.2.3 Autoriza hoja de “Programa Diario”. 4.2.4 Realiza los cambios si son requeridos. 4.2.5 Imprime de hojas anexas de archivo “Tráfico Diario” las Bitácoras, Comprobante de

Gastos por Maniobras, Tickets y Vales. Nota: Léase procedimiento TR-TI-001-3, en referencias externas.

4.2.6 Registra y genera las Remisiones Carta Porte en Liquidaciones 400. Nota: Léase procedimiento TR-TI-001-4, en referencias externas.

4.2.7 Imprime las Remisiones Carta Porte y anexa Documentos Tráfico Diario Excel. 4.2.8 Anexa Gastos por Maniobras predeterminados por ruta. 4.2.9 Si es el caso introduce los Documentos Porte y el dinero en efectivo por cada

Remisión Carta Porte en sobres tamaño carta. 4.2.10 Si es el caso avisa a Vigilancia para apoyar en la oficina para “Hacer los Sobres”. 4.2.11 Si es el caso introduce los Documentos Porte y el dinero en efectivo por cada

Remisión Carta Porte en sobres tamaño carta.

Grafico 29. Procedimiento ActualGrafico 29. Procedimiento ActualGrafico 29. Procedimiento ActualGrafico 29. Procedimiento Actual

140

FmtProcesoActual Acompañando al procedimiento tenemos el documento de proceso, aquí se muestra de

manera grafica las actividades vistas en el modelado, a través de un diagrama de flujo

usando una simbología establecida para diagramas de flujo, y utilizando en este proyecto

la herramienta Visio111 de Microsoft.

Grafico 30. Proceso ActualGrafico 30. Proceso ActualGrafico 30. Proceso ActualGrafico 30. Proceso Actual

111 “Microsoft Visio es un software de dibujo vectorial para Microsoft Windows”, http://es.wikipedia.org/wiki/Microsoft_Visio, [Agosto2009]

141

4 Requerimientos de Usuario

En esta etapa el equipo desarrolla diversas técnicas para obtener los requerimientos del

usuario (libre elección del analista), algunas técnicas utilizadas son las siguientes:

• Lluvia de Ideas

• Cuestionario

• Visita en Sitio

El resultado de estas técnicas de las cuales se obtuvieron los requerimientos son

plasmados en el siguiente formato:

FmtlstRequerimientos Aquí muestra la Unidad de Negocio (UN), la etapa, un folio consecutivo, descripción del

requerimiento, solicitante del requerimiento, el responsable de atender el requerimiento,

la fecha de registro, extensión del solicitante, algún comentarios, la solución al

requerimiento y el porcentaje de avance.

Con este control podemos llevar el avance de los requerimientos así como los avances que

se tienen.

Grafico 31. Requerimientos de UsuarioGrafico 31. Requerimientos de UsuarioGrafico 31. Requerimientos de UsuarioGrafico 31. Requerimientos de Usuario

142

5 Análisis

En esta etapa el equipo cuenta con la información obtenida del Modelado de Negocio, se

revisa la información obtenida, se analizar como esta operando actualmente el negocio y

se hace un análisis completo de la problemática.

El equipo con estos insumos genera un proceso y procedimiento nuevo, así como las

reglas de negocio que acompañan a estos, y que mejoran o dan solución al proceso con la

problemática actual.

Nuevamente hacemos uso de los documentos de Procedimiento y Proceso, los cuales

fueron definidos en la etapa de Modelado.

FmtProcedimientoNuevo Aquí el equipo desarrolla el nuevo proceso detallado que propone como solución a la

problemática actual, indica las actividades de manera secuencial y los responsables de las

mismas. DESARROLLO 4.1Requerimiento. Persona Interna o

Externa 4.1.4 Requiere los datos de Personas, Compañías y/o vehículos para su gestión

personal o para la atención correspondiente según sea la responsabilidad de su

área.

4.1.5 En caso de no tener acceso a la información del sistema debe solicitar el

requerimiento de información al administrativo correspondiente para obtener

la información requerida.

4.1.6 Realiza el requerimiento directamente con el área administrativa o lo puede

hacer mediante un mensaje por Lotus Notes.

4.1.7 En caso de tener acceso a la información del sistema puede realizar la gestión

requerida de forma personal según la autorización dada.

4.1.8 En caso de ser autorizado el acceso a Gestión en la aplicación de sistemas

Directorio, recibirá un mensaje por correo electrónico mediante Lotus Notes

y un mensaje del sistema.

4.1.9 En caso de no ser rechazado su requerimiento puede recibir un reporte

impreso con la información solicitada del administrativo.

4.2 Gestión Sistema Persona Interna o

Externa 4.2.12 Determina la operación a realizar en la aplicación de sistemas Directorio para

la gestión de datos.

Datos de ... Personas Compañías Vehículos Múltiple?

Identificación X X X

Documentos X X X X

Fechas de interés X X X X

Domicilio X X

Medios de comunicación X X X

143

Contactos X X X

Observaciones médicas X X

Posición laboral X X

4.2.13 Consulta/Actualiza el archivo Personas, Compañías y/o Vehículos con la

siguientes condiciones:

No se pueden modificar

a) Los datos principales de personas empleadas en TRAPRU, solo desde

Nómina.

b) Los datos principales de compañías clasificadas como Proveedores, solo

desde Compras.

c) Los datos principales de compañías clasificadas como Clientes, solo desde

Facturación.

d) Los datos principales de vehículos, solo desde *Transporte.

4.2.14 Realiza la consulta, actualización o impresión del archivo para la persona

solicitada

Grafico 32. Procedimiento NuevoGrafico 32. Procedimiento NuevoGrafico 32. Procedimiento NuevoGrafico 32. Procedimiento Nuevo

FmtProcesoNuevo Representación grafica del procedimiento nuevo, indicando los roles y actividades,

apoyados con una simbología basada en diagramas de flujo.

Grafico 33. Proceso NuevoGrafico 33. Proceso NuevoGrafico 33. Proceso NuevoGrafico 33. Proceso Nuevo

144

FmtReglasNegocio Para que el proceso funcione debe estar apoyado con las Reglas del Negocio, para ello se

van definiendo como se vayan detectando durante el desarrollo del proyecto.

El equipo define el siguiente formato que se compone de la Unidad de Negocio (UN), la

etapa donde se levanto la Regla de Negocio, un folio y un identificador, la Descripción de

la Regla, quien solicita la regla, el responsable, la fecha en que se registro, la extensión

del responsable de la regla y algún comentario que se desee agregar.

Grafico 34. Reglas de NegocioGrafico 34. Reglas de NegocioGrafico 34. Reglas de NegocioGrafico 34. Reglas de Negocio

145

6 Diseño

El equipo hasta esta etapa cuenta ya con un proceso nuevo, ahora trabajaremos en el

diseño del mismo, desde los formatos que servirán para las salidas, reportes, consultas,

interfases, reglas de integridad, diagramas entidad relación, diccionario de datos,

prototipo, entre otros.

FmtConsultas En este documento se plasma la definición de las consultas que requerirá el nuevo

proceso, contiene campos como quien elabora (siglas de la persona), una Consulta

Muestra indica si es que se tomo alguna referencia y se pone la ruta donde se encuentra

la misma, la Funcionalidad de la Consulta describe para que nos servirá la consulta, a que

tablas deberá acceder esta consulta y los campos que compondrán la consulta con su

respectiva definición como descripción de campo, tamaño, tipo, alias, etc.

Consultas

Fecha de Elaboración Emisión Por demanda

ELABORÓ

CONSULTA MUESTRA

FUNCIONALIDAD DE LA CONSULTA Presenta la información de los datos de las personas guardados en el directorio, incluye datos de personas de la compañía.

TABLAS DE LA CONSULTA FILEDIR03 y FILEDIR05 FILENOM

DESCRIPCIÓN DE CAMPOSDESCRIPCIÓN DE CAMPOSDESCRIPCIÓN DE CAMPOSDESCRIPCIÓN DE CAMPOS ALIAS NOMBRE CAMPO DESCRIPCIÓN TIPO DE DATO TAMAÑO VALOR

Nomina – Datos Personales NUMEMP Número de empleado 6,0 APAEMP Apellido paterno 20 AMAEMP Apellido materno 20 NOMEMP Nombre(s) 20 DIRECC Dirección 30 NOEXT Número exterior 5 NOINT Número interior 5 CALLE1 Entre la calle 20 CALLE2 Y la calle 20 COLONI Colonia 30 CODPOS Código postal 5,0 SEXO Sexo 1 ESTATU Estatura (metros) 5,2

146

PESO Peso (Kilogramos) 3,0 FECNAC Fecha de nacimiento 8,0 ECIVIL Estado civil 1 FECMAT Fecha de matrimonio civil 8,0 CNACIO Nacionalidad 3 NUMDEP Número de departamento 2,0

Grafico 35. ConsultasGrafico 35. ConsultasGrafico 35. ConsultasGrafico 35. Consultas FmtDiagramaER Es necesario representar el diseño de la base de datos que se manejara en el desarrollo,

para ello el equipo se basa en un diagrama entidad relación, el cual contiene las tablas

utilizadas, sus campos, llaves primarias, foráneas y las relaciones entre las tablas (uno a

uno, uno a muchos, etc).

Grafico 36. Diagrama Entidad RelaciónGrafico 36. Diagrama Entidad RelaciónGrafico 36. Diagrama Entidad RelaciónGrafico 36. Diagrama Entidad Relación

147

FmtDiccionarioDatos Para recabar toda la información que se define en las tablas utilizadas el equipo crea un

Diccionario de Datos, el cual contiene un identificador si el campo es llave, el nombre del

campo, la descripción del campo, el tipo de dato (carácter, numérico, etc) su longitud,

decimales, si es de entrada obligatoria, si es una llave foránea indicar cual es la tabla a la

que hace referencia y el campo del cual se hizo referencia.

Grafico 37. Diccionario de DatosGrafico 37. Diccionario de DatosGrafico 37. Diccionario de DatosGrafico 37. Diccionario de Datos

FmtlstSalidas Aquí el equipo define las salidas del proceso, indicando la Unidad de Negocio (UN), el

nombre del campo para la salida, tipo de importancia de la salida (prioridad), el

departamento solicitante, en que etapa del proyecto se llevara a cabo la ejecución, algún

formato en particular y la descripción de la salida.

Lista De Salidas

Fecha de Elaboración 30 enero 2006

Información General

UN Nombre Tipo Depto. Etapa Formato Descripción TE Compañías Detalle-Resumen 1 TE 1 TE Personas Detalle-Resumen 1 TE 1 TE Vehículos Detalle-Resumen 1 TE 1 TE Personas 2 TE 1 TE Personas 3 TE 1 Nomina

Además se realizará la conexión con catálogos de Nomina y Compras para datos como:

UN Nombre Tipo Depto. Etapa Formato Descripción TE Ubicaciones o Lugares 3 TE 1 Conexión con Compras TE Puesto 3 TE 1 Conexión con Nomina TE Departamento 3 TE 1 Conexión con Nomina TE Profesión 3 TE 1 Conexión con Nomina TE Nacionalidad 3 TE 1 Conexión con Nomina

Grafico 38. Lista de SalidasGrafico 38. Lista de SalidasGrafico 38. Lista de SalidasGrafico 38. Lista de Salidas

148

FmtPrototipo Para que los usuarios puedan palpar el entregable que se desea el equipo desarrolla los

prototipos, en ellos indican como se vera la aplicación, y con esto podemos obtener

observaciones mas especificas hechas por el usuario o el visto bueno del diseño.

El equipo desarrolla el prototipo en una herramienta Office.

• Funcionalidad

Integra la información de las personas internas y externas relacionadas con la compañía actual para la cual

se esta haciendo uso de la aplicación por el modulo de Directorio. Proveedores, Clientes, Circulo de

Servicio, de Servicios, Gobierno y Otras, además de las compañías del Grupo o Corporativo a donde

pertenece la compañía actual. Para el ejemplo de la imagen anterior la compañía actual es Transportes

Prueba. La finalidad es tener claro donde se localiza a una persona, los medios de comunicación que posee,

fechas de la persona que permitan recordarse a través de un e-mail y los contactos que se tienen con cada

persona.

Grafico 39. PrototipoGrafico 39. PrototipoGrafico 39. PrototipoGrafico 39. Prototipo

NSIXXXXXXX TRANSPORTES PRUEBAS, S.A. DE C.V. 2006/02/16 MDIR02 TRANSPORTE 11:37:07 ___________............................................................________ : Personas : Seleccione : : : Selecciona criterio : 1. Co : Número para persona ______ de ______ (Rango) F4=Lista : 2. Pe : Compañía ______ de ______ (Rango) F4=Lista : 3. Ve : Apellido paterno PI*_________________ : 4. Do : Apellido materno ____________________ : 5. Do : Nombre(s) ____________________ : 6. Me : Trato _____ F4=Lista : 7. Me : Abreviatura ____________________ : 8. Fe : Sexo _ (M=Masculino, F=Femenino) : 9. Fe : Puesto _____ F4=Lista : : Departamento/Area _____ F4=Lista : : Profesión _____ F4=Lista : : Origen de datos _ F4=Lista : : Atención _ F4=Lista : : Estado de registro _ (A o _=Activo, B=Baja) : Selección : : ===> _____ : Intro=Continuar F3=Salir : _______ F3=Salir :..........................................................:

149

FmtReportes Como el proceso requiere de reportes es necesario contar con la definición de los

mismos, para ello crea el siguiente formato el cual se compone de la persona que elabora,

si se obtuvo de otro reporte (Reporte Muestra), la funcionalidad que se busca del reporte,

tablas que se requieren para el reporte, la descripción de los campos que se presentaran,

la definición de algún criterio de selección y de ordenamiento (definición de campos), los

parámetros para el filtro, consideración especiales y finalmente los totales requeridos.

Reportes

Fecha de Elaboración Emisión

ELABORÓELABORÓELABORÓELABORÓ

REPORTE MUESTRAREPORTE MUESTRAREPORTE MUESTRAREPORTE MUESTRA

FFFFUNCIONALIDAD DEL REPORTEUNCIONALIDAD DEL REPORTEUNCIONALIDAD DEL REPORTEUNCIONALIDAD DEL REPORTE Emite un reporte por detalle y/o resumen de los datos de las compañías.

TABLAS DEL REPORTE ALIAS.MIEMBROTABLAS DEL REPORTE ALIAS.MIEMBROTABLAS DEL REPORTE ALIAS.MIEMBROTABLAS DEL REPORTE ALIAS.MIEMBRO FDIR del 1, 2, 9, 12, 18, 19, 24, 28 unimiembro, del Directorio

DESCRIPCIÓN DE CAMPOSDESCRIPCIÓN DE CAMPOSDESCRIPCIÓN DE CAMPOSDESCRIPCIÓN DE CAMPOS * Ver fmtDiccionarioDatos-TRADirectorio.xls, solo se hace referencia a las tablas ALIAS NOMBRE CAMPO DESCRIPCIÓN TIPO DE DATO TAMAÑO VALOR

FDIR01 Compañías FDIR02 Compañías Domicilio FDIR09 Documentos de Compañías FDIR12 Comunicación de Compañías FDIR18 Fechas de Compañías FDIR19 Avisos de Fechas por Medios Compañías FDIR24 Contactos de Compañías FDIR28 Catalogo General CRITERIO DE SELECCIÓNCRITERIO DE SELECCIÓNCRITERIO DE SELECCIÓNCRITERIO DE SELECCIÓN Archivo FDIR01, Compañías PRINCIPAL (NUMECO *EQ %RANGE(VarDSP1 VarDSP2)) *AND (NOMBCO *EQ %WLDCRD(VariableDePantalla)) *AND (ABRECO *EQ %WLDCRD(VariableDePantalla)) *AND (CLASCO *EQ %WLDCRD(VariableDePrograma) *AND (PRATCO *EQ “VariableDePantalla”) *AND (ORIRCO *EQ “VariableDePantalla”) *AND (EREG01 *EQ “VariableDePantalla”)

150

CRITERIO DE ORDENAMIENTOCRITERIO DE ORDENAMIENTOCRITERIO DE ORDENAMIENTOCRITERIO DE ORDENAMIENTO

NUMECO Parámetros para el filtroParámetros para el filtroParámetros para el filtroParámetros para el filtro Número de Compañía, numérico de 6,0 posiciones. Nombre, alfanumérico de 20 posiciones. Abreviatura, alfanumérico de 20 posiciones. Clasificación Tipo, alfanumérico, 1 posición. Giro, alfanumérico, 2 posiciones. Grupo, alfanumérico, 1 posición. Origen de datos, alfanumérico de 1 posiciones. Prioridad de atención, alfanumérico de 1 posiciones. Estado de registro, alfanumérico de 1 posiciones. Campos con rangos de seleccionCampos con rangos de seleccionCampos con rangos de seleccionCampos con rangos de seleccion NUMECO, Número de Compañía. CONSIDERACIONES ESPECCONSIDERACIONES ESPECCONSIDERACIONES ESPECCONSIDERACIONES ESPECIALESIALESIALESIALES

Realizar reporte por detalle y por resumen según totales. TOTAL / SUBTOTAL POR ...TOTAL / SUBTOTAL POR ...TOTAL / SUBTOTAL POR ...TOTAL / SUBTOTAL POR ...

1. Por cantidad de compañías. 2. Por clasificación. 3. Por origen de datos. 4. Por prioridad de atención. 5. Por estado de registro.

Grafico 40. ReportesGrafico 40. ReportesGrafico 40. ReportesGrafico 40. Reportes

151

7 Construcción

Ya que se tiene el diseño el equipo inicia con la construcción de la aplicación, esta es la

etapa donde los programadores hacen gala de sus aptitudes para la creación de líneas

de código que den solución a los requerimientos y diseños establecidos.

Los desarrolladores del equipo comienzan el trabajo de desarrollo en el lenguaje de

programación requerido y de los cuales ellos son expertos.

FmtCambiosProgramas Los desarrolladores necesitan ir registrando los nuevos programas y las modificaciones a

los mismos durante el desarrollo del proyecto, para ello crearon el siguiente formato con

el fin de tener el control de las versiones, las fechas, tipos de programas, entre otros.

Para nuestro ejemplo el lenguaje de programación utilizado es RPG112, por ello se ocupan

ciertas columnas propias de los desarrollos en RPG, sin embargo este formato es

adaptable al lenguaje de programación en el que se este desarrollando.

Este documento utilizado por los desarrolladores se compone del modulo u opción

desarrollada, la descripción del desarrollo, la biblioteca donde están todos los archivos del

desarrollo, el tipo de programa generado (DDS (Definición de Pantallas), CL (Programa de

Control),RPG (Programa RPG),PF (Archivo Físico),LF (Archivo Lógico)), las Unidades de

Negocio donde se instala el programa, el programador responsable y algún comentario.

Grafico 41. Cambios a ProgramasGrafico 41. Cambios a ProgramasGrafico 41. Cambios a ProgramasGrafico 41. Cambios a Programas

112 “El lenguaje de programación RPG es un lenguaje de programación desarrollado por IBM en 1964 y diseñado para generar informes comerciales o de negocios. Sus siglas en inglés significan Report Program Generator”, http://es.wikipedia.org/wiki/Lenguaje_de_programaci%C3%B3n_RPG, [Septiembre2009].

152

FmtMatrizPruebas El equipo cuenta con algún elemento encargado de realizar pruebas al desarrollo, para

ello se apoya de esta matriz que sirve de guía para hacer pruebas del proyecto, ya que

pone las opciones que por default deben estar asignadas, así como nuevas y deja de

manifiesto si funciono correctamente la aplicación o fallo.

En este control podemos ver el nombre del sistema, el modulo principal y las opciones y

funciones de las cuales se compone la aplicación, en las siguientes columnas tenemos las

opciones que se consideran estándar a todas las aplicaciones (la “O” indica Opción, la “F”

indica Función) y la columna de Locales marca aquellas funciones y opciones que son

particulares, es decir que no son estándar.

Grafico 42. Matriz PruebasGrafico 42. Matriz PruebasGrafico 42. Matriz PruebasGrafico 42. Matriz Pruebas

8 Implantación

En esta etapa el equipo esta listo para llevar a un ambiente productivo el desarrollo, para

ello tiene que analizar los perfiles que utilizaran los usuarios, los manuales de usuario, y

el proceso de migración del ambiente de desarrollo al ambiente de productivo.

FmtMatrizRoles Anteriormente tuvimos el formato fmtlstInvolucrados, el cual volvemos a utilizar para

asignándoles un perfil de acuerdo a sus actividades que desempeñaran en el nuevo

proceso con la nueva aplicación, esta es una matriz que indica el nombre del perfil, su

descripción y del lado derecho los usuarios que tendrán ese perfil.

Grafico 43. Matriz de RolesGrafico 43. Matriz de RolesGrafico 43. Matriz de RolesGrafico 43. Matriz de Roles

153

FmtManualUsuario La capacitación del usuario es necesaria, para ello el equipo desarrolla los manuales de

usuario. El formato es abierto y se utilizaron imágenes para ser mas específicos al

momento de impartir la capacitación.

Este documento nos ayuda para la capacitación a los diferentes usuarios, así como una

referencia del funcionamiento del programa.

Grafico 44. Manual de UsuarioGrafico 44. Manual de UsuarioGrafico 44. Manual de UsuarioGrafico 44. Manual de Usuario

154

FmtMigracion En este proyecto es necesario migrar de un sistema antiguo a uno nuevo, por lo tanto se

tiene que hacer un proceso de migración de información, para ello el equipo ocupa el

siguiente formato en el cual mapeamos la relación entre las tablas de los sistemas y sus

respectivos campos.

GGGG

rafico 45. Migraciónrafico 45. Migraciónrafico 45. Migraciónrafico 45. Migración

155

9. Pruebas Ahora toca el turno a las pruebas integrales, aquí se manejan escenarios y así como

puntos clave a ser revisados, para ello se elaboran check list y se obtiene una bitácora de

correcciones o mejoras.

FmtChkPruebas Para el equipo es muy importante tener un esquema de lo que se tiene que probar, para

ello desarrolla este check list que le sirve de guía para las pruebas a realizarse y también

para ir marcando las pruebas que se han llevado a cabo (Resp.).

Check-List De Pruebas Fecha de Elaboración / /


Tipo Descripción Resp. 1 Entrada de Datos

1.1 Tipo de datos

1.2 Longitud de datos

1.3 Reglas de Integridad

1.4 Reglas de Negocio

2 Procesos

2.1 Procesos


2.3 Afectaciones a Base de Datos

3 Salidas

3.1 Reportes

3.2 Consultas

3.3 Interfaces/Ligas

3.4 Ligas

4 Integridad Referencial

4.1 Reglas de Integridad


5 Valores


6 Concurrencia

6.1 Tiempo de Proceso

6.2 Bloqueo de registros

156

7 Concurrencia

7.1 Estándares de Programación

8 Ortografía 8.1 Errores de escritura

8.2 Acentos omitidos

Grafico 46. Check List de PruebasGrafico 46. Check List de PruebasGrafico 46. Check List de PruebasGrafico 46. Check List de Pruebas FmtCorreccionesMejoras Después de las pruebas el equipo obtiene observaciones o mejoras, este documento les

ayuda para irlas registrando y darles seguimiento, de esta manera todo se plasma y no se

pierde ninguna observación.

El documento se compone de la opción donde se detecto la falla o la mejora, tipo o

prioridad, la descripción del hallazgo, la ubicación de algún documento de referencia, la

fecha en que se capturo y quien hizo la prueba.

157

La segunda parte del documento se enfoca a la segunda revisión que se hace, y contamos

con las siglas del responsable de la corrección, fecha en que se le asigna, fecha de

entrega del desarrollo corregido, algún comentario u observación, fecha en que se acepta

por la persona que lo revisa, y si es necesaria una segunda revisión.

Grafico 47. Correcciones y MejorasGrafico 47. Correcciones y MejorasGrafico 47. Correcciones y MejorasGrafico 47. Correcciones y Mejoras

158

10. Liberación Finalmente el equipo ha llegado a la parte final del proyecto, después de las exhaustivas

pruebas tenemos un entregable completo, con calidad y que cumple con las

características definidas por nuestro usuario.

Para hacer el entregable es necesario convocar a una reunión donde se presente el

resultado del proyecto, para lo cual el equipo desarrolla una presentación, y se presenta el

plan de liberación que incluye la capacitación y la puesta en marcha. FmtPreDifusion El equipo convoca a una junta donde se presenta el nuevo proceso, y los beneficios que

este desarrollo nos trae. La presentación esta basada en tres puntos principalmente, que

son el objetivo del proyecto, cual es la nueva situación, y los beneficios que este

desarrollo nos trae.

GGGG

rafico 48. Presentación de Difusiónrafico 48. Presentación de Difusiónrafico 48. Presentación de Difusiónrafico 48. Presentación de Difusión

159

FmtPlanLiberacion Quedan un par de tareas pendientes que son el plan de capacitación y la implantación del

software, para ello genera un plan que cubra estas actividades principales y las que se

desprenden de ahí.

Este plan es creado en una herramienta Office.

Grafico 49. Plan de LiberaciónGrafico 49. Plan de LiberaciónGrafico 49. Plan de LiberaciónGrafico 49. Plan de Liberación

160

0. Administración de Proyectos Durante todo el proyecto existe una etapa que se encarga de controlar que todo vaya de

acuerdo a lo planeado, de identificar aquellas situaciones o elementos que puedan ser un

riesgo para el proyecto y un plan general, es en esta etapa inicial donde se define todo

esto, para lo cual se apoya de los siguientes documentos:

FmtListaRiesgos Durante el proyecto, el equipo detecto asuntos que ponían en riesgo al proyecto, sin

importar en que etapa del proyecto nos encontremos, se plasmó en este control para

darle seguimiento y eliminar o minimizar el riesgo anticipadamente.

El documento se compone de la Unidad de Negocio (UN), un folio, tipo en el que se

clasifico el riesgo, probabilidad de que suceda, el impacto que tiene para el desarrollo del

proyecto, que estrategia se recomienda tomar, y cual sería la estrategia a aplicar.

Lista De Riesgos Fecha de Elaboración


UN Folio Tipo Riesgo

Descripción Riesgo Prob. Impacto Tipo Estrategia

Descripción Estrategia

TA 1 Información Que no se le de seguimiento a la primer iteración del refaccionamiento por parte del personal de mantto.

Alto Alto Mitigar Platicar con el administrador del sistema para exponer las situaciones que se generaran al termino de esta primera iteración.

TA 2 Información Que el personal de planta no capture la información que será requerida en forma correcta.

Alto Alto Mitigar Platicar con el administrador del sistema para exponer las situaciones que se generaran al termino de esta primera iteración

Grafico 50. Lista de RiesgosGrafico 50. Lista de RiesgosGrafico 50. Lista de RiesgosGrafico 50. Lista de Riesgos

161

FmtPlanGeneral Durante todo el proyecto el equipo tuvo un plan general, en el cual se encuentra cada una

de las etapas y las fechas compromiso en las que se finalizara cada una, dentro de ellas

vendrán las actividades a detalle, y sirve para darle seguimiento al proyecto, este

documento es la columna vertebral del proyecto ya que aquí se encuentran las fechas

planeadas y las fechas compromiso, cuando el equipo encontraba una desviación tomaba

las medidas necesarias para corregir el camino.

Grafico 51. Plan GeneralGrafico 51. Plan GeneralGrafico 51. Plan GeneralGrafico 51. Plan General

162

FmtBitacoraAsuntos

Durante el desarrollo del proyecto surgieron asuntos que requerían de la participación de

otros involucrados para darle solución, estos asuntos iban desde requerimientos nuevos,

hasta puntos que se deben analizar para futuros desarrollos o proyectos, sin embargo

todos fueron plasmados y considerados a su debido tiempo para darle una solución.

El formato se compone de la Unidad de Negocio (UN), la etapa del proyecto donde se

levanto el punto, un folio de referencia, la descripción del asunto, quien lo solicita o el

interesado, el responsable del equipo que le dará seguimiento, la fecha de registro,

extensión del solicitante, la solución acordada, la fecha en que se le dio solución al asunto

y el estatus de avance.

Grafico 52. Bitácora de AsuntosGrafico 52. Bitácora de AsuntosGrafico 52. Bitácora de AsuntosGrafico 52. Bitácora de Asuntos

163

CONCLUSIONES

La Guía para el Desarrollo de Software en las Pequeñas y Medianas Empresas es un

documento que asesora a una organización que cuenta con recursos limitados a ejecutar

las tareas de generación de software de manera ordenada, y con calidad.

También puede ser utilizada por organizaciones que cuentan con un departamento de

desarrollo de software pequeño que quieran controlar sus proyectos de desarrollo.

Actualmente en nuestro país existen diversas PyMEs, que han sido analizadas y se han

determinado sus características, las cuales diferencian entre una pequeña y una mediana

empresa, también vemos que hay factores que afectan a la competitividad de las PyMEs,

es decir, cuales factores afectan o benefician a las PyMEs en nuestro país y se describen.

La guía fue basada en metodologías mayores que son utilizadas actualmente por grandes

organizaciones, de las cuales se analizaron las etapas que se componen esas grandes

metodologías, se tomaron las más importantes y se sintetizaron de manera que se cuente

con una guía practica, y de fácil uso para desarrollos de software.

Las PyMEs que se dedican al desarrollo de software pueden tomar diversas metodologías y

estándares que se encuentran en el mercado, desafortunadamente son herramientas de

altos costos y que están enfocadas a empresas que tienen ejércitos de personal en sus

áreas de Tecnologías de Información, esto hace que sean difíciles de alcanzar, aun

contando con los recursos económicos pueden llegar a encontrarse con problemas dado

la falta de recursos humanos para desempeñar las tareas que marcan esas metodologías.

Esperamos que este sea de utilidad para todos aquellos proyectos de desarrollo de

software que requieran de un control, seguimiento, orden, claridad y calidad en el cual la

metodología o guía sea entendible y gratuita, considerando los puntos o etapas

principales en el desarrollo de software y marcando claramente los limites y objetivos a

alcanzar, logrando finalmente un producto de software que cumpla con las necesidades

del usuario, con calidad y en los tiempos planeados, y que cuente con la documentación

necesaria para posteriores referencias.

164

BIBLIOGRAFÍA

Impresa:Impresa:Impresa:Impresa: Andersen, Arthur, 1999. “Diccionario de Economía y Negocios”, Editorial ESPASA, España. Méndez, Morales José Silvestre, 1996. “Economía y la Empresa”. Editorial McGraw-Hill, México. Pressman, R. S., 1993 , “Ingeniería del software. Un enfoque practico”, Editorial McGraw-Hill. McCall et al., 1977, “Factor/Criteria/Metrics FCM” ISO/IEC, 1991, “Marco ISO 9126” Basili & Rombach, 1988, “Goal-Question-Metric” Gilb, 1988, “Modelo de Gilb” Tinnirello, Paul C., 11 Mayo 1998, “How's Your IT: Teetering Or Leading-Edge PC Week” Pressman, Roger S., 1998, “Ingeniería de software. Un enfoque práctico”, Editorial McGraw-Hill Interamericana de España. Martín, James, 1994. “Análisis y Diseño Orientado a Objetos”, Editorial Prentice Hispanoamérica, México. Larman, Craig. 1999. “UML y Patrones. Introducción al análisis y diseño orientado a objetos” Editorial Pearson Educación. México. Grady Booch, James Rambaugh, Ivar Jacobson, 1997. “The UML specification documents”, Rational Software Corp. USA. Pender, Thomas A. 2002, “UML Weekend Crash Course”, Editorial: Wiley. Jugdev, K & Thomas, Diciembre 2002, “J. Project Management Maturity Models: The Silver Bullets of Competitive Advantage.”, Editorial Project Management Journal. “Volkswagen coaching Gmbh Project Management in co-operation with: IPMI University of Bremen. Project Management in Germany.” Editorial State&trenes, [2002].

165

Electrónica:Electrónica:Electrónica:Electrónica: “Institut National de la Statistique et des Études Économiques: INSEE”, http://www.insee.fr/en/insee-statistique-publique/default.asp “United States Small Business Administration”, http://www.sba.gov/, [06Julio2008] “Comisión Económica para América Latina y el Caribe”, http://www.eclac.org/, [06Julio2008] “Revista Mexicana de Ejecutivos de Finanzas”, http://ejecutivosdefinanzas.org.mx/, [06Julio2008] “Secretaría de Economía”, http://www.economia.gob.mx/, [06Julio2008] “La importancia de las PyMEs en México y para el mundo”, http://www.gestiopolis.com/canales2/economia/pymmex.htm [06Julio2008] “Secretaría de Economía”, http://www.economia.gob.mx/, [06Julio2008] “Banco Interamericano de Desarrollo”, http://www.iadb.org/?lang=es, [06Julio2008] “Universidad de Bolonia en Argentina”, http://www.ba.unibo.it/BuenosAires/default.htm, [15Julio2008] “Instituto Nacional de Estadística y Geografía”, http://www.inegi.gob.mx/inegi/default.aspx, [15Julio2008] “Observatorio PyME”, http://www.cipi.gob.mx/html/observatorio.html, [15Julio2008]. “Microempresa”, http://es.wikipedia.org/wiki/Microempresa, [15Julio2008] “Formas de Microempresario”, http://es.wikipedia.org/wiki/Microempresa, [15Julio2008] “Ventajas e Inconvenientes de la Microempresa”, http://es.wikipedia.org/wiki/Microempresa, [15Julio2008] “Aceleradora de Negocios”, http://www.economia.gob.mx/?P=7060, [03Agosto2008] “Centro Panamericano de Investigación e Innovación, http://www.cepii.biz/, [13Agosto2008] “Instituto Panamericano de Alta Dirección de Empresa”, http://www.ipade.mx/html/home.html, [20Agosto2008] “La importancia de las PYMES en México y para el mundo”, http://www.gestiopolis.com/canales2/economia/pymmex.htm [06Julio2008] “International Organization for Standardization”, http://www.iso.org/iso/home.htm, [15Julio2008] Fernández & Alarcón, “Necesidades de medicion en la gestión y el aseguramiento de calidad del Software”, http://www.sc.ehu.es/jiwdocoj/remis/docs/aseguracal.htm, [19Octubre2008] “Modelo de Boehm (espiral)”, http://es.wikipedia.org/wiki/Desarrollo_en_espiral, [22Octubre2008] “Modelo de Capacidad y Madurez (Capability Maturity Model), es un modelo de evaluación de los procesos de una organización”, http://es.wikipedia.org/wiki/Modelo_de_Capacidad_y_Madurez, [12 Septiembre2008] “Programa de trabajo para el desarrollo de un estándar internacional para la evaluación de los procesos de software”, http://www.usm.edu.ec/abedini/spice/spicess.htm, [04Octubre2008]

166

“Software Engineering Institute”, http://www.sei.cmu.edu/, [22Octubre2008] “International Organization for Standardization”, http://www.iso.org/iso/home.htm, [15Julio2008] “Normas iso 9000”, http://www.pilar.com.ar/industrias/temasgenerales/normas.htm, [14Noviembre2008] “ISO 9001 Auditing Practices Group Directriz”, http://www.inlac.org/documentos/Uso%20eficaz%20de%20la%20norma%20%20ISO%2019011%20rev.1.pdf, [14Noviembre2008] “ISO 14000 Wikipedia”, http://es.wikipedia.org/wiki/ISO_14000, [14Noviembre2008] “Estrategias de calidad para PYMES de desarrollo de Software”, http://www.monografias.com/trabajos16/calidad-sw-pymes/calidad-sw-pymes.shtml, [23 Agosto2008] “Ingeniería de Software”, http://es.wikipedia.org/wiki/Desarrollo_de_software, [22Diciembre2008]. “Ingeniería de Software”, http://www.monografias.com/trabajos5/inso/inso.shtml, [22Diciembre08] “Ingeniería de Software”, http://es.wikipedia.org/wiki/Desarrollo_de_software, [22Diciembre2008]. “Seminario Administración de Proyectos en Informática”, http://www.amereiaf.org.mx/pdf/seminario_administracion.pdf. [Marzo2008] “RUP”, http://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational, [Marzo2008] “Desarrollo de software Orientado a Objetos usando UML”, Letelier, Patricio. 2002., http://www.dsic.upv.es/~uml/ “Modelado Visual con UML”, http://www.utm.mx/~temas/temas-docs/nfnotas516.pdf, [Marzo2008] “Desarrollo Ágil de Software”, http://es.wikipedia.org/wiki/Desarrollo_%C3%A1gil_de_software, [Marzo2008] “Autoweb”, http://es.wikipedia.org/wiki/Autoweb , [Marzo2008] “DERCAS”, http://es.wikipedia.org/wiki/DERCAS, [Marzo2008] “ISO/IEC 12207”, http://es.wikipedia.org/wiki/ ISO/IEC 12207, [Marzo2008] “Metodología de Booch”, http://es.wikipedia.org/wiki/Metodolog%C3%Ada_de_Booch, [Marzo2008] “Manual de Administración de Proyectos.” http://www.liderdeproyecto.com/manual/que_es_el_pmbok.html, [Primavera2008]. “Programación Extrema o eXtreme Programming”, http://es.wikipedia.org/wiki/Programaci%C3%B3n_Extrema, [Enero2009] “MOPROSOFT”. http://www.comunidadmoprosoft.org.mx/Permanentes/Historiadeunanorma.pdf, [Noviembre2009] “Moprosoft: el nuevo modelo que impondrá una norma mexicana para la calidad en la industria del software”, http://www.iie.org.mx/boletin032003/ind.pdf, [Noviembre2009] ”Etapas proceso RUP”, http://www.syple.com.au/images/rup.gif, [Primavera2008].

167

ANEXO A A continuación se describen los símbolos utilizados para los diagramas de proceso y actividad del presente documento:

Símbolo Descripción

Inicio de un flujo

Representa un conjunto de actividades

Decisión, la condición no se representa en el flujo, solo las alternativas que serepresentan como salidas de alguna de las aristas del rombo.

Fin de un flujo

Actividades que se presentan en paralelo

Conector de actividades




InsertarTexto

Representa una actividad a realizar.

Grupo de actividades

Rol

InsertarTexto

InsertarTexto

InsertarTexto

tesis guia para desarrollo de software en las pymes · 4 agradecimientos a mis padres, por ser...

Documents