VIVAT ACADEMIA N º J U N I O

(1)

(2)

(II) (III)

C I R C U L O D E U S U A R I O S O R A C L E D E E S PA Ñ A

1. INTRODUCCIÓN

La industria de software a nivel mundial está formada en mayor medi-da por micro, pequeña y medianas empresas desarrolladoras de software –PyMEs– que suponen cerca del 90% de los negocios formales y generan entre el 40 y el 50 por ciento del empleo total

Estas empresas de software tienen serios problemas de madurez en sus

procesos de desarrollo y en la mayoría de los casos la operación de sus proce-sos es caótica, lo que afecta a toda la organización[4]. Esta situación es especialmente crítica ya que conlleva problemas asociados como falta de competitividad y consecuentemente limitaciones de crecimiento.

Desde hace varios años la comu-nidad de Ingeniería del Software a nivel mundial ha expresado especial interés en la mejora de procesos

soft-ware –SPI– en PyMEs. Pero sólo recientemente han aparecido están-dares y propuestas relacionadas con SPI para PyMEs, como por ejemplo:

Impact [26], Processus [13], Adept [20], Rapid [8], MoProSoft [21], EvalProSoft [22], MPS.BR [30], Agile SPI [14], Mares [1], MesoPyME [6]

Las PyMEs han intentando ase-gurar la calidad de sus productos

soft-UN ENFOQUE PRAGMATICO PARA

LA MEJORA DE PROCESOS SOFTWARE

EN LAS PYMES

EDITORES

R

AFAEL

R

OJO

C

ARMEN

G

UTIEZ

COORDINADOR

M

ARIO

P

IATTINI

