MEJORA DE PROCESO DE SOFTWARE DE UNA PEQUEÑA EMPRESA DESARROLLADORA DE SOFTWARE: CASO COMPETISOFT-...

UNIVERSIDAD NACIONAL DE SAN AGUSTÍN

Facultad de Ingeniería de Producción y Servicios

ESCUELA PROFESIONAL DE

INGENIERÍA DE SISTEMAS

TESIS

“MEJORA DE PROCESO DE SOFTWARE DE UNA PEQUEÑA

EMPRESA DESARROLLADORA DE SOFTWARE: CASO

COMPETISOFT- PERÚ 2DA FASE-AQPSIGMA”

Tesis para optar el Título Profesional de Ingeniero de Sistemas

Bach. Medardo DELGADO PAREDES

Asesores: Ing. Robert ARISACA – UNSA

Msc. Ing. Abraham DÁVILA – PUCP

Arequipa – Perú

2014

“Yo no lo niego ni lo afirmo. Puede que sí

y puede que no. Tratándose de maravillas,

no gasto tinta en defenderlas ni en refutarlas.”

RICARDO PALMA

DEDICATORIA

Con todo mi cariño y mi amor para las personas que hicieron todo

en la vida para que yo pudiera lograr mis sueños, por motivarme y darme

la mano cuando sentía que el camino se terminaba, a ustedes por siempre

mi corazón y mi agradecimiento.

Papá y mamá

A tu paciencia y comprensión, por ser esa persona maravillosa a la que

amo tanto, que me apoyo en todo momento para salir adelante y me brindo

siempre su amor, gracias por estar siempre a mi lado.

Rosemary

A la personita que con su encanto detiene el tiempo siempre….., eres bebe,

lo mejor que nos pudo suceder en la vida. Gracias por confiar siempre en

mi.

Antonella

1

AGRADECIMIENTOS

El presente trabajo está enmarcado dentro del proyecto DAI-2009-008 PUCP:

COMPETISOFT Perú 2da Fase: MYPESOFT. Incremento de la productividad de

PYMES desarrolladoras de software: determinación de patrones de problemas y

soluciones en un contexto de mejora de procesos del Programa Anual de Proyectos

de Investigación 2009 de la Dirección Académica de Investigación de la Pontificia

Universidad Católica del Perú, ejecutado por el Grupo de Investigación y Desarrollo

en Ingeniería de Software.

El proyecto COMPETISOFT Perú 2da Fase se desarrolla en colaboración con la

Universidad Nacional San Agustín (Arequipa), la Universidad Católica Santa María

(Arequipa), la Universidad Nacional de Trujillo (Trujillo), la Universidad Privada del

Norte (Trujillo), la Universidad César Vallejo (Trujillo), el Programa de Innovación y

Desarrollo de Arequipa (CID-AQP), el Colegio de Ingenieros del Perú en los Consejos

Departamentales de Lima y Arequipa, la Asociación de Peruana de Software Libre y

ACKLIS SAC.

2

INDICE Lista de figuras 3

Lista de tablas 5

Resumen 7

Abstract 8

Introducción 9

Capítulo 1: Planteamiento metodológico

1.1 Problema de investigación 10

1.1.1 Enunciado del problema 10

1.1.2 Descripción del problema 10

1.1.3 Formulación interrogativa del problema 11

1.1.4 Justificación de la investigación 11

1.1.5 Alcance de la investigación 11

1.2 Objetivos 12

1.2.1 Objetivo general 12

1.2.2 Objetivos específicos 12

1.3 Hipótesis 12

1.4 Variables 12

1.4.1 Variable independiente y variable dependiente 13

1.4.2 Operacionalización 13

1.5 Tipo de investigación 13

1.6 Área de Investigación 13

1.7 Antecedentes de la Investigación 13

1.8 Método de investigación 16

1.9 Técnicas, instrumentos y fuentes o informantes 17

1.10 Estrategia 17

1.11 Limitaciones de la Metodología de Investigación 17

Capítulo 2: Marco de Referencia.

2.1. Modelos de calidad de proceso. 18

2.2. VSE 39

2.3. Proyecto COMPETISOFT - PUCP 39

Capítulo 3: Empresa de estudio.

3.1. Descripción de la empresa. 41

3.2. Evaluación inicial. 42

3.3. Diagnóstico Inicial 42

3.4. Esquema de Trabajo de Proyecto 57

Capítulo 4: Mejora del proceso.

4.1. Identificación de Procesos para el Ciclo de Mejora 59

4.2. Propuesta de Plan de Mejora de Procesos 67

4.3. Procesos de Gestión de Negocios GNeg 70

4.4. Proceso Administración de Proyectos Específicos APE 77

4.5. Desarrollo y Mantenimiento de Software DMS 108

4.6. Evaluación Final del Ciclo de Mejora 153

4.7. Evaluación del Esfuerzo del Proyecto 160

4.8. Directrices para un Nuevo Ciclo de Mejora 161

3

Capítulo 5: Observaciones, Conclusiones y Recomendaciones.

5.1. Observaciones 162

5.2. Conclusiones 162

5.3. Recomendaciones 163

Bibliografía 164

Anexos 170

LISTA DE FIGURAS

Figura Nº Pag.

Figura Nº 2.1: El empleado de ventas es un actor del sistema de ventas 20

Figura Nº 2.2: Cuando el actor es otro sistema se cambia de notación 26

Figura Nº 2.3: Los casos de uso se representan gráficamente con óvales 36

Figura Nº 2.4: Descripción simplificada de un caso de uso 37

Figura Nº 2.5: Algunas alternativas de un caso de uso 37

Figura Nº 2.6: Una relación de extensión entre dos casos de uso 37

Figura Nº 3.1: Organigrama Empresa AQPSIGMA 41

Figura Nº 3.2: Perfil de Capacidades al Inicio del Ciclo de Mejora 43

Figura Nº 3.3: Distribución de Puntuación de Gestión de Negocios 44

Figura Nº 3.4: Distribución de Puntuación de Gestión de Procesos 46

Figura Nº 3.5: Distribución de Puntuación de Gestión de Proyectos 47

Figura Nº 3.6: Distribución de Puntuación de Gestión de Recursos 49

Figura Nº 3.7:

Distribución de Puntuación de Gestión de Recursos Humanos Ambiente de

Trabajo

50

Figura Nº 3.8:

Distribución de Puntuación de Gestión de Servicios e Infraestructura 52

Figura Nº 3.9:

Distribución de Puntuación de Gestión de Conocimiento de la Organización 53

Figura Nº 3.10:

Distribución de Puntuación de Administración de Proyectos Específicos 54

Figura Nº 3.11:

Distribución de Puntuación de Desarrollo y Mantenimiento de Software 56

Figura Nº 4.1: Diagrama de Evaluación de Impacto 61

Figura Nº 4.2:

Diagrama de Evaluación de Impacto (Objetivos de Negocio Vs. Procesos) 64

Figura Nº 4.3: Diagrama de Evaluación de Impacto (Problemas Vs. Procesos) 67

Figura Nº 4.4: Diagrama de Actividades Propuesto – Proceso Gestión de Negocios GNeg

73

Figura Nº 4.5: Diagrama de Actividades Situación Actual – Proceso de Administración

Proyectos Específicos

79

Figura Nº 4.6: Diagrama de Gestión Alcance, Tiempo, Costo y Riesgo 81

Figura Nº 4.7: Diagrama de Procesos de la Gestión de Alcance de Proyectos 82

Figura Nº 4.8: Diagrama de Actividades Propuestas para el Proceso Administración de

Proyectos Específicos APE – Gestión del Alcance

83

Figura Nº 4.9: Procesos de Gestión de Tiempo 87

4

Figura Nº 4.10: Diagrama de Actividades Propuesto para el Proceso Administración de

Proyectos Específicos APE – Gestión de Tiempo

88

Figura Nº 4.11: Diagrama de Actividades Propuesto para el Proceso Administración de

Proyectos Específicos APE – Gestión de Costo

93

Figura Nº 4.12: Gestión Continua de Riesgos 96

Figura Nº 4.13: Diagrama de Actividades Propuestas para el Proceso Administración de

Proyectos Específicos APE – Gestión de Riesgos

97

Figura Nº 4.14: Ejecución de Pilotos del Proceso Administración de Proyectos Específicos APE

106

Figura Nº 4.15: Diagrama Proceso Actual - Proceso de Desarrollo y Mantenimiento de Software

109

Figura Nº 4.16: La Ingeniería de Requisitos en el ciclo de vida del Desarrollo de Software 113

Figura Nº 4.17: Dimensiones de la Ingeniería de Requisitos 114

Figura Nº 4.18: Dimensiones de la Ingeniería de Requisitos 115

Figura Nº 4.19: Modelo de Procesos de Ingeniería de Requisitos: Iteración de Actividades 117

Figura Nº 4.20: La Ingeniería de Requisitos como un Proceso de Comunicación 119

Figura Nº 4.21: Metodología Propuesta Elicitación de Requisitos 119

Figura Nº 4.22: Rastreabilidad entre Participantes, Objetivos y Requisitos-C 122

Figura Nº 4.23: Metodología Propuesta Análisis de Requisitos 128

Figura Nº 4.24: Metodología Propuesta Validación de Requisitos 131

Figura Nº 4.25: Ejecución de Pilotos del Proceso Desarrollo y Mantenimiento de Software DMS

134

Figura Nº 4.26: Perfil de Capacidades al Final del 1er Ciclo de Mejora 139

Figura Nº 4.27: Perfil de Capacidades del nivel 1, al Iniciar el Proyecto 139

LISTA DE TABLAS

Tabla Nº Pag.

Tabla Nº 1.1: Variables, técnicas e instrumentos 17

Tabla Nº 2.1: Las normas familia ISO 9000 30

Tabla Nº 3.1: Nivel de Cumplimiento de Procesos al Inicio del Ciclo de Mejora 43

Tabla Nº 4.1: Escala de Impacto 59

Tabla Nº 4.2: Objetivos de Negocio 60

Tabla Nº 4.3: Objetivos de Negocio 62

Tabla Nº 4.4: Problemas de Negocio Vs. Procesos del Modelo MoProSoft 65

Tabla Nº 4.5: Roles y Competencias para el Proceso GNEG 72

Tabla Nº 4.6: Descripción de las Actividades del Proceso GNEG propuesto 74

Tabla Nº 4.7: Descripción de las Actividades Situación Actual del Proceso Administración

de Proyectos Específicos APE

80

Tabla Nº 4.8: Roles y Competencias Situación Actual del Proceso Administración de

Proyectos Específicos APE

80

Tabla Nº 4.9: Descripción de las Actividades Propuestas para el Procesos Administración

de Proyectos Específicos APE – Gestión del Alcance

84

Tabla Nº 4.10: Descripción de las Actividades Propuestas para el Proceso Administración

de Proyectos Específicos APE – Gestión del Alcance

85

5


de Proyectos Específicos APE – Gestión de Tiempo

89


de Proyectos Específicos APE – Gestión de Costos

94


de Proyectos Específicos APE – Gestión de Riesgos

98

Tabla Nº 4.14: Roles y Siglas de la Experiencia Piloto 105

Tabla Nº 4.15: Comportamiento y Evaluación del Proceso Gestión de Administración de Proyectos Específicos APE

105

Tabla Nº 4.16: Descripción Metodología de Elicitación de Requisitos 120

Tabla Nº 4.17: Descripción Metodología de Análisis de Requisitos 129

Tabla Nº 4.18: Descripción Metodología de Validación de Requisitos 132

Tabla Nº 4.19: Roles y Siglas de la Experiencia Piloto 133

Tabla Nº 4.20: Comportamiento y Evaluación del Proceso Gestión de Desarrollo y Mantenimiento de Software DMS

133

Tabla Nº 4.21: Objetivos de Mejora 138

Tabla Nº 4.22: Nivel de Cumplimiento de Procesos al Final del Ciclo de Mejora 138

Tabla Nº 4.23: Logros del Ciclo de Mejora según Objetivos de Mejora 139

Tabla Nº 4.24: Esfuerzo del Proyecto (Horas) 144

6

RESUMEN

El proyecto COMPETISOFT Internacional, proyecto de mejora de procesos para la

industria de software a nivel iberoamericano y COMPETISOFT Perú 2da Fase,

continuación del Proyecto, cuyo objetivo es establecer un esquema de mejora

continua de los procesos para pequeñas y medianas empresas desarrolladoras de

software. Ha servido como marco para el presente trabajo el cual propone la

realización de un ciclo de mejora de procesos en una pequeña empresa de software

mediante el desarrollo de pruebas controladas bajo el esquema de action research

cuyo proceso consiste en una espiral, donde se van dando los momentos de

problematización, diagnóstico, diseño de una propuesta de cambio, aplicación de la

propuesta y evaluación, para luego reiniciar un nuevo circuito partiendo de una nueva

problematización.

El proyecto COMPETISOFT Perú ha sido desarrollado en las ciudades de Arequipa,

Trujillo y Lima.

7

ABSTRACT

The International COMPETISOFT project, process improvement project for Latin American

software industry and the 2nd Phase COMPETISOFT Peru, then Project, which aims to

establish the level scheme of continuous process improvement for small and medium sized

software development companies. He has served as a framework for this work which

proposes the creation of a cycle of process improvement in a small software company

through the development of controlled trials under the scheme of action research which

process comprises a spiral where you are giving the moments of problematization,

diagnosis, design of a proposed change, implementation and evaluation of the proposal,

and then restart a new circuit based on a new problematization. COMPETISOFT Peru The

project has been developed in the cities of Arequipa, Trujillo and Lima.

8

INTRODUCCION

En la actualidad en el Perú, la industria de software viene creciendo de manera rápida,

como consecuencia de las necesidades, cada vez mayor, de soluciones usando

tecnologías de información. Sin embargo, las empresas han crecido de manera

desordenada, sin una estrategia que oriente su camino. Esta situación ha generado una

serie de problemas como por ejemplo, que sus costos de producción de soluciones sean

muy altos y su proceso de desarrollo de software cada vez más propenso a

errores; situación que le afecta significativamente como organización. Así mismo, la falta

de conocimientos formales en el campo de la Ingeniería de Software ha provocado que

las empresas tengan procesos totalmente impredecibles.

Los problemas en las empresas desarrolladoras de software no es una situación nueva y

se han realizado diversos esfuerzos para corregir dicha situación. Para el caso de las

grandes empresas se percibe un posible camino de solución a través de los modelos de

capacidad de procesos y por el contrario, para el caso de las pequeñas empresas

(PYMES) desarrolladoras de software, los modelos existentes más representativos

resultan ser muy difíciles de implementar. Uno de los modelos mejor posicionados en el

mundo es el Modelo de Capacidad y Madurez Integrado (CMMI) desarrollado por el

Instituto de Ingeniería de Software (SEI); sin embargo, a una PYME desarrolladora de

software, le toma mucho esfuerzo en adoptar el modelo y adaptarlo a su realidad, por una

serie de factores indicados anteriormente, es a causa de ello, que varios países han

desarrollado modelos propios que toman en cuenta el tamaño de las empresas

desarrolladoras de software de su país; ejemplos de estos modelos son: Entre otros, MPS

de Brasil y MoProSoft de México. La característica común de todos estos modelos, es que

están elaborados en un nivel que indica “EL QUE” se debe cumplir, pero no ofrece

información del “COMO” hacerlo; debido a que esto les permite ser más generales.

COMPETISOFT Perú 2da Fase es un esfuerzo nacional, continuación del

Proyecto COMPETISOFT internacional, que busca establecer un esquema de mejora

continua de los procesos para las PYMES desarrolladoras de

software. COMPETISOFT está basado en MoProSoft para la definición del modelo de

referencia, pero no se limita a ella, se utiliza también EvalProSoft y pmCOMPETISOFT

como el modelo de evaluación de procesos y el modelo de mejorar de procesos,

respectivamente. El presente proyecto propone la realización de un ciclo de mejora de

procesos en una empresa bajo el esquema de pruebas controladas. Las pruebas

controladas se desarrollarán bajo el esquema de action research en donde los

investigadores y las empresas hacen aportes al modelo de acuerdo a las experiencias que

les toque vivir. El proyecto se desarrolla en las ciudades de Arequipa, Trujillo y Lima.

9

CAPITULO I

PLANTEAMIENTO METODOLÓGICO

1.1. Problema de Investigación

1.1.1. Enunciado del Problema Falta de plan y estrategia para enfrentar los problemas derivados de la

construcción de software por parte de una pequeña empresa desarrolladora

de software.

1.1.2. Descripción del Problema

Las pequeñas y medianas empresas (PYMES) en la industria del software,

representan una cantidad significativa de recursos aplicados a problemas de

software de todo el mundo. Las PYMES desarrolladoras de software han

crecido de manera desordenada, sin un plan o estrategia que oriente su

camino, es a causa de esta situación, que ha generado que sus costos de

producción de soluciones sean altos y su proceso de desarrollo de software

muy propenso a errores, sumándose la falta de conocimientos formales en

ingeniería de software que genera que sus procesos sean totalmente

impredecibles.

Es la comprensión de cómo los procesos bien descritos y utilizados, pueden

contribuir a dar solución a estos problemas y lograr y mantener la

competitividad [2]; en ese sentido, en los últimos años en el Perú, muchas

organizaciones han enfocado su atención en la calidad de procesos del

desarrollo de software como elemento capaz de contribuir con la

competitividad en el medio nacional y de dar solución a los problemas

planteados, la mejora de procesos o SPI (de sus siglas en inglés de Software

Processes Improvement) nace en respuesta a esta necesidad, convirtiéndose

en una estrategia muy utilizada.

En el caso de AQPSIGMA, empresa desarrolladora de software, la cual

ofrece servicios de desarrollo de sistemas, auditorías, capacitaciones y

soporte técnico, como parte del convenio COMPETISOFT, viene llevando

acabo la implementación del modelo de calidad para Desarrollo de software

MoProSoft. Dicho modelo que ha sido creado en México y es norma en ese

país [3] y a partir de mayo del 2009, se adoptó como norma técnica peruana

NTP 291.100:2009 [4], es dirigido especialmente para PYMES de desarrollo

de software, proveyendo un modelo robusto y de varios niveles de madurez.

Es así que luego de realizar la evaluación inicial a la empresa en mención y

en base al cuestionario obtenido del modelo MoProSoft (tomando las

10

consideraciones de la evaluación de la ISO/IEC 15504 [5] – 2 al nivel 1 y 2

de capacidades de procesos software denominado Proceso Realizado, el

perfil de las capacidades de los procesos evaluados), dio como resultado,

que esta no había alcanzado los niveles esperados, debido entre otras cosas,

a la ausencia de procesos definidos, falta de instrumentos y de

documentación especializada. En este sentido, se propone la realización de

un ciclo de mejora siguiendo el modelo de calidad de procesos MoProSoft

para la mejora de los siguientes procesos, dado el tiempo limitado por el

proyecto: GNeg (Gestión de Negocio), APE (Administración de Proyecto

Específico) y DMS (Desarrollo y Mantenimiento de Software) y así elevar la

capacidad de los procesos al nivel esperado.

1.1.3. Formulación Interrogativa del Problema

¿Podrán mejorarse las capacidades de los procesos: GNeg (Gestión de

Negocio), APE (Administración de Proyecto Específico) y DMS (Desarrollo y

Mantenimiento de Software) de la empresa AQPSIGMA?

1.1.4. Justificación de la Investigación

Al tratarse de una investigación aplicada, busca aportar aspectos de

instrumentación, documentación especializada y procesos que

permitan caracterizar la problemática.

Busca contribuir en el incremento de la productividad y la producción

de software de calidad en la empresa en cuestión.

Existe la posibilidad personal de llevar a cabo el desarrollo de la

investigación en las organizaciones del medio.

Motiva la ejecución del presente proyecto el desarrollar la tesis para

optar el título en Ingeniería de Sistemas.

1.1.5. Alcance de la Investigación

El proceso de mejora se aplicará a una pequeña empresa desarrolladora

de software comprometida con el proyecto. La empresa representa el caso

AQPSIGMA de una lista mayor de empresas participantes. El proyecto

cubre desde el análisis de la situación actual y finaliza con el reporte

técnico, esto incluye la evaluación final y directrices para iniciar un nuevo

ciclo de mejora. Adicionalmente se presentan las lecciones aprendidas en

el proceso del ciclo de mejora seguido y la evaluación del esfuerzo

desarrollado en la mejora de procesos.

El ciclo de mejora se implementará en la empresa “AQPSIGMA”,

identificada con esta letra griega para mantener la confidencialidad del

caso. AQPSIGMA, empresa desarrolladora de software que ofrece

servicios de desarrollo de sistemas, auditorías, capacitaciones y soporte

11

técnico, cuenta con una experiencia de más de seis años dedicada a

brindar soluciones TI que se ajustan a cada modelo de negocio, en

procesos, actividades y requerimientos legales del gobierno.

1.2. Objetivos

1.2.1. Objetivo General

Ejecutar un ciclo de mejora de procesos en una pequeña empresa

desarrolladora de software del mercado peruano.

1.2.2. Objetivos Específicos

Son objetivos específicos de este proyecto:

Confeccionar un informe técnico denominado: Informe de

Evaluación Inicial AQPsigma.c1.02.01.inf.eval.ini.01.v.1, luego

de realizar la evaluación inicial de la empresa desarrolladora de

software basado en el proyecto COMPETISOFT.

Confeccionar un documento denominado: Plan de Proceso de

Mejora, luego de realizar la planificación de la mejora en la

organización.

Ejecutar un ciclo de mejora de acuerdo al plan de trabajo

establecido.

Confeccionar un informe técnico denominado: Informe de

Evaluación Final del primer ciclo de mejora

AQP.sigma.IT.06.EPF.2c.v1, luego de realizar la evaluación final

de la mejora realizada y del esfuerzo desplegado.

Elaborar un reporte técnico denominado: Reporte Técnico

AQPSIGMA, correspondiente para la empresa.

1.3. Hipótesis Es probable que la implementación del proyecto COMPETISOFT-PERÚ, permitirá

la mejora de las capacidades de los procesos de software de la Empresa

AQPSIGMA.

1.4. Variables

1.4.1. Variable Independiente

El Proyecto COMPETISOFT-PERÚ

12

1.4.2. Variable Dependiente Capacidad de los procesos de Software de la Empresa AQPSIGMA.

1.5. Tipo de Investigación Acción – Investigación (Action Research)

El tipo de investigación empleado en el presente proyecto de tesis ha sido

Investigación - Acción (I-A); un tipo de investigación cualitativa [61] ; que es una

forma de investigar de carácter colaborativo que busca unir la teoría y la práctica

entre investigadores y profesionales mediante el cambio y/o búsqueda de

soluciones a situaciones reales [62]. Los resultados de esta investigación deben

ser beneficiosos tanto para el investigador como para los profesionales. Una

premisa fundamental en esta forma de investigar es que los procesos sociales

complejos (y el uso de tecnologías de la información en organizaciones es de este

tipo) pueden ser estudiados mejor introduciendo cambios en dichos procesos y

observando los efectos que se producen [63].

1.6. Área de Investigación

“Ingeniería de Software” y la sub-área “Calidad de Procesos de Software”.

1.7. Antecedentes de la Investigación

Tesis:

“Herramienta para gestión de proyectos basada en xpdl para el proyecto

COMPETISOFT construcción, pruebas e integración.”, PUCP, Evelyn

Lindsay Ocampo Moreno Carlos Gonzáles Cajahuanca, 6 de julio del 2007

“Implementación de MoProSoft en el proceso de desarrollo y

Mantenimiento de software de la empresa E-volution hypermedia s.r.l.”,

Universidad Privada del Norte, Br. Roxana Lisettte Quintanilla Portugal,

2008

“Mejora del proceso software de una pequeña Empresa desarrolladora de

software: Caso COMPETISOFT-PERÚ-LAMBDA”, PUCP,Dianne Britt

Vergara Gonzáles, 2008,

"Evaluación de la capacidad de los procesos de RUP respecto a los

procesos de operación de MoProSoft usando ISO/IEC 15504", UNSM, 19

Febrero 2008.

"Componente modelador de procesos. Análisis, diseño y construcción de

una herramienta para modelado de procesos: MJS Process Designer",

Jackeline, Pedreschi, Meylin Camarena, Sandro Rondon 06 Junio 2008.

13

"Mejora del proceso software de una pequeña empresa desarrolladora de

software: Caso COMPETISOFT – Perú – Tau", PUCP, Gonzalo Sánchez.

27 Octubre 2008.


software: Caso COMPETISOFT – Perú – Epsilon", PUCP, Jackson

Mogrovejo. 25 Noviembre de 2008.


software: Caso COMPETISOFT – Perú – Alfa", PUCP, Patricia Morillo. 4

Diciembre de 2008.


software: Caso COMPETISOFT – Perú – Sigma", PUCP, Manuel

Calderón. 4 Diciembre de 2008.

“Mejora del proceso software de una pequeña Empresa desarrolladora de

software: caso COMPETISOFT-PERÚ-OMEGA”, PUCP Deborah Gabriela

Briceño Ortega. abril del 2009.

“Mejora del proceso software de una empresa Desarrolladora de software:

Caso COMPETISOFT-PERÚ-DELTA”, PUCP, Giancarlo Juan

Nakashima Chávez, Septiembre del 2009

Mejora del proceso de software de una empresa desarrolladora de

software: Caso COMPETISOFT-PERÚ-OMEGA segundo ciclo”

Lorenzo Esteban Cáceres Vizcarra. 26 de Abril del 2010

“Mejora del proceso de desarrollo de software de una Pequeña empresa:

Caso COMPETISOFT-AQP-DELTA”, Primer Ciclo, UCSM, Jara Delgado

Jonathan, 2010

“Mejora del proceso de desarrollo de software de una Pequeña empresa:

Caso COMPETISOFT-AQP-DELTA”, Segundo Ciclo, UCSM, Linda

Masias, 2010

“Mejora del proceso de una pequeña empresa Desarrolladora de software:

Caso COMPETISOFT-PERÚ-LIM.LAMBDA segundo ciclo”, Marco

Antonio Ibsen Palomino Vásquez, noviembre del 2011

“Mejora del proceso software de una pequeña empresa Desarrolladora de

software: caso COMPETISOFT-PERÚ LIM.OMEGA, primer ciclo”, PUCP,

Ángel Andrés Méndez Bazalar, julio de 2012

“Mejora de procesos de software de una pequeña empresa desarrolladora

de software – Caso: AQP-ALFA”, UNSA, verónica Ñaupac Pacco, 13 de

julio del 2012

Artículos:

III Congreso Regional de Estudiantes de Ingeniería de Sistemas. Trujillo.

Perú. Mayo 2007.

"Análisis, Diseño y Construcción de una Herramienta para Modelado de

Procesos, mjsProcess Designer."

14

Jackeline Pedreschi, Meylin Camarena, Sandro Rondon, Carla Basurto,

Abraham Dávila

VII Jornada Peruana de Computación, (JPC 2008). Lima, Perú. Noviembre

2008.

"Identificación de problemas en proyectos de mejora de procesos: una

experiencia en tres pequeñas empresas desarrolladoras de software en el

Perú."

Eddy Maidana, Nohelia Vilchez, Juana Vega, Abraham Dávila

VII Jornada Iberoamericana de Ingeniería de Software e Ingeniería del

Conocimiento (JIISIC 2008). Guayaquil, Ecuador. Enero 2008.

"Una Experiencia de Implantación de COMPETISOFT en una Pequeña

Empresa Desarrolladora de Software."

Jackson Mogrovejo, Abraham Dávila



"Experiencia de Implementación de Mejora de Procesos en dos PYMEs

Desarrolladoras de Software, que poseen certificación ISO9001:2000."

Dianne Vergara, Gonzalo Sánchez. Abraham Dávila



"Mapeo de los Procesos de RUP respecto a MoProSoft."

Katia Canepa, Abraham Dávila

World Congress on Project Management Institute (PMI) Lima Noviembre,

2009 [15]

“Modelo de Procesos de Software para pequeñas y medianas

organizaciones (MoProSoft)”, Medardo DELGADO-PAREDES

"Software Process Improvement and Certification of a Small Company

using the NTP 291 100 (MoProSoft)" en el 13th International Conference

on Product-Focused Software Development and Process Improvement

June 13-15, 2012 [16], Robert Arisaca y Verónica Ñaupac, Abraham

Dávila.

Algunas empresas Mexicanas certificadas que utilizan el modelo.

Magnabyte – Mayorista de Equipos Informáticos [6]

Magnabyte tiene el Nivel 2 de Madurez de Procesos según MoProSoft.

Expert - Sistemas Computacionales S.A. [7]

Expert - tiene el Nivel 1 de Madurez de Procesos según MoProSoft.

Valores Corporativos Softtek S.A. – servicios de TI nearshore [8]

Softtek - tiene el Nivel 2 de Madurez de Procesos según MoProSoft.

PSW Global Solutions - Herramientas de Conocimiento y Tecnología [9]

enfocados a la consolidación del Desarrollo Organizacional de Clase

Mundial.

PSW - tiene el Nivel 1 de Madurez de Procesos según MoProSoft.

15

En el caso peruano,

ASIS TP [10] recibió el 7 de Octubre la certificación de Nivel 1 de madurez

organizacional en la NTP 291.100 (MoProSoft).

Inexxo [11]

magia digital [12]

Nisira Systems (Trujillo) [13]

Microdata (Arequipa) [14]

1.8. Método de Investigación La metodología para llevar a cabo el proyecto es como sigue:

Preparación del ciclo de mejora: Actividad que se inició con la

recopilación de la información de la empresa, luego de ello se definió los

objetivos de la mejora de procesos; basados en la recopilación de la

información de la empresa, para alcanzar tales objetivos se hizo

necesario definir las Fases y Actividades que se llevarían a cabo, así

como también los recursos necesarios, luego de haber definido las fases

y actividades para poder llevar a cabo la mejora de procesos, se hizo

necesario definir un plan de trabajo, donde se detalló el periodo de

tiempo para cada una de las actividades.

Diagnóstico de los procesos: Se realizó una evaluación interna de

procesos para conocer el estado general de los procesos de la empresa

y analizar los resultados con el objetivo de establecer los casos de

mejora y sus prioridades. Esta información la registró en el Plan de

Mejora.

Formulación del Ciclo de Mejora: Luego de realizado el diagnostico

de los procesos, se identificó qué acciones se debían tomar en cada uno

de ellos; diseño o re diseño; según sea su situación. Sin embargo antes

de iniciar la mejora de procesos, se tuvo que dar un valor de importancia

a cada proceso, debido a que según ello se procedió a implementar la

mejora.

Ejecución del Ciclo de Mejora: Ejecución de Mejoras: En esta actividad

se gestionó y ejecutó las mejoras correspondientes a la iteración de

acuerdo con los planes establecidos. Finalmente se analizó las mejoras

que se habían introducido en los procesos de la organización.

Revisión del Ciclo de Mejora: La revisión del ciclo de mejora fue

realizada por un consultor experto, con el objetivo de corregir todas

aquellas deficiencias que se encontraran.

16

1.9. Técnicas, Instrumentos, y Fuentes o Informantes

Para la investigación se utilizará las siguientes técnicas, instrumentos y materiales

de verificación, tal como se señala en la Tabla 1.1:

VARIABLES TECNICAS INTRUMENTOS

DOCUMENTALES

Proyecto

COMPETISOFT-PERÚ

Capacidad de los procesos de Software de la Empresa AQPSIGMA.

Observación,

encuestas,

implementación de

procesos

Ficha de observación

documental,

entrevistas,

Evalprosoft para

evaluación de

procesos,

PmCompetisoft como

modelo de mejora de

procesos

Observación,

encuestas,

implementación de

procesos

Ficha de observación

documental,

entrevistas,

Evalprosoft para

evaluación de

procesos,

PmCompetisoft como

modelo de mejora de

procesos

Tabla 1.1: Variables, técnicas e instrumentos

Fuente: Elaborada por el autor

1.10. Estrategia

Primeramente se realiza la evaluación inicial y en base a ella se elabora el plan

de mejora, de tal forma que, ejecutándola planteando procesos pilotos,

herramientas, documentación especializada, etc. se pretende el objetivo de

alcanzar cierto grado de madurez en los procesos formalizados con la mejora

en la empresa.

1.11. Limitaciones de la Metodología de Investigación

La principal limitación fue el corto tiempo del ciclo de mejora establecida por el

proyecto de 5 a 6 meses, de tal manera que, únicamente se podía tratar algunos

procesos del modelo MoProsoft.

17

CAPITULO II

MARCO DE REFERENCIA

SDAS En esta sección se presenta los conceptos necesarios para la mejor comprensión

del presente trabajo el cual está dividido en las siguientes partes: El análisis de diferentes

modelos de referencia, descripción del proyecto COMPETISOFT y COMPETISOFT2

PERÚ.

