GESTIN DE PROYECTOS DE SOFTWARE

Informe Documental

Por Daniel Alejandro Vzquez Mrquez

Grupo I7
Docente: M.C.T.C Valdez Ramrez Esteban
Instituto Tecnolgico de Lzaro Crdenas

Fecha de elaboracin 20 de Noviembre de 2015

Introduccin

Tabla de Contenido

Contenido
Introduccin................................................................................................................... 2
Captulo 1: Introduccin a la gestin de proyectos....................................................................5
1.1.

Conceptos bsicos para la gestin de proyectos..............................................................5

1.2.

Fases de la gestin de proyectos................................................................................. 6

1.2.1. Planificacin de proyectos....................................................................................... 9

1.2.2. Propuesta.......................................................................................................... 10
1.2.3. Seleccin y Evaluacin de personal.........................................................................12
1.2.4. Supervisin y Revisin del proyecto........................................................................14
1.2.5. Informes........................................................................................................... 18
1.3 Fundamentos de P.M.I................................................................................................ 20
Captulo 2: Calidad de Software......................................................................................... 22
2.1 La gestin de proyectos usando un marco de calidad...........................................................22
2.2 Estndares y Mtricas de calidad en la ingeniera de SW......................................................24
2.2.1 PSP y TSP......................................................................................................... 26
2.2 CMM.................................................................................................................. 31
2.2.3 MOPROSOFT.................................................................................................... 34
2.3 Impacto de la calidad en tiempo, costo y alcance del proyecto...............................................36
Conclusin................................................................................................................... 39
Bibliografa............................................................................................................... 40

Tabla de figuras
Ilustracin 1 Factores y mtricas de calidad...........................................................................25
Ilustracin 2 Evolucin del proceso personal de software..........................................................28

4
Ilustracin 3 Elementos de PSP en CMM............................................................................. 29
Ilustracin 4 Estructura de CMM....................................................................................... 31
Ilustracin 5 Esquema del modelo CMMi............................................................................. 33
Ilustracin 6 Procesos de calidad........................................................................................ 36
Ilustracin 7 Proceso de calidad......................................................................................... 37
Ilustracin 8 Medicin del software.................................................................................... 38
Ilustracin 9 Procesos de medicin del software.....................................................................38

Captulo 5: Seleccin y evaluacin de personal

5.1 Roles y actividades
Segn la gua del PMBOK, El plan de gestin de los recursos humanos, el cual forma parte
del plan para la direccin del proyecto, proporciona una gua sobre el modo en que se deberan
definir, adquirir, dirigir y finalmente liberar los recursos humanos del proyecto. (PMI, 2013,
pg. 264).
Dentro del plan de gestin de los recursos humanos se incluyen, entre otros, los siguientes
elementos:

Roles y responsabilidades que definen los cargos, las habilidades y las competencias

que requiere el proyecto.

Organigramas del proyecto que indican la cantidad de personas necesarias para el

proyecto.
Plan para la gestin del personal que define los periodos de tiempo durante los cuales
se necesitar a cada miembro del equipo del proyecto, as como otra informacin
importante para la adquisicin del equipo del proyecto.

Al enumerar los roles y responsabilidades necesarias para completar un proyecto deben tenerse
en cuenta los siguientes aspectos:
Rol. La funcin asumida por o asignada a una persona en el mbito del proyecto. La claridad
del rol en lo relativo a su autoridad, responsabilidades y lmites, tambin se debe
documentar. (PMI, 2013, pg. 264)
Autoridad. El derecho de asignar los recursos del proyecto, tomar decisiones, firmar
aprobaciones, aceptar entregables e influir sobre otras personas para llevar a cabo el trabajo
del proyecto. (PMI, 2013, pg. 264)
Responsabilidad. Las tareas asignadas y el trabajo que se espera que realice un miembro del
equipo del proyecto a fin de completar las actividades del mismo. (PMI, 2013, pg. 264)
Competencia. La habilidad y capacidad requeridas para completar las actividades asignadas
dentro las restricciones del proyecto. Si los miembros del equipo del proyecto no poseen las
competencias necesarias, el desempeo puede verse amenazado. Cuando se identifican tales
desequilibrios, se originan respuestas proactivas, tales como capacitacin, contratacin,
cambios en el cronograma o en el alcance. (PMI, 2013, pg. 264)
Segn la gua del PMBOK, existen diversos formatos para documentar los roles de miembros
del equipo de los cuales se enmarcan en tres tipos: jerrquico, matricial y tipo texto. El objetivo
de estos formatos es asegurar que cada entregable tenga un responsable y que cada miembro del

equipo de desarrollo tenga claro su rol y responsabilidades dentro del proyecto. (PMI, 2013,
pg. 261).

Ilustracin x Formatos de definicin de roles y responsabilidades

5.2 Carga de trabajo

Segn la gua del PMBOK, durante la elaboracin del cronograma del proyecto se distribuye
la carga de trabajo de acuerdo a las aptitudes, habilidades y disponibilidad de cada miembro del
equipo del proyecto. (PMI, 2013, pg. 181).

La planificacin de los recursos humanos utiliza los requerimientos de recursos de las

actividades para determinar las necesidades de recursos humanos para el proyecto. Los requisitos
preliminares relativos a los miembros del equipo de proyecto necesarios y sus competencias son
elaborados gradualmente, como parte del proceso Planificar la Gestin de los Recursos
Humanos. Dentro de la gestin dl tiempo de tiene la tcnica de nivelacin de recursos la cual se
encarga de ajustar las fechas en el cronograma ayudando a equilibrar la carga de trabajo en el
equipo de desarrollo del proyecto. (PMI, 2013, pg. 259).

5.3 Asignacin de tareas

El plan para la gestin del personal es un componente del plan de los recursos humanos que
describe como y cuando se van a incorporar los miembros del equipo del proyecto y durante
cunto tiempo de les va a necesitar. Describe como se cumplirn los requisitos de recursos
humanos. El plan para la gestin del personal puede ser formal o informal, muy detallado o
formulado de manera general, dependiendo de las necesidades del proyecto. El plan se
actualiza recurrentemente durante el proyecto, para dirigir la adquisicin continua de
miembros del equipo y las acciones para su desarrollo. La informacin en este plan de gestin
de personal vara segn el rea de aplicacin y el tamao del proyecto. (PMI, 2013, pg. 265)
Segn PMBOOK, el calendario de recursos considerado en el plan para la gestin del
personal, identifica los das y turnos de trabajo en los cuales est disponible cada recurso
especifico. El plan para la gestin de personal describe los marcos temporales necesarios para
los miembros del equipo del proyecto, as como cuando deberan iniciarse las adquisiciones
como la contratacin del personal. Una de las herramientas que sirven para representar los
recursos humanos es el histograma de recursos, utilizado por el equipode direccin del
proyecto, como medio para representar de manera visual la asignacin de los recursos a las
diferentes partes interesadas. Este diagrama ilustra el nmero de horas que una persona,
departamento o equipo de proyecto completo, va a necesitar semanal o mensualmente durante
el transcurso del proyecto. El diagrama puede incluir una lnea horizontal que representa la
cantidad mxima de horas disponibles por parte de un recurso particular. Las barras que se
extienden ms all de la cantidad mxima de las horas disponibles, identifican la necesidad de
contar con una estrategia de optimizacin de recursos, tal como aadir recursos adicionales o
modificar el cronograma. (PMI, 2013, pg. 265)