(U

NIVERSIDAD DE

C

ASTILLA

-L

A

M

ANCHA

ALENCIA

E

RNEST

T

ENIENTE

(U

NIVERSIDAD

P

OLITECNICA DE

C

ATALUNA

)

**Hanna Oktaba°, Mario Piattini, Francisco J. Pino+, Félix García,**

Tomás Martínez, Claudia Alquicira°, Francisco Ruiz

° Facultad de Ciencias

Universidad Nacional Autónoma de México (UNAM)

Ciudad Universitaria, 04510 México D.F., México

ho@fciencias.una

m.mx, al

q_cae@yahoo.com.mx

* Grupo de Investigación ALARCOS

Departamento de Tecnologías y Sistemas de Información

Universidad de Castilla-La Mancha

Paseo de la Universidad, 4 – 13071 Ciudad Real, España

{Mario.Piattin, Félix.García, Tomas.Martinez, Francisco.RuizG}@uclm.es

+ Grupo de Investigación IDIS

Facultad de Ingeniería Electrónica y Telecomunicaciones

Universidad del Cauca

Calle 5 # 4 – 70, Popayán, Colombia.

fjpino@unicauca.edu.co

(3)

tificación de la empresa a través de la implementación de modelo de referencia de dos maneras: per-sonalizada para una empresa o conjunta entre un grupo de empresas (logrando así costos más accesibles para PyMEs). El mode-lo de referencia MR-MPS contie-ne los requisitos que los procesos de las unidades de la organización deben cumplir para estar en con-formidad con el modelo propues-to, e incluye también las defini-ciones de los niveles de madurez, procesos y atributos del proceso. La guía de evaluación contiene el proceso y el método de evalua-ción MA-MPS y los requisitos para los evaluadores e institucio-nes evaluadoras. El proceso y el método de evaluación MA-MPS cumplen la norma ISO/IEC 15504-2.

En Colombia se llevó a cabo el proyecto SIMEP-SW financiado por Colciencias y la Universidad del Cauca con el fin de crear, apli-car y probar un sistema de mejo-ra que integmejo-ra elementos de modelos de calidad, mejora y eva-luación reconocidos internacio-nalmente, adaptados a las carac-terísticas propias de la industria del software colombiana. Se pre-tende que los proyectos de mejo-ra que realicen las empresas de Colombia sigan un modelo nacional coherente a las caracte-rísticas propias de la idiosincrasia y aterrizadas al contexto socio-económico del país. El principal resultado de este proyecto es el marco de trabajo Agile SPI [14],

con la premisa esencial que los modelos utilizados sean ligeros y basados en estándares internacio-nales. Básicamente se estructura a partir de los componentes pri-marios de un programa de mejo-ra: una guía de mejora y unos modelos de soporte. Para el caso de Agile SPI, los modelos de soporte son: Light Quality Model (el modelo de referencia de pro-ceso), Light Evaluation Model (el modelo de evaluación de proce-sos), y Light Metrics Model (el modelo de medidas de proceso). Además hay dos elementos integradores de toda la estruc-tura: Framework PDS (el mode-lo conceptual de soporte) y Agile_SPI_Process (la guía de mejora que integra de manera dinámica los componentes). Agile SPI Basa su estrategia de mejora en proporcionar a las PyMEs un proceso ágil que guía un programa SPI acorde a sus necesidades, el cual cuenta con los elementos básicos para hacer posible que se pueda llevar a cabo esfuerzos de mejora en este tipo de organizaciones.

En Europa se han impulsado ini-ciativas como ESSI (European Software and System Initiative) que han promovido diferentes proyectos para fortalecer SPI en PyMEs, como por ejemplo SPIRE (Software Process Improvement in Regions of Europe)[29] y TOPS (Toward Organised Software Processes in SMEs) [10]. También se han desarrollado tra-bajos relacionados como

PRO-CESSUS [13] y Adept [20], entre otros y se han realizado investiga-ciones en donde se realizan ajus-tes de modelos de mejora como IDEAL para ser aplicados a PyMEs como muestra el estudio presentado en [7]. También MESOPYME [6] ha sido creado en España para guiar la mejora en pequeñas empresas.

En Australia el proyecto IMPACT [26] y el método Rapid [8] tam-bién persiguen este objetivo.

Por otro lado las organizaciones internacionales como el SEI e ISO comienzan a realizar esfuerzos con miras a que sus estándares de mejora de procesos software (o adaptaciones de éstos) puedan ser aplicados a micro y pequeñas empresas desarrolladoras de software. Es así como el SEI se ha interesado en el área de mejora de procesos para “Small Settings” (Improving Processes in Small Settings –IPSS–) [28]. El término Small Settings hace referencia a equipos pequeños, proyectos peque-ños, organizaciones pequeñas y/o pequeñas empresas.

También ISO trabaja en este sen-tido y ha conformando el grupo de tra-bajo SC7-WG24 con el objetivo de establecer un marco común para des-cribir perfiles evaluables del ciclo de vida de software para ser usados en Very Small Enterprises – VSEs – [17]. Definiéndose una VSE como una organización de menos de 25 emple-ados. El producto inicial será centra-do en procesos software con extensio-nes para los procesos de ingeniería de

(V)

ware a través de la mejora de la capa-cidad de sus procesos. Debido a dos razones fundamentales:

Su imagen, un factor clave en los objetivos de mantener el mercado local y tratar de establecer una posición en el mercado global con el fin de exportar softwre.

Por necesidad, para poder hacer de sus proyectos unidades adminis-trativas eficaces y eficientes.

Muchas PyMEs pueden plantear-se aplantear-segurar la calidad de sus productos a través de la mejora del proceso y la acreditación en modelos de calidad del Software Engineering Institute –SEI– e International Organization for Standardization –ISO– [19]. Sin embargo, la preparación previa a la acreditación es larga y costosa, porque los modelos de mejora, proceso y eva-luación como los propuestos por SEI e ISO están estructurados (y han sido construidos) para ser aplicables a grandes empresas [25]. Diversos estu-dios presentan que la aplicación de éstos es difícil para las PyMEs debido a que un proyecto de mejora siguien-do modelos orientasiguien-dos a grandes orga-nizaciones supone una gran inversión en dinero, tiempo y recursos, además las recomendaciones son complejas de aplicar y el retorno de la inversión se produce a largo plazo [4, 6, 12, 25]. Además, en las PyMEs la aplicación de estos modelos se agrava aún más ya que existe un problema “cultural” importante cuando se quiere “impor-tar” y adoptar, sin más, modelos crea-dos para otro tipo de organizaciones,

ya que, como señala Zahran en [31] si el proceso no “casa” con la cultura de la organización será rechazado por el “cuerpo” organizacional como sucede en los transplantes de órganos. Un problema parecido, se expone en la investigación de Dyba [9], en el que se destaca las importantes diferencias culturales en el éxito de la mejora de procesos software entre las empresas de EEUU y de Europa.

En el presente artículo se presen-ta el proyecto COMPETISOFT , que es una iniciativa integradora de las diferentes propuestas de mejora de procesos software para micro, peque-ñas y medianas empresas desarrolla-doras de software, teniendo en cuen-ta las características propias de este tipo de organizaciones. Este proyecto también sigue algunos elementos de los estándares internacionales crea-dos por instituciones como el SEI e ISO, entre los cuales se destacan CMMI [27], ISO/IEC 12207 [15], ISO/IEC 15504 [16]. El proyecto COMPETISOFT es financiado por CYTED con el objetivo de incremen-tar el nivel de competitividad de las PyMEs productoras de software mediante la creación y difusión de un marco metodológico común que, ajustado a sus necesidades específicas, pueda llegar a ser la base sobre la cual establecer un mecanismo de evalua-ción y certificaevalua-ción de la industria del software.

Además de esta introducción, el capítulo presenta en la sección 2 los trabajos previos relacionados. En la sección 3 se da una visión general del

método de investigación utilizado. La sección 4 se centra en el marco meto-dológico del Proyecto COMPETI-SOFT. Finalmente, la sección 5 mues-tra las conclusiones y futuros mues-trabajos.

2. T

RABAJOS RELACIONADOS En [23] se presenta un estado del arte de la literatura acerca de los esfuerzos SPI llevados a cabo en PyMEs, con el objetivo de conocer qué se ha realizado y logrado sobre mejora de procesos software en este tipo de empresas. También existen diferentes trabajos sobre estándares y propuestas relacionadas con SPI para PyMEs, algunas de las cuales se pre-sentan a continuación:

El gobierno de Brasil financió la implementación del programa PBQP-Software (Productivity and Quality Software Program) [5] y se ha desarrollado el proyec-to “MPS.BR” (melhoria do pro-cesso de software brasileiro) [30], cuyo objetivo principal es definir e implementar un modelo para la mejora de procesos de software orientado a las micro, pequeñas y medianas empresas de forma que estas obtengan un nivel de madu-rez 2 o 3 de CMMI a un costo accesible. El proyecto propone tres modelos para la mejora del proceso software: un Modelo de Referencia (MR-MPS), un Método de Evaluación (MA-MPS) y un Modelo de Negocio (MN-MPS). El modelo de nego-cio define los elementos e inter-acciones involucrados para la

cer-(IV)

1. Mejora de Procesos para Fomentar la Competitividad de la Pequeña y Mediana Industria del Software de Iberoamérica. 2. Programa Iberoamericano de Ciencia y Tecnología para el Desarrollo.

(4)

software conforme a ISO/IEC 15504-2 enfocada en PyMEs; y (v) las meto-dologías españolas MANTEMA [24] y METRICA v3_{. Esto permite que el} proyecto se fortalezca con la experien-cia de estos trabajos desarrollados previamente, ya que en los grupos participantes del proyecto COM-PETISOFT se cuenta con personas que han trabajado en el desarrollo de estas iniciativas.

Desde esta perspectiva, el Modelo de Referencia de Procesos de COM-PETISOFT es una evolución y refina-miento del modelo de procesos pro-puesto en MoProSoft, a la cual se le añaden elementos de la metodología de mantenimiento de software

MAN-TEMA. El Modelo de Evaluación de COMPETISOFT es un ajuste de EvalProSoft a las necesidades del pro-yecto, teniendo en cuenta también elementos de los modelos de

evalua-ción de MPS.BR y MARES. El Modelo de Mejora de COMPETI-SOFT parte y propone una adecua-ción del modelo y procesos de mejora de Agile SPI. Estos tres modelos serán desarrollados y adaptados según las necesidades de la industria software a partir de la experiencia que propor-cionan los investigadores, las PyMEs y las unidades gubernamentales que se puedan involucrar en el proyecto.

4.1 MODELO DEREFERENCIA DE

PROCESOS

El Modelo de Referencia de Procesos de COMPETISOFT, está basado en MoProSoft [21] y agrupa los procesos en tres categorías

principa-les: Alta dirección, Gestión y Operación. Esta división de procesos se ajusta a la organización funcional de una empresa. En la figura 3 se mues-tra las categorías de COMPETISOFT

junto con los procesos que engloba cada una de ellas, en un diagrama de paquetes UML.

4.1.1 CATEGORIA DEALTADIRECCION

Dentro de la categoría de Alta Dirección (DIR) se incluye única-mente el proceso de Gestión de Negocio (DIR.1) que engloba todas las prácticas relacionadas con la ges-tión de la empresa. Así establece los objetivos y las condiciones necesarias para lograrlos en función de las nece-sidades de los clientes y de los cam-bios que, propuestos a raíz de la eva-luación de los resultados obtenidos, permitan alcanzar la mejora continua. También debe capacitar a la organiza-ción para enfrentarse a un ambiente de cambio, a sus miembros para traba-jar en función de los objetivos

esta-(VII)

sistemas. Se planea producir un están-dar y dos guías que ayuden a las VSEs para producir productos de software de una manera disciplinada y profesional.

Siguiendo esta filosofía, hemos puesto en marcha una iniciativa inte-gradora de diferentes propuestas rela-cionadas con la mejora de procesos software para micro, pequeñas y medianas empresas desarrolladoras de software. La estructura del marco metodológico desarrollado permite que pueda ser utilizado por cualquier PyME del mundo, que lo considere válido para su programa de mejora de procesos. Además el proyecto COM-PETISOFT sigue la estrategia de brin-dar a las PyMEs la definición de mode-los que faciliten la adopción e implantación de diferentes estándares creados por proyectos u organizacio-nes nacionales ó internacionales. Este proyecto no pretende ser una “com-petencia” de los modelos internacio-nales del SEI o ISO, sino un apoyo para que las PyMEs en el futuro pue-dan iniciar y abordar programas de mejora de procesos con miras a obte-ner posteriormente certificaciones en este tipo de estándares.

3. M

ETODO DE

I

NVESTIGACION El método de investigación empleado en la definición, refina-miento y aplicación de los modelos de COMPETISOFT se denomina Investigación-Acción (I-A).

Investigación-Acción es una for-ma de investigar de carácter colabo-rativo que busca unir la teoría y la práctica entre investigadores y

profe-sionales mediante un proceso de natu-raleza cíclica. Este método está orien-tado a la producción de nuevo cono-cimiento útil en la práctica, que se obtiene mediante el cambio y/o bús-queda de soluciones a situaciones rea-les [2]. Los resultados de esta experien-cia deben ser beneficiosos tanto para el investigador como para los profe-sionales. Una premisa fundamental en esta forma de investigar es que los procesos complejos (y el uso de tecno-logías de la información en organiza-ciones es de este tipo) pueden ser estu-diados mejor introduciendo cambios en dichos procesos y observando los efectos que se producen [3]. En la figu-ra 1 se muestfigu-ra un esquema represen-tativo de I-A.

Los participantes involucrados en el proyecto se dividen en dos grupos: el primero está compuesto por inves-tigadores de distintas universidades y

el segundo, denominado grupo de consulta critica, engloba a los profe-sionales informáticos de PyMEs des-arrolladoras de software y organismos de estandarización.

4. M

ARCO METODOLOGICO DE

COMPETISOFT

Debido a que en diferentes países se han desarrollado estrategias nacio-nales para abordar la mejora de pro-cesos, COMPETISOFT parte de los resultados de estas diferentes iniciati-vas (véase figura 2), entre las que se puede destacar: (i) MoProSoft y EvalProSoft, desarrollados al interior del programa mexicano PROSOFT; (ii) Agile SPI desarrollado dentro del proyecto colombiano SIMEP-SW; (iii) MPS.BR desarrollado y coordina-do en Brasil (iv) MARES desarrolla-da en Brasil, la cual es una guía para conducir evaluaciones de procesos

(VI)

Figura 1: Aplicación del método Investigación-Acción al proyecto COMPETISOFT.

Figura 2: Enfoque general del proyecto COMPETISOFT.

3. http://www.csi.map.es/csi/metrica3/

Figura 3: Categorías y nombres de los procesos del Modelo de Referencia de COM-PETISOFT.

(5)

y proyectos, garantizando que se cumplen los objetivos del Plan Estratégico. Este proceso se divi-de en cuatro actividadivi-des: Pre-paración, Instrumentalización, Generación de Informes e Investigación de Tendencias Tecnológicas.

El último de los procesos de la

Categoría de Gestión es Gestión de Conocimiento (GES.5). Este proceso tiene como cometido la administración de la base de conocimiento,un repositorio en el que se guarda la información y los productos generados por todos los procesos implementados en la organización. Se debe enfatizar la importancia de la reusabilidad que se puede alcanzar por medio del desarrollo de la base de cono-cimiento en la cual se almacenan todas las experiencias obtenidas. Con este propósito se deben con-siderar otras propuestas como la presentada en [18]. Damos gran importancia a la base de expe-riencia desde el principio y en todos los niveles organizaciona-les, sin tener en cuenta la calidad de los componentes almacenados en la base, puesto que todos pue-den ser útiles. También se reco-noce la importancia de un méto-do más formal aunque ligero de captura de experiencias, apropia-do para una pequeña organiza-ción, proporcionando una guía y estructura para ayudar a los usuarios en la creación de más experiencias para la base de conocimiento. Otras cuestio-nes importantes a abordar son la

gestión de la documentación y configuración.

4.1.3 CATEGORIA DEOPERACION

En la Categoría de Operación (OPE)se incluyen las prácticas de los proyectos de desarrollo y manteni-miento de software agrupadas en tres procesos. La categoría de Operación se sitúa por debajo de Gerencia, por lo que realiza sus actividades de acuer-do a las directrices marcadas por ésta (en consonancia con los objetivos de la organización) y a la que entrega toda la información y productos gene-rados. A continuación se muestra una descripción general de los procesos que integran esta categoría:

El proceso deAdministración de un Proyecto Específico (OPE.1)está encaminado a establecer y ejecu-tar de forma sistemática las activi-dades que permiten cumplir con los objetivos de un determinado pro-yecto en el tiempo y costes plani-ficados. Este proceso incluye cua-tro actividades, Planificación, Realización, Evaluación y Control, y Cierre. En todas ellas se aplican los conocimientos, técnicas habi-lidades y herramientas disponibles dentro la organización.

El segundo de los procesos que integran esta categoría es

Desarrollo de Software (OPE.2), que se encarga de realizar

sistemá-(IX)

blecidos, e incluir la gestión de empre-sa virtual y la conectividad inter-com-pañía como una oportunidad de nego-cio en la industria del software actual. Estos últimos son puntos a tener en cuenta por compañías que partici-pan en clusters o redes virtuales y son requisitos clave para garantizar la supervivencia de las PyMEs en el mercado actual. Este proceso des-arrolla tres actividades fundamen-tales: Planificación E stratégica, Preparación para la Realiz ación de una E strategia y Valoración y Mejora Continua de la Organiz ación.

4.1.2 CATEGORIA DEGERENCIA

LaCategoría de Gerencia (GER)

está compuesta por cinco procesos, en los que se incluyen las prácticas nece-sarias para la gestión de procesos, pro-yectos y recursos en función de las directrices establecidas desde la Alta Dirección. Asimismo, se configura como punto de unión entre ésta y los procesos de la Categoría de Operación, a los cuales les proporcio-na los elementos necesarios para su funcionamiento y de los que sintetiza todos los resultados generados para comunicarlos a la dirección de la orga-nización. Una descripción general de los procesos de ésta categoría se pre-senta a continuación:

El proceso de Gestión de Procesos (GES.1) se encarga de establecer los procesos de la organización en función de las necesidades reco-gidas en el Plan Estratégico. Asimismo, está encargado de definir planificar e implantar las actividades de mejora en los

pro-cesos, de los mecanismos de ase-guramiento de calidad y las vali-daciones, tanto internas como externas. Las actividades con-templadas en este proceso son: la Planificación de Procesos, la Preparación a la Implantación y la Evaluación y Control de Procesos. Dentro de Gestión de Procesos se define un sub-proce-so de evaluaciones internas con el objetivo de generar datos de alta calidad que identifiquen las forta-lezas, debilidades y riesgos de los procesos software y así brindar información que sirva de base para tomar decisiones al interior de la empresa en los aspectos que realmente se debe mejorar. Además se ha definido un cues-tionario de valoración cuya fina-lidad es ayudar a las PyMEs en su primer contacto con la evalua-ción y mejora de la madurez de procesos.

El segundo proceso de la Categoría de Gerencia esGestión de Proyectos (GES.2). Todos los proyectos aprobados precisan de una planificación general, asig-nación de recursos y un segui-miento y evaluación de su ejecu-ción. Además, hay que evaluar las alternativas de realización en el caso de los proyectos internos, y la generación, presentación de la propuesta, firma de contrato y cierre para las oportunidades de proyecto. El proceso de Gestión de Proyectos está orientado a ase-gurar que los proyectos, tanto internos, externos como las opor-tunidades de proyecto,

contribu-yan al cumplimiento de los obje-tivos y estrategias de la organiza-ción. También se aborda las téc-nicas de estimación de mejora, una necesidad fundamental para las PyMEs pero difícil de enten-der y llevar a cabo en este tipo de organizaciones. Este proceso incluye varias actividades: Planificación, Realización y Evaluación y Control. Además se definen dos más de apoyo en el caso de proy e c t o s m u y novedosos o con un nivel de ries-go elevado, Concertación y Conceptualización.

El proceso de Gestión de Recursos Humanos (GES.3) tie-ne la finalidad de proporcionar a la organización los recursos humanos necesarios para cubrir los roles establecidos, además de evaluar el ambiente de trabajo en el que éstos se desenvuelven para garantizar que se cumplen los objetivos marcados en el Plan Estratégico. Se pueden diferen-ciar tres actividades de este pro-ceso:Preparación, Instrumenta-lización y Generación de Reportes, realizadas en función del Plan Estratégico, de los Planes de Adquisición y Capacitación y las Acciones Correctivas de los proyectos y procesos.

El cuarto proceso de esta catego-ría esGestión de Bienes, Servicios e Infraestructura (GES.4). La fun-ción principal de este proceso es proporcionar proveedores de estos tres elementos que satisfa-gan los requisitos de los procesos

(VIII)

(6)

capacidad de un proceso. A partir de los niveles de capacidad de los proce-sos que están dentro del alcance de la evaluación se determina el perfil del nivel de capacidad de los procesos. Cuando el alcance de evaluación incluye a todos los procesos de la orga-nización, se le asigna a esta un nivel de Madurez de Capacidades, que corresponde con el máximo nivel de capacidad alcanzado por todos los

pro-cesos. En la tabla 2 se puede ver que el nivel de capacidad de un proceso es aquel cuyos atributos son, al menos, amplia-mente alcanzados (A) y el cumplimien-to de cumplimien-todos los atribucumplimien-tos de niveles infe-riores es completamente alcanzados (C).

El modelo de evaluación define un proceso de evaluación conforme al patrón de procesos del modelo de refe-rencia de procesos de

COMPETI-SOFT (véase figura 4). Esto permite que el proceso de evaluación se inte-gre como un proceso más dentro de la organización. El modelo de evalua-ción soporta tres usos:

Evaluación para la Acreditación de Capacidades:permite a un eva luador certificado evaluar el per-fil del nivel de capacidad de los procesos implantados en una organización y determinar su nivel de madurez de capacidades. Los resultados obtenidos pueden emplearse para iniciar un ciclo de mejora usando el modelo de mejora de COMPETISOFT. El nivel de madurez se puede usar para realizar una comparativa entre organizaciones.

Evaluación de Capacidades de un Proveedor:permite que los clien-tes de una organización soliciten a un Evaluador Certificado una evaluación para obtener el nivel de capacidad de ésta de cara a contratar un servicio o seleccio-nar un proveedor. El cliente elige los procesos a evaluar en función del servicio requerido.

Autoevaluación de Capacidades de un Proceso: permite a una organización realizar una evalua-ción por su propio personal, sin que estos sean evaluadores certi-ficados, para obtener el perfil del nivel de capacidad por proceso. Este resultado se puede emplear para iniciar un ciclo de mejora.

El proceso de evaluación es un elemento integrador de algunos de los

0 0

IInnccoommppll eettoo EEll pprr oocceessoo nnoo eessttáá iimmppll aannttaaddoo oo nnoo aall ccaannzzaa ssuuss oobbjjeettiivvooss.. 11 EEll pprr oocceessoo eessttáá iimmppll aann ttaaddoo yy rr eeaall iizzaa ssuu pprr ooppóó ssiittoo.. R

Reeaall iizzaaddoo o AP 1.1 Atributo de realización del proceso.

E

Ell pprr oocceessoo ssee iimmppll aannttaa ddee mmaanneerr aa aaddmmiinniissttrr aaddaa yy ssuuss pprr oodduuccttooss ddee 22 ttrr aabbaajjoo eessttáánn eessttaabbll eecciiddooss,, ccoonnttrr ooll aaddooss yy mmaanntteenn iiddooss..

G

Geessttiioonnaaddoo o AP 2.1 Atributo de Gestión de la Realización. o AP 2.2 Atributo de Gestión del Producto de Trabajo.

E

Ell pprr oocceessoo ssee iimmppll aannttaa mmeeddiiaannttee uunn pprr oocceessoo ddeeff iinniiddoo,, 33 qquuee eess ccaappaazz ddee aallccaannzzaarr ll ooss rr eessuullttaaddooss ddeell pprr oocceessoo.. E

Essttaabbll eecciiddoo o AP 3.1 Atributo de Definición del Proceso. o AP 3.2 Atributo de Implantación del Proceso.

E

Ell pprr oocceessoo ooppeerr aa ddeennttrr oo ddee uunn ooss ll íímmiitteess ppaarr aa aall ccaannzzaarr 4

4 eell oobbjjeettiivvoo mmaarr ccaaddoo.. P

Prr eeddeecciibbll ee o AP 4.1 Atributo de Medición del Proceso. o AP 4.2 Atributo de Control del Proceso.

E

Ell pprr oocceessoo eess ccoonnttiinnuuaammeennttee mmeejjoorr aaddoo ppaarr ll ooggrr aarr ll aass mmeettaass ddee 55 nn eeggoocciioo aaccttuuaall eess yy ff uuttuurr aass..

O

Oppttiimmiizzaaddoo o AP 5.1 Atributo de Innovación del Proceso. o AP 5.2 Atributo de Optimización del Proceso.

(XI)

ticamente de las actividades necesarias para crear productos software. Está compuesto por uno o más ciclos de desarrollo integra-dos por las actividades de Inicio, Requisitos, Análisis, Diseño, Construcción, Integración, Pruebas y Cierre. Previa a la realización de todas estas fases, se realizan las actividades de Distribución de Tareas entre los miembros del Equipo de Trabajo, Verificación y Validación de los productos gene-rados y la generación de un Informe de Actividades.

El proceso de Mantenimiento de Software (OPE.3)de COMPETI-SOFT se basa en la metodología para el Mantenimiento del Software MANTEMA [24]. Da cobertura todo el proceso que involucra el mantenimien-to y modificación de producmantenimien-tos software.

Los procesos presentados ante-riormente se estructuran en un patrón de procesos, con el objetivo de que sea más intuitivo y fácil de usar por las PyMEs. El metamodelo del patrón de los procesos de referencia se presenta en la figura 4. También se ha definido un conjunto de plantillas para la des-cripción de todos los productos que se crean en los distintos procesos, de esta forma se ayuda a los usuarios a estruc-turar, clasificar y entender la informa-ción generada usando los modelos desarrollados por el proyecto.

Además, con el fin de reducir cos-tes en las PyMEs, se incorpora el uso y desarrollo de herramientas de

códi-go abierto y el desarrollo de técnicas específicas para la aplicación del pro-ceso de usabilidad del software en este tipo de organizaciones.

En el Anexo A, se incluye el proceso de Gestión de Negocio (Categoría de Alta Dirección), como un ejemplo de proceso descrito usan-do el patrón de procesos implementa-do por COMPETISOFT.

4.2 M

ODELO DE

E

VALUACION El modelo de evaluación de COMPETISOFT, que se basa en el método de evaluación EvalProSoft [22] y ha sido diseñado en consonan-cia con la norma internacional ISO/IEC 15504 (ver figura 5), define cinco niveles de madurez para la orga-nización: Realiz ado, Gestionado, Establecido, Predecible y Optimizado.

El modelo de capacidades de pro-cesos evalúa la capacidad de éstos en

una escala de 0 a 5, donde cero espe-cífica que no hay procesos definidos y cinco que la organización ha alcanza-do un nivel de mejora continua de sus procesos. Cada uno de estos niveles de capacidad se divide en uno o dos atri-butos de capacidad. Cada atributo mide un aspecto particular del proce-so, como se puede ver en la tabla 1.

Cada uno de los elementos des-critos anteriormente tienen una esca-la específica para su medición, es así que para los atributos de proceso y sus correspondientes prácticas de gestión los valores se reflejan en una escala discreta compuesta por los siguientes elementos: (i) C: completamente alcanzados, entre 86% y 100 %; (ii) A: ampliamente alcanzados, entre 51% y 85%; (iii) P: parcialmente alcanzados, entre 16% y 50%; y (iv) N: no alcanzados, entre 0% y 15%.

En función de la calificación de estos atributos, se obtiene el nivel de

(X)

Figura 5: Estructura del Modelo de Evaluación de COMPETISOFT.

Tabla 1: Niveles de capacidad de los procesos y sus atributos asociados

Tabla 2: Calificación del nivel de capacidad de un proceso. D

DEESSCCRRIIPPCCIIOONN YY AATTRRIIBBUUTTOOSS N NIIVVEELL E E VVAA LL UUAA CC II OO NN DD EE LL OO SS AATTRR II BB UUTTOO SS AP 1.1 AP 2.1 AP 2.2 AP 3.1 AP 3.2 AP 4.1 AP 4.2 AP 5.1 AP 5.2 N NIIVVEELL A ALLCCAANNZZAADDOO Realizado A Gestionado C A A Establecido C C C A A Predecible C C C C C A A Optimizado C C C C C C C A A

(7)

de desarrollo, el de calidad, mar-keting y demás partes relaciona-das con el proyecto SPI. La forma más eficiente y efectiva de comu-nicar información dentro de un equipo de mejora es mediante la conversación cara a cara.

Individuos motivados.Construir proyectos individuales, grupales y organizacionales en torno a indi-viduos motivados hacia la mejo-ra de procesos. Brindarles la opor-tunidad y el respaldo que necesitan y procurarles confianza para que realicen las tareas. El modelo de mejora promueve la conformación efectiva de los gru-pos propuestos por su infraestruc-tura, se preocupa por la calidad del trabajo humano a realizar.

Además, el modelo de mejora de COMPETISOFT para el éxito del proyecto SPI promueve:

El desarrollo sostenido del pro-yecto de mejora, a través del tra-bajo continuo e indefinido. La madurez del proceso y el desem-peño promedio de los proyectos debe ser la medida primaria y lige-ra de la mejolige-ra del progreso.

Una infraestructura técnica y de gestión, adecuada para soportar la mejora de procesos. El modelo de mejora promueve la conformación de una infraestructura organiza-cional dinámica, basada en obje-tivos, no en estrategias de control.

El aprendizaje continuo como una disciplina clave. El objetivo

de esta disciplina es que permita conocer el trabajo, reflexionar acerca de este y ajustar el trabajo a través de iteraciones cortas y concisas.

El modelo de mejora de COMPE-TISOFT define un conjunto de fases y disciplinas como muestra la figura 7.

En este modelo se describe un proceso de mejora de procesos de soft-ware en cinco fases (macro – activi-dades), a continuación se explica bre-vemente cada una de ellas:

Instalación. Esta es la actividad de partida para el proyecto SPI. Debe existir motivación por par-te de la empresa para emprender un plan de mejora de sus proce-sos. Se crea una propuesta de mejora basada en las necesidades del negocio, que guíe a la organi-zación a través de cada una de las actividades siguientes, esta pro-puesta debe ser aprobada por la alta dirección para garantizar la asignación de los recursos

necesa-rios involucrados en el proyecto SPI. Se definen los objetivos de mejora, los cuales son estableci-dos a partir de las necesidades de la empresa. También se debe estructurar una infraestructura de gestión, la cual describe la mane-ra en la cual se organizan las per-sonas comprometidas dentro del proyecto SPI. Esta infraestructu-ra organiza el proyecto SPI teniendo en cuenta un equipo de gestión (EG), un equipo de tec-nología de procesos (ETP) y equi-pos de mejora (EM)..

Diagnóstico.En esta actividad ya se ha iniciado un proyecto SPI. Se realizan tareas de valoración de procesos software para saber cuál es el estado general de los proce-sos de la empresa. Además, se rea-liza un análisis de los resultados de la valoración con el fin de esta-blecer la prioridad de los casos de mejora. Este análisis sirve para crear uno de los principales pro-ductos de esta actividad, que es la guía o plan general de mejora.

(XIII)

modelos desarrollados en COMPETI-SOFT como se muestra en la figura 6. Este proceso debe guiar las activida-des de evaluación a lo largo de todo el proyecto de mejora.

En el proyecto COMPETISOFT se ha desarrollado un conjunto de medidas para medir el rendimiento y la capacidad de los procesos software basados en el modelo de evaluación descrito:

El primer tipo de medidas está relacionado con la dimensión de la capacidad, y su objetivo es medir la capacidad de un proceso teniendo en cuenta los atributos de proceso de los niveles de capa-cidad definidos por el método de evaluación. Por cada atributo de proceso, la “medida de capaci-dad” se basa en la medición de los indicadores de: (i) las prácticas genéricas realizadas, (ii) los recur-sos genéricos utilizados y (iii) los productos de trabajo genéricos obtenidos en el proceso.

El segundo tipo se relaciona con la dimensión del proceso, y su objetivo es medir el rendimiento de un proceso teniendo en cuen-ta las características de los

proce-sos definidos por el modelo de referencia de procesos de COM-PETISOFT. Para cada proceso la “medida de rendimiento” se basa en la medición de los indicadores de: (i) las prácticas base realiza-das y (ii) los productos de traba-jo obtenidos en el proceso.

Tras la ejecución de la evalua-ción, se obtienen el Informe de Resultados y el Informe Estadístico. El primero contiene el perfil del nivel de capacidad de procesos y el nivel de madurez de la organización, además de un resumen de los hallazgos signi-ficativos encontrados. El segundo de los informes contiene datos relativos a la evaluación realizada.

4.3 M

ODELO DE

M

EJORA El modelo de mejora de COMPE-TISOFT está basado en Agile SPI [14]. Se caracteriza por ser ligero para su aplicabilidad en las PyMEs de soft-ware. El modelo de mejora es un pro-ceso, iterativo e incremental, organi-zado a través de mini-proyectos de mejora que abarcan casos de mejora dentro de un programa de mejora glo-bal. Un caso de mejora es una unidad atómica de mejora en las áreas de pro-cesos que la empresa ha seleccionado

dependiendo de sus objetivos de negocio. El objetivo de esta estructu-ración es obtener resultados rápidos de mejora.

Dentro del modelo de mejora se ha planteado satisfacer los siguientes propósitos:

Entrega temprana y continua de mejoras. Satisfacer las necesida-des de mejora de procesos de la organización a través de la entre-ga temprana y continua de mejo-ras significativas del proceso de desarrollo de software, es la prin-cipal prioridad. La generación de resultados visibles a corto plazo implica que los usuarios involu-crados el proceso de mejora observen los frutos de su trabajo de manera temprana e incremen-ten así su nivel de motivación.

Diagnóstico continuo de proce-sos.Diagnosticar continuamente los procesos de la organización, ya que es difícil definir requisitos de mejora de procesos totalmente estables por parte de la organiza-ción. Analizar, priorizar y realizar estos nuevos requisitos de mejora de procesos en la medida que sea factible.

Colaboración entre grupos.

Establecer una colaboración efectiva entre los diferentes acto-res involucrados en el proyecto de mejora de procesos software –SPI–. Un proyecto SPI debe basarse en la colaboración efecti-va entre los consultores, grupo de mejora, la alta gerencia, el grupo

(XII)

Figura 6: E7ntidades de la evaluación de procesos software

(8)

Formulación.En esta actividad se toman los casos de mejora de mayor prioridad, según los resul-tados arrojados por la valoración de procesos hecha en la actividad de diagnóstico y se realiza la pla-nificación de una primera (o nue-va) iteración de mejora, el obje-tivo en un principio es realizar una medida del esfuerzo que sirva de base para la estimación del esfuerzo que tomará llevar a cabo el resto del proyecto de mejora.

Mejora. En esta actividad se eje-cuta los casos de mejora, basados en la estimación hecha en la fase anterior, y se gestiona todo el esfuerzo involucrado en éstos. Se realizan las planificaciones correspondientes a las diferentes iteraciones que pueden resultar con cada uno de los casos de mejo-ra definidos. Se genemejo-ra un docu-mento donde se registra la ejecu-ción de los pilotos de prueba, la evaluación de la mejora por la introducción de los nuevos pro-cesos y por el perfeccionamiento de los procesos ya existentes. Si los planes piloto se han desarro-llado satisfactoriamente se defi-nen planes de aceptación e insti-tucionalización de los nuevos procesos en la empresa.

Revisión del programa.En esta actividad se hace un análisis pos-tmortem del caso de mejora eje-cutado antes de volver a comen-zar la fase de inicio de un nuevo caso de mejora. En esta fase todas las lecciones aprendidas y las

métricas desarrolladas para medir el cumplimiento de los objetivos sirven como base de conocimien-to o fuente de información para las personas involucradas en el siguiente ciclo de mejora. Con toda la información recolectada se debe evaluar el trabajo realiza-do y se deben corregir o ajustar todos los elementos relacionados con la ejecución del proyecto SPI, como la infraestructura esta-blecida, los métodos utilizados y los canales de comunicación, entre otros.

El modelo de mejora incluye un conjunto de disciplinas que pueden ser aplicadas en menor o mayor medi-da dependiendo de la fase en la que se aplique y de las prioridades del pro-yecto de mejora. Una disciplina de mejora es un cuerpo de conocimien-to altamente cohesivo asociado a un objetivo dentro del programa de mejora, tal como evaluar procesos, diseñar procesos, analizar procesos, aprender, entre otros.

5. C

ONCLUSIONES Y TRABAJO FUTURO

En este artículo se ha presentado el Proyecto COMPETISOFT, una iniciativa integradora de las dife-rentes propuestas de mejora de procesos software para micro, pequeñas y medianas empresas desarrolladoras de software, teniendo en cuenta para su des-arrollo las características propias de este tipo de organizaciones.

La evaluación y mejora de

proce-sos software hecha a la medida de las características especiales de las PyMEs es el principal reto hacia el que se dirige esta iniciativa, ya que empre-sas de este tipo necesitan sobrevivir en un mercado global cada vez más competitivo pero no tienen suficien-tes recursos económicos para aplicar métodos “pesados”. Para culminar con éxito este objetivo, el proyecto COMPETISOFT cuenta con la parti-cipación activa de profesionales e investigadores pertenecientes a dife-rentes universidades, PyMEs y organi-zaciones gubernamentales de 13 países.

La próxima versión del marco COMPETISOFT será creada en 2008 e incluirá la realimentación y las lec-ciones aprendidas de la aplicación de los modelos de referencia de procesos, evaluación y mejora que se están lle-vando a cabo en diferentes empresas participantes en el proyecto. (XV) (XIV) C I R C U L O D E U S U A R I O S O R A C L E D E E S PA Ñ A

B

IBLIOGRAFIA [1] Anacleto, A., C.G.v. Wangenheim, C.F. Salviano, y R. Savi. A Method for Process Assessment in Small Software Companies. 2004. 4th International SPICE Conference on Process Assessment and Improvement (SPICE 04). Portugal. pp. 69-76.

[2] Avison, D., F. Lan, M. Myers, y A. Nielsen, Action Research. Communications of the ACM, 1999. Vol. 42(1) pp. 94-97.

[3] Baskerville, R., Investigating Information Systems with Action Research.

Communications of the Association for Information Systems, 1999. Vol. 2(19).

[4] Batista, J. y A. Figueiredo, SPI in a very small team: a case with CMM. Software Process: Improvement and Practice, 2000. Vol. 5(4) pp. 243-250.

[5] Bedini, A., A. Llamosa, M. Pavlovic, y K. Steembecker. Quality Software Map of South America. 2005. Proceedings of the First International Research Workshop for Process Improvement in Small Settings. Pittsburgh. pp. 216-227.

[6] Calvo-Manzano, J.A., Métodos de mejora del proceso de desarrollo de sistemas de información en la pequeña y

mediana empresa. 1999, Universidad de Vigo.

[7] Casey, V.e I. Richardson, A practical application of the IDEAL model. Software Process: Improvement and Practice, 2004. Vol. 9(3) pp. 123-132.

[8] Cater-Steel, A.P., M. Toleman, y T. Rout, Process improvement for small firms: An evaluation of the RAPID assessment-based method. Information and Software Technology, 2005. pp. 1-12.

[9] Dyba, T., An Empirical

Investigation of the Key Factors for Success in Software Process Improvement. IEEE

Transactions on Software Engineering, 2005. Vol. 31(5) pp. 410-424.

[10] Esprit_Project. Toward

Organised Software Processes in SMEs. Esprit Project 27977 -TOPS. 1999. Disponible en: http://www.cordis.lu/esprit/src/2 7977.htm. 2006.

[11] Fuggetta, A. Software process: a roadmap. 2000. International Conference on Software Engineering (ICSE). ACM Press. pp. 25-34.

[12] Hareton, L. e Y. Terence, A process framework for small projects. Software Process: Improvement and Practice, 2001. Vol. 6(2) pp. 67-83.

[13] Horvat, R.V., I. Rozman, y J. Györkös, Managing the complexity of SPI in small companies. Software Process: Improvement and Practice., 2000. Vol. 5(1) pp. 45-54.

[14] Hurtado, J., F. Pino, y J. Vidal. Software Process Improvement Integral Model: Agile SPI. Technical Report SIMEP-SW-O&A-RT-6-V1.0. 2005. Universidad del Cauca -Colciencias. Popayán, Colombia. 2006.

[15] ISO_12207. ISO/IEC 12207:2002/FDAM 2. Information technology -Software life cycle processes. International Organization for Standardization. Ginebra. 2004.

[16] ISO_2. ISO/IEC 15504-2:2003/Cor.1:2004(E).

Information technology -Process assessment - Part 2: Performing an assessment. International Organization for Standardization. Ginebra. 2004.

[17] ISO_WG_24. ISO/IEC JTC1/SC7 Working Group 24. 2006. Disponible en: http://iso-iecsc7wg24.gelog.etsmtl.ca/Web page/iso-iecsc7wg24_english.html.

[18] Kurniawati, F. y R. Jeffery, The use and effects of an electronic process guide and experience repository: a longitudinal study. Information and Software Technology, 2006. Vol. 48(7) pp. 566-577.

(9)

[19] Mayer&Bunge. Panorama de la Industria del Software en Latinoamérica. Mayer & Bunge Informática LTDA. Brasil. 2004. Available on: www.mbi.com.br/200409_panor ama_industria_software_americ a_latina.pdf [20] McCaffery, F., I. Richardson, y G. Coleman. Adept – A Software Process Appraisal Method for Small to Medium-sized Irish Software

Development Organisations. 2006. European Systems & Software Process Improvement and Innovation (EuroSPI 2006). Joensuu, Finland. pp. 7.12-7.21.

[21] NYCE. Modelo de Procesos para la Industria de Software -MoproSoft - Versión 1.3, Agosto de 2005. NMX-059/01-NYCE-2005. Organismo nacional de normalización y evaluación de la conformidad -NYCE. Ciudad de México. 2005.

[22] NYCE. Método de Evaluación de procesos para la industria de software - EvalProSoft - Versión 1.1, Marzo de 2004. NMX-I-006/(01 al 04)-NYCE-2004. Organismo nacional de normalización y evaluación de la conformidad - NYCE. Ciudad de México. 2006.

[23] Pino, F., F. Garcia, y M. Piattini, Revisión sistemática de mejora de procesos software en

micro, pequeñas y medianas empresas. Revista Española de Innovación, Calidad e Ingeniería del Software (REICIS), 2006. Vol. 2(1) pp. 6-23.

[24] Polo, M., M. Piattini, y F. Ruiz, Using a qualitative research method for building a software maintenance methodology. Software Practice and

Experience, 2002. Vol. 32(13) pp. 1239-1260.

[25] Saiedian, H. y N. Carr Characterizing a software process maturity model for small organizations. ACM SIGICE Bulletin, 1997. Vol. 23(1) pp. 2-11.

[26] Scott, L., R. Jeffery, L. Carvalho, J. D'Ambra, y P. Rutherford. Practical Software Process Improvement -The IMPACT Project. 2001. Proceedings of the Australian Software Engineering Conference. pp. 182-189.

[27] SEI. CMMI for Systems Engineering/Software Engineering, Version 1.1. Software Engineering Institute (SEI). Pittsburgh. 2002.

[28] SEI. Improving Processes in Small Settings

(IPSS Project). 2006. Disponible en:

http://www.sei.cmu.edu/iprc/ipss background.html.

[29] SPIRE. Software Process Improvement in Regions of Europe (SPIRE). European Commission ESPRIT/ESSI Programme. 1993. Disponible en: http://www.cse.dcu.ie/spire/.

[30] Weber, K., E. Araújo, A. Rocha, Machado, D. Scalet, y C. Salviano, Brazilian Software Process Reference Model and Assessment Method, in Computer and Information Sciences. 2005, Springer Berlin / Heidelberg. p. 402-411.

[31] Zahran, S., Software Process Improvement:

Practical Guidelines for Business Success. 1998, Harlow, United Kingdom, Addison-Wesley.

(XVII) (XVI)

PROCESO

DIR.1 Gestión de Negocio

CATEGORIA A

ALTADIRECCION(DIR)

PROPOSITO L

El propósito de Gestión de Negocio es establecer la razón de ser de la organización, sus k

objetivos y las condiciones para lograrlos, para lo cual es necesario considerar las necesidades de los clientes, así como evaluar los resultados para poder proponer cambios que permitan la mejora continua.

Adicionalmente habilita a la organización para responder a un ambiente de cambio y a sus miembros para trabajar en función de los objetivos establecidos.

DESCRIPCION

El proceso de Gestión de Negocio se compone de la planificación estratégica, la preparación para la realización de la estrategia, y la valoración y mejora continua de la organización.

• Planificación Estratégica: Establece las decisiones sobre qué es lo más importante para lograr el éxito de la organización, definiendo un Plan Estratégico, con los siguientes elementos:

La Misión, Visión y Valores.

Los Objetivos de la organización, incluyendo los objetivos de calidad, así como la forma de alcanzar éstos por medio de la definición de Estrategias.

Análisis del entorno para obtener un diagnóstico preciso de la organización que nos permita crear o reajustar una estrategia de negocios y, en función de ello, tomar

decisiones acordes con los objetivos y políticas formulados. Este diagnóstico debe incluir: a) Diagrama de Flujo Situacional de los problemas asociados con el logro de los objetivos; b) Análisis de los Actores del entorno asociados con el logro de los objetivos y la realización del negocio/servicio, en términos de recursos, intereses, actitudes, motivaciones, etc.