2.1. Modelo de Calidad de Procesos de Software

2.1.1. Conceptos

Calidad: La Calidad del Software es “la concordancia con los

requerimientos funcionales y de rendimiento explícitamente

establecidos, con los estándares de desarrollo documentados y con

las características implícitas que se esperan de todo software

desarrollado profesionalmente” [17].

Según la norma ISO 9000:2000, calidad es el grado en el que un

conjunto de características inherentes cumple con los requisitos

establecidos.

W. Edwards Deming [20] indica que: “La calidad es una serie de

cuestionamientos hacia una mejora continua, definidos en términos

de satisfacción del cliente”.

Armad V. Feigenbaum [21], la define como: “La composición total de

las características de los productos y servicios de marketing,

ingeniería, fabricación y mantenimiento a través de los cuales los

productos y los servicios cumplirán las expectativas de los clientes”.

Philip Crosby [22], “Conformidad o cumplimiento con los requisitos” y

Joseph M. Duran [23] como: “La adecuación para el uso, satisfaciendo

las necesidades del cliente”.

A la hora de definir la calidad del software se debe diferenciar entre la

calidad del producto de software y la calidad del proceso de

desarrollo. No obstante, las metas que se establezcan para la calidad

del producto van a determinar las metas a establecer para la calidad

del proceso de desarrollo, ya que la calidad del producto va a estar en

18

función de la calidad del proceso de desarrollo. “Sin un buen proceso

de desarrollo es casi imposible obtener un buen producto.” [18]

Uno de los principales problemas a los que nos enfrentamos a la hora

de hablar de la calidad del software, es el de encontrar un conjunto de

propiedades en un software que nos den una indicación de su calidad.

Es a raíz de esta limitación que surgen los llamados Modelos de

Calidad.

Modelo de Calidad: Según la RAE [19], Modelo es el Arquetipo o

punto de referencia para imitarlo o reproducirlo. En los Modelos de

Calidad, la calidad se define de forma jerárquica y tienen como

objetivo resolver la complejidad mediante la descomposición.

La Calidad del Software debe implementarse en todo el ciclo de vida

del mismo.

Proceso: Según la NTP-ISO 9000:2001 [24], un proceso se define

como "conjunto de recursos y actividades mutuamente relacionadas

o que interactúan, las cuales transforman elementos de entrada en

resultados”. Es así que, en la triada Procesos-Tecnología-Personas

[26], son los procesos los que guían a las personas sobre que

procedimientos y actividades realizar para obtener eficientemente los

productos y la manera de cómo deben utilizar la tecnología para

lograrlo.

Madurez: El nivel de madurez de un proceso, proporciona una

manera de predecir el desempeño y gestión de éste dentro de una

organización. Es también, el grado de mejora para un conjunto de

áreas de procesos [27].

Mejora de Procesos: Según Ian Sommerville [25], la mejora de

procesos, significa entender los procesos existentes y cambiarlos

para y/o reducir los costes y el tiempo de desarrollo. Particularmente,

los procesos de software, comprenden una serie de actividades,

atributos o características (como los productos), tales como: La

comprensión, visibilidad, apoyo, aceptación, fiabilidad, robustez,

mantenibilidad y rapidez.

Pensar en la mejora de procesos, simplemente como la adopción de

métodos o herramientas particulares o utilizar un modelo cualesquiera

sin contemplar las particularidades que toda organización tiene tales

como: Factores organizacionales, procedimientos y estándares que

influyen en el proceso, no es comprender claramente su concepto y

19

la intención que persigue. La mejora de procesos, es en realidad, una

actividad cíclica (fig. 2.1) que comprende tres estados: Proceso de

medición de los atributos del proyecto actual o del producto, Proceso

de análisis y la Introducción de los cambios.

Fig. 2.1 Ciclo de Mejora de Procesos Fuente: [25]

Modelo de Calidad de Procesos: Marco de referencia. Base que

auxilia a elevar la calidad de los procesos de la organización,

contribuyendo, sin dejar de tomar en cuenta las particularidades de

cada organización, a establecer el ciclo de mejora continua para sus

procesos y cuyo resultado es generar productos de alta calidad.

Modelo de Referencia de Procesos: Un Modelo de Referencia,

permite el desarrollo de referencias específicas o de arquitecturas,

por medio del uso de estándares o especificaciones que soportan el

ambiente en cuestión. Un Modelo de Referencia consiste de un

conjunto mínimo de conceptos, axiomas y relaciones propios de un

dominio particular de problema, y es independiente de estándares

específicos, tecnologías, implementaciones, o de cualquier otro

detalle concreto [28].

El Modelo de Referencias de Procesos, ayuda a las organizaciones a

elevar el nivel de madurez y capacidad de los procesos que han

identificado con esta necesidad, así mismo, guían las actividades del

modelo para orientarse y tomar actividades de referencia aplicables

a su entorno y obtener los beneficios y objetivos esperados.

Evaluación: Estimar, apreciar, calcular el valor de algo.

Proceso de Evaluación: Determina el grado en el cual los procesos

contemplados en la organización, ayudan a la necesidad de mejora

Medición

Cambio Análisis

20

de estos procesos de manera continua y contribuyen al logro de los

objetivos de negocio.

2.1.2. Modelos de Evaluación y Mejora de Procesos de Software

Las iniciativas que han ido surgiendo en el mundo para la investigación en

esta área de mejora de procesos, han propiciado el desarrollo de diversos

modelos que proponen diferentes métodos de evaluación de la capacidad

de procesos.

El Modelo de Madurez de la Capacidad CMM y los Métodos más

representativos de evaluación y mejora asociados

o CMM: Desde la década de los años 80 el Instituto de

Ingeniería de Software (SEI, Software Enginieering Institute)

[30], de la Universidad Carnegie Mellon, se ha centrado en

proporcionar la base necesaria para mejorar el desarrollo de

software, considerando a las tareas de desarrollo de software

como una serie de procesos que se pueden definir, medir y

controlar. Como resultado, se han obtenido modelos de

referencia de la capacidad de los procesos y modelos de

evaluación de dicha capacidad.

El modelo Capability Maturity Model CMM [31], contiene los

elementos esenciales para conseguir los procesos eficaces en

uno o más cuerpos de conocimiento, estando estos conceptos,

basados en los conceptos desarrollados por los padres de la

calidad: Crosby, Deming, Juran y Humprey.

A la hora de establecer la madurez de los procesos de una

organización en CMM se establecen 5 niveles de capacidad,

que definen una escala ordinal para representar la evolución

del proceso de software desde el nivel inicial caótico (procesos

ad hoc cuyos resultados no son predecibles), hasta el estado

de mejora continua (maduro).

El modelo de referencia CMM, establece una serie de áreas

clave (hasta un total de 18) agrupadas en los distintos niveles

de madurez. Para que una organización pueda estar en un

determinado nivel de madurez debe de satisfacer los criterios

de evaluación asociados con las áreas clave que pertenecen

a ese nivel y a los niveles anteriores. Cada área clave de

proceso o KPA (Key Process Area), se describe en función de

una serie de prácticas clave (KPs, Key Practices), que a su vez

21

se organizan en una serie de características comunes

(common features).

En el año 2000, el CMM-SW fue actualizado hacia el modelo

CMMI (Capability Maturity Model Integration).

o SCE (Software Capability Evaluation): SCE [32], es el

método desarrollado para evaluar los procesos software de

una organización con el objetivo de determinar su capacidad.

Las principales áreas de aplicación de SCE son: Las selección

del suministrador, la monitorización del proceso y la

evaluación interna. SCE usa el modelo de madurez de

capacidad CMM como modelo de referencia. El objetivo de la

evaluación de SCE es el proceso de software, y en particular,

se centra en conjunto de procesos que se pueden agrupar en

tres categorías: Procesos organizacionales, Gestión de

proyectos y los procesos de ingeniería.

El proceso de evaluación definido en SCE está compuesto

básicamente por las siguientes actividades: Planificar y

preparar la evaluación, llevar a cabo la evaluación, e informar

sobre los resultados de la evaluación.

o CBA-IPI (CMM-Based Appraisal for Internal Process

Improvement): CBA-IPI [33], es un método que facilita a la

organización conocer la capacidad de sus procesos software

mediante la identificación de fortalezas y debilidades y la

relación de estas fortalezas y debilidades en base al modelo

CMM, con el fin de establecer y dar prioridades a planes de

mejora de software y para facilitar que la organización se

centre en la mejora de los aspectos que resulten más

beneficiosos en función de su nivel de madurez y sus

objetivos de negocio.

Los dos principales objetivos de CBA-IPI son:

Dar soporte, habilitar y animar a una organización a la

mejora de los procesos software.

Proporcionar una visión exacta de las fortalezas y

debilidades de los procesos software actuales de la

organización, usando CMM

22

Como modelo de referencia y para identificar las áreas clave

del proceso que es necesario mejorar.

Las actividades y alcance del proceso de evaluación del

método CBA-IPI son básicamente los mismos que en el

método SCE, con la diferencia fundamental de que CBA-IPI es

una evaluación centrada en la mejora de procesos, mientras

que SCE suele orientarse más a la selección de

suministradores, aunque también se puede usar para la

evaluación interna de procesos.

o El Modelo IDEAL: IDEAL [34], desarrollado en el SEI, intenta

dar respuesta a la pregunta: Qué debo hacer, una vez

evaluados mis procesos, para iniciar un programa de mejora y

que actividades debe de incluir el programa?. El modelo

IDEAL, propone el camino de acciones que deben de formar

parte del programa de mejora de procesos de software cuando

una organización desea llevar a cabo las buenas prácticas

recomendadas por el modelo CMM, en el cual se basa.

IDEAL es el acrónimo que corresponde a las iniciales d las

cinco fases del modelo (I: Initiating, D: Diagnosing, E:

Establishing, A: Acting, L: Leveraging)

o Personal Process Software (PSP): En el contexto del modelo

CMM y a la hora de facilitar la aplicación de los procesos de

evaluación y mejora de una organización, es necesario

implantar buenas prácticas en el desarrollo de software.

Con tal fin se desarrolló el método PSP [35], modelo de mejora

de procesos software formado por un conjunto estructurado de

descripciones de procesos, de mediciones y de métodos,

basado en la aplicación de métodos avanzados y tradicionales

de ingeniería al desarrollo de software y orientado a la mejora

individual de cada ingeniero de software.

Según PSP, para realizar un buen trabajo de ingeniería de

software, un técnico debe conocer el tiempo que necesita para

realizar bien su trabajo, planificarlo antes de comenzarlo y

realizarlo de forma correcta.

Entre los beneficios que PSP ofrece a los ingenieros de

software son:

23

Proporcionar una serie de principios al ingeniero para

llevar a cabo un proceso personal disciplinado.

Asiste a los ingenieros en la realización de planes

precisos.

Determina los pasos que los ingenieros deben seguir

para mejorar la calidad del producto.

Determina el impacto que los cambios de proceso

tienen sobre el rendimiento del ingeniero.

o Team Software Process (TSP): TSP [35], ayuda a conformar

equipos para el desarrollo de software de calidad, proporciona

un marco de trabajo que se construye sobre la base de PSP,

con fases de desarrollo bien definidas, en el que los productos

de software se generan en varios ciclos.

TSP se basa en los siguientes principios:

Los técnicos conocen mejor su trabajo y por ello

pueden realizar las mejores planificaciones.

Un seguimiento preciso de un proyecto requiere planes

bien detallados y datos precisos.

Para minimizar el tiempo del proyecto, los ingenieros

deben equilibrar su carga de trabajo.

Para maximizar la productividad, el primer foco de

atención debe de ser la calidad.

TSP está formado por dos componentes primarios bien

diferenciados que abarcan distintos aspectos del trabajo en

equipo:

Formación del equipo de trabajo

Gestión del equipo de trabajo

o People Capability Maturity Model (People-CMM): El modelo

de madurez People-CMM [36], es un marco de trabajo que

ayuda a las organizaciones a resolver de forma exitosa los

aspectos críticos relacionados con sus recursos humanos.

Está basado en las mejores prácticas en campos como los

recursos humanos, la gestión del conocimiento y desarrollo

organizacional para guiar a las organizaciones a la hora de

mejorar sus procesos de gestión y desarrollo de sus

empleados.

24

El modelo está diseñado sobre las premisas de que las

prácticas de mejoras de los empleados no tendrán éxito al

menos que el comportamiento de la organización cambie para

darles soporte. Es un modelo basado en el proceso que asume

que las prácticas de los empleados son procesos estándares

de la organización que pueden ser mejorados de forma

continua, mediante los mismos métodos que se utilizan para

otros procesos de negocio.

CMMI y SCAMPI: El modelo CMMI [37], es un marco creado a partir

de los modelos mencionados. Su desarrollo ha sido realizado para

que pueda adaptarse a distintas disciplinas. CMMI al igual que CMM,

proporciona un enfoque disciplinado para mejorar los procesos de una

organización, ayudando a establecer los objetivos de mejora y las

prioridades, proporcionando guías para implantar procesos de calidad

así como un marco de referencia para la realización de las

evaluaciones. En cambio, CMMI basa toda la aplicación en los

principios de CMM a lo largo de todo el ciclo de vida de ingeniería, no

únicamente al ciclo de vida del desarrollo del producto software.

Un aspecto importante y novedoso en el modelo CMMI, es que usa

dos tipos de representaciones de sus modelos, incluyendo de esta

forma la representación CMM y la ISO 15504, representación por

etapas y continuo.

o Representación por etapas: Un modelo por etapas

proporciona un marco predefinido para la mejora

organizacional basada en el agrupamiento y ordenación de

procesos y en las relaciones organizacionales asociadas. El

término por “etapas”, viene de la forma en la que el modelo

describe este marco como una serie de “etapas”,

denominadas “niveles de madurez”.

o Representación continua: Los modelos continuos

proporcionan una guía en el cual debería realizarse el proceso

de mejora. Se denomina continuos porque ninguna etapa

discreta está asociada con la madurez de la organización.

Como los modelos por etapas, los modelos continuos tienen

áreas de procesos que contienen prácticas. A diferencia de los

modelos por etapas, las prácticas de un área de procesos en

un modelo continuo, están organizadas de forma que dan

soporte a la mejora y al crecimiento de procesos individuales.

Desde el punto de vista de evaluación de los procesos, el

concepto clave de CMMI lo constituyen las áreas de proceso.

25

El modelo CMMI-SE/SW/IPPD tiene 24 áreas de proceso que

definen la dimensión del modelo. Estas áreas son las mismas

en toda representación de la arquitectura de CMMI. En la

representación continua, las áreas de proceso se agrupan por

las categorías: Gestión de Procesos, Gestión de Proyectos,

Ingeniería y apoyo y soporte.

El modelo CMMI en su enfoque escalonado contempla cinco

niveles de madurez (fig. 2.2):

Inicial o Nivel 1: El proceso de software es

impredecible, sin control y reactivo. El éxito de los

proyectos depende del talento de los individuos.

Gestionado o Nivel 2: El proyecto es gestionado tanto

en costos, calendario y funcionalidad. Hace posible

obtener exitosos resultados en proyectos similares.

Definido o Nivel 3: Existe un proceso de software

documentado y estandarizado, que es utilizado por los

proyectos.

Cuantitativamente Gestionado o Nivel 4: La

Organización recolecta métricas del proceso software

y de los entregables para la realización de controles

cuantitativos.

Optimizado o Nivel 5: Existe una mejora continua del

proceso software.

Fig. 2.2 CMMI Stage Maturity Levels

Fuente: [37]

26

SCAMPI [38], se usa este modelo para la evaluación basada en

CMMI. SCAMPI es un método de evaluación aplicable a un

amplio rango de modelos de evaluación, incluyendo tanto las

evaluaciones internas (valoraciones), como la determinación de

prioridades externas.

SCAMPI es un método de evaluación de clase A, de acuerdo a

la clasificación establecida por ARC (Appraisal Requirement for

CMMI) y puede dar soporte a la conducción de evaluaciones

basadas en ISO/IEC 15504.

SCAMPI incorpora las mejores prácticas del dominio de

evaluación, y está basado en las características de anteriores

métodos significativos de evaluación como son:

CMM-Based Appraisal for Internal Process

Improvement (CBA IPI) V1.1

Electronic Industries Alliance/Interim Standard (EIA/IS)

731.2 Appraisal Method (EIA 1998)

Software Capability Evaluation (SCE) V3.0 Method

Description

Al igual que los métodos de evaluación CBA/IPI y SCE las

principales fases de la evaluación SCAMPI son:

Planificación y preparación de la evaluación

Realización de la evaluación

Informe de resultados

El Modelo SPICE: El proyecto SPICE [39], representa el mayor marco

de colaboración internacional establecida con la finalidad de desarrollar

un estándar de evaluación de procesos de software. Se inició en 1993

con tres objetivos clave:

Desarrollar un marco de trabajo común para la

evaluación y mejora de procesos de software.

Aplicar el estándar desarrollado en la industria del

software.

Promover la transferencia de conocimiento y de

tecnología sobre procesos de software entre todas las

empresas.

ISO/IEC 15504, es un estándar internacional que es aplicable a

cualquier organización/empresa que quiera conocer y mejorar la

27

capacidad de sus procesos, independientemente del tipo de

organización, del modelo de ciclo de vida adoptado, de la metodología

de desarrollo y de la tecnología utilizada.

o El estándar ISO/IEC 15504 [40] [41] [42] [43]

El estándar completo vigente se denomina ISO/IEC 15504

Information Technology-Process Assessment, y se divide a su

vez en cinco partes:

ISO/IEC 15504-1:2004. Part 1: Concepts and

vocabulary. Representa una introducción general a la

norma, proporcionando una guía de uso de la misma.

ISO/IEC 15504-2:2003/Cor 1:2004. Part 2: Performing

an assessment. Define los requisitos que debe cumplir

una evaluación para que produzca resultados

repetibles, fiables y consistentes.

ISO/IEC 15504-3:2004. Part 3: Guidance on performing

an assessment. Establece una guía para la realización

de evaluaciones de procesos, interpretando los

requisitos de las partes normativas para diferentes

contextos de evaluación.

ISO/IEC 15504-4:2004. Part 4: Guidance on use for

process improvement and process capability

determination. Proporciona una guía para utilizar los

resultados de una evaluación en la mejora de los

procesos evaluados.

ISO/IEC 15504-5 Part 5: An exemplar Process

Assessment Model. Proporciona un modelo totalmente

compatible con la parte normativa, que incluye un

conjunto de indicadores que facilita el cálculo de la

capacidad de procesos.

Además de algunos pequeños cambios, como los producidos

en el nombre y en el número de partes, la revisión del estándar

ha proporcionado una arquitectura más abierta con diferentes

conjuntos de procesos, que podrán ser definidos según distintos

Modelos de Procesos de Referencia PRM’s (Process Reference

Models). En ISO/IEC 15504, la dimensión de procesos viene

representada por un Modelo de Procesos de Referencia

externo, que define un conjunto de procesos caracterizados

según su propósito y las salidas que genera. Los RPM’s

existentes o que se encuentran en desarrollo cubren las

siguientes áreas:

28

Procesos del ciclo de vida de software. Estudio de la

norma a través de la norma ISO/IEC 12207 AMD1/2

Procesos del ciclo de vida del sistema. Estudio a través

de la norma ISO/IEC 15288

Human Centered Lifecycle Process. Estudio a través de

la norma ISO/IEC 18529

Procesos de desarrollo basado en componentes.

Estudio a través del proyecto OOSPICE (Object

Oriented SPICE)

Procesos de Sistemas de gestión de calidad. A través de

la iniciativa SPICE for 9000 (S9K)

Software embebido para la automoción. A través de una

iniciativa de Automotive SPICE

La dimensión de capacidad ha sido también actualizada con el fin de

eliminar los puntos débiles detectados durante la aplicación de ISO/IEC

TR 15504 y para representar un alineamiento completo con la norma

ISO 9001:2000. Además de algunas modificaciones en la ordenación

de los atributos de proceso, los principales cambios se han producido

en el marco de medida para los niveles de capacidad 2 y 3,

incorporando un detalle mucho mayor e incluyendo una trazabilidad con

ISO 9001:2000.

Bootstrap: Es el resultado del proyecto ESPRIT 5441, que fue llevado

a cabo entre septiembre de 1991 y febrero de 1993. El principal objetivo

del proyecto era acelerar la aplicación tanto de los principios como de

la tecnología relacionada con la Ingeniería de Software a la industria

del software en Europa. Como resultado se obtuvo el método Bootstrap

que describe el proceso de evaluación desarrollado para determinar si

una organización se encuentra en cierto nivel de madurez, identificando

los puntos débiles, los puntos fuertes y ofreciendo las pautas de mejora

[44]. Bootstrap [45], una metodología de evaluación y mejora de

procesos de software, se basa en evaluar el nivel de capacidad y de

productividad de una Unidad de Desarrollo Software, SPU (Software

Producing Unit) y consiste en:

o Evaluar un SPU y sus proyectos, proporcionando perfiles

analíticos para cada uno de ellos, de forma que se establezca

la madurez de su proceso, identificando sus puntos fuertes y

débiles.

o Deducir las áreas de mejora a partir de los perfiles analíticos.

o Transformar el plan de acción en una serie de mini proyectos

para implementar mejoras recomendadas en el plan de acción

anterior.

29

Compatible con el que se utiliza en ISO/IEC 15504, que también es

equivalente al modelo IDEAL.

Las Normas de la Familia ISO 9000: Las normas de la familia ISO

9000 [46] desarrolladas a lo largo de la década de los ochenta a través

del comité técnico ISO/TC-176, basándose en todas las experiencias y

normas existentes relativas a la industria y al comercio en general, la

industria militar y nuclear. Fueron aprobadas en abril de 1987, con el

objetivo de establecer los principios a seguir sobre sistemas de calidad

y el aseguramiento de las mismas en una organización,

independientemente del sector de actividad. Presentamos (Tabla 2.1)

la diferencia entre ISO 9000, 9001, 9002, 9003 y 9004 el cual se

encontraba en el grado de cobertura en el ciclo de creación de un

producto.

Código Nombre

ISO/IEC 9000 Norma para la gestión y aseguramiento de

la calidad. Directrices de selección y uso:

ISO 9000-1:

Directrices generales para aplicar las

normas 9001, 9002, 9003:ISO 9000-2

Guía para aplicar las normas 9000 a

empresas de software: ISO 9000-3

Guía para la gestión de un programa de

seguridad: ISO 9000-4

ISO/IEC 9001 Modelo para el aseguramiento de la

calidad en el diseño/desarrollo, las

producción, la instalación y el servicio

postventa.


calidad en la producción y la instalación


calidad en la inspección y en los ensayos

finales o pruebas

ISO/IEC 9004-1:1994 Gestión de la calidad y elementos del

sistema de la calidad. Guía para

establecer el sistema de calidad:

Directrices para los servicios: ISO 9004-2

Directrices para los materiales

procesados: ISO 9004-3

Directrices para la mejora de la calidad:

ISO 9004-4

ISO/IEC 9000-3:1997 Guía de aplicación de la norma ISO

9001:1994 al desarrollo, suministro y

mantenimiento del software.

Tabla 2.1: Las normas familia ISO 9000

Fuente: [46]

30

En el caso específico del desarrollo de software, la norma ISO/IEC

9000-3:1997 constituía una guía de implantación de la norma ISO

9001:1994 para el desarrollo, suministro y mantenimiento de software.

Con la aparición de la versión en el año 2000, las normas ISO 9001,

9002 y 9003 se unificaron en una sola, tomando el nombre de ISO

9001:2000

o ISO 9001:2000: ISO 9001:2000 [46], especifica los requisitos

para un sistema de gestión de calidad cuando una organización:

Necesita demostrar su capacidad de proporcionar de

forma coherente productos que satisfagan los requisitos

del cliente y los reglamentos aplicables.

Aspira a aumentar la satisfacción del cliente, a través de

la aplicación eficaz del sistema, incluyendo procesos

para la mejora continua del sistema y el aseguramiento

de la conformidad con los requisitos del cliente.

o ISO 9001:2008: El objetivo de ISO 9001:2008 [47], es

proporcionar un conjunto de requisitos, que si se implementan

de manera adecuada, darán confianza a sus proveedores o

clientes que sus servicios o productos se realizan o ejecutan de

forma estructurada y organizada.

El estándar ISO 9001:2008 actúa bajo los fundamentos de la

norma ISO 9000, cuyos principios son:

Enfoque en los clientes

Liderazgo Los líderes

Compromiso del personal

Enfoque a procesos

Enfoque del sistema a la gestión Identificar, entender,

gestionar un sistema de procesos mejora la eficiencia y

eficacia de la organización.

Mejora continua

Acercamiento a la toma de decisiones

Relación mutuamente beneficiosa con los proveedores

o La guía TickIT: Como resultado de un informe encargado por

el DTI (Department of Traede and Industry) del Reyno Unido,

que documentaba el estado de la calidad de software y de sus

aplicaciones en las empresas de desarrollo, se pudo observar

que había cierto desinterés en adoptar la norma ISO 9000 y que

sus argumentos se centraban en el alto nivel de generalidad de

31

la norma, y la terminología era difícil de interpretar. Así pues,

que el gobierno y a través de la BCS (British Computer Society),

decidió iniciar el proyecto TickIT [48] en el año 1991.

Actualmente está en funcionamiento, siendo necesaria una gran

revisión de las versiones anteriores para poder dar soporte a los

nuevos requisitos de gestión de calidad estándar. En la guía se

puede encontrar todo un conjunto de material soporte, entre el

que se incluye:

Guías actualizadas y mejoradas para la interpretación y

aplicación de la ISO 9001:2000 al desarrollo de software.

Una información general sobre la aplicación de TickIT en

la mejora de procesos de software.

Referencias bien detalladas de todos los procesos del

ciclo de vida del software según ISO/IEC 12207.

Guías actualizadas y mejoradas para los proveedores.

Guías actualizadas y mejoradas para los auditores.

Guías actualizadas y mejoradas para los clientes.

Casos de estudio de como otras empresas han

adoptado otras normas.

o ISO/IEC 9003:2004: La versión vigente de la norma ISO/IEC

9003:2004 (ISO, 2004e), Software engineering-Guidelines for

the application of ISO 9001:2000 to computer software, tiene

sus orígenes en la Antigua ISO 9000-3:1997, guía para la

aplicación de la norma ISO 9001:1994 al desarrollo, suministro,

instalación y mantenimiento de software.

Este estándar internacional, tal como su nombre lo indica,

ofrece una guía de la aplicación de la ISO 9001:2000 en

empresas desarrolladoras de software. Para cada apartado de

la 9001:2000, ofrece una descripción de la interpretación o

adaptación que debe realizarse en el caso de empresas

desarrolladoras de software.

o ISO/IEC 12207:2004: Este estándar establece un marco común

orientado a los procesos del ciclo de vida del software, con una

terminología bien definida. Además incluye procesos que se

pueden emplear para definir, controlar y mejorar los procesos

del ciclo de vida del software.

La norma agrupa las actividades que se pueden realizar durante

el ciclo de vida del software en cinco procesos principales, diez

32

procesos de soporte, siete procesos organizacionales y el

proceso de adaptación. Cada proceso se divide en un conjunto

de actividades que a su vez se dividen en un conjunto de tareas

[49].

La estructura de la norma consiste en [50]:

PROCESOS PRINCIPALES

o Adquisición

o Suministro

o Desarrollo

o Explotación

o Mantenimiento

PROCESOS DE SOPORTE

o Documentación

o Gestión de configuración

o Aseguramiento de la calidad

o Verificación

o Validación

o Revisión conjunta

o Auditoria

o Resolución de problemas

o Usabilidad

o Evaluación del producto

PROCESOS ORGANIZACIONALES

o Gestión

o Infraestructura

o Mejora

o Recursos humanos

o Gestión de activos

o Gest. Prog. Reutilización

o Ingeniería de dominio

PROCESO DE ADAPTACIÓN

COMPETISOFT: La industria de software representa una actividad

económica de suma importancia para muchos países del mundo,

siendo una oportunidad para los países en vías de desarrollo ven viable

y desean aprovechar. Esta industria a nivel mundial está formada en

mayor parte por PYMES desarrolladoras de software. El proyecto

COMPETISOFT (Mejora de procesos para fomentar la competitividad

de la PYMES desarrolladora de software en Iberoamérica) [51], es una

iniciativa integradora de diferentes propuestas de mejora de procesos

33

software para PYMES desarrolladoras de software, teniendo en cuenta

para su desarrollo las características propias para este tipo de

organizaciones. Este proyecto también tiene en cuenta algunos

elementos de los estándares internacionales creados por instituciones

como el SEI, ISO, entre los que destacan CMMI, ISO/IEC 12207,

ISO/IEC 15504.

El proyecto COMPETISOFT, es financiado por CYTED (Programa

Iberoamericano de Ciencia y Tecnología para el desarrollo), con el

objetivo de incrementar el nivel de competitividad de las PYMES

desarrolladoras de software en Iberoamérica 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 evaluación y certificación de la industria

de software.

BRASIL: MPS.BR - Mejora de Proceso del Software Brasileño: La

empresa SOFTEX de Brasil, que tiene como misión transformar Brasil

en un centro de excelencia mundial en la producción y exportación de

software, coordina un proyecto para la mejora de procesos software

denominado Proyecto mps Br. Este proyecto engloba dos modelos [52]:

Modelo de negocio y modelo de referencia.

El modelo contempla los 22 procesos de la norma ISO 12207 (ISO,

2002) y 7 niveles de madurez: A (en optimización), B

(cuantitativamente gestionado), C (gestionado), D

(Grandemente/largamente definido), E (parcialmente definido), F

(gestionado), G (parcialmente gestionado). Con esta mayor

granularidad en los niveles se pretende facilitar una implementación

más gradual, adecuada y en plazos más cortos para las PYMES en

Brasil.

El método de evaluación, se basa en la norma ISO 15504. El grado de

implementación de una práctica se evalúa de acuerdo a 4 niveles:

Totalmente implementado, bastante implementado, parcialmente

implementado, no implementado; y se basa en 3 tipos de indicadores:

directos (productos intermedios), indirectos (documentos que indican

que una actividad fue realizada), y afirmaciones (resultantes de

entrevistas).

MEXICO - MoProSoft: MoProSoft [53] surge como respuesta a la

dificultad de las empresas mexicanas desarrolladoras de software, en

su mayoría pymes, por implementar los diferentes modelos de mejora

de procesos. El principal requerimientos de estas empresas en base a

34

su realidad era que necesitaban un modelo fácil de entender, práctico

y económico. Hanna Oktaba lideró el proyecto de desarrollar un modelo

de procesos para la industria de software para pymes surgiendo

MoProSoft [54].

El objetivo de MoProSoft es elevar la capacidad de las organizaciones

para ofrecer servicios con calidad y alcanzar niveles internacionales de

competitividad.

El modelo considera los tres niveles básicos de la estructura de la

organización que son: la Alta dirección, Gerencia y Operación, dividido

en nueve procesos [55] (fig. 2.3).

Categoría de Alta dirección: Aborda las prácticas de alta

dirección relacionadas con la gestión del negocio. Proporciona

los lineamientos a la categoría de gerencia y se retroalimenta

con la información generada por ésta. Contiene el siguiente

proceso:

o Gestión de Negocios

Categoría de Gerencia: Aborda las prácticas de gestión en

función de los lineamientos establecidos por la categoría de alta

dirección. Recibe y evalúa la información generada por la

categoría de operación y comunica los resultados a la categoría

de alta dirección.

Está integrada por los siguientes procesos:

o Gestión de Procesos

o Gestión de Proyectos

o Gestión de Recursos

Recursos Humanos y Ambiente de Trabajo

Bienes, servicios e Infraestructura

Conocimiento de la Organización

Categoría de Operación: Aborda las prácticas de desarrollo y

mantenimiento de software. Esta categoría realiza sus

actividades de acuerdo a lo proporcionado por la categoría de

gerencia y entrega los resultados al mismo. Está compuesta por

los siguientes procesos:

o Administración de Proyectos Específicos

o Desarrollo y Mantenimiento de software

35

Fig. 2.3 Modelo de Procesos de Software - MoProSoft

Fuente: [53]

EvalProSoft: EvalProSoft [56], se describe como un método de

evaluación de procesos para la industria de software que brinde a la

organización solicitante un perfil del nivel de capacidad de los procesos

implantados y un nivel de madurez de capacidades de la organización.

Este método de evaluación se aplica a las organizaciones dedicadas al

desarrollo y/o mantenimiento de software. EvalProSoft se utiliza como

modelo de procesos de referencia, los requisitos de procesos basado

en MoProSoft.

o Modelo de Capacidades de Proceso: La capacidad de proceso

se evalúa en una escala de 0 a 5. El valor cero se asocia al nivel

de capacidad más bajo, y significa que no se alcanza el