Ilustracin x Histograma de recurso

5.4 Herramientas para la evaluacin de productividad

La evaluacin de desempeo tiene como objetivo aclarar los roles y responsabilidades,

retroalimentar a los integrantes del equipo, identificar debilidades, desarrollar capacitaciones
individuales y establecer o reestructurar los objetivos especficos para periodos futuros. (PMI,
2013, pg. 282).
Segn la gua del PMBOK, Las herramientas para la evaluacin del personal proporcionan al
director del proyecto y al equipo de desarrollo una visin clara de las fortalezas y debilidades de
cada integrante del proyecto, estas herramientas ayudan al director del proyecto a evaluar la
preferencias y aspiraciones de los integrantes, as como mostrar la tendencia en toma de
decisiones por parte del personal involucrado al proyecto. (PMI, 2013, pg. 278).

Existen diversas herramientas disponibles, tales como las encuestas de actitud, las
evaluaciones especficas, las entrevistas estructuradas, las pruebas de habilidad y los grupos
focales, estas herramientas pueden proporcionar una mejor comprensin, confianza,
compromiso y comunicacin entre los miembros del equipo y fomentar equipos productivos a
lo largo de la fase de desarrollo de un proyecto. (PMI, 2013, pg. 278)
El desempeo de un equipo de exitoso de mide en trminos xito tcnico conforme a
objetivos previamente acordados para el proyecto, pueden ser de desempeo segn el
cronograma y presupuesto del proyecto. Los equipos de desarrollo de alto desempeo se
caracterizan por este funcionamiento orientado a tareas y a los resultados.
Los indicadores que puede incluir la evaluacin de la eficacia de un equipo son:

Mejoras en las habilidades que permiten a las personas realizar las tareas de manera

eficaz.
Mejoras a nivel de las competencias que ayudan al equipo a funcionar mejor como equipo.
Reduccin del ndice de rotacin de personal.
Mayor cohesin del equipo en que los miembros comparten abiertamente informacin y
experiencias (PMI, 2013, pg. 278)
Como resultado de evaluacin de desempeo al equipo de desarrollo del proyecto el director
puede identificar necesidades y aptitudes pertinentes para mejorar el equipo, tales medidas
pueden ser capacitaciones, tutoras o asistencias. Esto debe ser documentado y comunicado a
las partes pertinentes. (PMI, 2013, pg. 279)

Relacin secuencial. En una relacin secuencial, una fase slo se inicia cuando se completa la
fase anterior. La naturaleza paso a paso de este enfoque reduce la incertidumbre, pero puede

eliminar opciones para acortar el cronograma general.

Relacin de superposicin. En una relacin de superposicin, una fase se inicia antes de que
finalice la anterior. Esto puede aplicarse algunas veces como un ejemplo de la tcnica de

10

compresin del cronograma, conocida como ejecucin rpida. La superposicin de fases

puede requerir recursos adicionales para permitir que el trabajo se realice en paralelo, puede
aumentar el riesgo y hacer preciso repetir partes de un proceso, si la fase siguiente avanza
antes de que se disponga de informacin precisa de la fase previa.
(PMI, 2013, pg. 43)
Segn la gua del PMBOK, Los procesos de la direccin de proyectos se agrupan en cinco
categoras conocidas como Grupos de Procesos de la Direccin de Proyectos: (PMI, 2013, pg.
48).

Grupo de Procesos de Inicio. Aquellos procesos realizados para definir un nuevo proyecto o

nueva fase de un proyecto existente al obtener la autorizacin para iniciar el proyecto o fase.
Grupo de Procesos de Planificacin. Aquellos procesos requeridos para establecer el alcance
del proyecto, refinar los objetivos y definir el curso de accin requerido para alcanzar los

objetivos propuestos del proyecto.

Grupo de Procesos de Ejecucin. Aquellos procesos realizados para completar el trabajo
definido en el plan para la direccin del proyecto a fin de satisfacer las especificaciones del

mismo.
Grupo de Procesos de Monitoreo y Control. Aquellos procesos requeridos para rastrear,
revisar y regular el progreso y el desempeo del proyecto, para identificar reas en las que el

plan requiera cambios y para iniciar los cambios correspondientes.

Grupo de Procesos de Cierre. Aquellos procesos realizados para finalizar todas las actividades
a travs de todos los Grupos de Procesos, a fin de cerrar formalmente el proyecto o una fase
del mismo.
(PMI, 2013, pg. 49)
Generalmente se opta por ciclos de vida predictivos cuando el producto a entregar se

comprende bien o cuando un producto debe ser entregado en su totalidad para que tenga valor
para los grupos de interesados (PMI, 2013, pg. 46).

11

Para planificar un proyecto es necesario tener los conocimientos adecuados, y las tcnicas
necesarias para poder elaborar eficazmente la direccin del proyecto.
La direccin de proyectos es la aplicacin de conocimientos, habilidades, herramientas y
tcnicas a las actividades del proyecto para cumplir con los requisitos del mismo. Esta
aplicacin de conocimientos requiere de la gestin eficaz de los procesos de direccin de
proyectos.
(PMI, 2013, pg. 47)
El Grupo de Procesos de Planificacin est compuesto por aquellos procesos realizados para
establecer el alcance total del esfuerzo, definir y refinar los objetivos, y desarrollar la lnea de
accin requerida para alcanzar dichos objetivos. Los procesos de Planificacin desarrollan el
plan para la direccin del proyecto y los documentos del proyecto que se utilizarn para
llevarlo a cabo. La naturaleza compleja de la direccin de proyectos puede requerir el uso de
reiterados ciclos de retroalimentacin para un anlisis adicional. A medida que se va
recopilando y comprendiendo ms informacin o ms caractersticas del proyecto, es probable
que se requiera una planificacin adicional.
(PMI, 2013, pg. 55)
El plan para la direccin del proyecto es el proceso de definir, preparar y coordinar todos los
planes secundarios e incorporarlos en un plan integral para la direccin del proyecto. El

12

beneficio de este proceso es un documento central que define la base para todo el trabajo (PMI,
2013, pg. 72).
Segn (Kendall, K, & J) afirman que El anlisis y diseo de sistemas involucra muchos tipos
de actividades que en conjunto forman un proyecto. El analista de sistemas debe administrar el
proyecto con cuidado si quiere que tenga xito (2011, pg. 77).
La administracin de proyectos incluye las tareas generales de planeacin y control. La
planeacin incluye todas las actividades requeridas para seleccionar un equipo de anlisis de
sistema, asignar miembros del equipo a los proyectos apropiados, estimar el tiempo requerido
para completar cada tarea y programar el proyecto de manera que las tareas se completen a
tiempo. El control implica utilizar retroalimentacin para supervisar el proyecto, incluyendo
una comparacin del plan para el proyecto con su evolucin actual. Adems, el control
implica tomar la accin apropiada para agilizar o reprogramar las actividades de manera que
se puedan terminar a tiempo, a la vez que se motiva a los miembros del equipo para que
completen el trabajo en forma apropiada.
(Kendall, K, & J, 2011, pg. 77)
El analista de sistemas utiliza la informacin recolectada antes para realizar el diseo
lgico del sistema de informacin, disea los procedimientos para ayudar a que los usuarios
introduzcan los datos con precisin (Kendall, K, & J, 2011, pg. 11).