La forma de medir el logro de los Objetivos, por medio de la definición de Indicadores y Metas Cuantitativas asociadas a dichos Objetivos.

Los Procesos Requeridos con sus indicadores y metas.

La Cartera de Proyectos que habilite la ejecución de las Estrategias.

A

NEXO

A: P

ROCESO DE

G

ESTION DE

N

EGOCIO

(10)

METAS CUANTITATIVAS

• Valor numérico o rango de satisfacción por indicador.

RESPONSABILIDAD Y AUTORIDAD

• Responsable:

Responsable de Gestión de Negocio

• Autoridad: Grupo Directivo

SUBPROCESOS(OPCIONAL)

• Lista de procesos de los cuales se compone el proceso en cuestión.

PROCESOS RELACIONADOS • Gestión de Procesos • Gestión de Proyectos • Gestión de Recursos • Gestión de Conocimiento (XIX) (XVIII) C I R C U L O D E U S U A R I O S O R A C L E D E E S PA Ñ A

La Estructura Organizacional y Estrategia de Recursos que soporten la implantación de los procesos y la ejecución de los proyectos definidos, considerando los elementos de la Base de Conocimiento necesarios para el almacenamiento y consulta de la información generada en la organización.

El Presupuesto, el cual incluye los gastos e ingresos esperados. Periodicidad de Valoración del Plan Estratégico.