propósito del proceso, por el contrario el valor 5 se asocia al

nivel de capacidad más alto y significa que se logran las metas

de negocio actuales y proyectadas a través de la optimización y

mejora continua del proceso (Fig. 2.4)

o Calificación de los atributos del proceso: Es el grado del

cumplimiento del atributo del proceso se califica usando una

escala ordinal (Fig. 2.5)

o Calificaciones del nivel de capacidad del proceso: Es el nivel de

capacidad alcanzado por proceso. El nivel de capacidad del

proceso es el nivel cuyo cumplimiento de los atributos es, al

menos, ampliamente alcanzado y el cumplimiento de los

atributos de los niveles inferiores es completamente alcanzado

(Fig. 2.6)

36

Fig. 2.4 Niveles de capacidad de procesos de ISO/IEC 15504

Fig. 2.5 Calificacion de los atributos de los procesos

Fuente: [57]

Fig. 2.6 Calificacion del nivel de capacidades del proceso

Fuente: [56]

37

Agile SPI: Agile SPI [57], se lo describe como un framework de SPI

(Software Process Improvement) caracterizado por:

o Ser un framework basado en modelos livianos

o Estar acorde con una industria dinámica, creativa, innovadora e

incierta como lo es la industria del software.

o Guiar la mejora de los procesos de desarrollo de software de

forma ágil.

Con esto se buscó mantener una motivación del personal frente al

programa, a través de resultados de mejora permanentes y eliminar los

riesgos del proyecto en las primeras fases. Agile SPI se ha formado a

partir de:

o Modelo de calidad: Agile SPI – Light Quality Model.

o Modelo de evaluación: Agile SPI – Light Evaluation

Model.

o Modelo de métricas: Agile SPI – Light Metrics Model.

Una característica fundamental es el de desarrollar con independencia

los modelos presentes, de tal forma que fuera adaptable a las

necesidades de la organización.

COLOMBIA: SIMEP-SW: SIMEP-SW [58], proyecto financiado por

Colciencias y la Universidad del Cauca (Colombia). La finalidad del

proyecto fue poder crear, aplicar y probar un sistema de mejora.

Además, el proyecto incorporó modelos de calidad, mejora y evaluación

internacionales que han sido adaptados a las características de las

empresas vinculadas a la industria del Software en Colombia, se definió

una estrategia de mejora, la cual intenta cubrir dos esfuerzos: el de

aliviar requisitos y guiar en el proceso de mejora, así como el de generar

un conjunto de recomendaciones prácticas para la implementación de

los requisitos del proceso software.

PMCOMPETISOFT: PmCompetisoft [59] es un proceso para guiar la

mejora de procesos software en pequeñas empresas. Ha sido

desarrollado como parte de COMPETISOFT, proyecto que incluye un

modelo de referencia de procesos, un modelo de evaluación y un

modelo de mejora. PmCompetisoft integra el modelo de mejora y es un

proceso explícito que proporciona una guía, paso a paso, para llevar a

cabo esfuerzos de mejora de procesos. Adicionalmente,

PmCompetisoft es un proceso que sigue un enfoque iterativo e

incremental.

38

2.2. VSE (de Very Small Entities): El proyecto VSE (de Very Small Entities) [60], es

un esfuerzo internacional focalizado en organizaciones pequeñas (áreas de

sistemas, unidades de informática o empresas) que desarrollan software y cuyo

resultado se traduce en el nuevo estándar internacional ISO/IEC 29110. El WG24

de la ISO/IEC JTC1/SC7 tiene bajo su responsabilidad el proyecto VSE y de

manera complementaria y voluntaria también está desarrollando material de libre

disponibilidad para que las organizaciones puedan adoptar con facilidad (de

manera comparada) este nuevo estándar internacional.

La ISO/IEC 29110 tiene como propósito contribuir al incremento de la

competitividad de la VSE a través de la adopción de buenas prácticas de clase

mundial presentadas de manera más accesible para los profesionales de la VSE.

La 29110 está basado en la ISO/IEC 12207, ISO/IEC 15289 y MoProSoft y en la

experiencia de iniciativas de mejora de proceso en pequeñas organizaciones que

desarrollan software en varios países.

2.3. Proyecto COMPETISOFT – PUCP: El proyecto COMPETISOFT-PUCP es un

esfuerzo continuo que el Grupo de Investigación y Desarrollo en Ingeniería de

Software (GIDIS) de la Pontificia Universidad Católica del Perú lleva a cabo a favor

de la industria de software. El investigador principal y líder del proyecto es el Dr.

Abraham Dávila.

En el proyecto se apuesta por el mejoramiento sostenido de los procesos de

software en base a un modelo que se ajuste a las necesidades de las

organizaciones vinculadas al desarrollo de software, que en su mayoría son

pymes. El presente proyecto se denomina “Mejora de proceso de software de una

empresa desarrolladora de software: COMPETISOFT-PERÚ” y es ejecutado por

estudiantes y bachilleres de la especialidad de Ingeniería Informática de la

Pontificia Universidad Católica del Perú, para quienes representa su respectivo

proyecto de fin de carrera (tesis). El proyecto consiste en la participación de un

estudiante (miembro de la Universidad) en una empresa comprometida con el

proyecto y se firma un acuerdo de confidencialidad para garantizar la integridad

de la organización involucrada. Este acuerdo es respetado hasta entre los demás

estudiantes, los cuales tienen la responsabilidad de no divulgar información

sensible de la organización.

Luego, en el 2009, se consiguió extender el proyecto a otras dos ciudades

(Arequipa y Trujillo) con fondos de la DGI-008-2009-PUCP y de algunas

empresas. También participaron UNSA, UCSM y UPN en esta etapa.

Durante este año 2010, ACKLIS y PUCP con un fondo de FINCYT (09 PITEA-

FINCyT-2010) ha permitido concretar este primer logro con empresas. Contar con

un modelo de certificación local basado en estándares internacionales (ISO/IEC

39

15504) a costos accesibles para las PYMES de la industria peruana de software

y tener la primera empresas certificada. Dos empresas más de Lima serán

evaluadas y una de Trujillo y una de Arequipa en los primeros meses también,

con la idea de obtener la Certificación.

El Proyecto continúa bajo la denominación de cMoProSoft (COMPETISOFT 3era

etapa) cuyo objetivo en esta etapa es la de apoyar la adopción de modelos de

calidad de software adecuados a nuestra industria de software, en particular el

nuevo Proyecto VSE (que también está basado en MoProSoft)[60], para el cual

se llevará - consensuada con otros países - una propuesta de un Modelo de

Evaluación de Procesos a la reunión de lSO/IEC JTC1/WG24 (grupo de trabajo

que ve la VSE); propuesta que además está basada en ISO/IEC 15504.

40

CAPITULO III

EMPRESA EN ESTUDIO

3.1. Generalidades

3.1.1. Descripción de la Empresa

AQPsigma, empresa desarrolladora de software que ofrece servicios de

desarrollo de sistemas, auditorias, capacitaciones y soporte técnico.

Cuenta con una experiencia de más de seis años dedicada a brindar

soluciones TI que se ajustan a cada modelo de negocio, en procesos,

actividades y requerimientos legales del gobierno.

AQPsigma cuenta con un equipo humano capacitado con una gran

predisposición al trabajo coordinado y con buenas prácticas. Está

conformado por 4 Ingenieros, analistas y 2 practicantes universitarios. Así

mismo, AQPsigma está participando en proyectos financiados por el

Programa de Ciencia y Tecnología del gobierno – FINCyT y construcción

de software hospitalario y ERPs..

3.1.2. Organigrama

A continuación en la Fig. 3.1 mostramos el organigrama de la empresa

AQPSIGMA.

Fig. 3.1 Organigrama Empresa AQPSIGMA

Fuente: Elaboración propia

Gerente General

Jefe de Proyecto

Analista

Desarrollador

Desarrollador

Arquitecto

Tester

41

3.2. Evaluación Inicial

En esta sección se presenta el propósito de la evaluación, los objetivos de negocio

y el alcance de procesos previsto de acuerdo al modelo MoProSoft del proyecto

COMPETISOFT-PERÚ.

3.2.1. Propósito de la Evaluación

Esta evaluación tiene como propósito determinar el perfil de capacidades

de la organización para definir un plan de mejora de procesos respecto a

un modelo de procesos definido previamente. La evaluación usada es del

tipo ligera (o no rigurosa) para que pueda ser completada en un tiempo

comparativo muy breve.

El entregable de esta evaluación se denomina COMPETISOFT 2 Perú

Informe de Evaluación Inicial AQPsigma.c1.02.01.inf.eval.ini.01.v.1

(Anexo 1). El documento cotiene las siguientes secciones:

Evaluación inicial

Documentos referenciados

Perfil de capacidades

Resultados obtenidos

Datos técnicos del informe

3.2.2. Objetivos de la Empresa

Como parte del trabajo inicial en la empresa se obtuvieron los siguientes objetivos

de negocio:

Objetivo de negocio 1. Posicionarse como empresa

desarrolladora de software en la región sur del Perú.

Objetivo de negocio 2. Exportar software.

Objetivo de negocio 3. Productos con calidad.

Objetivo de negocio 4. Incrementar la productividad.

Objetivo de negocio 5. Crecer en ventas.

3.3. Diagnóstico Inicial

Luego de realizar la evaluación Inicial a la empresa AQPSIGMA y como parte del

proyecto COMPETISOFT-PERÚ, se realizó la evaluación para identificar el

estado inicial de los procesos de la organización tomando a MoProSoft como

modelo de referencia.

En esta sección se presenta una vista global, de manera gráfica, de las

capacidades de procesos de la organización (perfil de capacidades) evaluada con

42

una técnica de evaluación ligera. Asimismo, se presenta la interpretación de los

datos y el nivel de capacidad alcanzado.

En la Tabla 3.1 se encuentran los datos globales de cada proceso como un

porcentaje del cumplimiento de los procesos y en la Fig. 3.2, se encuentra el perfil

de capacidades que corresponde con los porcentajes.

El personal que participó de las entrevistas fue:

• Gerente General

• Gerente de Proyectos

Procesos

GNeg GProc GProy GRec GRHAT GBSI GCO APE DMS NivRef

% cumplimiento 22.7 6.3 42.0 15.6 47.9 30.6 23.3 47.7 61.9 100

Grado de cumplimiento

P N P P P P P P A

Nivel 0 0 0 0 0 0 0 0 1 5

Tabla 3.1. Nivel de Cumplimiento de Procesos al Inicio del Ciclo de Mejora Fuente: Elaboración propia

Fig. 3.2. Perfil de Capacidades al Inicio del Ciclo de Mejora


Podemos observar que 1 de los 9 procesos alcanzaron un Nivel 1, esto nos indica

que el 11.11 % de los procesos de la empresa se encuentran en un Nivel 1-

Proceso Realizado, de acuerdo a la Norma ISO/IEC 15504 – 2. Estos procesos

son:

Desarrollo y Mantenimiento de Software. DMS.

Los procesos que obtuvieron un Nivel 0 –Proceso Incompleto- son:

Perfil de Capacidades de Procesos

22.7

6.3

42.0

15.6

47.9

30.623.3

47.7

61.9

100

0

20

40

60

80

100

GNeg GProc GProy GRec GRHAT GBSI GCO APE DMS NivRef

% cumplimiento

43

Gestión de Negocios. GNeg.

Gestión de Proceso. GProc.

Gestión de Proyectos. GProy.

Gestión de Recursos. GRec.

Gestión de Recursos Humanos y Ambiente de Trabajo. GRHAT.

Gestión de Bienes Servicios e Infraestructura. GBSI

Gestión de Conocimiento de la Organización. GCO.

Administración de Proyectos Específicos APE.

3.3.1. Proceso: Gestión de Negocio

Según la evaluación, el logro de este proceso es: 22.7%

El gráfico que presenta la distribución de calificaciones de las respuestas

se presenta en la Fig. 3.3.

Fig. 3.3. Distribución de puntuación de Gestión de Negocios


De acuerdo a los resultados obtenidos, se desprenden las siguientes

fortalezas y debilidades:

Fortalezas

Las siguientes son las fortalezas identificadas para el proceso Gestión de

Negocios:

Distribución de Respuestas de Gestión de Negocio

NUNCA, 36%

POCO, 41%

REGULAR, 18%

CASI, 5% SIEMPRE, 0%

NUNCA

POCO

REGULAR

CASI

SIEMPRE

44

El Grupo Directivo tiene conocimiento para llevar a cabo la

Planificación Estratégica y estar comprometido con este.

El Responsable de Gestión de Negocios tiene cierto

conocimiento de las actividades necesarias para definir e

implantar exitosamente el PGNeg.

El Grupo de Gestión tiene cierto conocimiento para administrar

los proyectos e implantar los procesos definidos.

Se articula y documenta casi siempre la Planificación Estratégica.

Se entiende regularmente la situación actual que implica análisis

de la situación interna identificando fortalezas y debilidades.

Debilidades

Las siguientes son las debilidades identificadas para el proceso Gestión de

Negocios. No se manejan o no se generan adecuadamente:

Se elabora pocas veces el artefacto Factores Externos

(Tendencias, tecnológicas, clientes y competidores).

Se realiza pocas veces el artefacto Reportes Financieros.

Define o actualiza pocas veces la Estrategia de Recursos.

No se elaboran entregables de Plan de Adquisiciones

Capacitación.

No se definen ni se actualizan los objetivos y estrategias que

especifiquen el medio para alcanzar estos objetivos.

No se definen la Cartera de Proyectos necesaria.

No se define o actualiza la Estructura de la Organización

adecuada para la implantación del plan estratégico.

No se define o actualiza la Estrategia de Recursos que implica

identificar los elementos de la Base de Conocimiento.

No se calcula el presupuesto requerido para lograr la

implantación del Plan Estratégico y determinar el periodo para el

que se aplicara.

No se elabora o actualiza el Plan de Adquisiciones y

Capacitación para el proceso de Gestión de Negocio.

3.3.2. Proceso: Gestión de Procesos

Según la evaluación, el logro de este proceso es: 6.3 %


se presenta en la Fig. 3.4

45

Fig. 3.4 Distribución de puntuación de Gestión de Procesos


.



Fortalezas


Procesos:

El Responsable de Gestión de Negocios tiene el conocimiento para

llevar a cabo la Gestión de Procesos y sobre todo estar comprometido

con este.

El Responsable de Gestión de Procesos tiene conocimiento de las

actividades necesarias para definir e implantar exitosamente el proceso

de Gestión de Procesos.

Debilidades


Procesos. No se manejan o no se generan adecuadamente:

No realiza el artefacto Plan Estratégico que contiene Procesos

Requeridos.

No se realiza el entregable Plan de Procesos que contiene la definición

de elementos de procesos.

Distribución de Respuestas de Gestión de Procesos

NUNCA, 86%

POCO, 7%

REGULAR, 4%

CASI, 4%

SIEMPRE, 0%

NUNCA

POCO

REGULAR

CASI

SIEMPRE

46

No se elabora el entregable: Documentación de Procesos, que

contiene el Conjunto de Procesos de la organización definidos en

función del Plan de Procesos.

Casi no se realiza Planificación en el proceso de Gestión de Procesos.

No elabora o actualiza la Documentación de Procesos de acuerdo al

Plan de Procesos.

No se completa la actividad: Capacitación a la organización en los

procesos.

No se realiza la actividad de Implantación de proyectos pilotos.

3.3.3. Proceso: Gestión de Proyectos

Según la evaluación, el logro de este proceso es: 42 %



Fig. 3.5. Distribución de puntuación de Gestión de Proyectos.




Fortalezas


Proyectos:

Distribución de Respuestas de Gestión de Proyectos

NUNCA, 20%

POCO, 32%

REGULAR, 16%

CASI, 24%

SIEMPRE, 8%

NUNCA

POCO

REGULAR

CASI

SIEMPRE

47

Se realiza un Documento de Aceptación.

Se elaboran el entregable Contrato que contiene la documentación legal

para la prestación de servicios con el cliente.

Se elabora el entregable Registro de Proyecto que contiene la

información administrativa del proyecto.

Se elabora el entregable Descripción de Proyecto.

Se completa casi siempre la actividad Realizar Actividades de Plan de

Ventas que implica generar y presentar propuestas para oportunidades

identificadas.

Se elaboran contratos.

Se realizan actividades de Plan de Proyectos que implica cerrar los

proyectos internos o contratos al recibir el Documento de Aceptación.

Debilidades


Proyectos. No se manejan o no se generan adecuadamente:

No se realizan los entregables de Plan de Adquisiciones y Capacitación

No se realiza un Plan de Gestión de Ventas.

No se completa la actividad Generar o Actualizar el Plan de Gestión de

Proyecto en función de la Cartera de Proyectos del Plan de Trabajo

que implica elaborar o actualizar el Plan de Ventas.

No se completa la actividad de Generar o Actualizar el Plan de Gestión

de Proyecto en función de la Cartera de Proyectos que implica elaborar

o actualizar el Plan de Proyecto para gestionar los proyectos internos

y externos.

No se completa la actividad Elaborar el Plan de Adquisiciones y

Capacitaciones incluyendo los recursos y la capacitación requerida

para los proyectos.

Se realiza poco el Plan de Proyecto.

Se elabora el entregable pocas veces: Responsable de Administración

de Proyecto Específico, que contiene la definición de la persona

responsable de la administración de un Proyecto Específico.

3.3.4. Proceso: Gestión de Recursos




48

Fig. 3.6. Distribución de puntuación de Gestión de Recursos.




Fortalezas


Recursos.

El Responsable de Gestión de Recursos tiene un regular conocimiento

de las actividades necesarias para definir e implantar exitosamente el

Proceso de Gestión de Recursos.

El Responsable de Gestión de Recursos y Ambientes de Trabajo, tiene

un conocimiento regular de las actividades necesarias para implantar el

subproceso de Gestión de Recursos Humanos.

El responsable de Bienes Servicios e Infraestructura tiene un regular

conocimiento de las actividades necesarias para implantar

exitosamente el subproceso de Bienes y Servicios e Infraestructura.

El responsable de Conocimiento de la Organización tiene un regular

Conocimiento para garantizar la integridad, seguridad y eficiencia de la

Base de Conocimiento.

Debilidades


Recursos. No se manejan o no se generan adecuadamente:

Distribución de Respuestas de Gestion de Recursos

NUNCA, 63%POCO, 13%

REGULAR, 25%

CASI, 0%

SIEMPRE, 0%

NUNCA

POCO

REGULAR

CASI

SIEMPRE

49

No se elabora el Plan Operativo de Recursos Humanos y Ambiente de

Trabajo que contiene elementos a considerar en la selección,

capacitación, etc. De los Recursos Humanos.

No se realiza la actividad Generar o Actualizar el Plan Operativo de

Recursos Humanos y Ambientes de Trabajo, a partir de del Plan

Estratégico y el Plan de adquisición y Capacitación.


Bienes y Servicios e Infraestructura, a partir del Plan Estratégico y los

Planes de Adquisición y Capacitación para realizar el subproceso Bienes

y Servicios e Infraestructura.


Conocimiento de la Organización que implica establecer elementos para

la definición, operación y mantenimiento del conocimiento generado en

la Organización.

3.3.5. Proceso: Gestión de Recursos Humanos y Ambientes de Trabajo




Fig. 3.7. Distribución de puntuación de Gestión de Recursos Humanos y Ambiente de Trabajo.




Distribución de Respuestas de Recursos Humanos y Organización de Trabajo

NUNCA, 25%

POCO, 0%

REGULAR, 33%

CASI, 42%

SIEMPRE, 0%

NUNCA

POCO

REGULAR

CASI

SIEMPRE

50

Fortalezas


Recursos Humanos y Ambiente de Trabajo:

Se completa la actividad casi siempre, Definición de los Criterios para la

Selección.

Se completa la actividad casi siempre, Definición de los Criterios para la

Capacitación u otras acciones que satisfagan estas necesidades.

Se completa casi siempre, la actividad Seleccionar el Recurso Humano

del Personal de la Organización o contratarlo en función del perfil

solicitado.

Se completa casi siempre, la actividad Registrar en Registro de

Recursos Humanos en caso que se contrate a nuevo personal.

Debilidades


Recursos Humanos y Ambiente de Trabajo. No se manejan o no se generan

adecuadamente:

No se realiza la actividad Revisión del Plan Operativo de Recursos

Humanos y Ambiente de trabajo y Acciones Correctivas.

No se completa la actividad Elaboración o Actualización del Plan de

Capacitación con base en Plan Operativo de Recursos Humanos y

Ambiente de Trabajo.

No se dispone como entrada el artefacto Plan Operativo de Recursos

Humanos y Ambientes de Trabajo.

Se asume regularmente, el rol Responsable de Recursos Humanos y

Ambientes de Trabajo que tiene conocimiento de las actividades

necesarias para implantar exitosamente el subproceso de Recursos

Humanos y Ambientes de Trabajo.

3.3.6. Proceso: Gestión de Bienes Servicios e Infraestructura




51

Fig. 3.8. Distribución de puntuación de Gestión de Bienes Servicios e Infraestructura.




Fortalezas


Bienes Servicios e Infraestructura.

Se completa casi siempre, la actividad Obtener los presupuestos y

descripción del bien o servicio ofrecido por los proveedores.

Se completa casi siempre, la actividad Registrar el bien o servicio

aceptado en el Registro de Bienes o Servicios.

Debilidades


Bienes Servicios e Infraestructura. No se manejan o no se generan

adecuadamente:

No se completa la actividad Revisión del Plan de Bienes, Servicios e

Infraestructura y Acciones Correctivas.

No se completa la actividad Elaborar o Actualizar el Plan de

Mantenimiento con Base en Plan Operativo de Bienes, Servicios e

Infraestructura.

No se realiza la actividad Adquirir el Bien o servicio pedido en la Solicitud

de Bienes o Servicios.

Distribución de Respuestas de Bienes, Servicios e Infraestructura

NUNCA, 33%

POCO, 22%

REGULAR, 33%

CASI, 11% SIEMPRE, 0%

NUNCA

POCO

REGULAR

CASI

SIEMPRE

52

Se completa pocas veces, la actividad Registrar en el Catálogo de

Proveedores, en caso adquirir el bien o servicio de un proveedor nuevo.

3.3.7. Proceso: Gestión de Conocimiento de la Organización

Según la evaluación, el logro de este proceso es: 23.3%



Fig. 3.9. Distribución de puntuación de Gestión de Conociendo de la Organización.




Fortalezas


Conociendo de la Organización:

Regularmente se completa la actividad Definir o actualizar los

mecanismos de alimentación, consulta, mantenimiento y respaldo para

cada tipo de repositorio, en función de los requerimientos de los

procesos.

Regularmente, se completa la actividad Poner en operación y dar

mantenimiento a la Base de Conocimiento para que se incorporen y

consulten los productos aprobados provenientes de todos los procesos

y proyectos.

Distribución de Respuestas de Conocimiento de la Organización

NUNCA, 40%

POCO, 27%

REGULAR, 33%

CASI, 0%

SIEMPRE, 0%

NUNCA

POCO

REGULAR

CASI

SIEMPRE

53

Debilidades


Conociendo de la Organización. No se manejan o no se generan

adecuadamente:

No se dispone como entrada el artefacto Diseño de la Base de

Conocimiento que contiene el diseño del modelo conceptual.

No se completó la actividad Diseñar o actualizar el modelo conceptual,

incluyendo su metamodelo, de la Base de Conocimiento, en función de

los requerimientos de los Procesos.

No se realiza la actividad, Integrar y Documentar el diseño de la Base

de Conocimiento de la organización

3.3.8. Proceso: Administración de Proyectos Específicos




Fig. 3.10. Distribución de puntuación de Administración de Proyectos Específicos.




Fortalezas

Las siguientes son las fortalezas identificadas para el proceso

Administración de Proyectos Específicos:

Distribución de Respuestas de Administración de Proyecto Específico

NUNCA, 6%

POCO, 24%

REGULAR, 48%

CASI, 15%

SIEMPRE, 6%

NUNCA

POCO

REGULAR

CASI

SIEMPRE

54

Se dispone como entrada siempre, el artefacto Descripción del Proyecto.

Se elabora el entregable Documento de Aceptación.

Casi siempre, se completa la actividad Identificar las actividades para

llevar a cabo el Protocolo de Entrega.

Casi siempre, se completa la actividad Conformar el equipo de trabajo

asignando roles y responsabilidades.

Casi siempre, se completa la actividad Generar el Plan del Proyecto o

actualizando antes de iniciar un nuevo ciclo.

Casi siempre, se completa la actividad Acordar con el responsable de

Desarrollo y Mantenimiento del proyecto la asignación de tareas al

Equipo de Trabajo incluyendo a los subcontratistas.

Debilidades

Las siguientes son las debilidades identificadas para el proceso

Administración de Proyectos Específicos. No se manejan o no se generan

adecuadamente:

Se realiza regularmente los Roles Involucrados y Capacitación.

No se completa la actividad Priorizar los efectos de los riesgos sobre los

objetivos del proyecto.

Se completa pocas veces la actividad Identificar las probabilidades de

impacto de cada riesgo estimando sus implicaciones en los objetivos del

proyecto.

Se completa pocas veces la actividad Desarrollar procedimientos para

reducir el impacto de los riesgos.

3.3.9. Proceso: Desarrollo y Mantenimiento de Software




55

Fig. 3.11. Distribución de puntuación de Desarrollo y Mantenimiento de Software.




Fortalezas

Las siguientes son las fortalezas identificadas para el proceso Desarrollo y

Mantenimiento de Software:

Se elabora casi siempre, el entregable Componente que contiene el

conjunto de unidades de código relacionadas.

Se elabora el entregable casi siempre, Software que contiene

componentes agrupados en subsistemas posiblemente anidados.

Se elabora el entregable Manual de usuario.

Se asume casi siempre el rol de Analista, que tiene el conocimiento y

experiencia en la obtención, especificación y análisis de requerimientos.

Se asume el rol Programador.

Se asume el rol Responsable de Manuales.

Se completa siempre, la actividad Revisar con los miembros del equipo

el Plan de Desarrollo actual.

Se completa la actividad casi siempre, Distribuir tareas a los miembros

del equipo de trabajo.

Se completa la actividad casi siempre, Documentar o modificar la

Especificación de Requerimientos.

Se completa la actividad casi siempre, Documentar la versión preliminar

del manual de usuario o modificar el manual existente.

Se completa la actividad casi siempre, Incorporar Especificación de

Requerimientos y manuales de usuarios a la configuración de software.

Distribución de Respuestas de Desarrollo y Mantenimiento de Softw are

NUNCA, 0%POCO, 5%

REGULAR, 48%CASI, 43%

SIEMPRE, 5%

NUNCA

POCO

REGULAR

CASI

SIEMPRE

56

Se completa la actividad casi siempre, Distribuir tareas a los miembros

del equipo según su rol.

Se completa la actividad casi siempre, Incorporar Análisis y Diseño y

guardarlo en la configuración de Software.

Se completa la actividad casi siempre, Incorporar componentes a la

configuración de Software.

Se completa la actividad casi siempre, Realizar Integración que implica

integrar los componentes en subsistemas o en el sistema de software.

Se completa la actividad casi siempre, Documentar manuales de usuario

y de Operación.

Debilidades

Las siguientes son las debilidades identificadas para el proceso Desarrollo

y Mantenimiento de Software. No se manejan o no se generan

adecuadamente:

Pocas veces, se elabora el entregable Análisis y Diseño.

Se asume regularmente el rol Responsable del Proyecto Específico que

tiene Capacidad de Liderazgo.

Se asume regularmente el rol, Diseñador de Interfaz de Usuario.

3.4. Esquema de Trabajo del Proyecto

Para el presente proyecto, como parte de los elementos del proyecto

COMPETISOFT-PERÚ, se diseñó un esquema de trabajo basado en

PmCompetiSoft el cual comprende, en un ciclo de mejora, las siguientes

actividades: Instalación, Diagnóstico, Formulación, Ejecución y Revisión [62].

3.4.1. Instalación del Ciclo

En esta fase se establece o actualiza una Propuesta de Mejora

conteniendo: El proceso de mejora, los objetivos de mejora generales y los

recursos necesarios para llevar a cabo la iniciativa de mejora.

3.4.2. Diagnóstico de Procesos

El Responsable de Mejora de Procesos realiza la actividad de evaluación

interna de procesos, para conocer el estado general de los procesos de la

empresa y analizar los resultados. Esto con el objetivo de establecer los

casos de mejora y sus prioridades. Finalmente toda esta información se

registra en el llamado Plan General de Mejora.

57

3.4.3. Formulación del Ciclo de Mejora

En esta etapa, el responsable de la Mejora de Procesos, toma alguno de

los procesos de mejora y realiza la primera iteración del ciclo de mejora con

el fin de obtener una medida del esfuerzo de conducir esta iteración. El

objetivo de esto, es recaudar la información como base para la estimación

del esfuerzo, costo y tiempo que demandarán las demás iteraciones del

ciclo de mejora.

Es en el Plan de Implementación de Mejora, donde se registra la

información y el aprendizaje ganado de ésta primera iteración. Además de

realizar una planificación de la siguiente iteración piloto de mejora y la

estrategia a seguir para mejorar el proceso.

3.4.4. Ejecución de Mejoras

Se gestiona y ejecuta las mejoras correspondientes a la iteración piloto de

acuerdo con los planes establecidos.

Si la planificación de la iteración piloto se ha desarrollado

satisfactoriamente, se acepta e institucionaliza los nuevos procesos en la

organización. Luego, se actualiza el Plan de Implementación de Mejora

donde se describe la ejecución y evaluación de las iteraciones pilotos.

Es importante que se analice las mejoras que se han introducido en los

procesos de la organización, la cual puede realizarse una o varias veces en

un ciclo de mejora.

3.4.5. Revisión del Ciclo

El objetivo en esta etapa, es la de corregir o ajustar todos los elementos

relacionados con la ejecución de cada una de las iteraciones piloto de

mejora, y el de realizar un análisis del trabajo realizado en todo el ciclo de

mejora.

El responsable de mejora de procesos hace una realimentación del ciclo de

mejora llevado a cabo antes de volver a comenzar la fase de instalación de

un nuevo ciclo.

Las lecciones aprendidas son importantes debido a que se registran las

experiencias positivas y/o negativas ocurridas en el ciclo de mejora,

registrándose en el llamado Reporte de Mejora, medidas desarrolladas

también, para medir el cumplimiento de los objetivos, procesos mejorados,

etc.

58

CAPITULO IV

MEJORA DEL PROCESO

4.1. Identificación de Procesos para el Ciclo de Mejora

El proceso de evaluación efectuada mediante los instrumentos del proyecto

COMPETISOFT-PERÚ para identificar el diagnóstico de la situación actual de los

procesos trabajados en la empresa AQPSIGMA, nos brindaron información

relevante indicándonos el nivel de adhesión al inicio del proyecto con los procesos

planteados en el modelo MoProSoft. Esto nos permitió concluir qué procesos

serán diseñados y/o rediseñados en la Mejora de Procesos.

4.1.1. Priorización de Procesos: Objetivos de Negocio vs. Problemas de

Negocio

Para obtener los objetivos del negocio de la empresa a ser alcanzados en un

tiempo prudencial, se realizaron entrevistas con el Gerente; cabe mencionar

que estos objetivos no estaban plasmados en un Plan Estratégico y de igual

forma, los principales problemas que insidian o dificultaban en el no

cumplimiento de estos objetivos.

Seguidamente, con ambos aspectos identificados, evaluamos y medimos el

impacto de la presencia de estos problemas frente al desarrollo y alcance

exitoso de los objetivos estratégicos de la empresa, considerando la siguiente

escala de impacto (ver Tabla 4.1):

Alto (A) Medio (M) Bajo (B)

4 puntos 2 puntos 1 punto

Tabla 4.1 Escala de Impacto


Adicionalmente junto con el Gerente, se determinó el peso como el valor de

la importancia que tiene el objetivo para la evolución adecuada de la

empresa,

Como resultado se obtuvo el siguiente cuadro (ver Tabla 4.2):

59

Objetivos de Negocio

Pe

so

% P

es

o

Pro

ble

ma

s d

e T

es

tin

g

Pro

ble

ma

s d

e

de

term

ina

ció

n d

el a

lca

nc

e

Pro

ble

ma

s d

e e

lic

ita

ció

n d

e

req

ue

rim

ien

tos

Pro

ble

ma

s d

e S

op

ort

e

Pro

ble

ma

s d

e

de

term

ina

ció

n d

e p

rec

ios

O1 Consolidación en la Región Sur 10 22.7% A M B A A

O2 Mejorar la calidad de los productos 10 22.7% A M M M M

O3 Aumentar las Ventas 10 22.7% M M B M A

O4 Creación de nuevos productos 7 15.9% A A A M A

O5 Expansión hacia nuevos mercados 7 15.9% M A A M M