1.2.2. Propuesta

El analista de sistemas debe preparar una propuesta en la que se sintetiza la informacin

requerida de utilidad de los sistemas actuales.
Incluye un anlisis de costo-beneficio de las alternativas y, si se requiere, hace
recomendaciones. Si la administracin acepta una de las recomendaciones, el anlisis
contina por esa va. Cada problema de sistemas es nico, por lo que nunca hay slo una
solucin correcta. La manera en que se formule una recomendacin o solucin depende de las

13

cualidades individuales y la capacitacin profesional de cada analista, y de su interaccin con

los usuarios en el contexto de su entorno laboral.
(Kendall, K, & J, 2011, pgs. 10,11)

Organizacin de la propuesta de sistemas Aunque el propsito de los estatutos del proyecto es

identificar los objetos, determinar el alcance y asignar responsabilidades, el analista tambin
necesita preparar una propuesta de sistemas en la que se incluya la mayor cantidad de detalles
sobre las necesidades, opciones y recomendaciones del sistema. En esta seccin veremos el
contenido y el estilo que se utilizan para formular una propuesta de sistemas. En la propuesta
de sistemas debemos incluir una carta de presentacin para los gerentes y la fuerza de trabajo
de TI. Esta carta debe enlistar a las personas que hicieron el estudio e incluir un resumen de
los objetivos del mismo. La carta de presentacin debe ser concisa y amigable. (Kendall, K, &
J, 2011, pg. 88)
Segn la Gua del PMBOK El Enunciado del Trabajo del Proyecto es una descripcin
narrativa de los productos y resultados que debe entregar el proyecto (PMI, 2013, pg. 68).
El caso de negocio o documento similar proporciona la informacin necesaria desde una
perspectiva de negocio para determinar si el proyecto es viable o no en trminos de la
inversin requerida. Normalmente se utiliza para la toma de decisiones por parte de la
direccin o ejecutivos de un nivel superior al del proyecto. Normalmente, necesidad de
negocio y anlisis costo-beneficio se incluyen en el caso de negocio para justificar y
establecer los lmites del proyecto y el anlisis se suele llevar a cabo por un analista de
negocio sobre la base de las diversas aportaciones de los interesados. El patrocinador debera
estar de acuerdo con el alcance y las limitaciones del caso de negocio.
(PMI, 2013, pg. 69)
El plan de gestin de la calidad puede ser formal o informal, detallado o formulado de manera
general. El estilo y el grado de detalle del plan de gestin de la calidad se determinan en
funcin de los requisitos del proyecto. Se debera revisar el plan de gestin de la calidad en

14

una etapa temprana del proyecto para asegurar que las decisiones estn basadas en
informacin exacta. Entre los beneficios de esta revisin se pueden incluir el obtener un
enfoque ms claro sobre la propuesta de valor del proyecto, as como la reduccin de costos y
de la frecuencia con que se retrasa el cronograma.
(PMI, 2013, pg. 241)
Una vez que el analista determina objetivos razonables para un proyecto, necesita determinar
si es posible que la organizacin y sus miembros puedan ver el proyecto hasta su terminacin.
Por lo general, el proceso de evaluacin de la viabilidad es efectivo para descartar proyectos
inconsistentes con los objetivos de la empresa, que requieran una capacidad tcnica imposible
o que no tengan ningn mrito econmico.
(Kendall, K, & J, 2011, pg. 62)
El analista debe averiguar si es posible desarrollar el nuevo sistema teniendo en cuenta los
recursos tcnicos actuales. De no ser as, se puede actualizar o complementar el sistema de
tal forma que pueda cumplir con lo que se requiere? Si no es posible complementar o
actualizar los sistemas existentes, la siguiente pregunta es si existe o no la tecnologa que
cumpla con las especificaciones.
(Kendall, K, & J, 2011, pg. 63)

1.2.3. Seleccin y Evaluacin de personal

Es necesario que el analista y los usuarios de la empresa se comprometan con la calidad lo

antes posible para lograr el objetivo de sta. Este compromiso se ejerce como resultado de un
esfuerzo de ritmo uniforme hacia la calidad en todo el ciclo de vida de desarrollo de sistemas;
adems supone un fuerte contraste con el hecho de tener que invertir mucho esfuerzo para
resolver los problemas al final del proyecto.
Para lograr el apoyo de la organizacin en relacin con la calidad en los sistemas de
informacin administrativos, debemos proveer tiempo laboral para los crculos de calidad de
sistemas de informacin (IS), que consisten en seis a ocho colegas de la organizacin, cada

15

uno con la responsabilidad especfica de definir cmo mejorar los sistemas de informacin y
cmo implementar las mejoras.
(Kendall, K, & J, 2011, pg. 516)

El equipo del proyecto incluye al director del proyecto y al grupo de individuos que actan
conjuntamente en la realizacin del trabajo del proyecto para alcanzar sus objetivos. El equipo
del proyecto incluye al director del proyecto, al personal de direccin del proyecto y a otros
miembros del equipo que desarrollan el trabajo, pero que no necesariamente participan en la
direccin del proyecto. Este equipo est compuesto por individuos procedentes de diferentes
grupos, con conocimientos en una materia especfica o con un conjunto de habilidades
especficas para llevar a cabo el trabajo del proyecto. La estructura y las caractersticas de un
equipo de proyecto pueden variar ampliamente, pero una constante es el rol del director del
proyecto como lder del equipo, independientemente de la autoridad que ste pueda tener
sobre sus miembros.
(PMI, 2013, pg. 35)
Los equipos de proyecto incluyen roles tales como:

Personal de direccin de proyectos. Son los miembros del equipo que realizan actividades de
direccin del proyecto tales como elaboracin del cronograma, preparacin del presupuesto,
presentacin de informes y control, comunicaciones, gestin de riesgos y apoyo
administrativo. Este rol puede ser realizado o apoyado por una oficina de direccin de

proyectos (PMO).
Personal del proyecto. Son los miembros del equipo que llevan a cabo el trabajo de crear los

entregables del proyecto.

Expertos de apoyo. Los expertos de apoyo realizan actividades requeridas para desarrollar o
ejecutar el plan para la direccin del proyecto. stas pueden incluir roles tales como
contratacin, gestin financiera, logstica, asuntos legales, seguridad, ingeniera, pruebas o
control de calidad.

16

Dependiendo del tamao del proyecto y del nivel de apoyo requerido, los expertos de apoyo
pueden asignarse para trabajar a tiempo completo o simplemente participar en el equipo
cuando se requieren sus habilidades especficas.