Plan de Comunicación con el Cliente, incluye los mecanismos de comunicación con el cliente para su atención.

• Preparación para la Realización: Se define el Plan de Comunicación e Implantación del Plan Estratégico que permite difundir éste a los miembros de la organización,

asegurando que lo consideran el vehículo para lograr la satisfacción de las necesidades del cliente. En este plan también se establecen las condiciones adecuadas en el ambiente de la organización para la realización de los proyectos e implantación de los procesos.

• Valoración y Mejora Continua: Analiza los Reportes Cuantitativos y Cualitativos de los procesos y proyectos, Reporte de Acciones Correctivas o Preventivas Relacionadas con Clientes, Reportes Financieros, Propuestas Tecnológicas y considera los Factores

Externos a la organización. A partir de los resultados del análisis se generan Propuestas de Mejoras al Plan Estratégico. Adicionalmente con base en Plan de Mediciones de Procesos que recibe de Gestión de Procesos genera el Reporte de Mediciones y Sugerencias de Mejora.

Una vez que el Plan Estratégico ha sido valorado y se han detectado Propuestas de Mejora, será necesario revisar los elementos del plan que son afectados y realizar los cambios necesarios a éstos.

OBJETIVOS

1. Lograr una planificación estratégica exitosa mediante el cumplimiento del Plan Estratégico.