44 0.95 1.27 1.27 0.64 0.95

Tabla 4.2 Objetivos de Negocio


Fueron evaluados el impacto de cada uno de los problemas versus los

objetivos del negocio.

Para explicar de manera más detallada la evaluación realizada y a manera

de ejemplo vamos a calcular para uno de los mapeos de evaluación de

impacto y riesgo realizados para el primer problema (Problema 1) versus los

objetivos del negocio:

Problema 1: Testing

o Consolidación en la Región Sur: A=4

o Mejorar la calidad de los productos: A=4

o Aumentar las ventas: M=2

o Creación de nuevos productos: A=4

o Expansión hacia nuevos mercados: M=2

La evaluación de impacto (EI) la obtenemos al resolver el siguiente

cálculo:

EI= 4(10/44) + 4(10/44) + 2(10/44) + 4(7/44) + 2(7/44)

EI = 0.95

Tomando en cuenta las mismas consideraciones que en el primer problema,

se realizaron los mismos cálculos con los problemas subsecuentes, tal como

lo mostramos a continuación.

60

Problema 2: Determinación del alcance

En este segundo problema y en base al mismo cálculo, el EI que se

obtuvo es de: EI = 1.27

Problema 3: Elicitación de requerimientos

En este caso el, EI obtenido es: EI = 1.27

Problema 4: Soporte

En este caso, el EI es: EI = 0.64

Problema 5: Determinación de precios

Finalmente, el EI obtenido es de: EI = 0.95

Una vez realizada la medición del nivel de impacto para cada uno de los

problemas identificados en la organización y en base a los resultados

obtenidos seleccionamos los dos problemas de mayor puntaje y por ende de

mayor impacto (ver Fig. 4.1). Los cuales son:

Problemas de determinación de alcance (Problema 2)

Problemas de elicitación de requerimientos (Problema 3)

Fig. 4.1 Diagrama de Evaluación de Impacto


Problema 4

Problema 1

Problema 5

Problema 2

Problema 3

0

0.5

1

1.5

Valor

Problema 4 Problema 1 Problema 5 Problema 2 Problema 3

61

4.1.2. Priorización de Procesos: Objetivos de Negocio vs. Procesos

MoProSoft

En esta sección, se presentará la manera de cómo se determinó el impacto

de la ejecución de cada uno de los procesos del modelo MoProSoft (Como

parte del proyecto COMPETISOFT-PERÚ), para apoyar el alcance y logro de

los objetivos estratégicos del negocio. Esto se determinó luego de realizar la

entrevista al gerente de la empresa tomando en cuenta el impacto de cada

uno de los procesos con relación a la importancia que tiene el objetivo para

la evolución de la empresa.

La evaluación y resultados obtenidos de cada uno de los mapeos entre

proceso y objetivo para la valoración final, fue realizada de la misma manera

que la evaluación de los Problemas vs. Objetivos (descritos en la sección

anterior).

Como resultado se obtuvo el siguiente cuadro (ver Tabla 4.3):

Objetivos de Negocio

Pe

so

% P

es

o

GN

eg

GP

roc

GP

roy

GR

ec

GR

HA

T

GB

SI

GC

O

AP

E

DM

S

O1 Consolidación en la Región Sur 10 22.7% A M M B M M M A A

O2 Mejorar la calidad de los productos 10 22.7% B B M B A M M A A

O3 Aumentar las Ventas 10 22.7% A M A M M B M M M

O4 Creación de nuevos productos 7 15.9% A M M M M B M M M

O5 Expansión hacia nuevos mercados 7 15.9% A M M M M A M M M

44 3.32 1.77 2.45 1.55 2.45 1.93 2.00 2.91 2.91

cuartil 2.9

Tabla 4.3 Objetivos de Negocio


Fueron evaluados el impacto de la ejecución de cada uno de los procesos del

modelo MoProSoft para apoyar el alcance y logro de los objetivos

estratégicos del negocio.

Para explicar de manera más detallada los resultados y evaluación de cada

uno de los mapeos entre proceso y objetivo, se realizó utilizando el mismo

criterio que la evaluación de los Problemas vs. Objetivos descritos en la

sección anterior:

Proceso MoProSoft: Gestión de Negocio GNeg

o Consolidación en la Región Sur: A=4

62

o Mejorar la calidad de los productos: B=2

o Aumentar las ventas: A=4

o Creación de nuevos productos: A=4

o Expansión hacia nuevos mercados: A=4

La evaluación de impacto (EI) la obtenemos al resolver el siguiente

cálculo:

EI= 4 (10/44) + 2(10/44) + 4(10/44) + 4(7/44) + 4(7/44)

EI = 3.32

Tomando en cuenta las mismas consideraciones que en el primer Proceso

de MoProSoft, se realizaron los mismos cálculos con los demás procesos

subsecuentes, tal como lo mostramos a continuación.

Proceso MoProSoft: Gestión de Procesos GProc

En este segundo proceso MoProSoft y en base al mismo cálculo, el

EI que se obtuvo es de: EI = 1.77

Proceso MoProSoft: Gestión de Proyectos GProy

En este caso, el EI obtenido es: EI = 2.45

Proceso MoProSoft: Gestión de Recursos GRec

En este caso, el EI es: EI = 1.55

Proceso MoProSoft: Gestión de Recursos Humanos y Ambientes de

Trabajo GRHAT

Para este proceso, el El obtenido es de: EI = 2.45

Proceso MoProSoft: Gestión de Bienes y Servicios e Infraestructura

GBSI

Para este proceso, el El obtenido es de: EI = 1.93

Proceso MoProSoft: Gestión de Conocimiento GCO

Según cálculos, el EI es de: EI = 2.00

Proceso MoProSoft: Administración de Proyectos Específicos APE

63

Según cálculos, el EI es de: EI = 2.91

Proceso MoProSoft: Desarrollo y Mantenimiento de Software DMS

Finalmente, para este proceso el EI es de: EI = 2.91

Fig. 4.2 Diagrama de Evaluación de Impacto (Objetivos de Negocio Vs. Procesos

MoProSoft)


En la Fig. 4.2 se presenta el impacto de los procesos MoProSoft vs la

obtención de los objetivos de AQPSIGMA luego de realizar la entrevista a los

gerentes de la empresa. En base a los resultados mostrados, se

seleccionaron 3 procesos para que sean evaluados e implementados en la

organización a través del Plan de Mejora, estos procesos son:

GNEG: Gestión de Negocio

DMS: Desarrollo y Mantenimiento de Software

APE: Administración de Proyecto Específico

4.1.3. Priorización de Procesos: Problemas de Negocio vs. Procesos

MoProSoft

Finalmente, para completar la evaluación de los procesos a ser considerados

en el diseño del Plan de Mejora de Procesos, se realizó la evaluación entre

los problemas identificados en AQPSIGMA vs los procesos del modelo

0

0.5

1

1.5

2

2.5

3

3.5

1

GNeg GProc GProy GRec GRHAT GBSI GCO APE DMS

64

MoProSoft con el objetivo de identificar cuáles de éstos determinaban mayor

impacto en la solución de los problemas que afectaban el mejor desempeño

de la empresa, con el objetivo de que nos permita disminuir la ocurrencia de

los problemas identificados. El resultado de la misma se puede observar en

la Tabla 4.4.

A manera de ejemplo, para representar el cálculo del impacto tomamos como

modelo la valoración del primer proceso MoProSoft vs los problemas de la

empresa.

Problemas

Pe

so

% P

es

o

GN

eg

GP

roc

GP

roy

GR

ec

GR

HA

T

GB

SI

GC

O

AP

E

DM

S

prob1 Testing 10 23.3% B B M B M M B A A

prob2 Determinación del Alcance 7 16.3% M B A M M M M A A

prob3 Elicitación de Requerimientos 8 18.6% M B M M M M M M A

prob4 Soporte 9 20.9% M M A M M A A M M

prob5 Determinación Precios 9 20.9% M M A M A M M M M

43 1.77 1.42 3.16 1.77 2.42 2.42 2.19 2.79 3.16

cuartil 2.8

Tabla 4.4 Problemas de Negocio Vs. Procesos del Modelo MoProSoft


Proceso MoProSoft: Gestión de Negocio GNeg

o Problema 1: Testing. B=1

o Problema 2: Determinación del Alcance. M=2

o Problema 3: Elicitación de Requerimientos. M=2

o Problema 4: Soporte. M=2

o Problema 5: Determinación de Precios. M=2

De esta manera se realizó y midió el nivel de impacto (NI) para cada

uno de los procesos del Modelo MoProSoft.

NI= 1 (10/43) + 2(7/43) + 2(8/43) + 2(9/43) + 2(9/43)

NI = 1.77

Tomando en cuenta las mismas consideraciones que en el primer Proceso

de MoProSoft, se realizaron los mismos cálculos con los demás procesos

subsecuentes, tal como lo mostramos a continuación.

65

Proceso MoProSoft: Gestión de Procesos GProc

En este segundo proceso MoProSoft y en base al mismo cálculo, el

NI que se obtuvo es de: NI = 1.42

Proceso MoProSoft: Gestión de Proyectos GProy

En este caso, el NI obtenido es: NI = 3.16

Proceso MoProSoft: Gestión de Recursos GRec

En este caso, el NI es: NI = 1.77

Proceso MoProSoft: Gestión de Recursos Humanos y Ambientes de

Trabajo GRHAT

Para este proceso, el NI obtenido es de: NI = 2.42

Proceso MoProSoft: Gestión de Bienes y Servicios e Infraestructura

GBSI

Para este proceso, el Nl obtenido es de: NI = 2.42

Proceso MoProSoft: Gestión de Conocimiento GCO

Según cálculos, el NI es de: NI = 2.19

Proceso MoProSoft: Administración de Proyectos Específicos APE

Según cálculos, el NI es de: NI = 2.79

Proceso MoProSoft: Desarrollo y Mantenimiento de Software DMS

Finalmente, para este proceso el NI es de: NI = 3.16

66

Fig. 4.3 Diagrama de Evaluación de Impacto (Problemas Vs. Procesos MoProSoft)


Según los resultados, mostrados en la gráfica (Fig. 4.3), se identificaron 3

procesos que representaban ser los de mayor impacto para disminuir la

ocurrencia de los problemas identificados en AQPSIGMA. Estos procesos

fueron los siguientes:

Gestión de Proyecto GProy

Administración de Proyecto Específico APE

Desarrollo y Mantenimiento de Software DMS

4.2. Propuesta de Plan de Mejora de Procesos

4.4.1. Descripción

Tal como se mencionó anteriormente (Punto 3.4), el proceso de mejora de

Competisoft denominado PMCompetisoft, está compuesto por 5 macro

actividades: Instalación, Diagnóstico, Formulación, Mejora y Revisión del

programa. Luego de realizarse las tres evaluaciones y en base a los

resultados obtenidos, se compararon los procesos clasificados durante las

3 evaluaciones para definir la propuesta a ser considerada en la

elaboración del Plan de Mejora dando como resultado los siguientes

procesos:

Gestión de Negocio

Administración de Proyecto Específico

Desarrollo y Mantenimiento de Software

0

0.5

1

1.5

2

2.5

3

3.5

1


67

Se debe de aclarar que, debido al tipo de proyectos que la empresa

AQPSIGMA viene manejando, se desistió de incluir al proceso Gestión de

Proyectos GProy, manteniendo los procesos anteriormente mencionados.

4.4.2. Objetivos de la Mejora

Para los procesos seleccionados, se plantean los siguientes Objetivos de

Mejora (OM), que orientarán el Plan de Mejora de Proceso, para el primer

ciclo a implementar en la organización, los cuales se relacionan con los

objetivos de negocio, los problemas y procesos del modelo MoProSoft.

4.4.2.1. OM 1: Incrementar la capacidad del Proceso de Gestión de Negocio

(GNeg) a un nivel de adhesión superior al 85% dentro de la capacidad

del primer nivel.

Durante el diagnóstico realizado a AQPSIGMA, el porcentaje de

cumplimiento de las actividades del modelo MoProSoft dieron como

resultado: 22.7% (Ver Tabla 3.1).

Posterior a la ejecución del proyecto COMPETISOFT, planificamos

alcanzar el 85% de nivel 1 de cumplimiento, lo cual contribuya con los

siguientes objetivos de negocio y reduzca los siguientes problemas

encontrados:

Objetivos de Negocio afectados:

o Consolidación en la Región Sur

o Aumentar las ventas

o Creación de nuevos productos

o Expansión hacia nuevos mercados

Problemas que busca resolver:

o Determinación del Alcance

o Elicitación de Requerimientos

o Soporte

o Determinación de precios

4.4.2.2. OM 2: Incrementar la capacidad del Proceso de Administración de

Proyecto Específico (APE) a un nivel de adhesión superior al 85% dentro

de la capacidad del primer nivel.

68

El porcentaje de cumplimiento alcanzado dieron como resultado: 44.7%

(Ver Tabla 3.1).




encontrados:



o Mejorar la calidad de los productos


o Testing


4.4.2.3. OM 3: Incrementar la capacidad del Proceso de Mantenimiento y

Desarrollo de Software (DMS) a un nivel de adhesión superior al 50%

dentro de la capacidad del segundo nivel.

El porcentaje de cumplimiento alcanzado dieron como resultado: 61.9%

(Ver Tabla 3.1).




encontrados:



o Mejorar la calidad de los productos


o Testing


o Elicitación de requerimientos

69

4.3. Procesos Gestión de Negocios (GNeg)

4.3.1. Situación Actual

La organización AQPSIGMA no cuenta con un Plan Estratégico

documentado.

4.3.2. Propuesta de Cambio

Descripción del Proceso

En base a lo que indica el modelo MoProSoft, el propósito de este

proceso es el de establecer la razón de ser de la organización, sus

objetivos y las condiciones para lograrlo, considerando las

necesidades de los clientes y realizando evaluaciones continuas

para medir los resultados de tal forma que se puede proponer

cambios para permitir una mejora.

El proceso de Gestión de Negocio se compone de 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

Se define un plan estratégico con el objetivo de establecer las

decisiones sobre qué es lo más importante para lograr el éxito de la

organización. Sus elementos son:

o Misión, Visión y Valores

o Los objetivos de la Organización, incluyendo los objetivos

de calidad y la forma de cómo alcanzarlos mediante la

definición de Estrategia.

o Forma de medir el logro de los Objetivos, por medio de la

definición de Indicadores y Metas Cuantitativas asociadas

a dichos objetivos.

o Cartera de Proyectos que habilite la ejecución de

estrategias.

o Estructura Organizacional y Estrategias 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 de la Organización.

o Plan de Comunicación con el Cliente, incluyendo los

mecanismos de comunicación.

70

Preparación para la Realización

Se define el plan de Comunicación e Implantación del Plan

Estratégico que permita difundir éste a los miembros de la

organización. 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.

Objetivos

O1: Lograr una planificación Estratégica exitosa mediante el

cumplimiento del Plan Estratégico.

O2: Lograr que la organización trabaje en función del Plan

Estratégico mediante la correcta comunicación e implantación del

mismo.

Indicadores

I1: (O1) Este indicador mide el cumplimiento de los Objetivos del

Plan Estratégico:

I=Cantidad de Objetivos Alcanzados / Objetivos Totales

I2: (O2) Los miembros de la organización conocen el Plan

Estratégico y trabajan en función del mismo. En este caso se

realizarían encuestas.

I= Cantidad de personas de la organización que tienen

conocimiento del Plan Estratégico / Total del personal de la

organización

Roles y Competencias

En la Tabla 4.5 presentamos, en base al modelo MoProSoft, los

roles y competencias respectivas que nos servirán para la

implantación de este proceso.

71

Abreviatura Rol Competencias

GD Grupo Directivo Conocimiento del

esfuerzo requerido para

llevar a cabo la

planificación estratégica

y estar comprometido

con este

RGN Responsable de Gestión

de Negocios

Conocimiento de las

actividades necesarias

para definir e implantar

exitosamente

GG Grupo de Gestión Conocimiento para

administrar los proyectos

e implantar los procesos

definidos

Tabla 4.5 Roles y Competencias para el Proceso GNEG


En la Figura 4.4 mostramos el diagrama de actividades propuesto y en la Tabla 4.6

describimos de forma resumida las actividades definidas en el diagrama de actividades

propuesto obteniéndose los siguientes artefactos presentados en sus respectivos anexos:

Plan Estratégico (Anexo )

Plan de Comunicación con el Cliente (Anexo)

72

Fig. 4.4 Diagrama de Actividades Propuesto – Proceso Gestión de Negocios GNEG


73

Tipo Elemento Descripción Fuente Actividad Descripción de la Actividad

A1.1 Planificación

ENT Factores Externos Tendencias tecnológicas, clientes

competidores

Externa - -

SAL

Plan Estratégico

Misión, Visión, Valores

GProc,

GProy,

GRec

A1.1 Actualizar la

Misión, Visión y Valores

Documentar o actualizar la Misión, Visión

y Valores

Objetivos, Estrategias A1.2 Entender la

situación actual

Procesos requeridos, Carteras de

Proyectos

A1.3 Actualizar los

Objetivos estratégicos

Estructura de la Organización A1.4 Definir procesos y

proyectos

Estrategia de Recursos A1.5 Actualizar la

estructura de la

organización

Presupuesto A1.6 Definir

mecanismos de

comunicación con el

cliente

Plan de Comunicación con el Cliente A1.7 Integrar y

documentar el Plan

Estratégico

Cartera de Proyectos A1.9 Actualizar la

cartera de proyectos

SAL Plan de Adquisiciones

y Capacitación

GRec A1.8 Elaborar el Plan

de Adquisiciones y

Capacitación

A2. Realización

- - - - A2.1 Preparar el

ambiente adecuado

Tabla 4.6 Descripción de las Actividades del Proceso GNEG propuesto


74

4.3.3. Experiencia Piloto

Tal como se mencionó anteriormente (Punto 3.4) y que recordaremos, el

proceso de mejora continua de Procesos de Software se compone de uno o

más ciclos de mejora. Cada ciclo de mejora consta de 5 fases: Instalación del

programa, diagnóstico de procesos, formulación de mejoras, ejecución de

mejoras y revisión del programa. Cuyas actividades son: Instalación del ciclo,

Diagnóstico de los procesos, Formulación del ciclo de mejora, Mejora de

Procesos, Revisión de Ciclo de mejoras. En la actividad Mejora de Procesos,

se gestiona y ejecuta las mejoras correspondientes a la iteración piloto de

acuerdo con los planes establecidos. Si la planificación de la iteración piloto

(Aspecto que se tratara en este punto), se han desarrollado

satisfactoriamente se acepta e institucionaliza los nuevos procesos en la

organización.

Luego de realizar las evaluaciones respectivas y de decidir que el Proceso

de Gestión de Negocios - GNeg sería uno de los procesos a implantar, se

procedió a elaborar el proceso respectivo basándonos en el modelo

MoProSoft incorporándose para éste proceso formatos que son la base

guía y orden en el proceso y el cumplimiento de los procedimientos y

actividades inherentes al mismo. Gracias a ello, se permitió lograr el primer

nivel de mejora en el proceso de Gestión de Negocio en la organización,

meta inicial cumplida para dicho proceso.

La actividad principal de este proceso, ha sido la elaboración del Plan

Estratégico, formato que se encuentra en el Anexo respectivo, requiriéndose

para ello, la participación del Gerente General (GG) y todo el personal de

la organización. Para elaborar el Plan Estratégico, fue importante tener

conocimiento sobre la situación en que se encuentra la organización, a

dónde se quiere llegar y cómo se va a lograr, si bien la alta gerencia

tenía en claro todas estas interrogantes, no existía documentación alguna con

la consecuencia de que los objetivos que la organización perseguía no se

encontraban engranados con lo que el resto de la organización hacía, debido

fundamentalmente a su desconocimiento.

A continuación realizaremos una breve descripción de los formatos

elaboradoras para este proceso.

Plan Estratégico: Formato que establece las directrices

organizacionales, su misión, visión, valores, objetivos entre otros,

que sirven como base para el crecimiento, dirección y desarrollo

empresarial. En el caso de la empresa AQPSIGMA, esta contaba con

Misión, Visión y Valores las cuales se mantuvieron. Para generar el

75

análisis FODA, se realizaron reuniones con la alta gerencia y el

personal de la organización y en base a las diferentes sugerencias e

identificaciones de sus áreas respectivas en particular y para la

empresa en general, se unificó toda esta información generándose la

versión final del documento. Cabe mencionar que es a partir de esta

actividad, que se lograron identificar disconformidades del personal y

problemas existentes en la organización, incorporándose en los

objetivos estratégicos.

Plan Estratégico - Plan de Marketing y Comunicación Cliente. Se

establecerán las directrices y sugerencias a la organización para

contribuir en la mejora de la gestión de los clientes y la imagen de la

organización.

Plan Estratégico - Plan de Adquisiciones y Capacitación. Formato

que contiene solicitudes con los requerimientos de adquisición de

recursos, capacitación, proveedores e infraestructura.

Cartera de Proyectos. En cuanto a este formato, la organización ya

contaba con este documento actualizándose.

4.3.4. Lecciones Aprendidas

Tal como se indica en el informe técnico del Proceso de Mejora de

COMPETISOFT, en las actividad 5 Revisión del Ciclo de Mejora, cuyo

objetivo es la de corregir o ajustar todos los elementos relacionados con la

ejecución de cada una de las iteraciones piloto de mejora y también hacer un

análisis post- morten del trabajo realizado en todo el ciclo de mejora [62], es

el responsable de la mejora de procesos, hacer una realimentación que será

plasmada en un documento denominado Reporte de Mejora, de todas las

lecciones aprendidas de cada proceso que ha sido tratado, tal como

mencionaremos en cada proceso elegido para este ciclo. Recordemos que

las lecciones aprendidas son una forma de lograr organizar una información

para ser aprovechada en eventos que se enfrentarán en un mañana. Las

experiencias vividas en el pasado pueden ser un aporte fundamental siempre

y cuando se tenga una enseñanza que pueda ser aplicada en el futuro y así

afrontar situaciones similares con una mejor preparación, mejores

herramientas y elementos de juicio; para lograr este propósito es necesario

disponer de la información inherente a esas situaciones para que se transmita

a todos aquellos que puedan tener algún interés en llevar a cabo acciones

similares de la manera más eficiente y óptima posible. En este caso, podemos

mencionar las siguientes lecciones aprendidas en la realización de la mejora

del proceso.

76

Las reuniones convocadas para la preparación del análisis FODA se

realizaron mayormente con personal de alta gerencia y no con todo

el personal de las distintas áreas de la organización, debido entre

otras cosas, a la no disponibilidad por motivos de los horarios del

personal. Sin embargo, el personal presente, dio a conocer una serie

de disconformidades en sus respectivas áreas, no detectadas por el

personal de la alta gerencia.

La gran mayoría de actividades inherentes a la mejora de procesos

demanda un fuerte compromiso y en especial la participación de la

alta gerente, particularmente, en este proceso debido a su

implicancia directa.

La disposición del responsable del proceso de Gestión de

Negocios fue adecuada para la realización del ciclo de mejora,

de tal forma que se cumplieron los plazos previstos para la mejora de

este proceso.

Las reuniones se realizaron a la hora y en la fecha fijada, no

necesitándose ampliación de la duración de la misma ni

estableciendo reuniones adicionales, todo bajo un clima de apertura,

cordialidad y pro actividad.

Los documentos elaborados como formatos de plantillas fueron

observados y revisados por parte del responsable de Gestión de

Negocios.

Todas las modificaciones y propuestas de mejora fueron

aceptadas rápidamente, debido a que el responsable del proceso

de Gestión de Negocios ocupaba el cargo de Gerente General.

Esto nos muestra que mientras más comprometido está el nivel

jerárquico en la organización, todas las actividades realizadas en el

proceso de mejora se producen más eficientemente.

4.4. Proceso Administración de Proyecto Específico (APE)


El proceso de Administración de Proyecto Específico (APE), consiste en

establecer y llevar a cabo sistemáticamente las actividades que permitan

cumplir con los objetivos en tiempo y costo esperado. APE consta de tres

fases: Fase de planificación, de realización y de cierre. La fase de

planificación es realizada por el Responsable de Gestión de Proyectos, quién

tiene como actividades el desarrollo del plan de proyecto que incluye

los tiempos y costos estimados, entregables y la conformación del equipo de

trabajo. La fase de realización, es ejecutada por el Responsable de

Administración del Proyecto que tiene entre sus tareas más importantes

77

revisar las solicitudes de cambio por parte del cliente, reportar los avances

del proyecto y la configuración.

En la situación actual, se describe a la empresa en el momento de iniciar el

ciclo de mejora el cual fue iniciado con reuniones de coordinación donde el

principal gestor era el Gerente General incluyendo a parte del personal. Tal

como se determinó en la evaluación inicial, se identificaron por ejemplo las

siguientes ausencias, la falta de registro de horas de proyectos anteriores,

hecho que incrementaba el ajuste a la realidad al momento de negociar el

tiempo en el que incurrirían los proyectos, la no existencia de matrices de

riesgos, determinación del alcance de un determinado proyecto, lecciones

aprendidas, entre otros.

Para realizar una buena identificación de actividades, se realizó la

diagramación del flujo inicial de las prácticas que se ejercían en la empresa

para planificar, dirigir y evaluar los proyectos que se llevaban a cabo. Para

realizar dicha identificación y su respectiva validación, se realizaron

reuniones de entrevista y coordinación con el Jefe de proyecto y el gerente

general, surgiendo así el gráfico 4.5. La Tabla 4.7 en el que se pueden ver

mejor los detalles y finalmente Roles y Competencias en la Tabla 4.8.

78

Fig. 4.5 Diagrama de Actividades Situación Actual – Proceso Administración Proyectos Específicos APE


79

Rol Descripción

A1. Planificación

GER A1.1 Identificar el proyecto a desarrollar

CLI

ET

A1.2 Realizar la demostración la demostración del sistema al cliente

GER

CLI

A1.3 Se realiza una encuesta sobre las características del proyecto al

cliente

GER A1.4 Revisa la encuesta

GER A1.5 Reunión con el cliente para levantar nuevos requerimientos

GER A1.6 Analizar la lista de requerimientos del cliente

CLI A1.7 Definir junto al cliente el tiempo de entrega del proyecto

GER A1.8 Elaborar la propuesta técnica

GER A1.9 Elaborar el contrato

A2. Realización

GER A2.1 Conformar el equipo de trabajo

JDP A2.2 Elaborar el plan de trabajo

ET A2.3 Desarrollar el cronograma del plan de trabajo.

Tabla 4.7 Descripción de las Actividades Situación Actual del Proceso Administración de

Proyectos Específicos APE


Abreviatura Rol Competencias

GER Gerente General Conocimiento del

esfuerzo requerido para

llevar a cabo la

planificación estratégica

y estar comprometido

con este

JDP Jefe de Proyecto Conocimiento de las

actividades necesarias

para definir e implantar

exitosamente

ET Equipo de Trabajo Conocimiento para

administrar los proyectos

e implantar los procesos

definidos

Tabla 4.8 Roles y Competencias Situación Actual del Proceso Administración de Proyectos

Específicos APE



A continuación se presenta la propuesta de cambio para el proceso de

Administración de Proyecto Específico APE realizado a la organización en

80

estudio AQPsigma; la propuesta ha sido planteada en base a los objetivos de

este proceso propuesto por el modelo MoProSoft:

Objetivo 1. Lograr los objetivos del proyecto en tiempo y costo

mediante coordinación y el manejo de los recursos del mismo.

Objetivo 2. Mantener informado al cliente mediante la realización de

reuniones de avance de proyecto.

Objetivo 3. Atender las solicitudes de cambio del cliente mediante la

recepción y análisis de las mismas.

Para lograr los objetivos del proyecto en tiempo y costo se ha realizado una

serie de formatos y diagrama de actividades para tal fin y dentro de las

propuestas planteadas, hemos considerados a la Gestión de Alcance,

Tiempo, Costo y Riesgos (Fig. 4.6) del PMBOK, adaptado a la organización

en estudio, que se detallarán a continuación.

Fig. 4.6 Diagrama de Gestión Alcance, Tiempo, Costo y Riesgos (PMBOK)

adaptado a Gestión de Proyectos Específicos APE (MoProSoft)

Fuente: [61], Elaboración Propia

Gestión de Alcance. la Gestión del Alcance del Proyecto, incluye los

procesos necesarios para garantizar que el proyecto incluya todo el

81

trabajo requerido para completarlo con éxito. El objetivo principal de

la Gestión del Alcance del Proyecto es definir y controlar qué se

incluye y qué no se incluye en el proyecto. El PMBOK, guía del Project

Management Institute [61], en el cual se basa MoProSoft para este

proceso, establece cinco procesos básicos para la gestión exitosa del

alcance del proyecto. Los cinco procesos son los siguientes (Fig. 4.7):

1. Recopilar requisitos. Es el proceso que consiste en definir y

documentar las necesidades de los interesados a fin de cumplir con

los objetivos del proyecto.

2. Definición del alcance. Es el proceso que consiste en desarrollar

una descripción detallada del proyecto y del producto.

3. Creación de EDT. Es el proceso que consiste en subdividir los

entregables y el trabajo del proyecto en componentes más

pequeños y más fáciles de manejar.

4. Verificación del alcance. Es el proceso que consiste en formalizar la

aceptación de los entregables del proyecto que se han completado.

5. Control del alcance. Es el proceso que consiste en monitorear el

estado del alcance del proyecto y del producto, y en gestionar

cambios a la línea base del alcance.

Fig. 4.7 Diagrama de Procesos de la Gestión de Alcance de Proyectos

según el PMBOK

Fuente: [61]

En base a estas recomendaciones y adaptada a la organización en estudio,

se elaboró diagramas de actividades (Fig. 4.8) y la descripción de las mismas

(Tabla 4.9) con el fin de proponer un proceso piloto en el que se perciban

mejoras.

82

Fig. 4.8 Diagrama de Actividades Propuestas para el Proceso Administración de Proyectos Específicos APE – Gestión del Alcance

Fuente: Elaboración Propia

83

Rol Actividad Descripción Formato

Planificación

Entradas Project Charter El documento de constitución del proyecto, o “Project

Charter” es un documento que permite balancear las

intenciones y alinear las necesidades de los interesados

en el proyecto. Además, proporcionará un acuerdo

respecto a cuándo podrá considerarse exitoso el

proyecto.

Project Charter

StakeHolder Bajo el nombre “Registro de Stakeholders”, se decidió

exaltar esta actividad, ya que es uno de los más

importantes para establecer las bases tempranas

dirigidas a la posterior planificación, ejecución, así como

monitoreo y control de la información y comunicación del

proyecto, para alcanzar el éxito en éste. Este proceso

debe hacerse en la fase de inicio del proyecto para que

las salidas claves del Registro de Stakeholders y la

Estrategia de Administración de los Stakeholders sean

usadas asociativamente en el proceso de Gestión de la

Comunicación.

Registro de

StakeHolders

CLI

ET

B1.1

Recolectar

Requisitos

En base a las entradas: Project Charter y Registro de

Satakeholders se realiza la recolección de requisitos del

proyecto específico, registrándose en un documento

denominado “Documento de Requisitos” y una matriz

de trazabilidad de estos requisitos en el que La

trazabilidad de los requerimientos puede verse como la

habilidad de describir y seguir la vida de un

requerimiento tanto hacia atrás como hacia delante

durante todo el ciclo de vida de un proyecto. De modo

que dicha trazabilidad captura todos los niveles de

requerimientos, ayudando a garantizar que el proyecto

cumpla las expectativas del cliente.

Es por ello que la trazabilidad de los requerimientos

puede considerarse el pilar principal de cualquier

proyecto ya que permite asegurar que los

requerimientos técnicos han sido alcanzados mediante

los requerimientos funcionales que, a su vez, contienen

los requerimientos del negocio. Este será registrado en

un documento denominado: “Matriz de Trazabilidad de

Requisitos”

Documento de

Requisitos,

Matriz de

Trazabilidad de

Requisitos

Tabla 4.9 Descripción de las Actividades Propuestas para el Proceso Administración de Proyectos Específicos APE –

Gestión del Alcance (Parte I)


84


JDP B1.2 Definir

el Alcance

Con el ingreso del “Documento de Requisitos” se define el

alcance del proyecto, el cual me permitirá básicamente, definir

lo que está dentro de las fronteras del proyecto y lo que está

afuera de estas fronteras. Es decir, que el alcance es la

definición de los puntos que entran y no entran en el proyecto y

que es acordado por todas las partes, refiriéndose a todos los

requerimientos a satisfacer en el proyecto. Este alcance será

registrado en el documento: “Project Scope Statement”

Project Scope

Statement

B1.3 Crear

el WBS

Con el ingreso de los documentos; “Documento de

Requisitos” y el “Project Scope Statement”, se crea el WBS