Los socios de negocio son tambin compaas externas, pero tienen una relacin especial con
la empresa, obtenida en ocasiones mediante un proceso de certificacin. Los socios de
negocios proporcionan experiencia especializada o desempean un rol especfico, tales como
una instalacin, personalizacin, capacitacin o apoyo.
(PMI, 2013, pg. 36)
Las composiciones de equipos de proyecto dedicados y a tiempo parciales pueden existir bajo
cualquier estructura organizacional. Los equipos de proyecto dedicados son comunes en las
organizaciones orientadas a proyectos, donde la mayor parte de los recursos de la
organizacin participa en el trabajo de los proyectos y los directores de proyectos tienen un
alto grado de

independencia y autoridad. Los equipos de proyecto a tiempo parcial son

comunes en organizaciones funcionales, mientras que las organizaciones matriciales utilizan

equipos de proyecto tanto dedicados como a tiempo parciales. Otros miembros que tienen una
participacin limitada en diversas etapas de un proyecto pueden considerarse como miembros
del equipo del proyecto a tiempo parcial.
(PMI, 2013, pg. 37)

1.2.4. Supervisin y Revisin del proyecto

Segn (Kendall, K, & J, 2011) Una vez que el analista ha diseado y codificado el sistema, la
prueba, mantenimiento y auditora de ste son las consideraciones primordiales (pg. 526).
Aunque el proceso de prueba es tedioso, es una serie esencial de pasos que ayudan a asegurar
la calidad del sistema eventual. Es mucho menos perjudicial evaluar con anticipacin a tener
un sistema probado en forma incorrecta que falle despus de su instalacin. Las pruebas se

17

realizan en los subsistemas o mdulos del programa a medida que avanza su desarrollo. El
proceso de prueba se lleva a cabo en muchos niveles, a diversos intervalos. Antes de poner el
sistema en produccin hay que realizar una verificacin de escritorio de todos los programas,
comprobarlos con datos de prueba y comprobar que los mdulos funcionen en conjunto como
se haba planeado.
Tambin hay que probar el sistema como un todo funcional. Aqu se incluye la prueba de las
interfaces entre los subsistemas, la exactitud de la salida, adems de la utilidad y
comprensibilidad de la documentacin y salida del sistema.
(Kendall, K, & J, 2011, pg. 526)
Al concluir de manera satisfactoria las pruebas de vnculos, se debe probar el sistema como
una entidad completa. En esta etapa, los operadores y usuarios finales se involucran de
manera activa en la prueba. Aqu se utilizan los datos de prueba creados por el equipo de
anlisis de sistemas con el propsito especfico de probar los objetivos del sistema.
Como es de esperarse, hay varios factores a considerar a la hora de probar sistemas con datos
de prueba:

Examinar si los operadores tienen la documentacin adecuada en los manuales de

procedimiento (impresos o en lnea) para lograr una operacin correcta y eficiente.

Verificar si los manuales de procedimientos son lo bastante claros para comunicar la forma en
que se deben preparar los datos para la entrada.
(Kendall, K, & J, 2011, pg. 527)
La auditora es otra forma de asegurar la calidad de la informacin que contiene el sistema. En
trminos generales, la auditora se refiere al proceso de hacer que un experto que no est
involucrado en el proceso de establecer o usar un sistema examine la informacin para evaluar
su confiabilidad. Sin importar que la informacin resulte confiable o no, el hallazgo sobre su
confiabilidad se comunica a los dems con el fin de que acten en consecuencia. Para los
sistemas de informacin, en general hay dos tipos de auditores: internos y externos. El hecho
de determinar si ambos son necesarios para el sistema que usted disee depender del tipo de
sistema. Los auditores internos trabajan para la misma organizacin que posee el sistema de

18

informacin, mientras que los auditores externos (tambin llamados independientes) se

contratan del exterior.
Los auditores externos se utilizan cuando el sistema de informacin procesa datos que
influyen en los estados financieros de la empresa; los externos realizan una auditora sobre el
sistema para asegurar la imparcialidad de los estados financieros que se producen. Tambin se
pueden usar cuando ocurre algo fuera de lo normal en el que hay empleados de la empresa
involucrados, como una sospecha de fraude por computadora o malversacin de fondos.
Los auditores internos estudian los controles que se utilizan en el sistema de informacin para
asegurarse de que sean adecuados y que estn realizando la funcin esperada. Tambin
evalan la conveniencia de los controles de seguridad.
(Kendall, K, & J, 2011, pg. 529)
(Kendall, K, & J, 2011) Afirman que la capacitacin es un proceso educativo en el que
participan los analistas de sistemas con los usuarios. El usuario se ha involucrado en todo el ciclo
de vida de desarrollo de sistemas (pg. 536).
Segn Gua del PMBOK una oficina de direccin de proyectos es una estructura de gestin
que estandariza los procesos de gobierno relacionados con el proyecto y hace ms fcil compartir
recursos, metodologas, herramientas y tcnicas (PMI, 2013, pg. 11).
Las responsabilidades de una PMO pueden abarcar desde el suministro de funciones de
soporte para la direccin de proyectos hasta la responsabilidad de la propia direccin de uno o
ms proyectos. La PMO integra los datos y la informacin de los proyectos estratgicos
corporativos y evala hasta qu punto se cumplen los objetivos estratgicos de alto nivel. La
PMO constituye el vnculo natural entre los portafolios, programas y proyectos de la
organizacin y los sistemas de medida corporativos.
(PMI, 2013, pg. 11)
Una PMO puede tener la autoridad para actuar como un interesado integral y tomar decisiones
clave a lo largo de la vida de cada proyecto, hacer recomendaciones, poner fin a proyectos o
tomar otras medidas, segn sea necesario, a fin de mantenerlos alineados con los objetivos de

19

negocio. Asimismo, la PMO puede participar en la seleccin, gestin e utilizacin de recursos

de proyectos compartidos o dedicados.
(PMI, 2013, pg. 11)
Una funcin fundamental de una PMO es brindar apoyo a los directores del proyecto de
diferentes formas, que pueden incluir, entre otras:

Gestionar recursos compartidos a travs de todos los proyectos dirigidos por la PMO;
Identificar y desarrollar una metodologa, mejores prcticas y estndares para la direccin de

proyectos;
Entrenar, orientar, capacitar y supervisar;
Monitorear el cumplimiento de los estndares, polticas, procedimientos y plantillas de la

direccin de proyectos mediante auditoras de proyectos;

Desarrollar y gestionar polticas, procedimientos, plantillas y otra documentacin compartida
de los proyectos (activos de los procesos de la organizacin); y Coordinar la comunicacin
entre proyectos.
(PMI, 2013, pg. 11)
Los directores de proyecto y las PMOs persiguen objetivos diferentes y, por lo tanto,

responden a necesidades diferentes. Todos estos esfuerzos estn alineados con las necesidades
estratgicas de la organizacin. A continuacin se relacionan algunas de las diferencias entre los
roles de directores de proyecto y PMO:

El director del proyecto se concentra en los objetivos especficos del proyecto, mientras que la
PMO gestiona los cambios significativos relativos al alcance del programa, que pueden