2. Lograr que la organización trabaje en función del Plan Estratégico mediante la correcta comunicación e implantación del mismo.

3. Mejorar el Plan Estratégico mediante la implementación de la Propuesta de Mejoras.

INDICADORES

• (1.) El desempeño de los Indicadores de los Objetivos del Plan Estratégico es satisfactorio.

• (2.) Los miembros de la organización conocen el Plan Estratégico y trabajan en función del mismo.

• (3.) Las propuestas de mejora están definidas en función del Reporte de Valoración.

• (4.) Se realizan modificaciones al Plan Estratégico según las Propuestas de Mejoras.

NOMBRE FUENTE

Reporte Cuantitativo y Cualitativo Reporte Cuantitativo y Cualitativo

de procesos y proyectos de procesosy proyectos

Plan de Procesos Plan de Procesos

Plan de Mediciones de Procesos Plan de Mediciones de Procesos

Reporte de Acciones Correctivas o Preventivas Reporte de Acciones Correctivas o Preventivas

Relacionadas con Clientes Relacionadas con Clientes

Propuestas Tecnológicas Propuestas Tecnológicas

Factores Externos (tendencias tecnológicas, Factores Externos (tendencias tecnológicas, clientes

y competidores) clientes y competidores)

Reportes Financieros Reportes Financieros