o Estructura de Descomposición del Trabajo o EDT, también

conocida por su nombre en inglés Work Breakdown Structure,

es en gestión de proyectos una descomposición jerárquica

orientada al entregable, del trabajo a ser ejecutado por el

equipo de proyecto, para cumplir con los objetivos de éste y

crear los entregables requeridos, con cada nivel descendente

de la EDT representando una definición con un detalle

incrementado del trabajo del proyecto.

WBS,

Diccionario

WBS

Control

JDP,

ET

B2.1

Verificar

Alcance

En base a las entradas del documento “Project Scope

Statement” y el WBS, se realiza la verificación del alcance, la

que consiste en obtener la aceptación formal del alcance del

proyecto completado y los entregables relacionados. Esto

incluye que los interesados correspondientes revisen los

entregables para asegurarse que cada uno fue completado

satisfactoriamente. Es necesario aclarar que verificación de

alcance no es control de calidad. La verificación de alcance se

enfoca en la aceptación por parte de los interesados, y es una

actividad típicamente orientada hacia afuera del proyecto. La

verificación se realiza inspeccionando y esta inspección incluye

actividades tales como medir, examinar y verificar, a fin de

determinar si el trabajo y los productos entregables cumplen

con los requisitos y criterios de aceptación del producto. El

documento a presentar es “Solicitud de Cambio”.

Solicitud de

Cambio


Gestión del Alcance (Parte II)


85


Entrada Información de

Performance de

Trabajo

Información de Performance de Trabajo, consiste en el

estado de los entregables, progreso de Schedule y los

costos incurridos.

Información de

Performance de

Trabajo

ET,

JDP

B2.2 Controlar

Alcance

Controlar el alcance, es el proceso en el que se monitorea

el estado del alcance del proyecto y del producto y en el

que se gestionan los cambios, de

producirse, en la línea base del alcance definida en el

proceso. Este permitirá asegurar que todos los cambios

solicitados o las acciones preventivas o correctivas

recomendadas para evitar o mitigar un riesgo se procesen

a través del proceso de control integrado de cambios. En

base a la entrada del documento “Información de

Performance de Trabajo”, arroja los documentos

“Solicitud de Cambio” y “Mediciones de Performance

de Trabajo”, esto se puede realizar utilizando la Gestión

del Valor Ganado, una técnica de gestión de proyectos

que permite controlar la ejecución de un proyecto a través

de su presupuesto y de su calendario de ejecución,

Comparando la cantidad de trabajo ya completada en un

momento dado con la estimación realizada antes del

comienzo del proyecto. De este modo, se tiene una

medida de cuánto trabajo se ha realizado, cuanto queda

para finalizar el proyecto y extrapolando a partir del

esfuerzo invertido en el proyecto.

Solicitud de

Cambio,

Mediciones de

Performance de

Trabajo

JDP B2.3

Entregables

Aceptados

Una vez que se realiza la verificación del alcance, se

realiza el consolidado de los entregables aceptados.

Entregables


Gestión del Alcance (Parte III)


Gestión de Tiempo. Consiste en tener en cuenta todos los procesos necesarios para lograr

la conclusión del proyecto a tiempo, esto se logra con una serie de actividades que nos

permitirán organizarlos y programar de una forma adecuada. Estas actividades son:

1. Establecimiento de la Secuencia de las Actividades

2. Estimación de los Recursos de las Actividades

3. Estimación de la Duración de las Actividades

4. Desarrollo del Cronograma

5. Definición de las Actividades

6. Control del Cronograma

En Fig. 4.9 podemos visualizar la relación de estas actividades.

86

Fig. 4.9 Procesos de Gestión de Tiempo

Fuente: [61]

Presentamos en la Fig. 4.10 el proceso propuesto basado en las particularidades de la

organización y las buenas practicas sugeridas por el PMBOK, así mismo será descrito en detalle

en la Tabla 4.11 en el que se indican no sólo las actividades planteadas sino los roles y formatos

establecidos.

87

Fig. 4.10 Diagrama de Actividades Propuesto para el Proceso Administración de Proyectos Específicos APE – Gestión de Tiempo


88

Rol Actividad Descripción Formato Herramientas y Técnicas

Entradas Project

Scope

Statement

Descripción resumida que contiene los conceptos y

objetivos de: Alcance, tiempo, costo, calidad, satisfacción

del cliente, además de especificar los objetivos,

requerimientos, características y criterios de aceptación del

producto así como límites, requerimientos, entregables,

supuestos, restricciones, riesgos y cronograma (hitos) del

proyecto.

Project Scope

Statement

WBS Estructura de Descomposición del Trabajo o EDT, Work

Breakdown Structure o WBS

Formato WBS

Diccionario

WBS

Se realiza la descripción detallada de las actividades del

EDT

Formato

Diccionario WBS

ET

JDP

C1.1 Definir

Actividades

Se listan las actividades previamente definidas a realizarse

por cada uno de los entregables (paquetes de trabajo) del

EDT a realizar. La lista de actividades contiene las

actividades del cronograma, identificación de la actividad y

una descripción detallada.

Lista de

Actividades

Descomposición (Técnica que implica subdividir paquetes de

trabajo del proyecto en componentes más pequeños y más

fáciles de manejar) Planificación gradual (Consiste en

desglosar la EDT en niveles inferiores aquellos entregables que

se realizan en corto plazo, mientras que el trabajo a largo plazo

será planificado para los componentes de la EDT que se

encuentran en nivel más alto) y Juicios de Expertos.

C1.2

Secuencia

de

Actividades

Se realiza la secuencia de estas actividades. Esta consiste

en identificar y documentar las dependencias entre las

actividades del proyecto. Las actividades del cronograma

pueden estar ordenadas de forma lógica con relaciones de

precedencia adecuadas, así como también de adelantos y

atrasos, para respaldar el desarrollo posterior de un

cronograma de proyecto realista y confiable

Diagrama de

Red

Método de Diagramación por precedencia PDM (Método para

crear un diagrama de red del cronograma del proyecto que

utiliza casillas o rectángulos denominados nodos para

representar actividades, que se conectan con flechas que

muestran las dependencias), Determinación de dependencias

(Se utiliza tres tipos de dependencias para definir la secuencia

entre las actividades. Dependencia obligatoria (Lógica pura),

Dependencia discrecional, Dependencias externas), Aplicación

de adelantos y retrasos (Un adelanto Lead, permite la

aceleración de la actividad sucesora y un retraso Lag, causa

una demora en la actividad sucesora) y Plantilla de red de

cronograma.

Tabla 4.11 Descripción de las Actividades Propuestas para el Proceso Administración de Proyectos Específicos APE – Gestión de Tiempo (Parte 1)


89


ET

JDP

C1.3 Estimar

Recursos de

Actividades

Consiste en determinar cuáles son los recursos (personas,

equipos o material) y que cantidad de cada recurso se

utilizará, y cuando estará disponible cada recurso para

realizar las actividades del proyecto.

Requisitos de

Recursos

Juicio de expertos, Análisis de Alternativas (Muchas actividades

del cronograma cuentan con métodos alternativos de

realización. Estos incluyen el uso de distintos niveles de

capacidad o habilidades de los recursos, diferente tamaño o

tipo de máquinas, diferentes herramientas (manuales frente a

automatizadas) y la decisión de fabricación propia o compra a

terceros con respecto al recurso), Estimación ascendente

(Cuando no se puede estimar una actividad del cronograma con

un grado razonable de confianza, el trabajo que aparece dentro

de la actividad del cronograma se descompone con más detalle.

Se estiman las necesidades de recursos de cada una de las

partes inferiores y más detalladas del trabajo, y estas

estimaciones se suman luego en una cantidad total para cada

uno de los recursos de la actividad del cronograma).

C1.4 Estimar

Duración de

Actividades

Consiste en estimar la duración en periodos laborales que

se requerirán para completar cada actividad del

cronograma. Es en esta parte en el cual aparecen más

riesgos que debemos tomar en cuenta. Para realizar estas

estimaciones debemos tomar en cuenta: Los recursos

asignados a la actividad, la capacidad (productividad) de

dichos recursos, información histórica (proyectos anteriores

similares, base de datos comerciales, conocimientos y

experiencia del equipo de proyecto).

Estimación de

Duraciones