considerarse como oportunidades potenciales para alcanzar mejor los objetivos de negocio.
El director del proyecto controla los recursos asignados al proyecto a fin de cumplir mejor con
los objetivos del mismo, mientras que la PMO optimiza el uso de los recursos de la
organizacin compartidos entre todos los proyectos.
El director del proyecto gestiona las restricciones (alcance, cronograma, costo, calidad, etc.)
de los proyectos individuales, mientras que la PMO gestiona las metodologas, estndares,
riesgos y oportunidades globales, mtricas e interdependencias entre proyectos a nivel de
empresa.

20

(PMI, 2013, pg. 12)

1.2.5. Informes

Segn (Kendall, K, & J, 2011) existen diferentes tcnicas para usar, que depende con el que
la organizacin se identifique para redactar su informe (pg. 526)

Sea compatible con la documentacin existente.

Sea comprendida por los dems en la organizacin.
Le permita regresar a trabajar en el sistema despus de haber estado alejado durante un

periodo de tiempo.
Sea adecuada para el tamao del sistema en el que est trabajando.
Permita una metodologa de diseo estructurado, si eso se considera ms importante que otros
factores.
(Kendall, K, & J, 2011, pg. 526)
Es posible producir informes del anlisis mediante el uso de la informacin del repositorio
para mostrar en qu partes est incompleto el diseo o dnde hay errores. Las herramientas
CASE superiores tambin ayudan a sustentar el modelado de los requerimientos funcionales
de una organizacin, auxiliar a los analistas y usuarios para dibujar los lmites de un proyecto
dado y ayudarlos a visualizar la forma en que el proyecto encaja con otras partes de la
organizacin.
Algunos analistas marcan la diferencia entre las herramientas CASE superiores e inferiores.
Una herramienta CASE superior permite al analista crear y modificar el diseo del sistema.
Toda la informacin sobre el proyecto se almacena en una enciclopedia conocida como
repositorio CASE, una extensa coleccin de registros, elementos, diagramas, pantallas,
informes y dems informacin relacionada.
(Kendall, K, & J, 2011, pg. 14)
Copiar informes, acaparar el valioso tiempo de los empleados y duplicar encuestas intiles
representara un gran gasto innecesario. El muestreo ayuda a acelerar el proceso mediante la

21

recopilacin de datos seleccionados, en vez de recopilar todos los datos de toda la poblacin.
Adems, el analista de sistemas se evita la molestia de tener que analizar los datos de toda la
poblacin. La efectividad en la recopilacin de los datos tambin es un factor importante. El
muestreo ayuda a mejorar la efectividad si se permite obtener informacin ms precisa.
(Kendall, K, & J, 2011, pg. 132)
A medida que el analista de sistemas trabaja para entender a los usuarios, su organizacin y
sus requerimientos de informacin, debe examinar los distintos tipos de datos duros que
ofrecen informacin no disponible por cualquier otro medio de recopilacin. Estos datos
revelan dnde ha estado la organizacin y hacia dnde creen sus miembros que se dirige. Para
formarse una imagen precisa, el analista necesita examinar datos tanto cuantitativos como
cualitativos.
(Kendall, K, & J, 2011, pg. 136)
Informes para la toma de decisiones
Los informes de produccin incluyen los costos recientes, el inventario actual, la mano de
obra reciente y la informacin de la planta (Kendall, K, & J, 2011, pg. 136).
Adems de estos informes clave, los encargados de tomar las decisiones utilizan muchos
informes sintetizados para proveer informacin de apoyo, detectar las excepciones a las
ocurrencias normales y obtener vistas generales estratgicas de los planes de la organizacin
(Kendall, K, & J, 2011, pg. 136).
Informes de rendimiento
Consisten en una comparacin entre el rendimiento actual y el esperado. Una funcin
importante de ellos es medir la brecha entre el rendimiento actual y el esperado (Kendall, K, &
J, 2011, pg. 136).
El Grupo de Procesos de Monitoreo y Control est compuesto por aquellos procesos
requeridos para rastrear, analizar y dirigir el progreso y el desempeo del proyecto, para
identificar reas en las que el plan requiera cambios y para iniciar los cambios correspondientes.
El beneficio clave de este Grupo de Procesos radica en que el desempeo del proyecto se mide y

22

se analiza a intervalos regulares, y tambin como consecuencia de eventos adecuados o de

determinadas condiciones de excepcin, a fin de identificar variaciones respecto del plan para la
direccin del proyecto. El Grupo de Procesos de Monitoreo y Control tambin implica:

Controlar los cambios y recomendar acciones correctivas o preventivas para anticipar posibles

problemas,
Monitorear las actividades del proyecto, comparndolas con el plan para la direccin del
proyecto y con la lnea base para la medicin del desempeo del proyecto, e
Influir en los factores que podran eludir el control integrado de cambios o la gestin de la
configuracin, de modo que nicamente se implementen cambios aprobados.
(PMI, 2013, pg. 57)

1.3 Fundamentos de P.M.I.

Este estndar describe la naturaleza de los procesos de la direccin de proyectos en

trminos de la integracin entre los mismos, sus interacciones y los propsitos a los cuales
sirven. Segn este estndar, se supone que el proyecto, el director del proyecto y el equipo del
proyecto se asignan a la organizacin ejecutante. Los procesos de la direccin de proyectos se
agrupan en cinco categoras conocidas como Grupos de Procesos de la Direccin de Proyectos
(o Grupos de Procesos):

Grupo de Procesos de Inicio. Consta de aquellos procesos realizados para definir un nuevo
proyecto o una nueva fase de un proyecto existente y obtiene la autorizacin para iniciar el

proyecto o fase.
Grupo de Procesos de Planificacin. Consta de aquellos procesos requeridos para establecer el
alcance del proyecto, refinar los objetivos y definir el curso de accin necesario para alcanzar

los objetivos para cuyo logro se emprendi el proyecto.

Grupo de Procesos de Ejecucin. Consta de aquellos procesos realizados para completar el
trabajo definido en el plan para la direccin del proyecto a fin de cumplir con las
especificaciones del mismo.

23

Grupo de Procesos de Monitoreo y Control. Consta de aquellos procesos requeridos para

monitorear, analizar y regular el progreso y el desempeo del proyecto, para identificar reas

en las que el plan requiera cambios y para iniciar los cambios correspondientes.
Grupo de Procesos de Cierre. Consta de aquellos procesos realizados para finalizar todas las
actividades a travs de todos los Grupos de Procesos, a fin de cerrar formalmente el proyecto
o una fase del mismo.
(PMI, 2013, pg. 418)
La gua establece la direccin que deber llevar el proyecto, de manera consistente mediante

estndares se establecen las reglas para obtener la creacin de un proyecto aceptable.

El Lxico de Trminos de Direccin de Proyectos del PMI

proporciona el vocabulario