(11)

(XXI) (XX)

NOMBRE DESCRIPCION DESTINO PLANTILLASOPORTE APROBACION

Plan Misión: Razón de ser de Gestión de Plan Ver 1

Estratégico la organización. Procesos Estratégico

Visión: Posición deseada de Gestión de Val 1

la organización en el mercado Proyectos

Gestión de

... Recursos

Plan de Mecanismos para dar a Gestión de Plan de Val 2

Comunicación conocer el Plan Estratégico Proyectos Comunicación e a toda la organización,

Implantación haciendo énfasis en la Gestión de satisfacción de las Recursos necesidades del cliente.

Administración de un Proyecto

….. Específico

Reporte de Registro que contiene: Gestión de Reporte de Ninguna

Mediciones * Mediciones de los Procesos Seguimiento

y indicadores del

Sugerencias proceso de Gestión de de Mejora Negocio (ver Mediciones)

…..

Plan de Solicitudes con los Gestión de Plan de Ninguna

Adquisiciones requisitos de adquisición Recursos Adquisiciones

y de recursos. Incluye y Capacitación

Capacitación personal capacitado, proveedores, infraestructura y herramientas así como requisitos de capacitación.

Lecciones Registro de mejores prácticas, Gestión de Lecciones Ninguna

Aprendidas problemas recurrentes de este Conocimiento Aprendidas y experiencias exitosas,