Juicios de expertos, Estimación por tres valores (La precisión

de la estimación de la duración de la actividad puede mejorarse

teniendo en cuenta la cantidad de riesgo de la estimación

original. La técnica considera tres tipos de estimaciones para

cada actividad: Más probable, se toma en cuenta los recursos

que probablemente serán asignados, su productividad, las

expectativas realistas de disponibilidad para la actividad del

cronograma, las dependencias de otros participantes y las

interrupciones, Optimista, toma el mejor escenario posible y

finalmente el análisis de reserva (Calculados para un

cronograma del proyecto, se consideran según los riesgos del

cronograma. Estas reservas pueden ser calculadas como un

porcentaje de la duración estimada de la actividad, como una

cantidad fija de periodos laborales, o mediante el análisis

cuantitativo de riesgo de cronograma. La reserva para

contingencias puede utilizarse de forma total o parcial,

pudiendo reducirse o eliminarse con posterioridad a medida que

se dispone de información más precisa sobre el proyecto.



90


ET

JDP

C1.5

Desarrollar

Schedule

Consiste en determinar las fechas de inicio y fin planificadas

para las actividades del proyecto. Para ello se analiza las

secuencias de las actividades, la duración de las

actividades, los requisitos de los recursos y las

restricciones, todo esto con el fin de crear un cronograma

realista y efectivo

Schedule del

Proyecto

Método de la ruta crítica (Calcula la fechas de inicio y finalización

tempranas y tardías teóricas para todas las actividades del

cronograma, sin considerar las limitaciones de los recursos,

realizando un análisis de recorrido hacia adelante y un análisis de

recorrido hacia atrás a través de los caminos de red del cronograma

del proyecto. En cualquier camino de red, la flexibilidad del

cronograma se mide por la diferencia positiva entre las fechas

tempranas y tardías, y se denomina holgura total. Los caminos

críticos, tienen una holgura total o igual a cero o negativa, y las

actividades del cronograma en un camino crítico se denominan

actividades críticas.

Control

Entrada Información

de

performance

de Trabajo

Primero los Datos de desempeño del proyecto son

registrados en las actividades del día a día. Esto forma parte

del proceso de “Dirigir y Gestionar el trabajo en el proyecto”.

Esto incluye por ejemplo mediciones de trabajo físico

completado, mediciones técnicas de calidad, fechas de

inicio y fin real de las actividades, número de solicitudes de

cambios, número de defectos, costos reales, duraciones

reales, etc. Luego los datos sirven de insumo a diferentes

procesos de Monitoreo y Control.

Documento

de

Información

de

Performance

de Trabajo

ET

JDP

C2.1

Controlar

Schedule

Controla el correcto desarrollo del cronograma, teniendo en

cuenta entre otras cosas la línea base del cronograma.

Solicitud de

Cambios,

Medición de

Performance

de Trabajo

Solicitud de cambio: Establecer quien realiza solicitudes de cambio,

cual es el canal de comunicación apropiado y bajo que formato. Es

importante evitar que se hagan solicitudes directas a los

desarrolladores. Dicho procedimiento debería contemplar como

mínimo lo siguiente:

Análisis y valoración: El equipo revisa la solicitud y

determinar el esfuerzo (por ejemplo en horas) y la posible

planificación (Fecha).

Determinar si es un cambio menor: Si el cambio está dentro

de umbrales previamente establecidos, este puede ser

aprobado de forma expresa.

Comité de cambios: Un comité integrado por miembros del

equipo, del usuario y otros involucrados debe revisar la

solicitud ya valorada por el equipo. Ejecución del cambio:

Sólo después que se han cumplida la aprobación, bien sea

por vía expresa o por la vía de comité de cambio, se procede

a desarrollar el cambio.



91

Gestión de Costo. Asegura que las tareas se lleven a cabo dentro de los rangos económicos

impuestos (Presupuesto del proyecto o recursos asignados para la actividad

correspondiente). Se debe de tener en cuenta los requisitos de los interesados para la

obtención de los costos, ya que los diversos interesados medirán los costos del proyecto

de diferentes maneras y en tiempos diferentes. En ese sentido, detallaremos las tres

actividades que el PMBOK recomienda para garantizar que las tareas se lleven a cabo

satisfactoriamente, las mismas fueron adaptadas a la organización en estudio para para

lograr los objetivos planteados.

Estimar los Costos. Consiste en desarrollar una aproximación de los costos de los

recursos necesarios para completar cada actividad del cronograma. El estimador

debe de considerar las posibles causas de variación de los costos incluyendo los

riesgos. Los datos históricos, fundamentalmente de los proyectos anteriores, son

válidos en este proceso porque permite que los costos sigan patrones de desviación.

Existen distintos tipos de desviación de costos y niveles de exactitud son requeridas

en distintas fases del proyecto. Como por ejemplo, Estimación aproximada de orden

de maginitud ROM (Rough order of magnitude) el mismo es usado generalmente en

las fases tempranas del proyecto, su exactitud es -25% a +75%. Por otro lado,

tenemos también la desviación Presupuestario (Budgetary), esta se usa a menudo

para propósitos de apropiación y su exactitud es de -10% a +25%. Rango de

estimación (Range of estimate), se usa a menudo como una alternativa al tipo ROM

donde la exactitud de la estimación no se conoce bien. Exactitud, +/- 35%. Y

finalmente, Estimación definitiva, basada en información detallada del trabajo del

proyecto, con una exactitud de +/- 5%.

Para los fines del presente trabajo se sugirió a la organización realizar una primera

estimación a grosso modo, utilizando la estimación orden de magnitud, que como

ya mencionamos tiene un rango de un 25% hacia abajo y un 75% hacia arriba, lo

que representa un primer acercamiento a los entregables a construir. En la

planificación deberíamos realizar una estimación presupuestal (sobre el WBS) que

sería el primer abordaje para calcular los costos del proyecto, con un -10% y un

+25% de rango. Seguidamente, la estimación definitiva (-5%, +10%) es la que

utilizaremos en el plan del proyecto.

Determinar el Presupuesto de Costos. Consiste en sumar los costos estimados de

las actividades individuales o paquetes de trabajo a fin de establecer una línea base

de costo. Durante esta etapa se debe considerar las contingencias para evitar ser

sorprendidos por algunos riesgos. Debemos de aclarar que línea de costos no es lo

mismo que costo total y la reserva presupuestada no debería ir con la línea base

planteada como referencia. Esta línea base nos sirve para medir la ejecución con el

fin de medir el rendimiento del proyecto.

Controlar los Costos. Se realiza el seguimiento del presupuesto de los costos,

existen estrategias de aceptación del riesgo siempre y cuando el riesgo es pequeño

y no influya de tal manera que nos provoque alguna desviación no planificada.

92

Fig. 4.11 Diagrama de Actividades Propuesto para el Proceso Administración de Proyectos Específicos APE – Gestión de Costo


93


Entradas Project

Scope

Statement

Documento

del Project

Scope

Statement

WBS Diagrama

WBS

Diccionario

del WBS

Documento

del

diccionario

del WBS

Schedule del

Proyecto

GER

JDP

ET

D1.1 Estimar

Costos

Si bien en nuestras entradas no hemos considerado los el

documento de factores ambientales de la empresa tal como

sugiere el estándar del PMI, si sugerimos que se tome en

cuenta las condiciones del mercado, las bases de datos

comerciales que proporcionan información de costos

estándar referidas a insumos, equipos y recursos humanos.

Documento

de estimado

de costos de

actividades

Juicios de expertos,

Estimación análoga. Implica usar el costo real de proyectos

anteriores similares como base para estimar el costo del proyecto

actual. La estimación análoga es menos costosa que otras técnicas,

pero generalmente es menos exacta.

Estimación ascendente. Consiste en estimar el costo de paquetes de

trabajo individuales o actividades del cronograma individuales con el

nivel más bajo de detalle. El costo detallado luego se resume o

“acumula” en niveles superiores para fines de información o

seguimiento. El costo y la exactitud en general están motivadas por

el tamaño y la complejidad de la actividad del cronograma o del

paquete de trabajo individuales. En general, las actividades con un

esfuerzo asociado menor aumenta la exactitud de las estimaciones

de costos de las actividades del cronograma.

Finalmente, no debemos de dejar del lado el Análisis de Reserva, ya

que las reservas son para contingencias que utilizará a discreción el

director del proyecto, con el fin de gestionar eventos previstos, pero

no ciertos. Estos eventos son “incógnitas conocidas”, y forman parte

del alcance del proyecto y la línea base de costo. A medida que las

actividades del cronograma avanzan, la reserva para contingencias,

medida por el consumo de recursos de las actividades del

cronograma de duración distinta de cero, puede ajustarse.

Tabla 4.12 Descripción de las Actividades Propuestas para el Proceso Administración de Proyectos Específicos APE – Gestión de Costos (Parte 1)


94


GER

JDP

D1.2

Determinar

Presupuesto

Tal como se mencionó anteriormente, consiste en sumar los

costos estimados de las actividades individuales a fin de

establecer la línea base de costo.

Línea base

de Costo

Suma de Costo. Las estimaciones de costo de las actividades del

cronograma se suman por paquetes de trabajo de acuerdo con el

EDT. Las estimaciones de costos de los paquetes de trabajo, luego

se suman para los niveles superiores de componentes de la EDT.

Análisis de Reserva.

Juicio de Expertos,

Relaciones Históricas

Control

Entradas Línea Base

de Costo

Información

de

Performance

del Trabajo

JDP D2.1 Control

de Costos

El seguimiento de control se realiza a la línea base de costos

con el fin de evitar fluctuaciones muy severas.

Solicitud de

Cambios,

Mediciones

de

Performance

del Trabajo y

Pronóstico

de

Presupuesto

Tabla 4.12 Descripción de las Actividades Propuestas para el Proceso Administración de Proyectos Específicos APE – Gestión de Costos

(Parte 2)


95

Gestión de Riesgo. Un riesgo de un proyecto es un evento o condición inciertos que, si se

produce, tiene un efecto positivo o negativo sobre al menos un objetivo del proyecto, como

tiempo, costo, alcance o calidad.

El riesgo de un proyecto tiene su origen en la incertidumbre que está presente en todos los

proyectos. Riesgos conocidos son todos aquellos que han sido identificados y analizados,

y es posible planificar dichos riesgos siguiendo los procesos de gestión de riesgos. Los

riesgos desconocidos no pueden gestionarse proactivamente, y una respuesta prudente del

equipo del proyecto puede ser asignar una contingencia general contra dichos riesgos, así

como contra riesgos conocidos para los cuales quizá no sea rentable o posible desarrollar

respuesta proactiva. Los riesgos positivos son oportunidades y por el contrario, los

negativos amenazas, eventos inciertos que nos provocan problemas.

El proceso de planificación de Gestión de Riesgos incluye adoptar las siguientes acciones

(Fig. 4.12):

1. Identificar el Riesgo

2. Evaluar el Riesgo (Cuantificar – Cualificar)

3. Planes de acción. Estrategias para minimizar los riesgos.

4. Contingencia.

Para realizar la gestión de riesgos de forma adecuada, se necesita la inversión de recursos

como costo, tiempo, etc. Debido a ello debemos realizar priorización y tratar cada riesgo de

forma diferenciada. Así mismo, para efecto del presente trabajo, se realizó la adaptación

del PMBOK que sugiere la lista de acciones anteriormente descritas, las cuales deben estar

dirigidas a un contexto de pequeña y mediana empresa sin sacrificar ninguna de sus

directivas.

Fig. 4.12 Gestión Continua de Riesgos

Fuente: [61]

A continuación realizamos el diagrama de procesos (Fig. 4.13) y la Tabla de descripción del mismo (Tabla 4.13) Adaptado a la organización tomando en cuenta las particularidades encontradas.

96

Fig. 4.13 Diagrama de Actividades Propuestas para el Proceso Administración de Proyectos Específicos APE – Gestión de Riesgos


97


Entra

das

Project Scope

Statement

Documento de

Project Scope

Statement

Plan de Gestión

de Schedule

Documento de

Plan de Gestión

de Schedule

Plan de Gestión

de Costos

Documento de

Plan de Gestión

de Costos

Plan de Gestión

de

Comunicaciones

El Plan de Gestión de Comunicaciones del Proyecto, es

un componente del Plan de Dirección del Proyecto

(Project Management Plan) y describe la forma en que

se planificarán, estructurarán, monitorearán y

controlarán las comunicaciones del proyecto.

Documento de

Plan de Gestión

de

Comunicaciones

JDP

ET

E1.1 Planificar la

gestión de

Riesgos

Una vez recibida las entradas, se realiza la planificación

de la gestión de riesgos, la misma consiste en adoptar

acciones consistentes en: Identificar, Evaluar cualitativa

y cuantitativamente, Planes de acción (estrategia para

minimizar riesgos) y finalmente la contingencia del

riesgo. Las actitudes respecto al riesgo y la tolerancia al

riesgo de las organizaciones y las personas

involucradas en el proyecto influirán en el plan. Las

actitudes y tolerancias respecto al riesgo pueden

expresarse en enunciados de política o revelarse en

acciones.

Otra cosa que se realiza en esta actividad y no por ello

caer en el exceso de trabajo, es la descripción de cómo

se estructurará y realizará esta gestión, el cual incluirá:

Metodología (Define los métodos, herramientas y las

fuentes de información que pueden utilizarse para

realizar la gestión de riesgos), Roles y

Responsabilidades (Define el líder, el apoyo y los

miembros del equipo de gestión para cada actividad

Documento Plan

de Gestión de

Riesgos

Reuniones de planificación y análisis. Los equipos del

proyecto celebran reuniones de planificación y análisis para

desarrollar el Plan de Gestión de Riesgos, a estas reuniones

pueden asistir entre otros, el director del proyecto, miembros

del equipo de trabajo, e interesados en el proyecto

seleccionados, cualquiera de la organización con

responsabilidad de gestionar las actividades de

planificación y ejecución de riesgos y otras personas según

sea necesario.

Las plantillas generales de la organización para categorías

de riesgo y las definiciones de términos como niveles de

riesgo, la probabilidad por tipo de riesgo, el impacto por tipo

de objetivo, y la matriz de probabilidad e impacto se

adaptarán para el proyecto específico. Las salidas de estas

actividades se resumirán en el Plan de Gestión de riesgos.

Tabla 4.13 Descripción de las Actividades Propuestas para el Proceso Administración de Proyectos Específicos APE – Gestión de Riesgos

(Parte 1)


98


JDP

ET

E1.1 Planificar la

gestión de Riesgos

(Cont.)

…del plan de gestión, asigna personas a estos roles y

explica sus responsabilidades), Preparación del

Presupuesto (Asigna recursos y estima los costos

necesarios para la gestión a fin de incluirlos en la línea

base de costos), y finalmente Periodicidad (Define

cuándo y con qué frecuencia se realizará el proyecto de

gestión de riesgos durante el ciclo de vida del proyecto,

y establece las actividades de gestión que se incluirán

en el cronograma del proyecto).

Una de las cosas que se debe realizar es la de

categorizar a los riesgos con el fin de realizar un mejor

tratamiento, la misma consiste en proporcionar una

estructura que garantice un proceso completo de

identificación sistemática de los riesgos con un nivel de

detalle uniforme, y contribuye a la efectividad y calidad

de identificación. Una estructura de desglose de riesgos

(Risk Breakdown Structure: RBS) es uno de los métodos

para proporcionar dicha estructura.

E1.2 Identificar

Riesgos

Consiste en determinar qué riesgos pueden afectar al

proyecto y así documentar sus características

Documento de

Lista de

Riesgos

Técnica de Recopilación de Información (Entrevistas, a

participantes experimentados del proyecto, interesados y

expertos en la materia puede servir para identificar riesgos.

Las entrevistas son una de las principales fuentes de

recopilación de datos, así mismo, la identificación de la causa,

una investigación de las causas esenciales de los riesgos de

un proyecto. Refina la definición del riesgo y permite agrupar

los riesgos por causa. Se pueden desarrollar respuestas

efectivas a los riesgos si se abordan sus causas), Análisis de

Listas de Control (Pueden ser desarrolladas basándose en

información histórica y en conocimiento que ha sido

acumulado de proyectos anteriores similares y de otras

fuentes de información. El nivel más bajo de la RBS también

puede utilizarse como listas de control de riesgos. Si bien una

lista de control puede ser rápida y sencilla, es imposible

elaborar una que sea exhaustiva. Debe tenerse cuidado de

explorar elementos que no aparecen en la lista de control).


(Parte 2)


99


JDP

ET

E1.2 Identificar

Riesgos (Cont.)

Análisis de Supuestos o asunciones (Detrás de toda

suposición hay un riesgo escondido. El análisis de asunciones

es una herramienta que explora la validez de las asunciones

según su aplicación en el proyecto. Identifica los riesgos del

proyecto debidos al carácter inexacto, inconsistente o

incompleto de las asunciones), Técnicas de Diagramación

(Se pueden utilizar por ejemplo, diagramas causas y efectos

o diagramas Ishikawa o de espina de pescado, y son útiles

para identificar las causas de los riesgos, diagramas de flujo

o de sistemas, muestran cómo se relacionan los diferentes

elementos de un sistema, y el mecanismo de causalidad y

finalmente los diagramas de influencias, estos diagramas son

representaciones gráficas de situaciones que muestran las

influencias causales, la cronología de eventos y otras

relaciones entre variables y resultados.), Análisis FODA

(Análisis de debilidades, amenazas, fortalezas y

oportunidades) y finalmente el Registro de Riesgos (Contiene

los resultados de los demás procesos de gestión de riesgos a

medida que se llevan a cabo. La preparación del registro de

riesgos comienza en el proceso Identificación de riesgos y

luego está disponible para la gestión de otros proyectos y

otros procesos de gestión de los riesgos del proyecto,

podemos listarlos: Lista de Riesgos Identificados, Lista de

Posibles Respuestas, Causas de Riesgos y Categorías de

Riesgos actualizadas).


(Parte 3)


100


JDP

ET

E1.3 Realizar

Análisis

Cualitativo de los

Riesgos

Consiste en realizar un análisis cualitativo de la

probabilidad y el impacto de los riesgos principalmente

con el objetivo de priorizarlos por su severidad.

Priorización

de Riesgos

Evaluación de Probabilidad e Impacto de los Riesgos (Investiga la

probabilidad de ocurrencia de cada riesgo específico. La evaluación del

impacto de los riesgos investiga el posible efecto sobre un objetivo del

proyecto, como tiempo, costo, alcance o calidad, incluidos tanto los efectos

negativos por las amenazas que implican, como los efectos positivos por las

oportunidades que generan. Para cada riesgo identificado se evalúan la

probabilidad y el impacto. Los riesgos pueden ser evaluados en entrevistas

o reuniones con participantes seleccionados por su familiaridad con las

categorías de riesgo del orden del día. Entre ellos se incluyen los miembros

del equipo del proyecto y, quizás, expertos ajenos al proyecto. Es necesario

el juicio de expertos, ya que es posible que haya poca información sobre los

riesgos en la base de datos de la organización de proyectos anteriores. Un

facilitador experimentado puede dirigir la discusión, ya que los participantes

pueden tener poca experiencia en la evaluación de riesgos. El nivel de

probabilidad de cada riesgo y su impacto sobre cada objetivo se evalúa

durante la entrevista o reunión. Los detalles explicativos, incluidas las

asunciones que justifican los niveles asignados, también se registran). Un

análisis cualitativo de riesgo requiere datos exactos y sin sesgos para que

sea creíble. El análisis de la calidad de los datos sobre riesgos es una

técnica para evaluar el grado de utilidad de los datos sobre los riesgos para

la gestión de riesgos. Implica examinar el grado de entendimiento del riesgo,

y la exactitud, calidad, fiabilidad e integridad de los datos sobre el riesgo. El

uso de datos sobre riesgos de baja calidad puede llevar a un análisis

cualitativo de riesgos de poca utilidad para el proyecto. Si la calidad de los

datos es inaceptable, puede ser necesario recopilar datos mejores.

Categorización de riesgos (Los riesgos del proyecto pueden categorizarse

por fuentes de riesgo por ejemplo, usando el RBS, área del proyecto

afectada, por ejemplo, usando el EDT, u otra categoría útil, por ejemplo fase

de proyecto. Para determinar las áreas del proyecto que están más

expuestas a los efectos de la incertidumbre. Agrupar los riesgos por causas

comunes puede contribuir a desarrollar respuestas efectivas a los riesgos).

Evaluación de la urgencia del riesgo (Los riesgos que requieren respuestas

a corto plazo pueden ser considerados como más urgentes. Entre los

indicadores de prioridad pueden incluirse el tiempo para dar respuesta a los

riesgos, los síntomas y señales de advertencia, y la calificación del riesgo).


(Parte 4)


101


JDP

ET

E1.3 Realizar Análisis

Cualitativo de los Riesgos

(Cont.)

Actualización del Registro de Riesgos (El registro de riesgos se inicia

durante el proceso de Identificación de Riesgos. El registro de riesgo

se actualiza con información del Análisis Cualitativo de Riesgos y el

registro de riesgo actualizado se incluye en el plan para la dirección

del proyecto.

E1.4 Realizar Análisis

Cuantitativo de los Riesgos

Consiste en realizar un análisis cuantitativo a los

riesgos priorizados en el análisis cualitativo con

el fin de ser más certeros con la probabilidad y el

impacto de cada riesgo. Para esto se hacen uso

de técnicas avanzadas como Montecarlo, PERT,

distribución probabilística, etc.

Análisis

Probabilístico

Técnica de análisis cuantitativo de riesgo y de modelado. Dentro de

las distintas técnicas tenemos al Análisis del Valor Monetario

esperado, Modelado y Simulación y Análisis de Sensibilidad. Dadas

las características de proyectos que la organización asume, se ha

decidido utilizar esta última técnica que consiste en la ayuda para

determinar que riesgos tienen el mayor impacto posible sobre el

proyecto. Este método examina la medida en que la incertidumbre

de cada elemento del proyecto afecta al objetivo que está siendo

examinado, cuando todos los demás elementos inciertos se

mantienen en sus valores de línea base.

E1.5 Planificar Respuestas

a Riesgos

Consiste en definir las acciones a realizar para

reducir las amenazas de los riesgos y para

mejorar las oportunidades.

Documento

de Plan de

Riesgos

Estrategias para Riesgos Negativos o Amenazas. (Evitar el riesgo

(Risk Avoindance), implica cambiar el plan para la dirección del

proyecto para eliminar la amenaza que representa un riesgo

adverso. Transferir, Transferir el Riesgo (Risk Transfer), Requiere

trasladar el impacto negativo de una amenaza, junto con la

propiedad de la respuesta, a un tercero. Transferir el riesgo

simplemente da a otra parte la responsabilidad de su gestión; no lo

elimina ni significa que el encargado del proyecto deja de ser

responsable. Ejemplo, cuando decido que otra organización

desarrolle un sistema en vez de mi equipo debido a que este no

domina la herramienta y nos pone en riesgo de no completar la

solución en el tiempo dado así como no lograr la calidad esperada.

Mitigar. Mitigar el riesgo (Risk Mitigation), implica reducir la

probabilidad y/o el impacto de un evento de riesgo adverso a un

umbral aceptable. Ejemplo, Cuando decido enviar a mi equipo a un

curso para mitigar su falta de experiencia en una herramienta de tal

manera que el riesgo de que no domine la herramienta se minimice.

O cuando contrato a un consultor externo para reducir el riesgo de la

falta de experiencia de mi personal en el tipo de proyecto a

desarrollar. Aceptar, Estrategia


(Parte 5)


102


JDP

ET

E1.5 Planificar Respuestas a

Riesgos (Cont.)

que se adopta debido a que rara vez es posible eliminar todo el

riesgo de un proyecto. Esta estrategia indica que el equipo de

proyecto ha decidido no cambiar el plan para la dirección del

proyecto para hacer frente a un riesgo, o no ha podido identificar

ninguna otra estrategia de respuesta adecuada. Puede ser

adoptada tanto para las amenazas como para las oportunidades.

Esta estrategia puede ser activa o pasiva. La aceptación pasiva

no requiere acción alguna, dejando en manos del equipo de

proyecto la gestión de las amenazas o las oportunidades a

medida que se producen. La estrategia de aceptación activa más

común es establecer una reserva para contingencias, que

incluyan la cantidad de tiempo, dinero o recursos necesarios para

manejar las amenazas o las oportunidades conocidas, o incluso

también las posibles y desconocidas).

Estrategias para riesgos positivos u oportunidades. Según el tipo

de proyecto que se presente se puede utilizar por ejemplo estas

estrategias: Explorar, (Risk explotation), Se puede seleccionar

esta estrategia para los riesgos con impactos positivos, cuando

la organización desea asegurarse que la oportunidad se haga

realidad. Esta estrategia busca eliminar la incertidumbre asociada

con un riesgo del lado positivo en particular haciendo que la

oportunidad definitivamente se concrete. Compartir, compartir un

riesgo positivo (Risk sharing), implica asignar la propiedad a un

tercero que está mejor capacitado para capturar la oportunidad

para beneficio del proyecto. Mejorar. (Risk enhancement), Esta

estrategia modifica el “tamaño” de un oportunidad, aumentando

la probabilidad y/o los impactos positivos, e identificando y

maximizando las fuerzas impulsoras clave de estos riesgos de

impacto positivo. Finalmente, Aceptar. Aceptar la oportunidad,

consiste en tener la voluntad de tomar la ventaja de ella si se

presenta, pero sin buscarla de manera activa.

Actualización de Registros de Riesgos y Finalmente Juicios de

Expertos.


(Parte 6)


103


Control

Entradas Información del Performance

del Trabajo

Mediciones del Performance

del Trabajo

JDP

ET

E2.1 Monitoreo y Control de

Riesgos

El objetivo principal de monitorear y controlar

los riesgos es rastrear los riesgos identificados,

monitorear los riesgos residuales, identificar

nuevos riesgos, asegurar que los planes de

respuesta a riesgos se ejecutan en el momento

apropiado, y evaluar su efectividad a través del

ciclo de vida del proyecto. Para cada riesgo o

conjunto de riesgos para los cuales se ha

definido una respuesta de contingencia, se

debe haber especificado un correspondiente

conjunto de condiciones llamados

disparadores (triggers). Es la responsabilidad

del propietario de acción asegurar que estas

condiciones sean monitoreadas

efectivamente y que las acciones

correspondientes se lleven a cabo como se

definieron, de una manera oportuna.

Solicitud de

Cambio

Gestionar las Reservas de Contingencia. Las reservas se

pueden haber asignado separadamente para cubrir riesgos

relacionados al tiempo y riesgos relacionados al costo. Se

requieren técnicas para permitir al Director del Proyecto

evaluar en cualquier punto del proyecto si estas proveen el

nivel requerido de confianza en el éxito del proyecto.

Rastrear las Condiciones de los Disparadores (Triggers). Las

condiciones de los disparadores y sus correspondientes

métricas se definen durante el proceso Planificar Respuestas a

Riesgos. Se requieren herramientas para evaluar y rastrear

estas condiciones contra la línea base del proyecto o

umbrales especificados, basándose en el estado real del

proyecto. Estas herramientas pueden escogerse para proveer

información de riesgos relacionada con entregables, tales

como rendimiento, así como también con características del

proyecto, tales como tiempo y costo.


(Parte 7)


104


De igual forma como mencionamos en el punto relacionado a la experiencia piloto

del proceso Gestión de Negocios GNeg. Se ejecutaron 2 pilotos al proceso de

Administración de Proyectos Específicos con cada integrante del equipo de trabajo

asumiendo roles los cuales están indicados en la Tabla 4.14 y cuya descripción es

la siguiente: El rol denominado RAPE está a cargo por uno de los desarrolladores y

entre otras cosas, está a cargo del cumplimiento de las actividades y productos

generados durante su práctica y es en la Tabla 4.15 que se detalla el comportamiento

y evaluación de la ejecución del modelo de mejora propuesto y el piloto realizado así

como el cumplimiento de las actividades indicadas. La representación gráfica (Fig.

4.14) es el porcentaje de cumplimiento de las actividades del proceso de mejora

propuesto.

Roles Siglas

Gerente General GG

Analista Desarrollador AD

Responsable Administración Proyectos Específicos

RAPE

Tabla 4.14 Roles y Siglas de la Experiencia Piloto

Actividades

Denominación del Piloto Rol Núm. Diseñadas Núm. Realizadas % de Cumplimiento

Proyecto 1 GG 4 3 75

RGP 15 14 93

AD 20 18 90

Cumplimiento Total: 39 35 90


RGP 15 13 87

AD 15 14 93



RGP 11 10 91

AD 19 15 79


Tabla 4.15 Comportamiento y Evaluación del Proceso Gestión de Administración de Proyectos

Específicos APE Fuente: Elaboración Propia

105

Fig. 4.14 Ejecución de Pilotos del Proceso Administración de Proyectos Específicos APE Fuente: Elaboración Propia


Bajo el marco de trabajo del PMI, modelo en el que se basa MoProSoft para el

proceso de Administración de Proyectos Específicos APE, se han formulado e

implementado mejoras para este proceso y con el fin de sentar bases a futuros

procesos de mejora, en ese sentido implica conocer cómo se han desempeñado

estas mejoras hasta el momento, hay pues una necesidad de reflexionar sobre cómo

se puede mejorar la formulación e implementación en un nuevo ciclo de mejora. Para

lo cual mencionamos lo siguiente:

Dada la situación al inicio del proceso de mejora, la organización no tenía en claro

actividades, formatos, herramientas y técnicas que permitan cumplir con los objetivos

de los proyectos presentados. Los objetivos propuestos por el modelo MoProSoft es

lograr los objetivos del proyecto en tiempo y costo, una adecuada comunicación con

el cliente y con los miembros del equipo, controlar riesgos presentados con una

adecuada gestión de cambios que permita cumplir con el cronograma, costos y

calidad adecuados. En ese sentido, se planteó una serie de actividades relacionadas

a esos objetivos, es así que se planteó la implementación de procesos de Gestión

de Alcance para poder definir el cronograma de actividades que permitirán

cumplimentar con el alcance planteado, de igual forma, el proceso de Gestión de

Tiempo, para establecer la duración de actividades e hitos del proyecto, Proceso de

% Cumplimiento

80

82

84

86

88

90

Proyecto 1Proyecto 2

Proyecto 3

90

88

84

% Cumplimiento

106

Gestión de Costo, para controlar los gastos incurridos y la previsión en las

actividades que lo requieran y finalmente el Proceso de Gestión de Riesgos que nos

permitirá controlar situaciones previstas e incentivar oportunidades detectadas.

Debemos mencionar que al inicio de la implementación de las actividades para este

proceso, hubo cierta resistencia a participar de la aplicación de la misma

argumentándose excesos en la burocracia y poca claridad en el flujo del proceso

propuesto. Para enfrentar esta situación, se realizaron diversas reuniones para

explicar el objetivo que persigue el modelo en este proceso en particular, las ventajas

de seguir el flujo planteado, los formatos establecidos y las herramientas y técnicas

planteadas. Una forma de disminuir la complejidad en el flujo propuesto, fue la de

presentar de forma separada por procesos del modelo PMBOK adaptadas al proceso

APE del modelo MoProSoft. Es así que se presentó Gestión de Alcance, Tiempo,

Costo y Riesgos en flujos, actividades, formatos, herramienta y técnicas separadas

para el proceso APE así como Roles.

En la gestión de Procesos de Alcance y demás procesos, se adaptaron las

actividades, flujos, formatos y herramientas propuestas por PMBOK, adaptándose a

las necesidades de la organización y los objetivos de MoProSoft, generando así una

mayor aceptación por parte del equipo. Particularmente, se introdujo el concepto de

EDT para que la organización pueda organizar mejor sus actividades, ganar con esto

una mejor dimensión de tiempo, costos y controlar el cumplimiento del alcance, otro

aporte fue la gestión de cambios, ya que los cambios aceptados se realizaban sin

ningún tipo de control, en este sentido, el equipo de trabajo pensaba que el comité

de cambios necesariamente debería estar integrado por personal externo a la

organización pero luego de desarrollar el piloto se comprobó que era un rol que podía

estar asumido por parte del equipo.

Otro punto a resaltar, fue la incorporación de las líneas base (Tiempo, Costo) que

permitiría tener una referencia necesaria para el control y seguimiento de estos

procesos.

Es en la gestión de Riesgos donde se han realizado mayores aportes, ya que en el

proceso inicial de la organización no se contemplaron muchas de estas actividades

necesarias para garantizar la calidad de los proyectos, entregas, etc. Es así que se

generaron reuniones de trabajo con la participación de algún experto en el dominio

del problema para incentivar lluvia de ideas (Entre otras técnicas), para identificar

riesgos, es aquí donde se detectó una baja participación del equipo de trabajo para

dar aporte a esta identificación, para contrarrestar esto, se planteó la utilización del

algoritmo Round Robin (Algoritmo muy utilizado en la administración de los procesos

en los sistemas operativos, con la utilización del quantum de tiempo y la participación

total del equipo).

107

4.5. Desarrollo y Mantenimiento de Software (DMS)


Si bien el resultado de la evaluación inicial realizada a la organización como parte

del modelo MoProSoft dio como resultado un 61.9% de cumplimiento en este

proceso alcanzando por lo tanto el Nivel 1 del modelo, es por el contrario, que al

realizarse reuniones de entrevista a la directiva de la organización con el propósito

de identificar Objetivos y Problemas, los problemas mencionados relacionados con

este proceso dieron como resultado: La elicitación de Requerimientos y testing,

indicándonos por lo tanto, la falencia existente en estos puntos del ciclo de vida de

la Ingeniería de Software.

A continuación, realizaremos una descripción del proceso actual de DMS en el que

presentaremos las actividades y formatos encontrados en la organización, los

mismos que serán mostrados en el gráfico de la Fig. 4.15 parte 1 y 2. Analizando el

diagrama respectivo, podemos mencionar como partes resaltantes, que se hace una

revisión del proyecto y posterior asignación de tareas a los miembros del equipo,

posteriormente se analizan las necesidades del proyecto cuyo producto final es un

catálogo de requisitos, especificación de requerimientos (actualizado) y finalmente,

la realización de las pruebas, el manual de usuario y la configuración de software.

Un punto a mencionar además, es la falta de documentación suficiente como

resultado del trabajo efectuado en este proceso, recordando que la documentación

del software es la manifestación más importante del mismo, es la parte visible del

proceso y que sin ella el software no se puede mantener, los usuarios no pueden

realizar su entrenamiento y que prácticamente no se puede utilizar, entre otras

cosas.

Finalmente otro punto a mencionar, es la realización de pruebas, las mismas que se

efectúan al final del ciclo y no durante el proceso de desarrollo de software

provocando de esta manera, el incremento de los riesgos en la validación y

verificación del producto con la consecuente insatisfacción del cliente en la baja

calidad del producto software.

108

Fig. 4.15 Diagrama Proceso Actual - Proceso de Desarrollo y Mantenimiento de Software (Parte 1)


109

Fig. 4.15 Diagrama Proceso Actual - Proceso de Desarrollo y Mantenimiento de Software (Parte 2)


110


Para realizar la mejora de este proceso, se han identificado cuales actividades del

modelo no están incluidas en la situación inicial, enfocándose principalmente en los

Objetivos y Problemas planteados por los directivos de la organización relacionados

a este proceso. Así mismo, se han diseñado las actividades necesarias para la

elaboración de artefactos relacionados a la Elicitación de Requerimientos y

Verificación y Validación de software, haciendo la salvedad de que los artefactos

propuestos, las técnicas, herramientas y las actividades empleadas, fueron

discutidas y seleccionadas junto al Gerente de Proyectos y parte del equipo de

trabajo con más experiencia, persiguiendo el propósito de disponer de todos los

elementos necesarios y suficientes para alcanzar las sugerencias del modelo y la de

enfrentar los problemas identificados por los directivos sin caer en el exceso de

documentación burocratizante.

En la primera parte del proceso propuesto, se presentará todo lo referido a la

Elicitación de Requerimientos, basándonos principalmente en el trabajo de Amador

Durand Toro [63], en el que describe un entorno metodológico para la ingeniería de

requisitos de sistemas de información compuesto por un modelo de procesos

iterativo en el que se identifican tres actividades, Elicitación, Análisis y Validación,

una metodología para la Elicitación de requisitos incluyendo las actividades a

realizar, los productos a obtener y las técnicas a emplear, una metodología para el

análisis y finalmente una metodología para la validación de requisitos, adaptándose

al contexto de la organización en estudio.

1. Preliminares

Si realizamos un ejercicio de comparación con la situación que se venía dando

en los primeros tiempos de la computación en general y del desarrollo de software

en particular, pocos son los aspectos comunes que podríamos encontrar. Sin

embargo, podemos hacer un análisis e identificar algunas de las características

del desarrollo de software en los comienzos de la informática y como esa

situación ha variado notablemente en nuestra actualidad.

El hardware es mucho más caro que el software. La máquina y su

mantenimiento cuestan millones de dólares. Comparado con ese coste, el

sueldo del científico que escribe el programa es ridículo, así que ¿por qué

preocuparse por el coste del desarrollo de software?

El desarrollo del hardware es más complejo que el del software. La

tecnología hace que el hardware sea complejo de construir y mantener.

El software habitual suelen ser programas no muy grandes (debido, entre

otras limitaciones, a la escasa capacidad de memoria) y suelen estar escritos

por una única persona.

111

Los requisitos que tiene que cumplir el software son simples. Por lo tanto,

¿por qué preocuparse por la complejidad del software?

El hardware es poco fiable. Debido a la tecnología que se utiliza para su

implementación, en cualquier momento la máquina puede sufrir una avería,

así que ¿para qué preocuparse por la calidad del software?

Es así que en nuestra actualidad, esta despreocupada situación respecto al

software cambia casi radicalmente cuando, gracias a los avances en la

tecnología, aumenta la capacidad de memoria y se reducen los costes de

desarrollo y mantenimiento del hardware, se empiezan a comercializar los

primeros ordenadores y la demanda de software más complejo crece

rápidamente. La crisis del software, término utilizado por primera vez en la

conferencia organizada por la Comisión de Ciencia de la OTAN en Garmisch,

Alemania, en octubre de 1968, para designar la gran cantidad de problemas que

presentaba (y aún presenta) el desarrollo de software y el alto índice de fracasos

en los proyectos de desarrollo, hace su aparición también. ¿Qué podía hacerse

ante una situación en la que los proyectos software tenían un alto riesgo de

fracasar? La respuesta parecía obvia: construir software de forma similar a como

se construye hardware, aviones, barcos, puentes o edificios, es decir, aplicar los

métodos de la ingeniería a la construcción de software. Surge así la necesidad

de una Ingeniería de Software. Sin embargo, la ingeniería de software comprende

una serie de actividades los suficientemente diversas como para poder

considerar la necesidad de otras ingenierías dentro de la propia ingeniería del

software, surge así la necesidad de una Ingeniería de Requisitos.

Desde 1968 se ha invertido un gran esfuerzo en determinar las causas y proponer

soluciones para la crisis del software. En ese sentido en 1979, la Oficina de

Cuentas del gobierno norteamericano (Government Account Office, GAO) realizó

un estudio [64] seleccionando 9 proyectos de desarrollo de software para el

gobierno norteamericano cuyos contratos sumaban una cantidad total de

6.800.000 dólares. Así mismo, en 1995, el Grupo Standish realizó un estudio (el

informe CHAOS) mucho más amplio y significativo que el del GAO cuyos

resultados, a pesar de haber pasado más de 25 años, no reflejaban una mejoría

sustancial [65]. Al compararse con los de GAO presentan una mejora en los

proyectos que se entregan cumpliendo todos sus requisitos, 2% frente al 16.2%

(sólo el 9% en grandes compañías), pero empeoran ligeramente respecto a los

que se abandonan durante el desarrollo, 28.7% frente a 31.1%. Las encuestas

realizadas a los directores de los proyectos que participaron en el estudio

indicaron que, en su opinión, los tres principales factores de éxito eran:

Implicación de los usuarios

Apoyo de los directivos

Enunciado claro de los requisitos

Mientras que los tres principales factores de fracaso eran:

112

Falta de información por parte de los usuarios

Especificaciones y requisitos incompletos

Especificaciones y requisitos cambiantes

En 1996, el proyecto ESPITI (European Software Process Improvement Training

Initiative) [66] realizó una investigación sobre los principales problemas en el

desarrollo de software a nivel europeo. Los resultados, muy similares a los

obtenidos en el informe CHAOS, indicaron que los mayores problemas estaban

también relacionados con la especificación, la gestión y la documentación de los

requisitos.

Ensayando un resumen indicando la conclusión realizada por los autores de

estos informes, vemos como se ponen de manifiesto el hecho de que, “….a pesar

de que las herramientas para construir software han evolucionado enormemente,

se sigue produciendo software que no es satisfactorio para los clientes y

usuarios”. Esto indica que los principales problemas que han dado origen a la

crisis del software residen en las primeras etapas del desarrollo, cuando hay que

decidir las características del producto software a desarrollar. En palabras de F.

P. Brooks [67]:

"La parte más difícil de construir de un sistema software es decidir qué construir.

[...] Ninguna otra parte del trabajo afecta más negativamente al sistema final si

se realiza de manera incorrecta. Ninguna otra parte es más difícil de rectificar

después."

Otro hecho comprobado es que el coste de un cambio en los requisitos, una vez

entregado el producto, es entre 60 y 100 veces superior al coste que hubiera

representado el mismo cambio durante las fases iniciales de desarrollo [66,67],

por lo que no es de extrañar que aquellos proyectos en los que no se determinan

correctamente los requisitos y cambian frecuentemente durante el desarrollo,

superen con creces su presupuesto inicial. Todas estas circunstancias han

convencido a la gran parte de la comunidad de la ingeniería del software de la

necesidad, cada vez mayor, de una ingeniería de requisitos.

Dentro de las muchas definición de Ingeniería de Requisitos, la que más se

acomoda al objetivo planteado por el modelo y por las necesidades de la

organización, es la planteada por la IEEE [68], en la que indica que “La Ingeniería

de Requisitos es el proceso de estudiar las necesidades del usuario para llegar

a una definición de requisitos de sistema, hardware o software”.

Considerándosele por lo tanto, como un proceso de descubrimiento y

comunicación de las necesidades de clientes y usuarios y la gestión de cambios

de dichas necesidades. Por otro lado, en el trabajo presentado por Sawyer y

Kontoya [69], se presenta a la Ingeniería de Requisitos dentro del ciclo de vida

113

de desarrollo de software como un proceso continuo a lo largo de todo el proceso

(Fig. 4.16).

Fig. 4.16 La Ingeniería de Requisitos en el ciclo de vida del Desarrollo de

Software

Fuente: [69]

1.1. Las Dimensiones de la Ingeniería de Requisitos.

En el trabajo realizado por Pohl en los años 94 y 97 [70] y comentado por

Durán Toro [63] (Trabajo en el que nos estamos basando para presentar la

Elicitación de Requerimientos), indica una posible visión de la ingeniería de

requisitos es considerarla como un proceso de construcción de una

especificación de requisitos en el que se avanza desde especificaciones

iniciales, que no poseen las propiedades oportunas, hasta especificaciones

finales completas, formales y acordadas entre todos los participantes (Fig.

4.17), teniendo en cuenta que el grado de formalismo de la representación

del conocimiento sobre dichos requisitos, no implica necesariamente un

mayor conocimiento.

Fig. 4.17 Dimensiones de la Ingeniería de Requisitos

Fuente: [70]

114

De forma que durante el proceso de ingeniería de requisitos se avanza

desde especificaciones incompletas, informales e individuales hacia la

especificación ideal que sería completa, formal y acordada entre todos los

participantes.

1.2. Los Requisitos como Restricciones.

Otro punto interesante en el trabajo de Durán Toro, es la de presentar a los

requisitos como restricciones, (esto fue planteado en 1989 por Gause y

Weinberg [71] y Davis en 1990 [72]), donde los requisitos pueden ser

interpretados como restricciones que determinan el espacio de sistemas

válidos, en la figura 4.18 se presenta el planteamiento de los autores.

Fig. 4.18 Dimensiones de la Ingeniería de Requisitos

Fuente: [71]

“Si Sp es el espacio de todos los posible sistemas, cada requisitos Ri

establece una partición formada por Si y Ṡi, donde Si representa el conjunto

de sistemas que satisfacen el requisito Ri y Ṡi representa al conjunto de

sistemas que no lo satisfacen. En esta situación, Sv, el conjunto de los

sistemas válidos es decir aquellos que satisfacen todos los requisitos, se

correspondería con la intersección de todos los conjuntos Si. En otras

palabras: Sv = S1 ∩ S2 ∩…∩ Sn”. Es así que la Ingeniería de Requisitos

podríamos considerarla como el proceso iterativo de exploración [71] para

determinar las restricciones correctas, es decir los requisitos, que

determinen adecuadamente el espacio de sistemas válidos.

1.3. Propiedades de los Requisitos.

Existen una gran cantidad de propiedades deseables de los requisitos y

diversos autores que han hablado de ello, tales como, la IEEE [73], Davis

115

[74], Wieringa [75] entre otros. Las propiedades que se pueden considerar

más importantes son por ejemplo, que el requisito sea comprensible por

clientes y usuarios, correcto, consistente, no ambigua, completa,

verificable, modificable y rastreable. Realizaremos a continuación la

descripción de algunas de estas propiedades con el fin de establecer el

sentido de la definición y el aporte al presente trabajo.

Verificable. Según Davis, “Una especificación de requisitos es

verificable si y sólo si todo requisito contenido en ella es verificable,

es decir, existe un proceso finito y de coste razonable por el que una

persona o una máquina pueda comprobar que el sistema final

cumple el requisito” [74].

Una condición absolutamente necesaria para que un requisito sea

verificable es que no sea ambiguo y que se defina de forma medible,

ya que no se puede comprobar algo que no se puede medir ni definir

de forma precisa.

No ambigua. Davis también nos brinda una definición de no

ambigüedad, en ese sentido indica: “Una especificación de

requisitos no es ambigua si y sólo si todo requisito contenido en ella

tiene una sola interpretación” [74].

Una forma de evitar interpretaciones erróneas de aquellos términos

en los cuales existe la posibilidad de una doble interpretación, es la

de que surja un glosario de términos en el que se especifiquen

claramente su significado en el documento.

Rastreable. IEEE indica que, “Una especificación de requisitos es

rastreable si y sólo si para cada requisito contenido en ella se

conoce su origen y puede referenciarse como origen en posteriores

documentos durante el desarrollo, es decir, cada requisito puede

rastrearse hacia atrás y hacia delante” [76].

Una condición necesaria para que un requisito pueda rastrearse

hacia delante es que pueda referenciarse de manera única,

normalmente mediante algún tipo de código. La forma habitual de

registrar la rastreabilidad son las matrices de rastreabilidad.

2. Modelo Propuesto de Ingeniería de Requisitos.

Tal como lo mencionamos anteriormente, el modelo propuesto e implementado en

la organización en estudio para la fase de Requerimientos, consta de tres

actividades, Elicitación, Análisis, y Validación y su principal característica es la

iteratividad, tal como lo mostramos en la figura 4.19 en la que se ha expandido la

fase de Ingeniería de Requisitos presentada en la figura 4.16. La característica de

iteratividad se refiere al proceso de elicitar requisitos, analizarlos y validarlos, ya que

116

es prácticamente imposible obtener todos los requisitos en una sólo proceso y que

cumplan las propiedades presentadas en el punto 1.3 del presente trabajo.

Fig. 4.19 Modelo de Procesos de Ingeniería de Requisitos: Iteración de Actividades

Fuente: [63]

El modelo propuesto consta además de tres ciclos de iteración, dos internos al

modelo y uno externo, los ciclos internos son: El ciclo Elicitación-Análisis-Validación,

el cual indica la posibilidad de que durante el proceso de validación de los requisitos

por parte de los clientes y usuarios aparezcan conflictos o nuevos requisitos que

hasta entonces estaban ocultos. En el caso de que ocurriese esto, es necesario

resolver dichos conflictos y consensuar los nuevos requisitos mediante nuevas

reuniones de elicitación/negociación, repitiendo a continuación las actividades de

análisis y validación. Elicitación-Análisis, se trata de un ciclo que indica la posibilidad

de que durante la realización del análisis de los requisitos elicitados se descubran

conflictos o deficiencias en dichos requisitos, lo que puede provocar la necesidad de

nuevas reuniones de elicitación/negociación y el posterior análisis de sus resultados.

Finalmente, el ciclo externo: Ingeniería de Requisitos-Resto de Desarrollo, que

muestra la posibilidad de que durante el resto del desarrollo sea necesario volver a

alguna de las actividades de ingeniería de requisitos, posiblemente porque se

117

detecte la necesidad de renegociar algunos requisitos de difícil implementación,

porque aparezcan nuevos requisitos durante el desarrollo.

2.1. Elicitación de Requisitos

La Elicitación de Requisitos es considerada como la actividad de la Ingeniería

de Requisitos en la que los ingenieros de requisitos interactúan con el resto de

participantes para obtener, registrar, y si es necesario negociar, los requisitos

que deberá satisfacer el sistema a desarrollar, desde el punto de vista de

clientes y usuarios, es decir, los Requisitos–C. En la figura 4.20 presentaremos

a la Ingeniería de Requisitos como un proceso de comunicación definiendo

como Requisitos-C a los requisitos provenientes de Clientes y Usuarios y

Requisitos-D como los requisitos provenientes de los Desarrolladores.

Objetivos. Los objetivos concernientes a esta fase son los siguientes:

• Conocer el Dominio del Problema. Se le puede denominar también

Modelo Conceptual del Dominio, se usa para describir cualquier modelo

cuyo sujeto primario sea el mundo real al que da apoyo el sistema de

cómputo, Debe de pensarse en el primer Modelo de Dominio en un

esqueleto y no en un modelo de alto nivel. Modelo de alto nivel significa que

carece de detalles y con ello se cae en el error de no mostrar los atributos

en estos modelos. La clave está en encontrar y concentrarse en los detalles

importantes y la mayor cantidad de esos detalles se cubrirán durante el

desarrollo iterativo.

• Descubrir las necesidades reales de clientes y usuarios. Además de

aquellas necesidades explícitamente manifestadas por los clientes y

usuarios, es muy importante llegar a descubrir el conocimiento tácito, es

decir, aquellas necesidades que la mayor parte de las veces se asumen y

toman por implícitas [77, 78].

• Consensuar los requisitos entre los propios clientes y usuarios. Durante

la elicitación, normalmente después de la primera iteración, es necesario

negociar entre los distintos participantes hasta obtener una visión común

de los requisitos [79]. Algunos autores [69,70] separan las actividades de

negociación de las de elicitación, en el presente modelo y dado el contexto

de la organización en estudio, preferimos que la elicitación englobe también

los aspectos de negociación, dado que la negociación puede entenderse

como la elicitación de la información necesaria para llegar a un acuerdo y

además suelen aparecer nuevos requisitos cuando es necesario negociar

ya que ambas actividades requieren reuniones entre los participantes

involucrados en las que predominan los aspectos sociales sobre los

técnicos.

118

Fig. 4.20 La Ingeniería de Requisitos como un Proceso de Comunicación

Fuente: [63]

2.1.1. Propuesta Metodológica para la Elicitación de Requisitos

La propuesta metodológica para la Elicitación de Requisitos que se

propone en este trabajo, propone una serie de tareas a realizar y

productos a obtener, en la propuesta se contemplan las siete tareas que

pueden verse en la figura 4.21, en la que se propone un posible orden de

realización orientativo. Las tareas son: Obtener información sobre el

dominio del problema y el sistema actual, Preparar y realizar las sesiones

de Elicitación/Negociación, Identificar/revisar los objetivos del sistema,

Identificar/revisar los requisitos de información, Identificar/revisar los

requisitos funcionales, Identificar/revisar los requisitos no funcionales y

Priorizar objetivos y requisitos. Realizaremos una explicación un poco

más detallada en la Tabla 4.16.

Fig. 4.21 Metodología Propuesta Elicitación de Requisitos

Fuente: [63]

119

Entradas Tareas Descripción Herramientas y Técnicas Salidas

Clientes/Usuarios,

Requisitos-C,

Requisitos-D,

Prototipo,

Conflictos

1) Obtener

información sobre

el dominio del

problema y el

sistema actual.

El objetivo principal de esta tarea es conocer

el dominio del problema lo mejor posible.

En segundo lugar, el ingeniero de requisitos

debe evitar utilizar sus propios esquemas y

categorías mentales a la hora de obtener la

información, ya que esto puede dificultar la

comunicación debe aprender a pensar en los

términos en los que lo hacen clientes y

usuarios.

En tercer lugar, mantener sesiones de

elicitación sin conocer el dominio del

problema puede provocar que los

malentendidos o las preguntas continuas

sobre el significado de los términos

empleados por clientes y usuarios hagan que

la confianza hacia el equipo de ingeniería de

requisitos se vea deteriorada enormemente,

provocando cierta reticencia a participar e

involucrarse en el proyecto.

El equipo que construya el Modelo de Dominio, debe de

ser pequeño (de 2 a 4 personas, pero no 1), y debe de

estar incorporado por desarrolladores y expertos de

dominio. El equipo trabajará hasta concluir el modelo y

el Jefe de Proyecto deberá evitar el peligro del

empantamiento, el líder deberá asegurar que el equipo

no se empantane en los detalles ni que opere a un nivel

más alto que pierda contacto con la realidad. Una fecha

límite para la entrega ayuda en este sentido.

Entrevistas (*). Las entrevistas son la técnica de

elicitación más utilizada, y de hecho son prácticamente

inevitables en cualquier desarrollo ya que son una de

las formas de comunicación más naturales entre

personas. En las entrevistas se pueden identificar tres

fases: preparación, realización y análisis [81].

Joint Applicaction Development (*)

Brainstorming (*)

Casos de Uso (*)

Requisitos-C,

Modelos del

Sistema Actual,

Documentación

de la

Organización,

Documentos de

desarrollos

previos sobre el

mismo dominio de

problemas,

Información

proveniente de

expertos.

Preparar y realizar las sesiones de

Elicitación/Negociación.

Las salidas de esta actividad es una nueva versión.

Algunos autores como Raghavan et al.[80], Sawyer y

Kontoya [69] y Pohl [70], añaden una actividad

diferenciada a la que le denominan especificación o

documentación, en la que registran los requisitos en

uno u otro documento. En el modelo propuesto, el

proceso de registrar los requisitos es implícito, a la

Elicitación en el caso de los Requisitos-C

Tabla 4.16 Descripción Metodología de Elicitación de Requisitos (Parte 1) Fuente: Elaboración Propia

(*) Se elaborará una explicación más detallada en el punto 2.1.2

120


Clientes/Usuarios,

Requisitos-C,

Requisitos-D,

Prototipo,

Conflictos

2) Preparar y

realizar las

sesiones de

Elicitación/Neg

ociación.

El objetivo de esta tarea es conocer las

necesidades de clientes y usuarios y resolver

los conflictos identificados en las actividades

de análisis de iteraciones previas. Es la tarea

más crítica, ya que en ella es donde existe

una mayor interacción personal entre el

equipo de ingeniería de requisitos y los

clientes y usuarios, por lo que una adecuada

selección de los participantes es crucial.

Las técnicas que pueden emplearse para la

realización de esta tarea son las técnicas de

elicitación como la negociación y las plantillas

para elicitación de requisitos.

Los productos resultantes de

esta tarea, al igual que en la

tarea anterior, son también

internos y suelen

componerse de notas

tomadas durante las

sesiones, transcripciones o

actas de las sesiones,

grabaciones de audio o

vídeo, si se han resuelto

conflictos durante las

sesiones, se pueden

considerar como productos

dichos conflictos resueltos

junto con la probable

necesidad de cambios en los

Requisitos–C. Una primera

versión o un borrador de los

Requisitos–C.

Tabla 4.16 Descripción Metodología de Elicitación de Requisitos (Parte 2)


121


Clientes/Usuarios,

Requisitos-C,

Requisitos-D,

Prototipo,

Conflictos

3) Identificar/revisar

los objetivos del

sistema.

El objetivo de esta tarea es conocer por qué se acomete el desarrollo, y

por lo tanto conocer qué objetivos se esperan alcanzar mediante el

sistema software a desarrollar. En la primera iteración se realizará una

primera identificación de los objetivos. En las iteraciones posteriores

puede que sea necesario revisarlos si se han identificado conflictos que

les afecten. Esta información puede que haya sido dada previamente al

comienzo del desarrollo, puede que se haya manifestado de forma

explícita durante las sesiones de elicitación o puede que haya que

deducirla de la información recopilada durante dichas sesiones. La idea

básica es ir obteniendo los requisitos como un refinamiento de los

objetivos, de forma que la existencia de un requisito esté siempre

justificada como una necesidad para alcanzar uno o más objetivos. Esta

es una de las relaciones de rastreabilidad, en concreto de

prerrastreabilidad [82], que se contempla en la figura 4.22

Para la determinación de

los objetivos se pueden

utilizar técnicas como el

análisis de factores críticos

de éxito [80,83]

Los productos

resultantes de esta

tarea son los

objetivos del sistema

expresados mediante

las plantillas para

objetivos



Fig. 4.22 Rastreabilidad entre Participantes, Objetivos y Requisitos-C

Fuente: [63]

122


Clientes/Usuarios,

Requisitos-C,

Requisitos-D,

Prototipo,

Conflictos


los requisitos de

información.

Las tareas que tienen por objetivo realizar la

identificación y posterior revisión de posibles

conflictos en los Requisitos-C son las tareas

4,5,6 y es únicamente por simplicidad que las

tareas se han dividido en tres y no porque se

asuma que esa deba ser la secuencia de

realización. Particularmente en la tarea 4, se

deben identificar o revisar los requisitos de

almacenamiento de información que deberá

satisfacer el sistema. Habitualmente estos

requisitos son la respuesta a la pregunta

¿qué información, relevante para los

objetivos de su negocio, deberá almacenar el

sistema?. Este tipo de requisitos no suele

incluirse como un grupo separado en las

metodologías actuales, sin embargo, y

siguiendo las propuestas de Pohl y Raghavan

et al. [70,80], es importante identificarlos

claramente. Existen otros enfoques en los

que no se incluyen estos requisitos porque

pueden deducirse de los requisitos

funcionales, especialmente si se utilizan

casos de uso los cuales me permiten

también, deducir la información que debe

almacenar el sistema, pero por sugerencia

del autor de la metodología propuesta es

conveniente hacerla explícita.

Se sugiere también una posible división de

esta tarea en subtareas identificando primero

los conceptos relevantes sobre los que el

sistema debe almacenar información, para

posteriormente ir identificando los datos

específicos sobre cada concepto relevante.

Requisitos de almacenamiento de

información,



123


Clientes/Usuarios,

Requisitos-C,

Requisitos-D,

Prototipo,

Conflictos


los requisitos

funcionales.

En esta tarea se deben identificar o revisar

los requisitos funcionales que deberá

satisfacer el sistema, para lo que se ha

optado por la utilización de los casos de uso

[85]. Estos requisitos suelen obtenerse

como respuesta a la pregunta ¿qué debe

permitir el sistema hacer a los usuarios con

la información almacenada?.

Casos de Uso, además de los casos de

uso, en esta tarea es necesario identificar

y describir a los actores del sistema [85].

Otro aspecto importante es la

determinación del ámbito del sistema

[85], es decir qué aspectos serán

responsabilidad del sistema y que

aspectos se gestionarán manualmente o

por otro procedimiento. Finalmente la

utilización de los diagramas de casos de

uso [87], el cual permite de forma sencilla

especificar claramente qué queda dentro

y qué queda fuera del ámbito del sistema.

Por otro lado, en el trabajo elaborado por

Díaz y Rodriguez [88], se plantea la

posibilidad de partir obteniendo primero

los objetivos, luego ir identificando los

casos de uso asociados a los actores, se

estudian las distintas alternativas de cada

caso de uso y se determina la

responsabilidad de los distintos criterios

que dan lugar a las alternativas

asignándolas al sistema o a otros actores.

Los productos de esta tarea son

los diagramas de casos de uso y

las especificaciones tanto de los

actores como de los casos de uso

expresados.



124


Clientes/Usuarios,

Requisitos-C,

Requisitos-D,

Prototipo,

Conflictos


los requisitos no

funcionales.

En esta tarea se deben identificar o revisar

los requisitos no funcionales del sistema,

normalmente relacionados con aspectos

técnicos o legales: comunicaciones,

interfaces con otros sistemas, fiabilidad,

entorno de desarrollo, portabilidad, etc.


los requisitos no funcionales

7) Priorizar