profesional de base que puede ser utilizado de manera consistente por directores de proyecto,
directores de programa, directores de portafolios y otros interesados.
Lxico de Trminos de Direccin de Proyectos del PMI y armonizan con otros estndares del
PMI, se han establecido reglas de negocio que se han respetado en la actualizacin de la
Quinta Edicin.
Cuando los trminos utilizados en la Gua del PMBOK no estn presentes en el Lxico del
PMI pero s lo estn en otros estndares relevantes del PMI, la definicin de los trminos
deber ser la misma. Si las definiciones no estn en lnea con los respectivos estndares, el
trmino es elevado al equipo del Lxico del PMI a fin de obtener asistencia para la creacin
de una definicin comn aceptable.
(PMI, 2013, pg. 465)

24

Captulo 2: Calidad de Software

2.1 La gestin de proyectos usando un marco de calidad

La calidad del software se ha mejorado significativamente. Una de las razones ha sido que las

compaas han adoptado nuevas tcnicas y tecnologas como el uso de desarrollo orientado a
objetos y el soporte asociado de herramientas CASE.
Ha habido una mayor conciencia de la importancia de la gestin de la calidad y de la
adopcin de tcnicas de gestin de la calidad para desarrollo en la industria del software
(Sommerville, 2005, pg. 588).
Con el objetivo de establecer formas estndares en las prcticas y activos de desarrollo
aparecieron a lo largo de los aos distintas normas y modelos de referencia. Los llamamos as
porque constituyen la referencia al momento de implementar una mejora de procesos en una
organizacin con el objetivo de aumentar la calidad de procesos y productos generados. Un
fin para el cual se han utilizado estos modelos ha sido la calificacin, clasificacin y
comparacin de empresas por parte de los compradores de productos de software.
(Pantaleo, 2011, pg. 19)
Mientras estndares y procedimientos son las bases de la gestin de la calidad, los gestores
de calidad experimentados reconocen que hay aspectos intangibles en la calidad del software
(elegancia, legibilidad, etc.) que no puede ser incorporada en los estndares. Ellos ayudan a la
gente interesada en estos aspectos intangibles de calidad y fomentan comportamientos
profesionales en todos los miembros del equipo.
La gestin formal de la calidad es particularmente importante para equipos que desarrollan
sistemas grandes y complejos. La documentacin de la calidad es un registro de que es hecho
por cada subgrupo en el proyecto. Esto ayuda a la gente a ver qu tareas importantes no deben
ser olvidadas o que una parte del equipo no haga suposiciones incorrectas acerca de lo que
otros miembros han hecho. La documentacin de calidad es tambin un medio de

25

comunicacin sobre el ciclo de vida de un sistema. Esta permite al grupo responsabilizarse de

la evolucin del sistema para saber qu ha hecho el equipo de desarrollo.
(Sommerville, 2005, pg. 588)
La clave de la calidad en el desarrollo de sistemas pequeos es el establecimiento de cultura
de calidad y asegurarse de que todos los miembros del equipo hacen una aproximacin positiva a
la calidad del software.
La gestin de calidad del software se estructura en tres actividades principales:

Garanta de la calidad. El establecimiento de un marco de trabajo de procedimientos y

estndares organizacionales que conduce a software de alta calidad.

Planificacin de la calidad. La seleccin de procedimientos y estndares adecuados a partir de

este marco de trabajo y la adaptacin de stos para un proyecto software especfico.

Control de la calidad. La definicin y fomento de los procesos que garanticen que los
procedimientos y estndares para la calidad del proyecto son seguidos por el equipo de
desarrollo de software.
La gestin de la calidad provee una comprobacin independiente de los procesos de desarrollo
software. Los procesos de gestin de la calidad comprueban las entregas del proyecto para
asegurarse que concuerdan con los estndares y metas organizacionales.
(Sommerville, 2005, pg. 589)
El equipo de calidad no est asociado con ningn grupo de desarrollo, sino que tiene la

responsabilidad de la gestin de la calidad en toda la organizacin (Sommerville, 2005, pg.

589).

2.2 Estndares y Mtricas de calidad en la ingeniera de SW

26

Las mtricas de calidad del producto son de gran valor para resaltar tos componentes
anmalos que tienen problemas de calidad. Estos componentes se debern analizar con ms
detalle (Sommerville, 2005, pg. 605).
Una mtrica es una cantidad insignificante que puede extraerse de algn documento o cdigo
dentro de un proyecto de software (Pressman, 2002, pg. 17).
La recopilacin de mtricas de calidad permite a una organizacin sintonizar su proceso de
ingeniera del software para eliminar las causas poco vitales de los defectos que tienen el mayor
impacto en el desarrollo del software (Pressman, 2002, pg. 66).
Una mtrica de prueba puede usarse para determinar cundo finalizar la prueba de un
elemento del cdigo. Una mtrica de legibilidad puede usarse para juzgar la legibilidad de algn
documento en lenguaje natural.
Una mtrica de comprensin del programa puede utilizarse para proporcionar algn umbral
numrico que los programadores no pueden cruzar. Para que estas mtricas alcancen este nivel
es necesario que todos los componentes del nivel 3 CMM, en castellano MCM (Modelo de
Capacidad de Madurez), estn conseguidos, por ejemplo notaciones bien definidas para
actividades como la especificacin del diseo de requisitos, por lo que estas mtricas pueden
ser fcilmente extradas de modo automtico.
(Pressman, 2002, pg. 17)
Las mtricas de la calidad del software, como mtricas de productividad, se centran en el
proceso, en el proyecto y en el producto. Desarrollando y analizando una lnea base de
mtricas de calidad, una organizacin puede actuar con objeto de corregir esas reas de
proceso del software que son la causa de los defectos del software.
La medicin produce cambios culturales. La recopilacin de datos, el clculo de mtricas y
la evaluacin de mtricas son los tres pasos que deben implementarse al comenzar un
programa de mtricas. En general, un enfoque orientado a los objetivos ayuda a una
organizacin a centrarse en las mtricas adecuadas para su negocio.
(Pressman, 2002, pgs. 74-75)

27

Ilustracin 1 Factores y mtricas de calidad.

2.2.1 PSP y TSP
El proceso personal de software PSP se concentra en las prcticas de trabajo de los ingenieros
en una forma individual.
Sirve para producir software de calidad, cada ingeniero debe trabajar en la necesidad de
realizar trabajo de calidad. PSP se dise para ayudar a profesionales del software para que
utilicen constantemente prcticas sanas de ingeniera de software.

28

(SEI, 2000)
Asimismo les ensea a cmo planear y darle un seguimiento a su trabajo, a utilizar un
proceso bien definido y medido, a establecer metas mesurables, y finalmente a la utilizacin
del rastreo constante para alcanzar dichas metas. PSP les demuestra a los ingenieros a cmo
manejar la calidad desde el principio del trabajo, a cmo analizar los resultados de cada
trabajo, y a cmo utilizar los resultados para mejorar el proceso del proyecto siguiente.
La importancia de los datos en PSP
Uno de los aspectos fundamentales de PSP es el uso de datos histricos para analizar y
mejorar el desempeo del proceso. La recoleccin de datos para PSP es soportada por cuatro
elementos importantes:

Guiones.

Mtricas.

Estndares.

Formatos.
(SEI, 2000)