de este proceso.

durante la implantación.

IDENTIFICACION DE ROLES INVOLUCRADOS Y COMPETENCIAS REQUERIDAS

ABREVIATURA ROL COMPETENCIAS

GD Grupo Directivo Conocimiento del esfuerzo requerido para

llevar a cabo la planificación estratégica, y sobre todo estar comprometido con éste.

RGN Responsable de Conocimiento de las actividades necesarias

Gestión de Negocio para definir e implantar exitosamente el proceso de Gestión de Negocio.

GG Grupo de Gestión Conocimiento para administrar

los proyectos e implantar los procesos definidos.

S

ALIDAS

P

RODUCTOS INTERNOS

P

RACTICAS

- R

OLES INVOLUCRADOS Y COMPETENCIAS

NOMBRE DESCRIPCION PLANTILLASOPORTE FORMA DE APROBACION

Propuesta de Mejoras Descripción de las sugerencias Propuesta de Mejoras Val 3 de mejora de los elementos del

Plan Estratégico.

Reporte de Valoración Documento que contiene Reporte de Seguimiento Ninguna el registro de los resultados de

a actividad A3.1. Análisis de la información y evaluación del desempeño.

Reporte(s) de Verificación Registro de participantes, Reporte de Verificación Ninguna fecha, lugar, duración

y defectos encontrados.

Reporte(s) de Validación Registro de participantes, Reporte de Validación Ninguna fecha, lugar, duración

(12)

(XXIII) (XXII)

SALIDAS Plan Estratégico

Plan de Adquisiciones y Capacitación

A2. PREPARACION PARA LAREALIZACION (O2)

ENTRADAS Plan Estratégico

RGN A2.1. Preparar el ambiente adecuado para la implantación del Plan Estratégico. GD

RGN A2.2. Definir y ejecutar el Plan de Comunicación e Implantación del Plan Estratégico, en este se deberán identificar:

GD • Las líneas y medios de comunicación, que permitan la divulgación efectiva del Plan Estratégico.

• …

GD A2.3. Validar el Plan de Comunicación e Implantación (Val 2).

RGN A2.4. Corregir los defectos encontrados en el Plan de Comunicación e Implantación con base en el Reporte de Validación y obtener la aprobación de las correcciones.

SALIDAS Plan de Comunicación e Implantación

A3. VALORACION YMEJORACONTINUA (O3)

ENTRADAS Reportes Cuantitativos y Cualitativos de procesos y proyectos

Reporte de Acciones Correctivas o Preventivas Relacionadas con Clientes Propuestas Tecnológicas