objetivos y

requisitos.

En esta última tarea se deben asignar

prioridades a los objetivos y requisitos

estableciendo su importancia y su urgencia,

de forma que en el caso de que se

desarrolle incrementalmente se tengan los

criterios suficientes para saber qué

requisitos deben implementarse en cada

versión que se vaya entregando.


los objetivos y requisitos

identificados/revisado en las

tareas anteriores con su prioridad

establecida.

Tabla 4.16 Descripción Metodología de Elicitación de Requisitos (Parte 6) Fuente: Elaboración Propia

125

2.1.2. Herramientas y Técnicas

2.1.2.1. Entrevistas. En las entrevistas se pueden identificar tres fases: preparación, realización y análisis.

Preparación de Entrevistas. Las entrevistas no deben improvisarse, por lo que conviene realizar las siguiente tareas previas:

Estudiar el dominio del problema: Para conocer el dominio del problema se puede recurrir a técnicas de estudio de documentación, a bibliografía sobre el tema, documentación de proyectos similares realizados anteriormente, la inmersión dentro de la organización para la que se va a desarrollar

Seleccionar a las personas a las que se va a entrevistar: Se debe minimizar el número de entrevistas a realizar, por lo que fundamental seleccionar a las personas a entrevistar.

Determinar el objetivo y contenido de las entrevistas: para minimizar el tiempo de la entrevista es fundamental fijar el objetivo que se pretende alcanzar y determinar previamente su contenido. Previamente a su realización, se pueden enviar cuestionarios que los futuros entrevistados deben rellenar y devolver, y un pequeño documento de introducción al proyecto de desarrollo, de forma que el entrevistado conozca los temas que se van a tratar y el entrevistador recoja información para preparar la entrevista.

Planificar las entrevistas: la fecha, hora, lugar y duración de las entrevista deben fijarse teniendo en cuenta siempre la agenda del entrevistado. En general, se deben buscar sitios agradables donde no se produzcan interrupciones y que resulten naturales a los entrevistados.

Realización de Entrevistas. Dentro de la realización de las entrevistas se distinguen tres etapas.

Apertura: el entrevistador debe presentarse e informar al entrevistado sobre la razón de la entrevista, qué se espera conseguir, cómo se utilizará la información, la mecánica de las preguntas, etc.

Desarrollo: la entrevista en si no debería durar más de dos horas, distribuyendo el tiempo en un 20% para el entrevistador y un 80% para el entrevistado. Se deben evitar los monólogos y mantener el control por parte del entrevistador, contemplando la posibilidad de que una tercera persona tome notas durante la entrevista o grabar la entrevista en cinta de vídeo o audio, siempre que el entrevistado esté de acuerdo.

Terminación: Al terminar la entrevista se debe recapitular para confirmar que no ha habido confusiones en la información recogida, agradecer al entrevistado su colaboración y citarle para una nueva entrevista si fuera necesario, dejando siempre abierta

126

la posibilidad de volver a contactar para aclarar dudas que surjan al estudiar la información o al contrastarla con otros entrevistados.

Análisis de Entrevistas. Una vez realizada la entrevista es necesario leer las notas tomadas, pasarlas a limpio, reorganizar la información, contrastarla con otras entrevistas o fuentes de información, etc. Una vez elaborada la información, se puede enviar al entrevistado para confirmar los contenidos. También es importante evaluar la propia entrevista para determinar los aspectos mejorables.

2.1.2.2. Brainstorming. El brainstorming o tormenta de ideas es una técnica de

reuniones en grupo cuyo objetivo es la generación de ideas en un ambiente libre de críticas o juicio. Las sesiones de brainstorming suelen estar formadas por un número de cuatro a diez participantes, uno de los cuales es el jefe de la sesión, encargado más de comenzar la sesión que de controlarla. Como técnica de elicitación de requisitos, el brainstorming puede ayudar a generar una gran variedad de vistas del problema y a formularlo de diferentes formas, sobre todo al comienzo del proceso de elicitación, cuando los requisitos son todavía muy difusos. Al encontrarse frente a la situación de poca participación del equipo al expresar sus ideas, se puede aplicar el algoritmo Round Robin utilizado en la asignación de tareas en base a quantums de tiempo.

2.1.2.3. Casos de Uso. Los casos de uso son una técnica para la especificación de

requisitos funcionales propuesta inicialmente en [85] y que actualmente forma parte de la propuesta de UML. Un caso de uso es la descripción de una secuencia de interacciones entre el sistema y uno o más actores en la que se considera al sistema como una caja negra y en la que la que los actores obtienen resultados observables. Los actores son personas u otros sistemas que interactúan con el sistema cuyos requisitos se están describiendo. Los casos de uso presentan ciertas ventajas sobre la descripción meramente textual de los requisitos funcionales, ya que facilitan la elicitación de requisitos y son fácilmente comprensibles por los clientes y usuarios. Además, pueden servir de base a las pruebas del sistema y a la documentación para los usuarios.

2.1.3. Documento de Requisitos de Sistemas – DRS.

En la propuesta metodológica, el producto final entregable de las actividades de elicitación de requisitos es el Documento de Requisitos del Sistema (DRS).

2.2. Análisis de Requisitos Esta es la actividad a la que más importancia se la ha otorgado tradicionalmente. La Elicitación e incluso la validación podrían considerarse como más importantes de cara a obtener un producto final que satisfaga las necesidades de clientes y usuarios.

127

Sus Objetivos son:

Detectar conflictos en los Requisitos-C

Profundizar en el conocimiento del dominio del problema.

Establecer las bases para el diseño

Al igual que en el punto anterior, la propuesta metodológica para el análisis de requisitos que se propone en este trabajo, propone una serie de tareas a realizar y productos a obtener durante la realización de la actividad de análisis de requisitos del modelo de procesos de ingeniería de requisitos. En la propuesta se contemplan las cuatro tareas que pueden verse en la figura 4.23 y cuyo detalle se desarrollará en la Tabla 4.17, en la misma se propone un posible orden de realización orientativo en el que las tareas de analizar los tres tipos de requisitos–C se realizarían en paralelo.

Fig. 4.23 Metodología Propuesta Análisis de Requisitos

Fuente: [63]

128


Requisitos-C

(Elicitados en la

etapa anterior),

Requisitos-D,

Prototipo de la

iteración previa,

Información

proveniente de

clientes y

usuarios.

1) Analizar los

requisitos de

almacenamiento de

información

El objetivo principal de esta tarea, al igual

que el de la siguiente, es descubrir

conflictos en los requisitos profundizando

en el conocimiento del problema y

estableciendo las bases para un futuro

diseño del sistema.

Durante el análisis de los requisitos–C,

normalmente mediante la construcción de

un modelo, es habitual que al incrementar

la precisión con la que es necesario

expresar los requisitos aparezcan dichas

contradicciones o ambigüedades que

deberán resolverse en nuevas reuniones

de elicitación mediante algún mecanismo

de negociación.

Construir un modelo suele conllevar un

incremento en el grado de conocimiento

del problema que puede facilitar el

proceso de construir un producto útil para

clientes y usuarios. En la construcción del

modelo podrían participar aquellos

clientes y usuarios con los conocimientos

apropiados. En esta propuesta se

recomienda la utilización de técnicas de

modelado orientadas a objetos.

.

Requisitos-D,

Prototipos,

Conflictos (Posibles conflictos

detectados en los Requisitos-C)

Modelo estático del sistema,

compuesto por los diagramas de

tipos y la descripción textual de los

elementos que lo integran.

2) Analizar los

requisitos funcionales

Esta tarea es similar a la anterior, con la

diferencia de que se centra en los

Requisitos–C funcionales, expresados

mediante casos de uso. Para analizar los

requisitos funcionales lo habitual es

construir modelos funcionales y, si se

considera oportuno, modelos dinámicos.

Los productos resultantes de la

realización de esta tarea son los

modelos funcional y dinámico y los

conflictos que se hayan detectado

al construir ambos modelos.

Tabla 4.17 Descripción Metodología de Análisis de Requisitos (Parte 1)


129


Requisitos-C

(Elicitados en la

etapa anterior),

Requisitos-D,

Prototipo de la

iteración previa,

Información

proveniente de

clientes y

usuarios.

3) Analizar los

requisitos no

funcionales

Esta tarea tiene también como objetivo

descubrir conflictos en los requisitos–C, en

este caso en los requisitos no funcionales.

Sin embargo, a diferencia de las dos tareas

anteriores, las escasas propuestas de

modelado que integran este tipo de

requisitos aun no pueden considerarse

satisfactorias. La naturaleza heterogénea

de este tipo de requisitos hace que su

análisis sea necesario realizarlo mediante

una lectura detenida de su contenido, y

combinando esta lectura con la experiencia,

detectar posibles conflictos como la

imposibilidad técnica de la implementación

de ciertos requisitos. Normalmente, estos

requisitos se tendrán en consideración

durante el diseño de la arquitectura del

sistema lo que probablemente provocará

iteraciones entre el resto del desarrollo y la

fase de ingeniería de requisitos.

Los productos

resultantes de esta

tarea son, por lo tanto,

aquellos conflictos que

se hayan detectado al

realizar el análisis de

los requisitos no

funcionales.

4) Desarrollar

prototipos

El objetivo de esta tarea es el desarrollo de

prototipos que puedan utilizarse durante la

elicitación o validación de los requisitos, y

que por lo tanto deben centrarse en la

interfaz de usuario.

Las actuales herramientas de desarrollo rápido de

aplicaciones (RAD, Rapid Application Development)

permiten la construcción rápida de interfaces de

usuario que no tienen por qué desecharse una vez

utilizadas para obtener información de los clientes.

Otra posibilidad consiste en la prototipación de la

funcionalidad de la

aplicación mediante prototipos generados a partir de

lenguajes de especificación formal como Z [89].

Tabla 4.17 Descripción Metodología de Análisis de Requisitos (Parte 2)


130

2.2.1. Documento de Análisis de Sistemas – DAS En la propuesta metodológica, el Documento de Análisis del Sistema (DAS) es el principal producto entregable, junto con el prototipo si se considera oportuna su realización, de las actividades de análisis de requisitos. Los conflictos detectados pueden registrarse en el Documento de Requisitos del Sistema, en el DAS o en un documento aparte.

2.3. Validación de Requisitos.

Dentro del entorno metodológico propuesto, la validación de requisitos se considera como la actividad de la ingeniería de requisitos en la que clientes y usuarios, junto con la ayuda de los ingenieros de requisitos, revisan los productos obtenidos durante las actividades anteriores para confirmar que realmente reflejan sus necesidades y que definen el producto deseado. La validación de requisitos es otra de las actividades de la ingeniería de requisitos, que junto con la elicitación, han recibido tradicionalmente poca atención. La razón, al igual que en el caso de la elicitación, ha sido la suposición de que los requisitos eran proporcionados directamente por el cliente, con lo que, implícitamente, se asumían validados. La ingeniería de requisitos actual asume como una necesidad la participación de los ingenieros de requisitos tanto en las actividades de elicitación, para ayudar a clientes y usuarios a encontrar y describir sus necesidades, como en las actividades de validación, para ayudar a clientes y usuarios a comprobar que los requisitos elicitados y analizados resultantes del proceso describen realmente todas sus necesidades correctamente. La propuesta metodológica para la validación de requisitos que se propone y puede ser visualizada en la figura 4.24 y descrita detalladamente en la Tabla 4.18, propone una serie de tareas a realizar y productos a obtener durante la realización de la actividad de validación de requisitos.

Fig. 4.24 Metodología Propuesta Validación de Requisitos

Fuente: [63]

131


Requisitos-C,

Requisitos-D,

Prototipos,

Información de

validación

provenientes de

clientes y usuarios

1. Validar los

requisitos de

almacenamiento de

información y

funcionales

El objetivo de esta tarea es validar los

requisitos de almacenamiento de

información y funcionales, es decir,

asegurarse de que representan realmente

las necesidades de clientes y usuarios.

Aunque las actividades de elicitación y análisis se

hayan realizado correctamente, siempre es

necesario confirmar que los requisitos obtenidos se

corresponden realmente con los que los clientes y

usuarios desean, de forma que se evite la situación

en la que el producto final, que puede ser

técnicamente correcto, no es satisfactorio. Las

actividades de validación conllevan generalmente la

Elicitación de nuevos requisitos debido a que, a

medida que el nuevo sistema se va perfilando,

suelen ir apareciendo nuevas necesidades que

hasta entonces estaban ocultas, sobre todo

mediante la utilización de prototipos.

Los productos

resultantes de esta

tarea serían los

requisitos de

almacenamiento de

información, los

requisitos funcionales y

el prototipo validados

total o parcialmente. En

el caso de que se

descubran conflictos

durante la validación,

éstos serían también

productos de esta tarea

y deberían resolverse

en nuevas sesiones de

elicitación/negociación.

2. Validar los

requisitos no

funcionales

El objetivo de esta tarea es validar los

requisitos no funcionales.

A diferencia de la tarea anterior, la única técnica que

parece aplicable para realizar esta tarea es una

revisión por parte de los clientes y usuarios,

ayudados por los ingenieros de requisitos para

aclarar las posibles dudas que surjan durante la

revisión.

Sus productos, de

forma similar a la tarea

anterior, serían los

requisitos no

funcionales validados

total o parcialmente, y

los posibles conflictos

que pudieran aparecer.

3. Cerrar la versión

de los requisitos

Si no han aparecido nuevos conflictos

durante el proceso de validación, se debe

llegar a un acuerdo entre clientes y

desarrolladores para cerrar la versión actual

de los requisitos, siempre teniendo en

cuenta que representa el conocimiento

actual de los mismos y que, probablemente,

sufrirá cambios en el futuro.

El producto de esta

actividad es, por lo

tanto, una versión

cerrada de los

requisitos y del

prototipo.

Tabla 4.18 Descripción Metodología de Validación de Requisitos


132


Se ejecutaron 2 pilotos al proceso de Desarrollo y Mantenimiento de Software con cada

integrante del equipo de trabajo asumiendo roles los cuales están indicados en la Tabla

4.19 y cuya descripción es la siguiente: El rol denominado RDMS está a cargo por uno

de los desarrolladores y entre otras cosas, está a cargo del cumplimiento de las

actividades y productos generados durante su práctica y es en la Tabla 4.20 que se

detalla el comportamiento y evaluación de la ejecución del modelo de mejora propuesto

y el piloto realizado así como el cumplimiento de las actividades indicadas. La

representación gráfica (Fig. 4.25) es el porcentaje de cumplimiento de las actividades

del proceso de mejora propuesto.

Roles Siglas

Gerente General GG

Analista Desarrollador AD

Responsable de Desarrollo y Mantenimiento de Software

RDMS

Tabla 4.19 Roles y Siglas de la Experiencia Piloto

Actividades

Denominación del Piloto Rol Núm. Diseñadas Núm.

Realizadas % de

Cumplimiento

Proyecto 1

GG 8 8 100

AD 17 15 88

RDMS 20 17 85


Proyecto 2

GG 6 5 83

AD 17 14 82

RDMS 19 18 95


Proyecto 3

GG 5 5 100

AD 11 10 91

RDMS 23 19 83


Tabla 4.20 Comportamiento y Evaluación del Proceso Gestión de Desarrollo y Mantenimiento de Software DMS


133

Fig. 4.25 Ejecución de Pilotos del Proceso Desarrollo y Mantenimiento de Software DMS Fuente: Elaboración Propia


Luego de aplicar la mejora al proceso de Desarrollo y Mantenimiento de Software DMS

del modelo MoProSoft, y de haber realizado la prueba piloto y de haberse establecido

varias reuniones para discutir y documentar las lecciones aprendidas a lo largo de todo

el proceso, se tiene la percepción de un claro ordenamiento, seguimiento y control de

todas las actividades emprendidas por todo el personal de la organización en estudio en

los diferentes proyectos, esto se ha visto reflejado en los resultados de la prueba piloto,

pero es finalmente en la evaluación final que se comprobará el avance de todo lo

efectuado y sobretodo, tener en consideración los puntos más sobresalientes a tratar

en futuros ciclos de mejora. A continuación entonces, se presentara las lecciones

aprendidas del proceso que han surgido luego de las reuniones de trabajo con los

miembros de la organización.

1. Lección

o Fase del proyecto: Elicitación de Requisitos

o Categoría: Operaciones Modelo MoProSoft Proceso DMS

o Acciones implementadas: Se presentó una metodología para poder

realizar la Elicitación de requisitos debido a la aparición de problemas

diversos producto de una mala captura de requerimientos, para lo cual,

se planteó una serie de actividades, roles, flujos, formatos, entre otros,

para poder cumplir con el objetivo de este proceso y fundamentalmente

mitigar los problemas presentados.

o Resultados obtenidos:

Los resultados fueron satisfactorios reflejándose los mismos en

los resultados de las pruebas piloto y principalmente por la

percepción de como los miembros de la organización en estudio

controlaban sus actividades, tenían identificados sus roles y la

utilización de formatos.

86

86.5

87

87.5

88

88.5

89

% de Cumplimiento

Proyecto 1 Proyecto 2 Proyecto 3

134

Se detectó al igual que en el proceso anterior en APE, una cierta

resistencia a la aplicación de formatos y seguimiento de

actividades.

o Recomendaciones: Se recomienda la continuidad de estas prácticas y

una constante evaluación para asegurar una mejora continua, además de

una constante capacitación y reuniones de concientizaciones en los

beneficios del modelo.

2. Lección

o Fase del proyecto: Riesgos y Elicitación de Requisitos

o Categoría: Operaciones Modelo MoProSoft, Procesos APE y DMS

o Acciones implementadas:

Aplicación del algoritmo de Round Robin para promover la

participación del equipo de trabajo en el planteamiento de

diferentes propuestas para la identificación de riesgos y

problemas.

Aplicación de las reglas utilizadas en las reuniones para

identificación de tarjetas CRC. Estas reglas permiten un mejor

ordenamiento y convivencia entre el grupo de trabajo.


Hubo una buena aceptación de estos dos aportes ya que el grado

de participación de los miembros del equipo creció

sustancialmente.

o Recomendaciones:

Se recomienda la continuidad de estas prácticas

Las reuniones de esta índole se deben de realizar sin sillas y

controlando el tiempo de la participación para no excederse en el

tiempo de las reuniones.

3. Lección

o Fase del proyecto: Resto del Ciclo de Desarrollo de Software

o Categoría: Operaciones Modelo MoProSoft, Proceso DMS

o Acciones implementadas: Planteamiento de diversas metodologías

o Resultados obtenidos: En las primeras partes de la implementación de las

metodologías para las mejoras, se notó la falta de capacitación en dichas

metodologías, mayores reuniones de trabajo para organizar las

actividades.

o Recomendaciones:

Organizar mayores capacitaciones antes de realizar

implementaciones de metodologías para el mejoramiento de los

procesos.

Promover mayores de reuniones con los directivos de la

organización y miembros del equipo para informar sobre el

objetivo del trabajo.

4. Lección

135

o Fase del proyecto: Resto del Ciclo de Desarrollo de Software


o Acciones implementadas: Implementación de roles para el cumplimiento

de las actividades planteadas.


Dificultades en asumir diferentes roles por parte de los miembros

de la organización debido a la poca costumbre en asumir

diferentes actividades.

Se planteó la utilización de escenarios (Técnica utilizada en las

reuniones de las tarjetas de CRC para la identificación de Clases,

Roles, Responsabilidades), para poder asumir de una manera

teatral diferentes responsabilidades que conllevan los diferentes

roles.

o Recomendaciones: Utilizar con más frecuencia la técnica de aplicación

de escenarios.

5. Lección

o Fase del proyecto: Mantenimiento de Software


o Acciones implementadas: Se elaboró un flujo de trabajo para

mantenimiento de software diferenciado al del desarrollo.


Al principio los miembros del equipo indicaron que se generaría

una mayor burocracia en el proceso, pero una vez que se

estableció el flujo no hubieron mayores dificultades

o Recomendaciones: Continuar con la implementación de otros flujos de

trabajo para este proceso (Mantenimiento de Software).

4.6. Evaluación final del ciclo de mejora

4.6.1. Resumen

Este informe técnico de Evaluación Final del Primer Ciclo de Mejora ha sido desarrollado como parte del proyecto COMPETISOFT-PUCP para la empresa desarrolladora de software Empresa AQPsigma. El reporte tiene las siguientes secciones:

Evaluación final del ciclo de mejora.

Documentos referenciados.

Resultados y comparaciones del ciclo de mejora.

Análisis y recomendaciones para la empresa.

Datos técnicos del informe.

4.6.2. Evaluación final del ciclo de mejora

136

En esta sección se presenta el propósito de la evaluación, los objetivos de negocio previstos para este ciclo de mejora y los objetivos de mejora del ciclo que es evaluado.

4.6.2.1. Propósito de la evaluación

Esta evaluación tiene como propósito determinar el perfil de capacidades de los procesos de la Empresa respecto del modelo MoProSoft al final del ciclo de mejora. La evaluación realizada es del tipo basada en evidencias y tiene un bajo grado de rigurosidad para que permita ser completada en un tiempo razonable.

Como parte del proyecto COMPETISOFT-PUCP se tiene previsto la evaluación de todos los procesos de acuerdo al modelo MoProSoft y no únicamente los procesos que han sido objeto de mejora. La Empresa puede y debe usar estos resultados como base para la definición de un plan de mejora de procesos en lo sucesivo.

Un objetivo adicional de esta evaluación ha sido involucrar más a los diversos actores de la organización respecto de sus propios procesos y preparar a la Empresa en la elaboración de la documentación necesaria para evaluaciones más rigurosas.

4.6.2.2. Objetivos de negocio

Los objetivos de negocio considerados en el ciclo de mejora están descritos en el informe inicial y que a continuación se presentan para facilitar la comprensión del presente informe. Los objetivos de negocio son:

Objetivo de negocio 1. Posicionarse como empresa desarrolladora de software en la Región sur del Perú.

Objetivo de negocio 2. Exportar software.

Objetivo de negocio 3. Productos con calidad.

Objetivo de negocio 4. Incrementar la productividad.

Objetivo de negocio 5. Crecer en ventas.

4.6.2.3. Objetivos del ciclo de mejora

Los objetivos del ciclo de mejora están descritos en el Plan de Mejora de Procesos y que a continuación se presentan para facilitar la comprensión del presente informe. Los objetivos de mejora fueron:

Abreviatura Descripción Nivel Meta (%)

GNeg Gestión de Negocios 1 80

GProc Gestión de Procesos - -

GProy Gestión de Proyectos - -

GRec Gestión de Recursos - -

GRHAT Gestión de Recursos Humanos y Ambiente de Trabajo

- -

137

GBSI Gestión de Bienes, Servicios e Infraestructura

- -

GCO Gestión de Conocimiento - -

APE Administración de Proyecto Específicos 1 80

DMS Desarrollo y Mantenimiento de Software 2 50

Tabla 4.21 Objetivos de Mejora Fuente: Elaboración Propia

4.6.3. Documentos referenciados

Los siguientes documentos han sido utilizados como base para la elaboración del presente informe y deben ser consultados para su mejor comprensión en los casos que sea necesario:

MoProSoft, Modelo de Referencia de Proceso Software.

ISO/IEC 15504-2 Tecnología de Información. Evaluación de Proceso Software.

Propuesta del Plan de Mejora de Proceso del 1er Ciclo.

Informe de Evaluación Inicial de la Empresa.

4.6.4. Resultados y comparaciones del ciclo de mejora

En la Tabla 4.22 y la figura 4.26 se aprecian los resultados obtenidos en la última Evaluación realizada. La figura 4.27 presenta la evaluación inicial al iniciar el proyecto. Los colores en la figura 4.26 corresponden a la cantidad de prácticas calificadas en cada nivel de cumplimiento siendo: Rojo, cuando la práctica no existe o casi no se hace; amarillo, cuando la práctica se hace poco; verde, claro cuando la práctica se hace con cierta frecuencia pero no lo suficiente; y verde oscuro, cuando se hace bien la práctica. Para estas calificaciones se utiliza como referencia el criterio de la ISO/IEC 15504.

Tabla 4.22 Nivel de Cumplimiento de Procesos al Final del Ciclo de Mejora


% cumplimiento 88% 17% 31% 25% 22% 29% 22% 91% 89%

Grado de cumplimiento C P P P P P P C C

Nivel 1 0 0 0 0 0 0 1 1

% cumplimiento 0% 0% 0% 0% 0% 0% 0% 5% 12%

Grado de cumplimiento 0 0 0 0 0 0 0 C C

Nivel 1 1 1 1 1 1 1 0 0

Resumen

1 0 0 0 0 0 0 1 1

Procesos al Nivel 1

Niv

el 1

Niv

el 2

138

Figura 4.26. Perfil de Capacidades al Final del 1er Ciclo de Mejora

Figura 4.27. Perfil de Capacidades del nivel 1, al Iniciar el Proyecto.

Para cada objetivo de mejora, tal como se aprecia en la Tabla 4.31, se presentan los resultados de cada uno de los procesos y su evolución a través del proyecto de mejora.

Objetivo de Mejora Meta % Inicial % Nivel Inicial Evaluación Final (%) Nivel Final

GNeg 1-85 1-80 0 1-88 1

GProc - 1-66 0 1-17 0

GProy - 1-87 0 1-31 0

GRec - 1-32 0 1-25 0

GRHAT - 1-75 0 1-22 0

GBSI - 1-66 0 1-29 0

GCO - 1-13 0 1-22 0

APE 1-92 1-88 0 2- 5/ 1-91 1

DMS 2-50 1-86 1 2- 12/ 1-89 1

Tabla 4.23. Logros del Ciclo de Mejora según Objetivos de Mejora

0.00

0.20

0.40

0.60

0.80

1.00

1.20

1.40

1.60

1.80

2.00


2N

2P

2A

2C

1N

1P

1A

1C

139

4.6.5. Análisis de los Procesos

En esta sección se presenta el análisis para cada uno de los objetivos del ciclo de mejora y del proceso en su conjunto. Asimismo, se presentan algunas recomendaciones para la empresa.

4.6.5.1. Proceso: GNeg. Gestión de Negocio.

El proceso Gestión de Negocio se entiende como:

El propósito de Gestión de Negocio es establecer la razón de ser de la organización, sus 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.

El resultado que se obtuvo es de 88% del nivel 1. En evaluación inicial se obtuvo 80% de nivel 1. La diferencia o mejora aparente se debe a que el instrumento utilizado en la evaluación inicial es sensible a la declaración de los entrevistados y su percepción de la realidad, sin embargo la evaluación al cierre está basada en evidencias. Adicionalmente, otra razón para que la evaluación haya dado como resultado una leve mejora es debido a la utilización de los distintos instrumentos.

Durante el proyecto, la alta dirección mostró compromiso con el proyecto pero no lo concreto a causa de no disponer del tiempo necesario para completar las actividades requeridas en el Proyecto ni presentarlas. El proceso “Gestión de Negocio” tiene varios puntos importantes que se mencionan a continuación:

Se tiene implementado una primera versión del Plan Estratégico de la Empresa (PEE) pero éste no está completo y por tanto se utiliza para dirigir los otros planes operativos de la empresa.

Se han diseñado las plantillas entre las que encontramos: Registro de Adquisiciones, Registro de capacitación, Registro de Comunicaciones, que aún no están en funcionamiento y que deberán ser llenada debidamente.

4.6.5.2. Proceso: GProc. Gestión de Procesos.

El proceso Gestión de Procesos se entiende como:

El propósito de Gestión de Procesos es establecer los procesos de la organización, en función de los Procesos Requeridos identificados en el Plan Estratégico. Así como definir, planificar, e implantar las actividades de mejora en los mismos.

El proceso: GProc. Gestión de Procesos no fue parte de la mejora establecida en el proyecto COMPETISOFT; sin embargo El resultado que se obtuvo es de 17% del nivel 0. En evaluación inicial se obtuvo 66% de nivel 0. La diferencia o desmejora se debe a que en este caso la evaluación final es realizada en base a evidencias.

140

4.6.5.3. Proceso: GProy. Gestión de Proyectos.

El proceso Gestión de Proyectos se entiende como:

El propósito de la Gestión de Proyectos es asegurar que los proyectos contribuyan al cumplimiento de los objetivos y estrategias de la organización.

El proceso: GProc. Gestión de Procesos no fue parte de la mejora establecida en el proyecto COMPETISOFT; sin embargo El resultado que se obtuvo es de 31% del nivel 0. En evaluación inicial se obtuvo 87% de nivel 0. La diferencia o desmejora se debe a la misma razón mencionada anteriormente.

4.6.5.4. Proceso: GRec. Gestión de Recursos.

El proceso Gestión de Recursos se entiende como:

El propósito de Gestión de Recursos es conseguir y dotar a la organización de los recursos humanos, infraestructura, ambiente de trabajo y proveedores, así como crear y mantener la Base de Conocimiento de la organización. La finalidad es apoyar el cumplimiento de los objetivos del Plan Estratégico de la organización.

El proceso: GRec. Gestión de Recursos no fue parte de la mejora establecida en el proyecto COMPETISOFT; sin embargo El resultado que se obtuvo es de 25% del nivel 0. En evaluación inicial se obtuvo 32% de nivel 0. La diferencia o desmejora se debe a la misma razón mencionada.

4.6.5.5. Proceso: GRHAT. Gestión de Recursos Humanos y Ambiente de Trabajo.

El proceso Gestión de Recursos Humanos y Ambiente de Trabajo se entiende como:

El propósito de Recursos Humanos y Ambiente de Trabajo es proporcionar los recursos humanos adecuados para cumplir las responsabilidades asignadas a los roles dentro de la organización, así como la evaluación del ambiente de trabajo.