Los guiones de PSP proveen una gua de nivel experto para seguir los pasos del proceso,
los guiones proveen un marco de trabajo para aplicar las mediciones. En PSP hay cuatro
mediciones esenciales:

Tamao: el tamao de una parte del producto, medido en lneas de cdigo (LOC) o piezas de

software equivalentes que facilitan la medicin.

Esfuerzo: el tiempo requerido para cumplir una tarea, se suele medir en minutos.

29

Calidad: la cantidad de defectos en el producto.

Agenda: una medicin de progresin del proyecto, comparacin de lo planeado contra las
fechas de cumplimiento actuales.
La aplicacin de estndares al proceso puede asegurar que los datos sean precisos y
consistentes. Los datos son registrados en formatos, frecuentemente son registrados en
aplicaciones para medir PSP.
(SEI, 2000)
El diseo de PSP se basa en los siguientes principios de planeacin y de calidad

Cada ingeniero es esencialmente diferente; para ser ms precisos, los ingenieros deben

planear su trabajo y basar sus planes en sus propios datos personales.

Para mejorar constantemente su funcionamiento, los ingenieros deben utilizar personalmente

procesos bien definidos y medidos.

Para desarrollar productos de calidad, los ingenieros deben sentirse personalmente

comprometidos con la calidad de sus productos.

Cuesta menos encontrar y arreglar errores en la etapa inicial del proyecto que encontrarlos en

las etapas subsecuentes.

Es ms eficiente prevenir defectos que encontrarlos y arreglarlos.
La manera correcta de hacer las cosas es siempre la manera ms rpida y ms barata de hacer
un trabajo.
(SEI, 2000)

La disciplina del PSP provee un marco estructurado para desarrollar habilidades personales y
mtodos que se necesitarn ms adelante para ir forjando al ingeniero de software. Es
importante que la calidad del software desarrollado abarque hasta el ms mnimo detalle, por
muy pequeo que ste sea, ya que si no se hace as, puede daar el sistema entero.
(SEI, 2000)

30

Ilustracin 2 Evolucin del proceso personal de software

La ilustracin 2 muestra un diagrama que contiene todos los niveles de PSP. As mismo se
muestra que cada nivel cuenta con sus propios requerimientos (SEI, 2000).

31

Ilustracin 3 Elementos de PSP en CMM

Los ingenieros de software se estn dedicando a mejorar continuamente los procesos futuros
sin dejar de lado todos los registros que PSP (SEI, 2000).
Los mtodos de la ingeniera de software pueden variar desde predictivos hasta adaptativos.
PSP es una metodologa predictiva, desarrollo gil es considerada una metodologa adaptiva,
pero a pesar de sus diferencias, TSP/PSP y desarrollo gil comparten varios conceptos
aproximaciones, particularmente en cuanto a la organizacin del equipo. Con ambos es
posible:

32

Definir sus metas y estndares.

Estimar y agendar el trabajo.
Determinar agendas realistas y alcanzables.
Realizar planes y procesos de mejora.
Desarrollo gil y TSP/PSP comparten la idea que los miembros del equipo se responsabilicen
por su propio trabajo y trabajen juntos para acordar un plan realista, crear un ambiente de
confianza y responsabilidad. Sin embargo, el TSP/PSP se diferencia del desarrollo gil en su
nfasis en la documentacin del proceso y el uso de datos para predecir y definir la agenda del
proyecto.
(PSP/TSP, 2005)
En combinacin con el Personal Software Process (PSP), el llamado Team Software Process
(TSP) proporciona un marco de trabajo de procesos definidos que est diseado para ayudarle
a equipos de gerentes e ingenieros a organizar y producir proyectos de software de gran
escala, que tengan tamaos mayores a varios miles de lneas de cdigo. El objetivo del TSP es
mejorar los niveles de calidad y productividad de un proyecto de desarrollo de software de un
equipo, con el fin de ayudarlos a alcanzar los acuerdos de costos y tiempos en dicho
desarrollo.
(PSP/TSP, 2005)

2.2 CMM

33

A mediados de los 80, el SEI inici un estudio de las formas de evaluar las capacidades de
los proveedores de software. El resultado de estos estudios fue el Modelo de Madurez de la
Capacidad de Software del SEI (Sommerville, 2005, pg. 620).
Con el se busc establecer estndares de organizaciones. La utilizacin inteligente de este
modelo contribuy a mejorar los productos de software, mientras que el mal uso gener
frustraciones y despilfarro de recursos. En la dcada de 1990 el modelo CMM (Capability
Maturity Model) se convirti en el estndar de hecho a nivel global. Ms tarde, en la dcada
de 2000, fue reemplazado por su versin mejorada CMMi (Capability Maturity Model
Integration).
(Pantaleo, 2011, pg. 19)
El Software Engineering Institute (SEI) lleva a cabo un programa a largo plazo, de mejora
del proceso del software. Parte de este programa es el Modelo de Madurez de la Capacidad
(CMM) para el proceso del software (Sommerville, 2005, pg. 558).
Al modelo CMM de software lo siguieron otros modelos de capacidad de madurez, entre ellos
el Modelo de Madurez de la Capacidad de Personal (Curts, 2001)

Ilustracin 4 Estructura de CMM

34

La comunidad informtica opt por elegir el modelo de referencia CMM que se convirti en
el estndar del mercado de desarrollo de software de los aos 90 y su versin perfeccionada y
aumentada CMMi en el ao 2000 (Pantaleo, 2011, pg. 150).
Segn (Pantaleo) CMMi es un modelo de capacidad y madurez. Posee dos vistas que
permiten un enfoque diferente segn las necesidades de quien vaya a implementarlo. Una
estructurada en cinco niveles de madurez y otra en seis de capacidad (2011, pg. 151)
Los niveles de madurez indican cmo se desempea una organizacin en base a la capacidad
y madurez en un conjunto de reas de proceso. El nivel de madurez uno (ML1) indica que los
procesos no se realizan, lo que significa que los proyectos se desarrollan de manera
impredecible y descontrolada. Los niveles de madurez aumentan hasta el nivel de madurez
cinco (ML 5), en el que los proyectos se desarrollan de una forma cuantitativamente definida
para la organizacin y mejorando continuamente.
El modelo est compuesto por los siguientes componentes: objetivos, prcticas y subprcticas.

Los objetivos son componentes requeridos, es decir que al momento de evaluar a una
organizacin deben estar satisfechos. Estos objetivos son de dos tipos: especficos, por rea de

proceso, y genricos, relacionados a la institucionalizacin.

Las prcticas son esperadas, es decir que si se alcanzaron los objetivos se espera contar con
las prcticas que lo hicieron posible. Estas prcticas son especficas, asociadas a los objetivos

especficos, y genricas, asociadas a los objetivos genricos.

Las subprcticas son componentes informativos que ayudan a la interpretacin e
implementacin de las prcticas. Estas estn constituidas por los activos de trabajo y las
distintas disciplinas.
(Pantaleo, 2011, pg. 158)

35

Ilustracin 5 Esquema del modelo CMMi

