Académique Documents
Professionnel Documents
Culture Documents
PER
ESCUELA DE POSTGRADO
MAESTRA EN INFORMTICA
MENCIN EN INGENIERA DE SOFTWARE
Supervisor
INDICE
INTRODUCCIN .................................................................................................................... 3
DEFINICIN DEL PROBLEMA .................................................................................................... 3
OBJETIVO GENERAL ............................................................................................................. 4
OBJETIVOS ESPECFICOS ...................................................................................................... 5
RESULTADOS ESPERADOS ..................................................................................................... 5
JUSTIFICACIN..................................................................................................................... 5
MTODOS Y PROCEDIMIENTOS ............................................................................................... 6
CONCLUSIONES.............................................................................................................. 57
RECOMENDACIONES ....................................................................................................... 58
REFERENCIAS ..................................................................................................................... 84
Captulo 1
1.1. Introduccin
Las Normas Internacionales traen beneficios tecnolgicos, econmicos y
sociales 27. Ayudan a armonizar las especificaciones tcnicas de los
productos y servicios haciendo a la industria ms eficiente, permitiendo su
ingreso al comercio internacional y a los consumidores a travs de productos
seguros y eficaces 27.
Cabe indicar que el 90% de las 300 empresas desarrolladoras de software
en el Per, son micro y pequeas7, segn la Comisin de Promocin del
Per para la Exportacin y el Turismo PROMPER; por ello, al ser las
mypes el tipo de empresa que representa la mayor proporcin para
desarrollar software, se presenta la necesidad de apoyarlas para que sean
cada vez ms competitivas y una forma de alcanzarlo es a travs del uso de
estndares internacionales.
Para el presente proyecto de tesis, se pretende evaluar los procesos
asociados al ciclo de vida de desarrollo de software en una mype y plantear
propuestas de mejora de procesos tomando como marco de referencia la
ISO/IEC 12207:2008 para la evaluacin y mejora de procesos en
microempresas y pequeas empresas desarrolladoras de software.
Por otro lado, las pequeas empresas desarrolladoras de software en el
Per tienen respaldo del Centro de Innovacin Tecnolgica de Software
(CITE Software), que ha sido creado, segn resolucin N 002-2007Produce/DVI, con el nimo de promover el desarrollo y la innovacin
tecnolgica de la industria peruana de software, especialmente mypes y
brinda a las empresas de la cadena productiva de software, servicios
tecnolgicos que ayuden a fortalecer su competitividad y mejorar su
productividad 5.
Uno de los factores importantes que genera una imagen positiva en una
empresa
desarrolladora de software es un buen producto de software y servicio; y
para alcanzarlo es conveniente considerar los estndares de calidad
presentados por la ISO/IEC y otros marcos de referencia como
MOPROSOFT, COMPETISOFT que elevan la calidad de los procesos
involucrados en el desarrollo del producto de software; dichos estndares o
marcos de referencia constituyen buenas prcticas para mejorar los
procesos involucrados en la realizacin de los proyectos, incorpora
temas de gestin de negocios, procesos, recursos, administracin,
desarrollo y mantenimiento de software 37; para el presente proyecto se
realiz a travs de la aplicacin de la ISO/IEC 12207 en una empresa en
particular.
Existen proyectos que se han realizado para la evaluacin y mejora de
procesos del ciclo vida de software en pequeas empresas, tal es el caso
del proyecto
COMPETISOFT, que busca
que
las
empresas
desarrolladoras de software de los pases iberoamericanos, dentro de
los cuales se encuentra Per, mejoren sus procesos software y en tal
sentido tengan las competencias necesarias para colocarse en el mercado
internacional a travs de la aplicacin de los modelos propuestos por el
proyecto 39. Por otro lado, la ISO / IEC 29110 considera un conjunto de
normas e informes tcnicos que se ha desarrollado para las pequeas
empresas (VSE Very Small Entities) reconociendo a stas como
proveedoras de software de alta calidad. Dicha norma fue adoptada en el
Per a travs de NTP- ISO/IEC 29110 19.
En este contexto, la tesis busca responder a la pregunta cmo aplicar la
ISO/IEC 12207:2008 en una mype?. Por ello se presenta un estudio de caso
a travs de la aplicacin de la ISO/IEC 12207 en una microempresa
desarrolladora de software. Se realizar la evaluacin de los procesos
asociados al ciclo de vida de desarrollo de software, considerando aquellos
procesos que afecten en mayor medida los objetivos de negocio; y en base
a dichos resultados se realizarn propuestas para la mejora de los procesos
teniendo como marco de referencia la ISO/IEC 12207. La metodologa
aplicada para el anlisis, evaluacin y propuestas de mejora son tomadas de
los documentos del proyecto COMPETISOFT 52.
Las propuestas sern llevadas a cabo a travs de un piloto, cuya
implementacin al final se evalu a fin de verificar si los procesos mejoraron.
1.6. Justificacin
La industria de software representa una actividad econmica de
suma importancia para todos los pases del mundo. Ofrece mltiples
fuentes de negocio y se perfila como la oportunidad ms grande de
los pases en va de desarrollo. Pero, en los pases latinoamericanos
la industria de software es incipiente e inmadura 47.
Al 2013, existen unas 60 millones de pymes en Latinoamrica y el
Caribe, de las cuales un gran porcentaje an no han despertado al
mundo tecnolgico. Del lado de la demanda es clave mencionar que
5
operativa de la empresa.
Para desarrollar el proyecto, el cual estuvo programado para 9 meses
de trabajo; se realiz el planteamiento el problema, la revisin de
conceptos y literatura asociada, se propuso la creacin de formatos y
documentacin para facilitar la mejora de procesos en la empresa.
Para lograr los resultados deseados se propuso desarrollar las
siguientes actividades:
Captulo 2
Marco de Referencia
La definicin de modelos de calidad y mejora de procesos de software
para pequeas empresas demuestra ser un punto clave y de rpido
crecimiento en el contexto iberoamericano 45. Prueba de ello son los
proyectos de investigacin desarrollados en Mxico con la definicin
del Modelo de Procesos para la Industria del Software
(MOPROSOFT), Brasil con su Modelo de Referencia para la Mejora
de Proceso de Software (MPS.BR), el proyecto "Mejora de Procesos
para Fomentar la Competitividad de la Pequea y Mediana Industria
del Software de Iberoamrica" (COMPETISOFT) 45 y la ISO / IEC
29110 que se ha desarrollado para las pequeas empresas.
Es por ello, que el marco de referencia presenta la informacin
necesaria para comprender los conceptos y antecedentes utilizados
en el proyecto.
La primera seccin abarca los modelos de calidad de proceso
(ISO 9001:2000, ISO/IEC 12207, CMMI, MOPROSOFT,
MPS.BR, ISO/IEC 29110).
La segunda seccin cubre los modelos de evaluacin de
procesos (ISO/IEC 15504, SCAMPI, EVALPROSOFT).
La tercera seccin trata los modelos de mejora de procesos
(AGILE SPI
, IDEAL, PMCOMPETISOFT)
Finalmente, el proyecto COMPETISOFT, COMPETISOFTPUCP, PACIS, RELAIS.
2.1
2.2
2.2.1
ISO 9001
La norma ISO 9001, es una norma internacional que se aplica a los
sistemas de gestin de calidad; se concentra principalmente en los
procesos usados para producir un servicio o producto y proporciona el
marco necesario para supervisar y mejorar el rendimiento de cualquier
rea de negocio. 24
2.2.2 ISO/IEC
12207: 2008
2.2.3
CMMI
Capability Maturity Model Integration (CMMI) es un modelo que
proporciona las mejores prcticas para ayudar a las organizaciones a
mejorar sus procesos, habilidad para gestionar el desarrollo,
adquisicin y mantenimiento de productos o servicios 11. Es el modelo
internacionalmente ms reconocido para la industria de software
11
, fue creado por el Sofware Engineering Institute (SEI) a pedido del
Departamento de Defensa de los EEUU 11.
CMMI tiene seis niveles de capacidad, cada uno es una capa base
para la mejora de procesos, se denominan por los nmeros del 0 al 5
23
.
0. Incompleto
1. Realizado
2. Gestionado
3. Definido
4. Cuantitativamente Gestionado
5. Optimizacin
Nivel de capacidad 0: Incompleto
Un proceso incompleto es un proceso que, o bien no se realiza, o se
realiza parcialmente. Al menos una de las metas especficas del rea
de proceso no se satisface y no existen metas genricas para este
nivel, ya que no hay ninguna razn para institucionalizar un proceso
realizado parcialmente.
Nivel de capacidad 1: Realizado
Un proceso realizado es un proceso que lleva a cabo el trabajo
necesario para producir productos de trabajo. Se satisfacen las metas
especficas del rea de proceso.
Nivel de capacidad 2: Gestionado
Un proceso gestionado es un proceso realizado que se planifica y
ejecuta de acuerdo con la poltica; emplea personal cualificado que
tiene los recursos adecuados para producir resultados controlados;
11
2.2.4
MoProSoft
2.2.5
MPS.BR
2.2.6
ISO/IEC 29110
2.3
2.3.1
ISO/IEC 15504
32
La dimensin de proceso:
Se caracteriza por los propsitos de proceso (objetivos de medicin
esenciales de un proceso) y el resultado esperado del proceso (la
indicacin de su finalizacin exitosa).
La dimensin de capacidad:
Esta dimensin define una escala de medida para determinar la
capacidad de cualquier proceso. Consta de 6 niveles de capacidad:
2.3.2
SCAMPI
El Standard Appraisal Method for Process Improvement (SCAMPI)
es el mtodo de Evaluacin de CMMI para la mejora de procesos,
satisface los requerimientos de evaluacin de CMMI y est
basado en los requisitos para evaluacin de proceso de la ISO/IEC
15504 55.
La definicin de SCAMPI describe los requisitos, las actividades y las
prcticas relacionadas con cada uno de los procesos que componen el
mtodo SCAMPI y determina tres clases de evaluacin (A, B y C) 55.
17
2.3.3
EvalProSoft
El modelo de evaluacin EvalProSoft est desarrollado para ser utilizado
en organizaciones vinculadas a la industria del Software y nace como un
esfuerzo conjunto para ser adaptado a las Pequeas y Medianas
Empresas; aplicado a aquellas organizaciones que han utilizado a
MoProSoft como modelo de referencia para la implantacin de procesos
44
.
El mtodo de evaluacin EvalProSoft est basado en los requisitos
expresados en la norma ISO/IEC15504-2. Los procesos se miden en
base a sus capacidades. La capacidad de un proceso se evala en una
escala entre 0 y 5, donde el 0 se asocia al nivel de capacidad ms bajo,
y significa que no se alcanza el propsito del proceso. Por otro lado, el
valor 5 como capacidad del proceso se asocia al nivel ms alto e indica
que se logran las metas de negocio actuales y proyectadas a travs de
la optimizacin y mejora continua del proceso 44.
La medicin de la capacidad de un proceso se obtiene a travs de un
conjunto de atributos del proceso, los cuales son utilizados para
establecer la capacidad de un determinado proceso 44.
El grado de cumplimiento del atributo del proceso se califica usando una
escala ordinal, tomando como referencia los porcentajes de la
ISO/IEC15504 -2 44.
2.4
Agile SPI
relacionar los elementos del proceso con los elementos del modelo de
calidad, con el modelo de evaluacin y con el modelo de medida 52.
Agile SPI est compuesto por 5 fases, las cuales se muestran en la Figura
3: Instalacin, Diagnstico, Formulacin, Mejora y Revisin del Programa y
se describen a continuacin 52.
1. Instalacin, se crea una propuesta de mejora de acuerdo a las
necesidades del negocio adems de disear la infraestructura de gestin,
donde se describe cmo se organizarn las personas, teniendo en cuenta
un equipo de gestin, de tecnologa de procesos y de mejora 52.
2. Diagnstico, en esta fase los equipos de gestin y de tecnologa
de procesos realizan actividades de valoracin para determinar el
estado de los procesos en la organizacin y luego realizar un anlisis
de los resultados estableciendo de esta forma posible casos de mejora y
estructurar un plan general de mejora 52.
3. Formulacin, el equipo de mejora se enfoca en los casos de mejora
crticos, de acuerdo a los resultados obtenidos en la fase anterior, se
realizan las primeras iteraciones de mejora las cuales se toman como
muestra y estimacin de esfuerzo, costos y tiempo que tomar ejecutar el
resto de casos de mejora. Con estas estimaciones se podr realizar
la planificacin de las dems iteraciones de mejora 52.
4. Mejora, en esta fase se gestionan y ejecutan todos los casos de mejora
de acuerdo a la planificacin realizada en la fase de formulacin 52.
5. Revisin del Programa, el equipo de gestin realiza un anlisis de
todas las fases anteriores utilizando las lecciones aprendidas y las
mtricas desarrolladas para el cumplimento de los objetivos, como base
del conocimiento para las personas que tendrn a cargo el siguiente ciclo
de mejora. Con toda la informacin obtenida en el ciclo de mejora se debe
evaluar el trabajo realizado, mtodos utilizados, infraestructura, etc. y
corregir los errores cometidos en la ejecucin de la mejora 52.
2.4.2
IDEAL
20
46
21
2.4.3
PMCOMPETISOFT
El modelo de mejora de COMPETISOFT (PMCOMPETISOFT) tiene
como propsito mejorar los procesos de la organizacin en funcin de
sus objetivos de negocio, as como ayudar a conducir la mejora de
procesos de software en las pequeas organizaciones, a travs de la
definicin de una gua para implementar paso a paso la mejora de
procesos 9.
Est basado en Agile SPI (Software Process Improvement) y est
compuesto
de
5
macro-actividades: Instalacin, Diagnstico,
Formulacin, Mejora y Revisin 9.
Instalacin del ciclo: Se crea o actualiza una Propuesta de Mejora
alineada con la planeacin estratgica de la organizacin plasmada en
el Plan Estratgico. La propuesta debe ser aprobada y divulgada para
garantizar, de esta manera, la asignacin de los recursos necesarios y
el compromiso de los involucrados.
Diagnstico de procesos: Se realiza la actividad de evaluacin interna
de procesos para conocer el estado general de los procesos de la
organizacin y analizar los resultados con el objetivo de establecer las
22
2.5
COMPETISOFT
En el proyecto COMPETISOFT estuvieron involucrados 13 pases,
incluido el Per; fue un proyecto financiado por el Programa
Iberoamericano de Ciencia y Tecnologa para el Desarrollo, que implic
un organismo de normalizacin y certificacin, ms de 10 empresas
pequeas y 27 grupos de investigacin de 13 pases de Amrica, que
han sumado el esfuerzo de involucrados, el conocimiento de procesos
adquiridos, el proceso de mejora realizada con la base del knowhow y
beneficios descritos por las empresas 9.
Dicho proyecto tuvo como objetivo general el incrementar el nivel de
competitividad de las pymes Iberoamericanas productoras de
software, mediante la creacin y difusin de un marco metodolgico
comn que ajustado a sus necesidades especficas, pueda llegar a
ser la base para establecer un mecanismo de evaluacin y
certificacin de la industria del software reconocido en toda
Iberoamrica 9.
COMPETISOFT define un patrn de procesos aplicable a cualquier
organizacin desarrolladora de software y presenta tres partes 9:
El modelo de referencia est basado en MOPROSOFT y agrupa los
procesos en tres categoras principales: Alta direccin, Gestin y
Operacin; el modelo de evaluacin est basado en el mtodo de
evaluacin EvalProSoft e ISO/IEC 15504-2; el modelo de mejora est
basado en Agile SPI 43.
23
2.6
COMPETISOFT PERU
Los estudiantes de pregrado y bachilleres de la especialidad de
Ingeniera Informtica de la Pontificia Universidad Catlica del Per bajo
la supervisin de un asesor y director del proyecto integraron el Grupo
de Investigacin y Desarrollo en Ingeniera de Software (GIDIS);
cada uno de ellos ha participado en diferentes empresas peruanas
desarrolladoras de software para realizar la evaluacin y mejora de los
procesos utilizando los modelos relacionados al Proyecto Competisoft 36.
El proyecto en mencin forma parte de un esfuerzo Iberoamericano que
busca elevar el nivel de competitividad de las pequeas y medianas
empresas de la industria de software, a travs del mejoramiento de
sus procesos, lo cual se traduce en la realizacin de pruebas
controladas de implantacin de un marco metodolgico de mejora
de procesos adaptado a la realidad de cada empresa 36.
Este proyecto se desarroll del ao 2007 hasta el 2011 y estuvo
conformado por 3 fases. Cada
fase constituye
un
proyecto
independiente, la fase 1 se realiz a travs del Proyecto
Internacional financiado por CYTED, la fase 2 sirvi para realizar la
replicacin a otras ciudades y la fase 3 para la certificacin de
empresas 12.
En la Fase 2, GIDIS-PUCP ha participado en COMPETISOFT-Per 2,
en coordinacin con la Universidad Nacional San Agustn de
Arequipa (UNSA), Universidad Catlica Santa Mara (UCSM) y la
Universidad Nacional de Trujillo (UNT), en el marco de
colaboracin
de
la
Red Peruana de Universidades (RPU).
COMPETISOFT Per 2 36; como en su primera etapa, busca la mejora
de procesos software en un grupo de pymes que desarrollan software 39.
El proyecto permiti obtener un conjunto de beneficios y resultados
tanto para empresas, como para profesionales y acadmicos. Tuvo
buena aceptacin en las empresas y estudiantes que vieron una
oportunidad interesante para desarrollar distintas habilidades 12.
2.7
PACIS
PACIS es el Programa de Apoyo a la Competitividad de la Industria del
Software, proyecto cofinanciado por el Banco Interamericano de
Desarrollo BID/FOMIN, y ejecutado por la Cmara de Comercio de Lima
con el apoyo de la Asociacin Peruana de Productores de Software
(APESOFT) 14.
24
2.8
RELAIS
La Red Latinoamericana de la Industria del Software (RELAIS), es una
organizacin regional actualmente coordinada por cuatro importantes
instituciones de Brasil, Colombia, Mxico y Per. Su objetivo principal es
aumentar la competitividad de la industria del software en Amrica
Latina y el Caribe (ALC) promoviendo la calidad en el proceso de
produccin y adquisicin de software y desarrollo de los servicios de
tecnologa de la informacin y favoreciendo el clima de negocios 49.
La RELAIS promueve la diseminacin en los pases participantes de los
modelos de calidad de software para pymes desarrollados con xito en
Brasil y Mxico, la creacin y el posicionamiento de la Red como entidad
referente en temas de ingeniera y calidad de software en la Regin 49.
La Red trabaja con los Modelos de Mejora de procesos 49:
26
Captulo 3
Empresa de estudio
En este captulo se describe a la empresa, cundo fue creada, qu servicios
realiza y los objetivos que persigue.
3.1
Descripcin de la empresa
Para evaluar la aplicacin de la ISO/IEC 12207:2008 se consider
una micro empresa peruana, a la cual de ahora en adelante se
denominar X a fin de garantizar la confidencialidad de la misma.
X es una microempresa peruana, que orienta sus servicios y
soluciones de modo horizontal; orientada a la prestacin de servicios
de consultora, gestin de proyectos, mejora de procesos de gestin;
desarrollo e implementacin de sistemas de informacin, informticos
y comunicaciones, soporte de gestin e informtico; comercializacin
de equipos, insumos informticos y de comunicaciones; exportacin e
importacin de productos y servicios de gestin, informticos,
software y comunicaciones.
X fue constituida a finales de Octubre del 2010, y a la fecha cuenta
con 8 personas prestando sus servicios en la organizacin, los cuales
conforman la siguiente estructura organizacional:
2 Analistas QA
1 Especialista en Procesos y Seguridad Informtica
1 Contador
Nota: El Gerente General a su vez desempea el rol de Jefe de
Proyectos y forma parte de la Gerencia de Proyectos.
Los productos y servicios que realiz X desde su creacin incluyen:
3.2
Objetivos de la Empresa
Como parte del proceso de induccin en la empresa, se consider
efectuar un levantamiento de informacin para determinar los
objetivos de negocio de X, los cuales no estaban formalizados ni
documentados.
Se obtuvieron a travs de entrevistas realizadas al gerente general
los siguientes objetivos:
1.
2.
3.
4.
5.
29
Captulo 4
4.1
4.1.1
4.1.2
Resultados obtenidos
Se presentaron los resultados obtenidos al gerente general, el que a
su vez desempea el cargo de jefe de proyectos. Estos resultados
detallan la situacin encontrada en la empresa X, que fue obtenida
durante la evaluacin realizada con los responsables de los procesos.
30
4.1.3
Evaluacin inicial
Para realizar la evaluacin se utiliz la metodologa empleada por el
Proyecto COMPETISOFT-PUCP, la que utiliza cuadros de evaluacin
que permiten seleccionar qu procesos deben ser priorizados.
En la evaluacin inicial se consider:
a) Priorizacin de procesos:
Problemas de Negocio
Objetivos
de
Negocio
vs.
31
Objetivos
Pocas
utilidades
o bajos
ingresos
para la
Peso Peso % empresa
5
Demora
por parte
del cliente
en las
diferentes
etapas del
proyecto
6
Mala
administra
cin del
conocimie
nto de la
organizaci
n
8 16.00%
7 14.00%
6 12.00%
8 16.00%
7 14.00%
6 12.00%
8 16.00%
1.44
1.58
1.42
1.58
1.28
1.58
50
33
34
de
Negocio
vs.
35
36
4.1.4
4.1.5
Tabla 4.1 Estructura del proceso de Gestin de Riesgos segn la ISO/IEC 15504-5
MAN.5 Gestin de Riesgos
ID del proceso
Propsito
proceso
del
Prcticas base
32
39
Outputs
07-07 Medidas de Riesgos [Resultado: 5]
Las practicas base, que son tareas y/o actividades que se deben
realizar para generar un resultado,
a)
Definicin de la mtrica
48
Definicin
NRP_std
NPB_std
NPBRi_std
Nmero de prcticas base que contribuyen al logro del resultado i, del proceso
software a evaluar definidos por el estndar ISO/IEC 15504-5.
PRP
VPBRi_ro
Valor de las prcticas base para el resultado i, realizadas o llevadas a cabo por
la organizacin. Se obtiene a partir de un instrumento de recoleccin de
informacin.
GCRi (PB)
MRP (PB)
GCRi (PB)
Definicin
Pregunta
41
NPTE_std
NPTS_std
5
Nmero
de productos de trabajo de salida del proceso software a evaluar
definidos por el estndar ISO/IEC 15504-5.
NPTERi_std
9
Nmero
de productos de trabajo de entrada del resultado i, del proceso
software a evaluar definidos por el estndar ISO/IEC
15504-5.
NPTSRi_std
9
Nmero de productos de trabajo de salida del resultado i, del proceso
software a evaluar definidos por el estndar ISO/IEC 15504-5.
22
NTPTRi
NPTRi_ro
31
Nmero de productos de trabajo para el resultado i, realizadas o llevadas a
cabo por la organizacin. Se obtiene a partir de un instrumento de
recoleccin de informacin.
GCRi (PT)
14
Grado de cumplimiento del resultado i, en funcin de los productos de trabajo.
GCRi (PT) = NPTRi_ro / NTPTRi
3.09
MRP (PT)
GCRi (PT)
0.51
48
42
Mtrica
Definicin
Medida del rendimiento del proceso.
MRP
b)
el
instrumento
de
recoleccin
de
ID del Proceso
Gestin de
Riesgo
Grado de Realizacin
Propsito del
Proceso
PRACTICA BASE
SPB1
SPB2
SPB3
SPB4
Nunca
Casi
Nunca
Casi
Siempre
X
Siempre
X
X
X
43
SPB5
SPB6
SPB7
X
X
4.1.5.1
44
R02
R03
Descripcin Detallada
Impacto
Probabilidad
a Ocurrir
Alto
15%
Alto
10%
Alto
10%
Deficiencia en la
comunicacin con los
usuarios
Falta de aprobacin de
algn documento
presentado al cliente.
R04
Cambio en la Solucin
Operativa.
Alto
10%
R05
Cambio en los
requerimientos funcionales
por partes de los usuarios.
Alto
10%
Estrategia de Mitigacin
Nombrar al personal de reemplazo.
Transferencia de conocimientos, informacin
y documentos al personal sustituto.
Establecer
un
lenguaje
sencillo
y
comprensible adecuado a la preparacin de
los usuarios.
Definir en el cronograma los hitos, los cuales
tienen que ver con los entregables del
documento.
Comunicacin permanente con los usuarios
para anticipar posibles cambios. Reuniones
peridicas de seguimiento.
Documentar los requerimientos, validarlos,
analizar el impacto (costo, tiempo, calidad,
alcance) y consolidarlos mediante un acta.
(Mitigacin).
b) Propuesta de mejora:
El modelo propone la documentacin del proceso con respecto a la
identificacin, anlisis, tratamiento y monitoreo continuo de los riesgos
33
. Se elaboran y procesan encuestas para recoger la informacin
asociada a la gestin de riesgos; establecimiento de los roles y
responsabilidades, definiendo al lder o jefe del proyecto y considerando
el presupuesto o recursos humanos ante posibles contingencias.
La empresa X no cuenta con un proceso establecido para la Gestin de
Riesgos; sin embargo para el desarrollo de sus anteriores proyectos
consideraba como anexo al Plan de Desarrollo de Software un listado de
Posibles Riesgos que podan presentarse en la ejecucin de los
proyectos.
Para el proyecto Z Web se introdujeron las siguientes mejoras como la
elaboracin e introduccin formal de las siguientes herramientas en la
empresa: Gua para identificar Riesgos y Matriz de Riesgos (Vase
Anexo N 04), para ello se realiz la propuesta de los siguientes
formatos:
46
Piloto:
4.1.5.2
Fortalezas
Existen formatos para la aceptacin del producto y/o servicio.
Se tiene conocimiento de los trmites administrativos para iniciar
el proceso de aceptacin en el Sector Pblico.
Debilidades
No existe una estrategia de aceptacin planificada ni
documentada en el Sector Pblico.
No se sabe cmo aplicar el proceso de aceptacin; empleando
las sugerencias que seala la ISO/IEC 12207: 2008.
b) Propuesta de mejora:
El modelo propone la documentacin del proceso con respecto a las
revisiones y pruebas de producto de software, y ante ello la empresa
responde positivamente, cuenta con los formatos adecuados; sin
embargo dicha documentacin no estaba organizada. Por ello se
propone las siguientes especificaciones en los estndares de Pruebas y
Aceptacin:
Para las pruebas de aceptacin:
1. En la organizacin existe un responsable para realizar
las pruebas.
2. Se cuenta y se usa el catlogo de pruebas.
3. Se
verifica
que
las
especificaciones
correctamente implementadas.
estn
50
4. Se
verifica
que
estn
implementadas
funcionalidades del documento de requerimientos.
5. Los tipos de
identificados.
defectos
observaciones
las
son
c)
Piloto:
4.1.5.3
56
Captulo 5
Conclusiones y Recomendaciones
El presente captulo presenta las conclusiones y recomendaciones finales a
travs del proyecto del ciclo de mejora.
5.1
Conclusiones
El trabajo realizado estuvo dirigido a cumplir con los siguientes objetivos:
5.2
Recomendaciones
Para el prximo ciclo de mejora se recomienda revisar el proceso de
Aseguramiento de la Calidad de Software; sin embargo la empresa no lo
consider porque prioriz en los otros 3 planteados en el proyecto
(Gestin de Riesgos, Gestin de Aceptacin de Software y Gestin de
Activos de Reuso), toda vez que los consideraba crticos.
Se recomienda que la empresa siga aplicando pilotos hasta obtener la
experiencia y habilidad necesaria para que la metodologa empleada sea
utilizada en cualquier tipo de proyecto.
La mype debera designar una persona de la organizacin que tenga
como responsabilidad la implementacin de las mejoras de procesos,
de modo que se consolide la participacin de la empresa en los
procesos de mejora e involucre ms a las partes operativas a fin de
58
59
Objetivo estratgico
Propsitos muy especficos a donde se debe llegar
(grandes finalidades de la Organizacin)
Objetivos Especficos
Es el siguiente nivel que se obtiene al disgregar los
objetivos estratgicos
Estrategia
A partir del diagnstico de la empresa, su entorno y
su posicin relativa, el siguiente paso consiste en planear
hacia dnde queremos ir y cmo lograrlo.
Consultora
a) Anlisis y diseo de sistemas de informacin:
b) Diseo y mejoramiento de procesos
c) Consultora en TI:
d) Inteligencia de Negocios:
e) Capacitacin y asistencia tcnica:
60
f) Otro:
Informacin obtenida del personal de la empresa
Objetivos
Pocas
utilidades
o bajos
ingresos
para la
Peso Peso % empresa
5
Demora
por parte
del cliente
en las
diferentes
etapas del
proyecto
6
Mala
administra
cin del
conocimie
nto de la
organizaci
n
8 16.00%
7 14.00%
6 12.00%
8 16.00%
7 14.00%
6 12.00%
8 16.00%
1.44
1.58
1.42
1.58
1.28
1.58
50
61
62
63
64
65
Nunca
Casi nunca
Casi siempre
Siempre
b) Casi nunca
c) Casi siempre
d) Siempre
Nunca
Casi nunca
Casi siempre
Siempre
c) Casi siempre
d) Siempre
14. Se evalan dominios para un reuso potencial?
a) Nunca
b) Casi nunca
c) Casi siempre
d) Siempre
15. Se evalan las propuestas de reutilizacin?
a) Nunca
b) Casi nunca
c) Casi siempre
d) Siempre
16. Se implementa el programa de reutilizacin?
a) Nunca
b) Casi nunca
c) Casi siempre
d) Siempre
17. Se recoge y gestiona el aprendizaje de reuso?
a) Nunca
b) Casi nunca
c) Casi siempre
d) Siempre
18. Se obtiene retroalimentacin de reutilizacin?
a) Nunca
b) Casi nunca
c) Casi siempre
d) Siempre
19. Se supervisa la reutilizacin?
a) Nunca
b) Casi nunca
c) Casi siempre
d) Siempre
68
Anexo N 01
Resultados del Proceso de Gestin de Riesgos:
Primera Evaluacin:
69
70
Anexo N 02
Resultados del Proceso de Aceptacin:
Primera Evaluacin (solo se realiz una evaluacin toda vez que se observ
que cumplan el nivel 1)
Grado de Realizacin
PRACTICA BASE
Nunca
3
3
0.33
1
1
Resultado
2
2
3
1
0.3
0.6
0.6
0.3
0.3
0.6
1
5
Resultado
2
3
3
1
0.5
0.5
0.5
0.4
7
3
0.5
43%
71
PRACTICA BASE
Nunca
3
3
0.33
1
1
Resultado
2
2
3
1
1.6
0.6
0.8
0.6
1
5
Resultado
2
3
3
1
1
6
1
4
1
2
0.7
0.5
0.8
7
3
0.7
78%
72
Anexo N 03
Resultados del Proceso de Reuso:
Primera Evaluacin:
73
74
Anexo N 04
Herramientas y artefactos asociados al Proceso de Gestin de Riesgos
Gua para identificar Riesgos
Ingeniera del Producto
Requerimientos
Variacin de los
requerimientos
Completitud de
los
requerimientos
Factibilidad de los
requerimientos
Diseo
Funcionalidad
Pruebas
Ambiente de Desarrollo
Capacidad
75
Fiabilidad
Recurso Humano
Presupuesto
Facilidades /
Logstica
Contratos
Tipo de contrato
Restricciones
Ambiente de Trabajo
Colaboracin y
clima de trabajo
76
Organizacin del
Proyecto
Experiencia en
Adm. de
proyectos
77
Descripcin
Item
Probabilidad Impacto
del Riesgo
Fecha
Severidad
planificada
(Prob x
de la
Impacto)
revisin
Fecha de
revisin
Responsa
ble de
seguimien
to y
atencin
Mitigacin
del riesgo
Plan de
contingencia
Observaciones / acciones
tomadas
Anexo N 05
Actualizado a
{Nombre mes} {Ao}
Historial de Revisiones
tem
{01}
Fecha
{dd/mm/aaa
a}
Versin
{n.n.n}
Autor
Descripcin
Responsable de
revisin y/o
aprobacin
{Nombre
del autor}
{Descripcin de
los cambios en
el documento}
{Nombre de
responsable de
revisin y/o
aprobacin}
Equipo
{Nombre del
equipo}
80
INTRODUCCIN
[La introduccin brinda una vista rpida de todo el documento respecto al sistema en desarrollo.
Da una idea general del contenido del documento as como algunos alcances generales. ]
OBJETIVO
ALCANCE
[Una breve descripcin del alcance de este documento y qu otros documentos se ven afectados
por ste.
Adems debe mencionarse qu otro(s) sistema(s) estn asociados o se ven afectados por el
sistema en desarrollo.]
DEFINICIONES Y ABREVIACIONES
PRUEBAS EJECUTADAS
81
PERSONAL ASIGNADO
Nro.
1.
Caso de Prueba
Rol
Usuario asignado
[ Rol 1.]
[ Usuario 1.
Usuario 2.]
[ Rol 2.]
[ Usuario 3.]
Tipo de prueba
Fecha de
prueba
Estado
Observaciones
{Tipo de pruebas a
realizar}
{Si se ejecuto o se
{Fecha en que se
encuentra
realizo la
pendiente o fue
prueba}
cancelada}
{Comentarios u
observaciones relevantes}
{Tipo de pruebas a
realizar}
{Si se ejecuto o se
{Fecha en que se
encuentra
realizo la
pendiente o fue
prueba}
cancelada}
{Comentarios u
observaciones relevantes}
Observaciones
Nueva fecha de
prueba
Usuario
{Tipo de pruebas a
realizar}
{observacin ocurrida
durante la prueba}
{Fecha en que se
realizara la
prueba}
{Tipo de pruebas a
realizar}
{observacin ocurrida
durante la prueba}
{Fecha en que se
realizara la
prueba}
82
Acta de Reunin
Fecha
Hora Inicio Planeada
Real
Duracin Planeada
Real
Local
Objetivo
Equipo de la empresa X
ASISTENTES Nombre Participante
Usuario - Cliente
Asisti
Agenda
Nombre Participante
Asisti
Revisado
1.
2.
Desarrollo
1.
2.
3.
Conclusiones y Acuerdos
1.
2.
3.
Firmantes:
83
REFERENCIAS
1
2
5
6
7
8
9
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
86