El proceso: GRHAT. Gestión de Recursos Humanos y Ambiente de Trabajo no fue parte de la mejora establecida en el proyecto COMPETISOFT; sin embargo El resultado que se obtuvo es de 22% del nivel 0. En evaluación inicial se obtuvo 75% de nivel 0. La diferencia o desmejora se debe a la misma razón mencionada.

4.6.5.6. Proceso: GBSI. Gestión de Bienes Servicios e Infraestructura.

El proceso Gestión de Bienes Servicios e Infraestructura se entiende como:

El propósito de Bienes, Servicios e Infraestructura es proporcionar proveedores de bienes, servicios e infraestructura que satisfagan los requisitos de adquisición de los procesos y proyectos.

141

El proceso: GBSI Gestión de Bienes Servicios e Infraestructura no fue parte de la mejora establecida en el proyecto COMPETISOFT; sin embargo El resultado que se obtuvo es de 29% del nivel 0. En evaluación inicial se obtuvo 66% de nivel 0. La diferencia o desmejora se debe a la misma razón mencionada.

4.6.5.7. Proceso: GCO. Gestión de Conocimiento de la Organización.

El proceso Gestión de Conocimiento de la Organización se entiende como:

El propósito de Conocimiento de la Organización es mantener disponible y administrar la Base de Conocimiento que contiene la información y los productos generados por la organización.

El proceso: GCO Gestión de Conocimiento de la Organización no fue parte de la mejora establecida en el proyecto COMPETISOFT; sin embargo El resultado que se obtuvo es de 22% del nivel 0. En evaluación inicial se obtuvo 13% de nivel 0.

4.6.5.8. Proceso: APE: Administración de Proyecto Específico.

El proceso Administración de Proyectos Específicos se entiende como:

El propósito de la Administración de Proyectos Específicos es establecer y llevar a cabo sistemáticamente las actividades que permitan cumplir con los objetivos de un proyecto en tiempo y costo esperados.

El resultado que se obtuvo es de 91% del nivel 1 y 5% del nivel 2. En evaluación inicial se obtuvo 88% de nivel 0. La diferencia se debe a la utilización de formatos, realización de actividades y cumplimiento de roles.

Durante el proyecto, la alta dirección mostró compromiso con el proyecto, al principio surgió una desconfianza propia de la falta de conocimiento en el modelo, pero a medida que las actividades se tornaban automáticas, todo fue cambiando y con ella la confianza. Se han implementado una serie de plantillas y formatos, que ayudarán indudablemente a la gestión de proyectos específicos y por ende a la visualización de una mejora en el proceso.

4.6.5.9. Proceso: DMS. Desarrollo y Mantenimiento de Software.

El proceso Desarrollo y Mantenimiento de Software se entiende como:

El propósito de Desarrollo y Mantenimiento de Software es la realización sistemática de las actividades de análisis, diseño, construcción, integración y pruebas de productos de software nuevos o modificados cumpliendo con los requerimientos especificados.

El resultado que se obtuvo es de 89% del nivel 1 y 12% del nivel 2. En evaluación inicial se obtuvo 86% de nivel 0. La diferencia o mejora se debe a la misma razón mencionada en el Proceso APE, en el que la utilización de los diversos formatos, actividades y aplicación de roles han permitido esta mejora, pero es fundamental la confianza en el modelo para ayudar a resolver los problemas detectados y con

142

la ayuda de la directiva de la organización en estudio, el objetivo se alcanzó satisfactoriamente.

4.6.6. Recomendaciones para la Empresa

A partir de la evaluación final de este ciclo de mejora y considerando los objetivos de la Empresas, del Proyecto COMPETISOFT y de las evaluaciones previas, se recomiendan lo siguiente:

Implementar los distintos formatos y/o plantillas para los distintos procesos.

Disponer de mayor tiempo de la persona encargada de la supervisión de la mejora por parte de la Empresa para que realice el seguimiento de la implementación de los formatos de los distintos procesos.

Realizar el esfuerzo que amerite la mejora.

Definir y delegar responsables de los distintos procesos para evitar el riesgo de generar retrasos.

Comunicar al personal de la Empresa de la importancia y las enormes ventajas de seguir las buenas prácticas recomendadas en el modelo.

4.6.7. Observaciones la Calificación - Evaluación

La empresa ha pasado por una evaluación donde sólo se solicitó una evidencia y en las certificaciones es por lo general 4 evidencias. Por razones de falta de disponibilidad de tiempo por parte de la Alta Gerencia, no se puedo recolectar las evidencias necesarias de los otros procesos que no han sido tocados en este 1er ciclo. Y la falta de evidencias suficientes en los procesos que si se tocaron por el contexto actual que viene pasando la empresa en cuanto a inicio de nuevos proyectos y desarrollos.

Se recomienda, para una siguiente evaluación de la organización que los propios participantes con apoyo del equipo COMPETISOFT armen las carpetas de evidencias de modo que cubran con mayor amplitud y conocimiento de las mismas.

4.6.8. Datos técnicos del informe

Para la obtención de los datos a ser usados para la evaluación, se utilizó la técnica de entrevistas y revisión de evidencia, utilizando un cuestionario como guía. El cuestionario fue obtenido del modelo MoProSoft considerando la evaluación de de la ISO/IEC 15504 – 2 al nivel 1 y 2 de capacidades de procesos software denominado Proceso Realizado.

La evaluación siguió el mismo esquema que el utilizado en las evaluaciones pasadas, sin embargo, constituye un mejor referente para tomar decisiones puesto que ahora se usó un mayor nivel de formalidad en las evidencias y no solamente la respuesta de los entrevistados.

4.7. Evaluación del esfuerzo del proyecto

El equipo de proyecto estuvo conformado por todo el personal de AQPsigma, un participante

del equipo COMPETISOFT, el coordinador general del proyecto en Perú, MSc. Abraham Dávila

y el coordinador por parte de la Universidad Ing. Robert Arisaca. Las actividades realizadas por

143

cada participante del equipo fue registrado en un Reporte de Horas, el cual detalla la fecha,

actividad y horas invertidas en su ejecución. En la tabla 4.24, detallamos el total de esfuerzo

invertido en el proyecto representado en horas.

Participante Nro. De Horas

Empresa-AQPsigma-Coordinadores 101 Hs.

Empresa-AQPsigma – Implantación de Procesos 55 Hs.

Medardo DELGADO PAREDES 625 Hs.

Abraham Dávila 40 Hs.

Robert Arisaca 80 Hs.

Total 901 Hs.

Tabla 4.24. Esfuerzo del Proyecto (Horas)

4.8. Directrices para un nuevo ciclo de mejora

Durante este primer ciclo de mejora se han trabajado directamente los procesos Gestión

de Negocio, Administración de Proyectos Específicos y Desarrollo y Mantenimiento de

Software. Se han elaborado diversas plantillas exigidas por el modelo Competisoft, así

como también se documentaron estos procesos. La empresa decidió continuar con un

segundo ciclo, enfatizando la mejora de APE y DMS, debido a que son procesos

importantes en la organización.

De continuar con un 2do ciclo de mejora, se han determinado las siguientes directrices

cuyo cumplimiento contribuiría a la mejora de procesos durante el segundo ciclo del

proyecto.

Segregación de Tareas. La segregación de tareas debe ser establecida

formalmente para evitar la duplicidad de esfuerzos durante el desarrollo de la

solución del requerimiento de cambio en el proceso de Mantenimiento de Software.

Asimismo durante la ejecución de los proyectos definidos en AQP sigma, los roles

de cada uno de los integrantes del equipo de trabajo deben ser definidos desde el

inicio, en especial el del responsable de hacer cumplir los tiempos y entregables

pactados con el usuario.

Registro de actividades y tiempos. El equipo de trabajo encargado de realizar el

proceso de mantenimiento de software y Administración de Proyecto Específico de

la organización, debe continuar con el registro de las actividades desarrolladas

durante la solución de los procesos en mención.

Documentación de procesos. Para cada proceso propuesto en el Plan de Mejora,

se han establecido actividades, artefactos y entregables que a lo largo del flujo se

van elaborando. Éstos son necesarios realizar para mantener un control y

monitoreo de la efectividad de desarrollo de las actividades realizadas dentro de

cada proceso. Si éstos no se generan, el proceso no se desarrolla completamente

y por ende tendería a no resultar efectivo ni reflejar la calidad de su desarrollo y

bien o producto obtenido.

144

CAPITULO V

OBSERVACIONES, CONCLUSIONES Y RECOMENDACIONES

5.1. Observaciones

El tiempo que se estimó para este primer ciclo de mejora fueron 4 meses, sin embargo el tiempo

real que se dedicó fueron aproximadamente 6 meses y medio. La razón se debe que surgieron

diversos imprevistos a lo largo del ciclo, tales como poca experiencia en mejora de procesos,

poca disponibilidad de la alta dirección o las plantillas elaboradas sufrieron varios ajustes antes

de la aprobación final.

Se observó que algunos directivos de la empresa tenían poca disponibilidad para concertar

reuniones, e incluso, algunas ya establecidas las postergaban por motivo de la carga de trabajo

del día a día.

A lo largo del ciclo de mejora de procesos, se trató con todo tipo de personas, algunos

mostraban interés en el tema y otros no estaban de acuerdo en aplicar el modelo MoProSoft y

eran de la idea de utilizar CMMI. Además, algunos no estuvieron preparados para el cambio y

mucho menos entendieron que la finalidad del ciclo de mejora es hacer mejor las cosas y no

dificultar el trabajo.

Ejecutar un primer ciclo de mejora en una empresa puede resultar más complicado que los

próximos ciclos, debido al desorden organizacional en que se encuentran inicialmente y

llevarlos a la mejora continua es un paso difícil.

5.2. Conclusiones

Se logró completar un ciclo de mejora en la empresa AQPsigma, utilizando los modelos

previstos de Competisoft y las plantillas desarrolladas por el grupo.

Se realizó una evaluación inicial en la empresa AQPsigma y se pudo conocer el estado de la

organización al inicio del ciclo de mejora, apreciando un desorden y caos organizacional,

ejecutándose los procesos sin un plan ni un orden definido. Se concluye que los procesos que

obtuvieron un nivel de calificación más bajo fueron GProc, GRec y GCO, en cambio los que

obtuvieron un nivel más alto fueron APE, GProy y DMS. Se ha logrado que la alta dirección

observe y analice las principales fortalezas y debilidades presentadas por cada proceso.

Se logró realizar la planificación de la mejora en la organización a partir de los resultados de la

evaluación inicial. Se identificaron los 3 procesos que tienen mayor impacto para el logro de

los objetivos de negocio y mayor relación para la resolución de los problemas definidos por la

alta dirección. Los procesos seleccionados fueron GNeg, APE y DMS y se estableció elevarlos

a un nivel de adherencia superior al 85% dentro de la capacidad del primer nivel de

Competisoft. Se ha logrado que la alta dirección asigne al gerente de proyectos como principal

responsable del seguimiento de la mejora.

Se ejecutó la mejora de los procesos, realizando las actividades detalladas en el plan de

mejora. Se revisaron y modificaron los procesos a mejorar de acuerdo a las prácticas sugeridas

145

por el modelo Competisoft y se ejecutaron en proyectos piloto con la finalidad de hacer ajustes.

Una vez aprobado y definido el nuevo proceso, se realizó el despliegue de la mejora en toda la

organización. Se registraron el tiempo y las experiencias ocurridas a lo largo de todo el ciclo,

con el fin de realizar una mejor estimación y prever más riesgos en los próximos ciclos de

mejora.

Se logró realizar la evaluación final en la empresa, observando una mejora en el perfil de

capacidades de sus procesos. Con esta evaluación, se consiguió un mayor compromiso por

parte del personal de la empresa AQPsigma, debido a que se insistió en la presentación de

evidencias para sustentar las respuestas. Sin embargo, no fue posible recolectarlas en todos

los casos, recurriéndose a esquemas indirectos. Se concluye que los procesos que alcanzaron

un mayor nivel de cumplimiento fueron GNeg, APE y DMS alcanzando el nivel 1 dentro del

modelo COMPETISOFT incluso APE y DMS inicios del nivel 2.

Se elaboró un reporte técnico para la empresa Delta, el cual contiene la evaluación final y

directrices para iniciar un nuevo ciclo de mejora.

Se logró introducir el pensamiento de mejora continua en la empresa. Al final del ciclo, el

gerente general mostró gran interés y motivación en realizar un próximo ciclo, con la finalidad

de mejorar los demás proceso. Además, se logró que el personal entienda cual es la finalidad

de usar modelos de calidad de procesos, un tema totalmente nuevo para muchos de ellos.

Con respecto al proceso MoProSoft, Desarrollo y Mantenimiento de Software DMS, considero

que se puede dar la posibilidad en futuras versiones, de separar ambos aspectos para un

tratamiento más especializado.

5.3. Recomendaciones

Se recomienda invertir trabajo y esfuerzo en los procesos de Desarrollo, Mantenimiento de

Software DMA y Administración de Proyecto Específico APE, siendo los de mayor prioridad y

criticidad en la empresa AQPsigma, los cuales contribuyan al cumplimiento de los objetivos

planteados y establecidos en el Plan Estratégico de la organización.

El nivel alcanzado durante el primer ciclo de mejora implementado define una base adecuada

para continuar con el segundo ciclo de mejora que permita alcanzar el nivel 1 en los demás

procesos que no se tomaron en cuenta y alcanzar el nivel 2 de los procesos que si se trabajaron

Se recomienda designar a una persona responsable del seguimiento, rediseño y control de los

procesos priorizados y críticos de la organización, cuya función entre otras sea la planificación

y mejora continua de los procesos, que asegure mayor intervención y compromiso del equipo

operativo y gerencial de AQPsigma.

Se recomienda la necesidad de una revisión con respecto al proceso Desarrollo y

Mantenimiento de Software DMS, en la posibilidad de la separación del Desarrollo y el

Mantenimiento de Software dadas las tendencias del incremento del mantenimiento del mismo.

146

Finalmente, se recomienda en la necesidad de elaborar un formato de encuesta para ser

presentado y llenado por parte del personal de la empresa en estudio, para que de esta manera

se pueda disponer de información sobre su punto de vista con respecto al modelo, el trabajo

de ciclo de mejora, entre otros.

BIBLIOGRAFIA

[1] Proyecto COMPETISOFT 506PI287- Mejora de Procesos para Fomentar la Competitividad de

la Pequeña y Mediana Industria del Software de Iberoamérica Financiado por: CYTED Ciencia y

Tecnología para el Desarrollo Código de proyecto 3789, programa internacional de cooperación

científica y tecnológica multilateral, de ámbito iberoamericano.

[2] Software Process Improvement for small and Medium Enterprise, Hanna Oktaba, Mario Piattini,

1996

[3] NMX-059/01-NYCE-2005 http://www.moprosoft.com.mx/contenido.aspx?id_pagina=8 (revisado

4/11/2013 12h16)

[4] NTP 291.100:2009

http://www.indecopi.gob.pe/0/modulos/TIE/TIE_DetallarProducto.aspx?PRO=5755 (revisado

4/11/2013 12h30)

[5] ISO/IEC 15504-1:2004 Technologies de l'information -- Évaluation des procédés -- Partie 1:

Concepts et vocabulaire

http://www.iso.org/iso/fr/home/store/catalogue_tc/catalogue_detail.htm?csnumber=38932

[6] Magnabyte – Mayorista de Equipos Informáticos. http://www.magnabyte.com (revisado

5/11/2013 11h25)

[7] Expert - Sistemas Computacionales S.A. http://www.expert.com.mx/ (revisado 5/11/2013 12h25)

[8] Valores Corporativos Softtek S.A. – servicios de TI nearshore http://www.softtek.com/mexico/

(revisado 5/11/2013 13h25)

[9] PSW Global Solutions http://www.psycowin.com/ (revisado 5/11/2013 14h25)

[10] Asis TP http://www.asistp.com/ (revisado 5/11/2013 14h30)

[11] Inexxo, http://inexxo.com/index-1.html (revisado 5/11/2013 14h44)

[12] magia digital http://magiadigital.com/principal/categoria/premios-y-certificaciones-

ganadas/11/c-11 (revisado 5/11/2013 14h50)

[13] Nisira Systems http://www.nisira.com.pe/presentacion.shtml (revisado 5/11/2013 14h52)

147

[14] Microdata http://microdataperu.com/index.php (revisado 5/11/2013 14h55)

[15] http://www.pmi.org.pe/sitio/modules/smartsection/item.php?itemid=92, (revisado 5/11/2013

14h55)

[16] 13th International Conference on Product-Focused Software Development and Process

Improvement June 13-15, 2012

http://www.grise.upm.es/profes2012/PROFES_2012/Welcome.html.(revisado 5/11/2013 15h55)

[17] Pressman, R.S: Ingeniería del Software. Un enfoque práctico. Mc Graw Hill, 2002

[18] “Estudio Comparativo De Los Modelos Y Estandares De Calidad Del Software”, Tesista: Lic.

Fernanda Scalone, Universidad Tecnologica Nacional Facultad Regional Buenos Aires”, junio 2006.

[19] Real Academia española RAE http://lema.rae.es/drae/?val=Modelo (revisado, 6/11/2013 9h09)

[20] The W. Edwards Deming Institute, http://www.deming.org, (revisado, 6/11/2013 9h36)

[21] National Academy of Engineering, http://www.nae.edu/, (revisado, 6/11/2013 9h40)

[22] Philip Crosby Associates, http://www.philipcrosby.com/pca/index.html, (revisado, 6/11/2013

9h45)

[23] Juran, http://www.juran.es, (revisado, 6/11/2013 9h49)

[24] NTP ISO 9000:2001 Sistemas de gestión de la calidad - Fundamentos y Vocabulario,

http://sisbib.unmsm.edu.pe/bibvirtualdata/publicaciones/indata/vol4_2/a07.pdf (revisado, 6/11/2013

10h)

[25] Software Engineering, Eight edition, Ian Sommerville, Adison-Wesley 2007

[26] Entity Web Hosting for IEEE Organizational Units http://www.ewh.ieee.org, (revisado, 6/11/2013

11h12)

[27] Understanding Maturity Levels, http://www.cmmi.de/cmmi_v1.2/maturitylevels.html#hs:null,

(revisado, 6/11/2013 11h20)

[28] http://www.oasis-open.org/committees/download.php/19679/soa-rm-cs.pdf (revisado,

6/11/2013 17h07)

[29] Técnicas cuantitativas para la gestión en la ingeniería del software, Javier Tuya, Isabel Ramos

Román y Javier Dolado Cosín, NETBIBLIO Espana 2007

[30] Software Engineering Institute, http://www.sei.cmu.edu/ (revisado, 6/11/2013 19h35)

[31] SEI(1995) The Capability Maturity Model: Guidelines for Improving the Software Process,

Software Engineering Institute

148

[32] Byrnes P. Philips, M. (1996), Software Capability Evaluation Version 3.0. Method Description.

Technical Report CMU/SEI-96-TR-002 ESC-TR-96-002

[33] Dunaway, D.K. CMM SM-Based Appraisal for Internal Process Improvement (CBA-IPI) Lead

Assesor's Guide (CMU/SEI-96-HB-003) Software Enginieering Institute, Carnegie Mellon University,

Pittsburg, 1996

[34] McFeeley. B, (1996)IDEAL: A User's Guide for Software Process Improvement, tech report

CMU/SEI-96-HB-00, Software Enginieering Institute SEI.

[35] Humphrey, W. (1997). Introduction to Personal Software Process, Addison Wesley.

[36] Curtis, B. Hefley B. y Miller, S. (2001). People Capability Maturity Model (P-CMM), Version 2.0

Software Enginieering Institute SEI, CMU/SEI-2001-MM-001

[37] CMMI, Guía para la implementación de procesos y la mejora de productos Segunda Edición.

Disponible en internet,http://www.sei.cmu.edu/library/assets/cmmi-dev-v12-spanish.pdf) (revisado,

7/11/2013 4h34)

[38] SEI (2009), Standard CMMI Appraisal Method for Process Improvement (SCAMPI), Version

1.1: Method Definition Document. CMU/SEI-2001-HB-001

[39] ISO (2004a), ISO IEC 15504-1:2003, Information Technology - Process assessment - Part 1:

Concepts and vocabulary, International Standards Organization, Ginebra Suiza

[40] ISO (2004b), ISO IEC 15504-2:2003, Information Technology - Process assessment - Part 2:

Performing an assessment, International Standards Organization, Ginebra Suiza

[41] ISO (2004c), ISO IEC 15504-3:2003, Information Technology - Process assessment - Part 3:

Guidance on performing an assessment, International Standards Organization, Ginebra Suiza

[42] ISO (2004d), ISO IEC 15504-4:2003, Information Technology - Process assessment - Part 4:

Guidance on use for process improvement and process capability determination, International

Standards Organization, Ginebra Suiza

[43] ISO (2006), ISO IEC 15505:2003, Information Technology - Process assessment - Part 5: An

exemplar process assessment model, International Standards Organization, Ginebra Suiza

[44] Zaharan, S. (1998) Software Process Improvement. Practical guidelines for business sucess.

Adison-Wesley.

[45] Kuvaja, P. Bicego, A. (1994)"Bootstrap-a European Assessment Methodology", Software

Quality Journal, 3, pp. 117-127

[46] ISO 9000 and ISO 14000. International Organization for Standardization (revisado, 7/11/2013

9h28)

149

http://www.iso.org/iso/iso_catalogue/management_standards/iso_9000_iso_14000.htm.

[47] ISO 9001:2008 Quality Management System - Requirements

[48] TickIT http://www.tickit.org/ (revisado, 7/11/2013 9h41)

[49] Testing and Quality Assurance for Component-Based SoftwareJerry Gao, H.S .Tsai, Ye Wu,

2003

[50] I. Pedro Ruiz. Universidad de Cantabria, España, 2008.

[51] COMPETISOFT: Mejora de Proceso Software para Pequeñas Empresas http://alarcos.inf-

cr.uclm.es/Competisoft/. (revisado, 7/11/2013 10h44)

[52] Weber, K. y Rocha, A. (2004), "Modelo de referencia para Melhoria de Processo de Software:

uma abordagm brasileira", Procedings of the QUATIC 2004, pp. 73-78

[53] Hanna Oktaba (Directora), Claudia Alquicira Esquivel, Angélica Su Ramos, Alfonso Martínez

Martínez, Gloria Quintanilla Osorio, Mara Ruvalcaba López Francisco López Lira Hinojo. Modelo de

Procesos para la Industria de Software – MoProSoft. Versión 1.3, Agosto 2005.

[54] Historia de una norma. Hanna Oktaba. Basado en la columna de Tejiendo nuestra red de la

revista Software Guru publicada en los números Año 01 No.03, 05 de 2005, Año 02 No.04 de 2006

Año 03 No.1 de 2007

[55] MoProSoft sin fronteras. Hanna Oktaba, 2008

[56] Método de Evaluación de procesos para la industria de software EvalProSoft Versión 1.1 Marzo

2004

[57]COMPETISOFT – Mejora de Procesos para Fomentar la Competitividad de la Pequeña y

Mediana Industria del Software de Iberoamérica, Versión 0.1, Diciembre 2006.

[58]Proyecto SIMEP-SW Trabajo de Investigación: “Hacia una Linea de Procesos Agiles Agile SPsL

Version 1.0”. Disponible en

internet, http://www.dcc.uchile.cl/TR/2005/TR_DCC-2005-008.pdf (revisado, 7/11/2013 11h46)

[59] Mejora continua de procesos de negocio basada en PmCompetisoft integrando BPMM.

Disponible en internet

http://www.sistedes.es/TJISBD/Vol-4/No-4/articles/PNIS-articulo-1.pdf (revisado, 7/11/2013 11h53)

[60] VSE http://profs.etsmtl.ca/claporte/English/VSE/index.html

[61] Guía de los Fundamentos de la Dirección de Proyectos Tercera Edición. Norma Nacional

Americana ANSI/PMI 99-001-2004

150

[62] Proceso de Mejora Ver. 0.5 Francisco José Pino, Juan C. Vidal, Julio A. Hurtado, Mario Piatinni,

Hanna Oktaba. Informe técnico Nro. D.21 15 de Marzo 2007 COMPETISOFT.

[63] Un Entorno Metodológico de Ingeniería de Requisitos para Sistemas de Información. Memória

de la tesis doctoral desarrollada por Amador Durán Toro para optar el grado de Doctor en la

Universidad de Sevilla España, Septiembre 2000.

[64] [GAO 1979] Contracting for Computer Software Development: Serious Problems Require

Management Attention to Avoid Wasting Additional Millions. Report FGMSD–80–4, U. S.

Government Account Office, Noviembre 1979.

[65] TSG. The CHAOS Report. The Standish Group, 1995. Disponible en

http://www.standishgroup.com/chaos.html.

[66] R. S. Pressman. Ingeniería del Software. Un Enfoque Práctico. McGraw–Hill, 4a edición, 1997.

[67] A. M. Davis. Software Requirements: Objects, Functions and States. Prentice–Hall, 2a edición,

1993.

[68] IEEE. IEEE Standard Glossary of Software Engineering Terminology. IEEE Standard 610.12–

1990, Institute of Electrical and Electronics Engineers, 1990.

[69] P. Sawyer y G. Kontoya. SWEBOK: Software Requirements Engineering Knowledge Area

Description. Informe Técnico Versión 0.5, SWEBOK Project, 1999. Disponible en

http://www.swebok.org.

[70] K. Pohl. Requirements Engineering: An Overview. Encyclopedia of Computer Science and

Technology, 36, 1997. Disponible en http://sunsite.informatik.rwth-

aachen.de/CREWS/reports96.htm.

[71] D. C. Gause y G. M. Weinberg. Exploring Requirements: Quality Before Design. Dorset House,

1989.

[72] A. M. Davis. Software Requirements: Objects, Functions and States. Prentice–Hall, 2a edición,

1993.

[73] IEEE. IEEE Standard for Developing Software Life Cycle Processes. IEEE/ANSI Standard

1074–1995, Institute of Electrical and Electronics Engineers, 1995.

[74] A. M. Davis. 201 Principles of Software Development. McGraw–Hill, 1995.

[75] R. J. Wieringa. Requirements Engineering: Frameworks for Understanding. John Wiley & Sons,

1996.

[76] IEEE. IEEE Software Engineering Standards Collection. Institute of Electrical and Electronics

Engineers, 1997.

151

[77] J. A. Goguen y C. Linde. Techniques for Requirements Elicitation. En Proceedings of the First

International Symposium on Requirements Engineering, 1993. También aparece en [Thayer y

Dorfman 1997]. Disponible en http://www.cse.ucsd.edu/˜goguen

[78] B. L. Kovitz. Practical Software Requirements: A Manual of Content & Style. Manning, 1998.

[79] J. Parets-Llorca y P. Grünbacher. Capturing, Negotiating, and Evolving System Requirements:

Bridging Win Win and the UML. En Proceedings of 25th EUROMICRO Conference, Milan, 1999.

[80] S. Raghavan, G. Zelesnik, y G. Ford. Lecture Notes on Requirements Elicitation. Educational

Materials CMU/SEI–94–EM–10, Software Engineering Institute, Carnegie Mellon University, 1994.

Disponible en http://www.sei.cmu.edu.

[81] M. G. Piattini, J. A. Calvo-Manzano, J. Cervera, y L. Fernández. Análisis y Diseño Detallado de

Aplicaciones Informáticas de Gestión. rama, 1996.

[82] M. Jarke. Requirements Tracing. Communications of the ACM, 41(12), Diciembre 1998.

[83] MAP. Metodología de Planificación y Desarrollo de Sistemas de Información. MÉTRICA Versión

2.1. Tecnos/Ministerio para las Administraciones Públicas, 1995.

[84] J. Robertson y S. Robertson. Volere Requirements Specification Template Edition 6.0. Informe

técnico, Atlantic Systems Guild, 1998. Disponible en

http://www.atlsysguild.com/GuildSite/Robs/Templsects.html.

[85] I. Jacobson, M. Christerson, P. Jonsson, y G. Övergaard. Object–Oriented Software

Engineering: A Use Case Driven Approach. Addison–Wesley, 4a edición, 1993.

[86] S. Lilly. How to Avoid Use–Case Pitfalls. Software Development, Enero 2000. Disponible en

http://www.sdmagazine.com/breakrm/features/s0001f4.shtml.

[87] G. Booch, J. Rumbaugh, y I. Jacobson. The Unified Modeling Language User Guide. Addison–

Wesley, 1999.

[88] O. Díaz y J. J. Rodríguez. On Use Case Elicitation. En Actas de las III Jornadas de Ingeniería

del Software, Murcia, 1998.

[89] J. M. Spivey. The Z notation: a Reference Manual. Prentice Hall, 2a edición, 1992.

152

ANEXOS

Documentos y Formatos

1)

153

2)

154

3)

155

4)

156

5)

157

6)

Tipo de Artefacto: Documento de Requisitos. Nombre del Sistema A Revisar: Nombre del Artefacto a Revisar:

EVAL = Excelente; Bien; Aceptable; Regular; Deficiente CÓDIGO Descripción EVAL

REQ-DR-01 Están cada uno de los objetivos del sistema cubriendo mínimo una necesidad del cliente, según el listado de necesidades entregado por el cliente.

REQ-DR-02 Cada requisito de información especifica datos concretos que debe manejar el sistema.

REQ-DR-03 Cada requisito funcional especifica una función que debe cumplir el sistema.

REQ-DR-05 Cada regla de negocio especifica una restricción o cálculos que complementan o delimitan algún requisito de información o funcional.

REQ-DR-04 Cada requisito no funcional esta adecuadamente justificado y relacionado con la funcionalidad a la cual impacta.

REQ-DR-06 Están identificados todos los participantes del proyecto.

REQ-DR-07 Esta el documento de requisitos establecido de acuerdo la plantilla estándar de la empresa.

REQ-DR-08 Se han identificado las fuentes de información de cada requisito u objetivo.

REQ-DR-09 Se han identificado los autores de la información de cada requisito objetivo.

REQ-DR-10 Cada requisito tiene una y sólo una interpretación.

REQ-DR-11 Cada requisito está escrito en un lenguaje apropiado para el cliente.

REQ-DR-12

Está cada requisito está libre de errores ortográficos y gramaticales.

REQ-DR-13

Se han identificado requisitos redundantes y se han reducido al mínimo.

REQ-DR-14

Cada término del glosario tiene una definición clara y concisa.

REQ-DR-15 Todas las figuras, tablas y diagramas incluyen etiquetas de referencia, definición de términos y unidades de medida completas.

REQ-DR-16

Cada requisito tiene un identificador único y siguen el siguiente formato:

REQ-XXX-#### + Nombre del requisito donde XXX es el tipo de requisito ya sea FUN para funcionales, INF para los de información, NFU para los no funcionales y RNG para las reglas de negocio. #### es el código único que se asigna a cada requisito.

REQ-DR-17 Para cada requisito se ha establecido el grado de importancia, estabilidad y prioridad.

158

REQ-DR-18

No hay requisitos duplicados.

REQ-DR-19

Cada requisito puede ser medible y/o verificable.

REQ-DR-20

Todos los requisitos están expresados como condiciones o capacidades del sistema y no en forma de diseño o implementación de una solución o función.

REQ-DR-21 Están debidamente relacionados los requisitos con los objetivos que los justifican.

REQ-DR-22 Si se usa la técnica de casos de uso, se asegura que todos los requisitos funcionales han sido mapeados en los casos de uso.

REQ-DR-23

Están especificadas por lo menos las siguientes matrices: a. Requisitos funcionales vs. Objetivos. b. Requisitos de información vs. Requisitos funcionales. c. Requisitos funcionales y de información vs. Reglas de negocio.

d. Casos de uso vs Requisitos funcionales.

REQ-DR-24 Los conflictos en los requisitos se encuentran detectados.

REQ-DR-25 Han sido revisados y aprobados por el cliente todos los requisitos definidos.

REQ-DR-26 Existe una clara explicación de la manera como fueron resueltos los conflictos encontrados en los requisitos.

OBSERVACIONES

7) Matriz de Trazabilidad (Requisitos – Objetivos)

159

8) Matriz Trazabilidad

160

9) Lista de Cambios del Documento de Requisitos del Sistema

10)

161

11)

12)

162

13)

163

14)

164

15)

16)

165

17)

18)

166

19)

20)

167

21)

22) Estructura DRS

MEJORA DE PROCESO DE SOFTWARE DE UNA PEQUEÑA EMPRESA DESARROLLADORA DE SOFTWARE: CASO COMPETISOFT-...

Documents

Transcript of MEJORA DE PROCESO DE SOFTWARE DE UNA PEQUEÑA EMPRESA DESARROLLADORA DE SOFTWARE: CASO COMPETISOFT-...