Reportes Financieros Factores Externos

RGN, GD A3.1. Análisis de la información y evaluación del desempeño:

• Análisis de los Reportes Cuantitativos y Cualitativos de procesos y proyectos para comparar resultados con metas planteadas.

• …

RGN A3.2. Generación de Reporte de Valoración en donde se registran los detalles de la tarea A3.1 RGN, GG, GD A3.3. Generación de Propuesta de Mejoras al Plan Estratégico actual.

GD A3.4. Validar la Propuesta de Mejoras (Val 3).

RGN A3.5. Corregir los defectos encontrados en la Propuesta de Mejoras con base en el Reporte de Validación y obtener la aprobación de las correcciones.

RGN A3.6. Generar el Reporte de Mediciones y Sugerencias de Mejora de este proceso, de acuerdo al Plan de Mediciones de Procesos.

RGN A3.7. Identificar las Lecciones Aprendidas e integrarlas a la Base de Conocimiento. Como ejemplo, se pueden considerar las mejores prácticas, experiencias exitosas de manejo de riesgos, problemas recurrentes, entre otras.

SALIDAS Reporte de Mediciones y Sugerencias de Mejora Lecciones Aprendidas

A

CTIVIDADES

- S

E ASOCIAN A LOS OBJETIVOS Y DESCRIBEN LAS TAREAS Y ROLES RESPONSABLES

P

RACTICAS

- R

OLES INVOLUCRADOS Y COMPETENCIAS ROL DESCRIPCION

A1. PLANIFICACIONESTRATEGICA(O1)

ENTRADAS Reporte Cuantitativo y Cualitativo de procesos y proyectos Factores Externos

Plan Estratégico anterior Reportes Financieros

GD A1.1. Articular, documentar o actualizar la Misión, Visión y Valores. RGN A1.2. Entender la situación actual.

•Análisis del entorno – identificación de oportunidades y amenazas con base en: necesidades de los clientes, información sobre competidores, tendencias tecnológicas, etc.

•….

RGN A1.3. Desarrollar o actualizar Objetivos y Estrategias, considerando las Propuestas de Mejora, en caso de existir.

•Definir o actualizar los Objetivos, y las Estrategias que especifiquen el medio para alcanzar estos objetivos.

•….

RGN A1.4. Definir o actualizar los procesos y proyectos, considerando las Propuestas de Mejora en caso de existir. GG •Identificar los Procesos Requeridos.

•…

RGN A1.5. Definir o actualizar la Estructura de la Organización adecuada para la implantación del plan, para lo cual es necesario considerar las Propuestas de Mejora en caso de existir.

RGN A1.6. Definir o actualizar la Estrategia de Recursos, considerando las Propuestas de Mejora en caso de existir, que permita:

•Identificar y distribuir los recursos necesarios para la implantación del plan.

•….

RGN A1.7. Calcular el presupuesto requerido (gastos e ingresos esperados) para lograr la implantación del GD Plan Estratégico, y determinar el periodo para el que aplicará.

RGN A1.8. Definir o actualizar la Periodicidad de Valoración del Plan Estratégico, considerando las GD Propuestas e Mejora, en caso de existir.

RGN A1.9. Definir los mecanismos de comunicación con el cliente para su atención y documentarlos en el GD Plan de Comunicación con el Cliente.

RGN A1.10. Integrar y documentar el Plan Estratégico. RGN A1.11. Verificar el Plan Estratégico (Ver 1).

RGN A1.12. Corregir los defectos encontrados en el Plan Estratégico con base en el Reporte de Verificación y obtener la aprobación de las correcciones.

GD A1.13. Validar el Plan Estratégico (Val 1).

RGN A1.14. Corregir los defectos encontrados en el Plan Estratégico con base en el Reporte de Validación y obtener la aprobación de las correcciones.

(13)

(XXV) (XXIV)

D

IAGRAMA DE FLUJO DE

T

RABAJO

(14)

(XXVII) (XXVI)

VERIFICACIONES Y VALIDACIONES

M

EDICIONES

G

UIAS DE

A

JUSTE VERIFICACIONES Y VALIDACIONES Se definen las verificaciones y validaciones asociadas a los productos generados

en las actividades que se mencionan.

En la verificación como en la validación se identifican los defectos que deben corregirse antes de continuar con las actividades posteriores.

La validación de un producto puede ser interna (dentro de la organización) o externa (por el cliente) con la finalidad de obtener su autorización.

Se recomienda que las validaciones se efectúen una vez que las verificaciones asociadas al producto sean realizadas.

VERIFICACION O VALIDACION ACTIVIDAD PRODUCTO ROL LINEAMIENTOS DEVERIFICACION OVALIDACION

Ver 1 A1.11 Plan Estratégico RGN Verificar que todos los elementos son consistentes y que cumplan con las siguientes características: ….

Val 1 A1.13 Plan Estratégico GD Validar que esté de acuerdo con las expectativas de la organización.

Los defectos encontrados se documentan en un Reporte de Validación.

Val 2 A2.3 Plan de GD Validar que contempla todos los

Comunicación niveles de la organización.

e Implantación Los defectos encontrados se documentan en un Reporte de Validación.

Val 3 A3.4 Propuesta GD Validar que se son viables en cuanto a

de Mejoras recursos y tiempo para realizar las mejoras. Los defectos encontrados se documentan en un Reporte de mejoras.

MEDICIONES Medicionesque se establecen para evaluar los indicadores del proceso. Las mediciones se identifican como M1, M2, etc. y entre paréntesis se especifica la identificación del indicador que le corresponde. Con base en Plan de Mediciones de Procesos se genera un reporte periódico del avance de los indicadores del proceso con respecto a las metas cuantitativas definidas, se sugieren las siguientes mediciones:

MEDICION INDICADOR OBJETO DE MEDICION ROL MECANISMO DE MEDICION

M1 I1 Indicadores GD Evaluar los indicadores del Plan Estratégico usando del Plan Estratégico información contenida en la Base de Conocimiento y

Reporte de Valoración y compararlos con las Metas Cuantitativas correspondientes a cada Indicador, para verificar su logro.

M2 I2 Conocimiento GG Realizar encuestas periódicas a los miembros de la del Plan Estratégico organización para comprobar el nivel de conocimiento por parte de los del Plan Estratégico y su aplicación a sus actividades, miembros de la así como la toma de conciencia sobre las necesidades

organización del cliente.

M3 I3 Propuesta de Mejoras RGN Cotejar la Propuesta de Mejoras para comprobar que está definida en función del análisis de Reportes Cuantitativos y Cualitativos de procesos y proyectos, Reporte de Acciones Correctivas o Preventivas Relacionadas con Clientes, Propuestas Tecnológicas, Reportes Financieros y Factores Externos.

M4 I4 Plan Estratégico GD Cotejar el Plan Estratégico para comprobar que está modificado en función de la Propuesta de Mejoras.

ACTIVIDAD RECURSO

A1 Herramientas que permitan documentar, manejar y controlar el Plan Estratégico.

A2 Herramientas que permitan publicar y dar a conocer el Plan Estratégico a todos los miembros de la organización.

A3 Herramientas que permitan registrar periódicamente el avance de los Indicadores de los Objetivos.

Descripción de posibles modificaciones al proceso que no deben afectar los objetivos del mismo.

AJUSTE ALPLANESTRATEGICO Existen modelos de planificación estratégica que no contemplan los elementos de Misión, Visión y Valores, como se definen en el Plan Estratégico menciona do en este proceso; más sin embargo incluyen otros elementos, los cuales con tienen información similar.

AJUSTE AL PROCESO PARA AREAS INTERNAS Se puede ajustar este proceso para las áreas internas dedicadas al desarrollo de Software y al mantenimiento de software que forman parte de una organiza ción. En este caso el Plan Estratégico se convierte en un plan para el área corres pondiente y se elabora en función de los objetivos de la organización, defini dos para el área, y con la participación del grupo directivo de la organización. Los Reportes de Valoración se entregan al Grupo Directivo de la organización, para su evaluación.

(15)