Los resultados no fueron tan frustrantes ni tuvieron un impacto tan importante para aquellas
organizaciones que eligieron ISO en lugar de CMMi. Sin embargo debemos hacer notar que la
norma y el modelo resultan incomparables, ya que fueron pensados para objetivos diferentes.
En definitiva, CMMi es un modelo bien pensado por gente que conoce acerca del desarrollo
de software, pero muy mal utilizado por una gran cantidad de personas que desconocen acerca
de este tema.
(Pantaleo, 2011, pg. 158)

36

2.2.3 MOPROSOFT

Segn (Pantaleo) MOPROSOFT (Modelo de Procesos para la Industria del Software),

concebido en Mxico, con el objetivo de ser aplicado a las pequeas y medianas empresas
dedicadas al desarrollo de software (2011, pg. 24).
Est inspirado en los niveles 2 y 3 del modelo CMM y en las normas ISO/IEC 15504.
Algunos de los criterios con los que fue elaborado este modelo son los siguientes:

Procesos estratificados segn el organigrama tpico de este tipo de organizaciones (gerencia

alta, gerencia media y operacin).

La gerencia alta tiene como actividades centrales la de definir las estrategias de la

organizacin y promover las mejoras continuas.

La gerencia media es la encargada de proveer los recursos para los proyectos y monitorear el

cumplimiento de las planificaciones orientadas a cumplir con los objetivos estratgicos.

La operacin es la encargada de llevar adelante los proyectos. Los procesos deben ser

definidos de tal forma que mantengan entre ellos una relacin integradora.
El proceso de administracin de proyectos es atmico.
La ingeniera de productos es desarrollada con el soporte de otros procesos orientados a
garantizar y controlar la calidad de los mismos (verificacin, validacin, documentacin y

control de la documentacin).
Se le asigna especial atencin a la administracin de los recursos que aportan al conocimiento
de la organizacin: productos generados por proyectos, mediciones, documentacin de
procesos y datos relevados de su implementacin en los proyectos as como lecciones
aprendidas.
(Pantaleo, 2011, pg. 24)

Categora alta direccin (DIR)

37

Comprende la definicin de las polticas, los objetivos de negocio y las estrategias para su
logro incorporando la informacin de la evolucin de la organizacin a efectos de promover la
mejora continua.

Gestin de Negocio: establecer la visin y los objetivos de negocio que fijen el contexto para
las actividades de la gerencia media y los proyectos.
(Pantaleo, 2011, pg. 24)

Categora Gerencia (GER)

Comprende la gestin de los procesos, proyectos y recursos de la organizacin de manera
alineada con las polticas definidas por la gerencia alta. Informa a la gerencia alta acerca de la
evolucin de la organizacin.

Gestin de Procesos: promover la definicin e implementacin de los procesos de la

organizacin a partir de las necesidades expresadas por el plan estratgico. Coordinar y

colaborar en la mejora de los procesos definidos.

Gestin de Recursos: Administrar los recursos de la organizacin proveyendo a los proyectos.
Promover y facilitar la administracin del capital de conocimiento de la organizacin.

(Pantaleo, 2011, pg. 25)

Categora operacin (OPE)
Comprende las prcticas de gestin y tcnicas de los proyectos de desarrollo.

Administracin de proyectos especficos: estimar, planificar y monitorear el desarrollo de los

proyectos de desarrollo y la generacin de los productos esperados.
Desarrollo y mantenimiento de software: desarrollo de las actividades del ciclo de vida de

productos nuevos o modificados (anlisis, diseo, construccin, integracin y pruebas) alineadas

con los requerimientos del proyecto.
(Pantaleo, 2011, pg. 26)

2.3 Impacto de la calidad en tiempo, costo y alcance del proyecto

38

En el desarrollo software, por lo tanto, la relacin entre la calidad del proceso y la calidad del
producto es muy compleja. Es difcil de medir los atributos de la calidad del software, como
mantenibilidad, incluso despus de utilizar el software durante un largo periodo. En
consecuencia, es difcil explicar cmo influyen las caractersticas del proceso en estos
atributos.

Ilustracin 6 Procesos de calidad

Adems debido al papel del diseo y la creatividad en el proceso software, no podremos
predecir la influencia de los cambios en el proceso en la calidad del producto. A pesar de ello,
la experiencia nos muestra que la calidad del proceso tiene una influencia significativa en la
calidad del software. La gestin y mejora de la calidad del proceso debe minimizar los
defectos en el software entregado.
La gestin de la calidad del proceso implica:

Definir estndares de proceso, como las revisiones a realizar, cundo llevarlas a cabo,

etctera.
Supervisar el proceso de desarrollo para asegurar que se sigan los estndares.
Hacer informes del proceso para el gestor del proyecto y para el comprador del software.
(Sommerville, 2005, pg. 590)

Existen situaciones en las que el equipo de gestin de calidad sugiere que este prototipo no se
puede llevar a cabo debido a que su calidad no se puede supervisar. En tales situaciones, el

39

gestor principal debe intervenir para asegurar que el proceso de calidad ayude al desarrollo del
producto en lugar de impedirlo.

Ilustracin 7 Proceso de calidad

(Sommerville, 2005, pg. 590)

Las revisiones de la calidad son caras, consumen tiempo e inevitablemente retrasan la entrega
del software. Idealmente, sera posible acelerar el proceso de revisin utilizando herramientas
que procesaran el diseo del software o el programa, e hiciesen valoraciones automticas de la
calidad del software. Estas valoraciones permiten comprobar que el software tiene el umbral
de calidad requerido, y destacar las partes en las cuales no se ha alcanzado para revisarlas.
La medicin del software se refiere a derivar un valor numrico desde algn atributo del
software o del proceso software. Comparando estos valores entre s y con los estndares
aplicados en la organizacin, es posible sacar conclusiones de la calidad del software o de los
procesos para desarrollarlo.
(Sommerville, 2005, pg. 599)

40

Ilustracin 8 Medicin del software

La imagen de abajo muestra el proceso de medicin del software dentro de un proceso de
control de calidad. Cada uno de los componentes del sistema se analiza por separado y los
diversos valores de las mtricas se comparan entre s y, quizs, con los datos histricos de
medicin recogidos en los proyectos previos. Las medidas anmalas se utilizan para centrar.
(Sommerville, 2005, pg. 599)

Ilustracin 9 Procesos de medicin del software

41

Conclusin

42

Bibliografa
Curts, P.-C. (2001). Modelo de Madurez de la Capacidad de Personal.
Humphrey, W. (1996).
Introduction to the Team Software Proces. (s.f.).
Kendall, K, & J. (2011). Analisis y diseo de sistemas. Camden, New Jersey: Prentice
Hall, Pearson.
Pantaleo, G. (2011). Calidad del desarrollo de software. Alfaomega.
PMI. (2013). Proyect Managemente Institute. Newtown Square, Pensilvania.
Pressman, R. (2002). Ingeniera de Software, Un enfoque prctico. McGRAW-HIL.
Proyect Managemente Institute. (2013). PMI.
PSP/TSP. (2005). A Self-Improvement Process for Software Engineers.
SEI. (2000). Instituto de la Ingenieria de Software.
Sommerville, I. (2005). Ingeniera del Software. Madrid: PEARSON.