Universidad Abierta y a Distancia de

Mxico

Fundamentos de Administracin
Unidad 1

Autorreflexin: Etapas de la gestin de proyectos

en el desarrollo de software

Alumno: Julio Molina Carreo

Matrcula: AL12501614
Febrero, 2013
 2

Contenido
Presentacin........................................................................................................................ 3
I Ciclo de vida de un proyecto............................................................................................. 4
Inicio................................................................................................................................ 6
Planeacin........................................................................................................................ 6
Ejecucin.......................................................................................................................... 7
Monitoreo y control.......................................................................................................... 7
Cierre............................................................................................................................... 7
El CMMI............................................................................................................................ 8
II Procesos del software..................................................................................................... 12
III La administracin de proyectos de software.................................................................14
Planificacin y calendarizacin...................................................................................... 15
Administracin del riesgo............................................................................................... 16
Administracin de personal............................................................................................ 18
Administracin de los costos de software......................................................................20
Administracin de la calidad.......................................................................................... 21
IV El administrador del proyecto....................................................................................... 22
V Reflexin........................................................................................................................ 24
 3

Presentacin

Es poco probable encontrar proyectos que se hayan completado a tiempo, con la

calidad deseada y con el presupuesto planificado inicialmente; muchas veces se
llega a cumplir con uno o dos de ellos con mucho esfuerzo.
En la primera dcada del siglo XXI, las empresas que desarrollan software
requieren de personal calificado y certificado en la administracin de proyectos de
software. Sin embargo, la educacin formal tradicionalmente se ha centrado en
los aspectos tcnicos del software (formacin integral en el rea de desarrollo de
software) y ha dejado la adquisicin de las habilidades de la administracin de
proyectos a la escuela de la vida (participacin en proyectos hasta adquirir la
experiencia suficiente).
Existen varias instituciones educativas y algunas organizaciones civiles que han
desarrollado cursos para que las personas interesadas en ste tema, adquieran
las habilidades necesarias. A nivel internacional, la organizacin Project
Management Institute (PMI)1 es reconocida por promover la administracin de
proyectos como una carrera y por ofrecer el apoyo a nivel capacitacin y
certificacin. Para ello, el PMI ha creado diversos estndares entre ellos el
PMBOK Guide (Project Management Body of Knowledge), que es una gua que
contiene tcnicas y conocimientos para la administracin de casi todo tipo de
proyectos.
Por lo anterior, es importante comprender cules son los elementos que
conforman la administracin de proyectos y en particular cul es la relacin que
guarda con la administracin de proyectos de software.
Finalmente, es importante mantenerse actualizado tanto en las tcnicas de
desarrollo de software como en las tcnicas para la administracin de proyectos
de software. En Internet hay sitios que ofrecen informacin sobre calendarios de
cursos referentes a la administracin de proyectos, entre ellos:
http://www.liderdeproyecto.com

http://www.milestone.com.mx
Julio Molina Carreo

Mxico, febrero de 2013

1
Se puede visitar el sitio http://www.pmi.org para conocer ms sobre esta organizacin, fundada
en 1969 el PMI cuenta con diversos captulos entre ellos el PMI Captulo Mxico y se puede
visitar la pgina http://www.pmimexico.org para mayor informacin.
 4

I Ciclo de vida de un proyecto

Un proyecto es una secuencia bien definida de eventos con un principio y un
final identificados, que se centra en alcanzar un objetivo claro 2. Cada proyecto
crea un nico producto, servicio o resultado3.
Aunque de naturaleza temporal, los proyectos son un medio para el logro de las
metas y los planes estratgicos de una organizacin. Los proyectos son
autorizados como resultado de una o ms de las siguientes consideraciones 4:
Demanda del mercado.

Oportunidad estratgica.

Solicitud de un cliente.

Avance en la tecnologa.

Requisitos legales.

Los proyectos requieren de la administracin de proyectos, mientras que las

operaciones (que son actividades permanentes que producen salidas repetitivas,
es el da a da), requieren que la empresa se auxilie del proceso
administrativo, aunque en muchas ocasiones los proyectos pueden llegar a
coincidir con las operaciones de la empresa5.
Las organizaciones que ejecutan proyectos normalmente los dividen en varias
fases a fin de permitir una mejor administracin y un control adecuado. Existen
varios modelos entre ellos el que el PMI propone con las siguientes fases 6:
Inicio. Son aquellos procesos que se realizan para definir un nuevo
proyecto o una nueva fase de un proyecto ya existente por medio de la
autorizacin para el comienzo de la fase o del proyecto.
Planeacin. Son aquellos procesos que permiten establecer el alcance del
proyecto, refinar los objetivos y definir el curso de accin para alcanzar los
objetivos que el proyecto tiene comprometidos.
2
Colmenar, Antonio et al. Gestin de proyectos con Microsoft Project 2007. Alfaomega Grupo
Editor. Mxico. 2007. p. 29.
3
Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK
Guide). Cuarta edicin. Estados Unidos. 2008. p.5.
4
Idem. p. 10.
5
Idem. p. 12.
6
Idem. p. 6. Aunque tcnicamente este material integra cada una de las fases con procesos y es
as como los denomina: grupo de procesos; sin embargo se hace la aclaracin de que fases y
procesos son dos elementos conceptuales diferentes.
 5

Ejecucin. Son aquellos procesos realizados para completar el trabajo

definido en el plan de administracin del proyecto, para satisfacer las
especificaciones del proyecto.
Monitoreo y control. Son aquellos procesos requeridos para realizar el
seguimiento, revisar y regular el progreso y el desempeo del proyecto,
identificar las reas en las que los cambios en el plan son necesarios; e
iniciar los cambios correspondientes.
Cierre. Son aquellos procesos realizados para terminar con todas las
actividades en todos los Grupos de Procesos y dar el cierre formal del
proyecto o de una fase.
Colectivamente estas fases son mejor conocidas como ciclo de vida de un
proyecto7. La estructura en fases permite segmentar al proyecto en
subconjuntos lgicos para facilitar su administracin, planificacin y control. Tanto
la segmentacin en fases, el nmero de fases, y el grado de control por aplicar,
depende del tamao, de la complejidad y el potencial impacto del proyecto.
Independientemente del nmero de fases que contenga un proyecto, todas las
fases tienen caractersticas similares8.
Desde hace varios decenios, la administracin de proyectos ha contribuido de
manera significativa a que las organizaciones puedan planear, dirigir y sobre
todo controlar mejor sus recursos de manera estructurada y ptima. Esta forma
de trabajo permite encarar retos antes insuperables por la administracin
tradicional. Con esta filosofa se genera creatividad, iniciativa y la delegacin de
autoridad entre los miembros del equipo del proyecto y hace trabajar en
conjuncin recursos multidisciplinarios para lograr un bien comn 9.
Antes de comenzar un proyecto, se debe determinar su objetivo. Un objetivo
especfico clarifica el mbito del proyecto, las personas afectadas y el periodo de
tiempo10.
Con la administracin de proyectos se aplican los conocimientos, habilidades,
herramientas y tcnicas para cumplir con los requerimientos con los

7
St-Pierre, Armand et al. Microsoft Project 98, gua prctica con ejercicios. Ed. Trillas. Mxico. 2000.
p. 21.
8
Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK
Guide). Cuarta edicin. Estados Unidos. 2008. p.18.
9
St-Pierre, Armand et al. Microsoft Project 98, gua prctica con ejercicios. Ed. Trillas. Mxico. 2000.
p. 14.
10
Colmenar, Antonio et al. Gestin de proyectos con Microsoft Project 2007. Alfaomega Grupo
Editor. Mxico. 2007. p. 30.
 6

requerimientos de los proyectos; esto requiere del conocimiento y de la

administracin efectiva de los procesos correspondientes 11.

Inicio
En este proceso se define el alcance inicial del proyecto. Se identifican a las
personas interesadas (stakeholders). Si el administrador del proyecto an no ha
sido asignado, este es el momento. Se genera el Acta de Constitucin del
Proyecto (ACP)12.
Por lo general, cuando se permite la participacin de los clientes y de otros
interesados, es ms probable la existencia de la responsabilidad compartida, la
aceptacin de los entregables de este proceso y la satisfaccin de los clientes.

Planeacin
Este proceso consiste en todas aquellas actividades orientadas a:
El establecimiento del esfuerzo total necesario.

Definir y refinar los objetivos.

Desarrollar el curso de accin requerido para alcanzar esos objetivos.

En este proceso se realiza el plan de administracin del proyecto y aquellos

documentos que se utilizarn para llevar a cabo el proyecto. Los documentos
pretenden explorar los siguientes aspectos:
El alcance.

Los tiempos.

Los costos.

11
Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK
Guide). Cuarta edicin. Estados Unidos. 2008. p.37.
12
Para lograr un proyecto exitoso, es necesario comenzarlos apoyndonos en un documento
formal que ayude a que todos los participantes en el proyecto estn alineados a los objetivos que
se plantearon para llevarlo a cabo. Este documento debe contener la suficiente informacin para
conocer la razn por la cual se realizar el proyecto; cules son los objetivos; quines son los
participantes clave del proyecto y qu esperan de l; documentar las restricciones que se tengan;
quin ser el responsable de coordinarlo. Toda esta informacin se consolida en un documento que
en Administracin Profesional de Proyectos se le denomina Charter (Chamoun, 2002:53), o acta de
nacimiento del proyecto el documento debe venir firmado por quien asigna al responsable del
proyecto y por la persona encargada o gerente de proyecto. Este documento ser la base para
realizar la planeacin y el comienzo de una comunicacin efectiva entre todos los participantes del
proyecto. (Trevio Guajardo, Ma. Del Roble. Cmo iniciar un proyecto.)
 7

La calidad.

La comunicacin.

Los riesgos.

Las contrataciones.

As, el plan de administracin del proyecto se convierte en la fuente de

informacin primaria pues es donde se visualiza la planificacin, la ejecucin, el
monitoreo y control, y el cierre del mismo.
Para este proceso, la naturaleza multidimensional de la administracin de
proyectos crea ciclos con retroalimentacin para anlisis adicionales 13.

Ejecucin
Este proceso consiste en todas las actividades necesarias para completar el
trabajo definido en el plan del proyecto, con el objetivo de cumplir con las
especificaciones del proyecto. Estas actividades incluyen aquellas que
corresponden a la coordinacin de los recursos disponibles, as como la
integracin y desempeo de las actividades establecidas en el plan del proyecto.
En este proceso se realizan actualizaciones al proyecto y en particular a la lnea
base.

Monitoreo y control
En este proceso se realizan las siguientes actividades que permiten hacer el
seguimiento, la evaluacin, ajustar el progreso y la ejecucin del proyecto. Se
identifican las reas en las que se necesita realizar los cambios al plan del
proyecto. El seguimiento continuo proporciona una visin de la salud del proyecto
e identifica las reas que requieren atencin adicional.

Cierre
En este proceso se realizan todas aquellas actividades que permiten dar fin a
todas las actividades de los otros procesos del proyecto con el objetivo de dar por
terminado al proyecto y cumplir con las obligaciones contractuales con el cliente.
Se verifica que todos los procesos definidos en el plan se hayan completado de
manera apropiada y establece de manera formal el trmino del proyecto.

13
Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK
Guide). Cuarta edicin. Estados Unidos. 2008. p.46.
 8

Al cierre del proyecto se presenta lo siguiente:

Se obtiene la aceptacin del cliente.
Se lleva a cabo una fase de revisin final.
Se documentan las lecciones aprendidas.
Se almacenan todos los documentos relevantes para ser utilizados como datos
histricos.

El CMMI
El anterior es uno de los modelos existentes para identificar el ciclo de vida de un
proyecto y para su administracin, pero no es el nico; existen otros modelos.
Uno de ellos es el conocido como Capability Maturity Model Integration
(CMMI)
El CMMI es un modelo de madurez de mejora de los procesos para el desarrollo
de productos y de servicios, que consiste en las mejores prcticas que tratan las
actividades de desarrollo y de mantenimiento que cubren el ciclo de vida del
producto, desde la concepcin a la entrega y el mantenimiento 14.
En la dcada de los 30, Walter Shewhart comenz a trabajar en la mejora de
procesos introduciendo los principios del control estadstico de la calidad
[Shewhart 1931]. Estos principios fueron refinados por W. Edwards Deming
[Deming 1986], Phillip Crosby [Crosby 1979] y Joseph Juran [Juran 1988]. Watts
Humphrey, Ron Radice y otros los ampliaron y comenzaron a aplicarlos al
software en su trabajo en IBM y en el Software Engineering Institute (SEI)
[Humphrey 1989]. En el libro de Humphrey Managing the Software Process se
describen los principios y conceptos bsicos en los cuales se basan muchos de los
modelos de madurez y de capacidad (CMMs)15.
El SEI tom la premisa de la administracin de proceso y defini los CMMs que lo
reflejan. La adhesin a este principio se encuentra en el seno de los movimientos
de calidad de todo el mundo, como lo muestra la ISO/IEC (International
Organization for Standardization/International Electrotechnical Comission) en su
conjunto de estndares16.
Desde 1991, los CMM se han desarrollado para innumerables disciplinas. Algunas
de las ms notables comprenden modelos para la ingeniera de sistemas, la
14
Chrissis, Mary Beth et al. CMMI Gua para la integracin de procesos y la mejora de productos.
Carnegie Mellon University Estados Unidos. 2006. p. XI.
15
Idem. p. 5.
16
Para mayor informacin se puede visitar los siguientes sitios: http://cmmiinstitute.com/cmmi-
getting-started/, http://www.sei.cmu.edu/process/index.cfm
 9

ingeniera del software, la adquisicin del software, el desarrollo y la gestin del

personal, y el desarrollo integrado de productos y procesos (IPPD) 17.
El proyecto de integracin de CMM ha sido realizado para regular el problema de
utilizar mltiples CMM. La misin inicial del equipo del producto CMMI (CMMI
Product Team) fue combinar tres modelos fuente:
1. SW-CMM (Capability Maturity Model for Software), versin v2.0 draft C [SEI
1997b]
2. SECM ( Systems Engineering Capability Model) [EIA 1998] 18
3. IPD-CMM (Integrated Product Development Capability Maturity Model), version
v0.98 [SEI 1997a]
Estos tres modelos fuente fueron seleccionados debido a su extensa adopcin por
las comunidades de desarrollo de sistemas y de software y tambin porque
proponen diversos acercamientos a la mejora de procesos en el seno de una
organizacin.
El CMMI le permite aproximarse a la mejora de procesos y a las evaluaciones
usando dos representaciones diferentes:
Continua. Esta representacin permite a una organizacin seleccionar un
rea de proceso (o un grupo de reas de proceso) y mejorar los procesos
relacionados con sta.
Por etapas. Esta representacin utiliza conjuntos predefinidos de reas de
proceso para definir un camino de mejora para una organizacin. Este
camino de mejora se caracteriza por diversos niveles de madurez. Cada
nivel de madurez proporciona un conjunto de reas de proceso que
caracterizan diferentes comportamientos organizativos.
Los componentes del modelo se agrupan en tres categoras:
Requerido. Describen lo que una organizacin debe realizar para satisfacer
un rea de proceso. Este logro se debe implementar de forma visible en los
procesos de una organizacin. Los componentes requeridos en CMMI son
las metas especficas y los objetivos genricos. La satisfaccin de objetivos
se utiliza en las evaluaciones como base para determinar si un rea de
proceso ha sido realizada y satisfecha.
Esperado. Describen lo que una organizacin puede implementar para
lograr un componente requerido. Los componentes esperados guan a los

17
Idem. p. 11.
18
El Modelo de Capacidad de la Ingeniera de Sistemas tambin se conoce como Alianza de
Industrias Electrnicas (EIA 731)
 10

que implementan mejoras o realizan evaluaciones. Los componentes

esperados incluyen las prcticas especficas y las prcticas genricas.
Informativo. Proporcionan detalles que ayudan a las organizaciones a
comenzar a pensar en cmo aproximarse a los componentes requeridos y
esperados. Las sub-prcticas, los productos de trabajo tpicos, las
ampliaciones, las elaboraciones de las prcticas genricas, los ttulos de
metas y prcticas, las notas de metas y prcticas, y las referencias son
ejemplos de componentes informativos del modelo.

reas de proceso
Un rea de proceso es un grupo de prcticas relacionadas en un rea que, cuando
se implementan de forma conjunta, satisfacen un grupo de objetivos
considerados importantes para la mejora en ese rea. Hay 22 reas de proceso:
Anlisis causal y resolucin (CAR).
Gestin de configuracin (CM).
Anlisis de decisiones y resolucin (DAR).
Gestin integrada del proyecto + IPPD (IPM + IPPD)1.
Medicin y anlisis (MA).
Innovacin y despliegue en la organizacin (OID).
Definicin de procesos de la organizacin + IPPD (OPD + IPPD)1.
Enfoque en procesos de la organizacin (OPF).
Rendimiento del proceso de la organizacin (OPP).
Formacin organizativa (OT).
Integracin de producto (PI).
Monitorizacin y control del proyecto (PMC).
Planificacin de proyecto (PP).
Aseguramiento de la calidad de proceso y de producto (PPQA).
Gestin cuantitativa de proyecto (QPM).
Desarrollo de requerimientos (RD).
Gestin de requerimientos (REQM).
Gestin de riesgos (RSKM).
 11

Gestin de acuerdos con proveedores (SAM).

Solucin tcnica (TS).
Validacin (VAL).
Verificacin (VER).
 12

II Procesos del software

Un proceso del software es un conjunto de actividades que conducen a la
creacin de un producto de software. Los procesos de software suelen ser
complejos y dependen de las personas que toman decisiones. No existe un
proceso ideal, y muchas organizaciones han desarrollado su propio enfoque; sin
embargo, algunas actividades fundamentales son comunes entre todos ellos 19:
Especificacin del software. Especificacin del software o ingeniera de
requerimientos, es el proceso de comprensin y definicin de qu servicios
se requieren del sistema y de identificacin de las restricciones del
funcionamiento del mismo. Los errores en esta etapa originan
inevitablemente problemas posteriores en el diseo e implementacin del
sistema. En los mtodos giles20 los requerimientos se desarrollan de forma
incremental conforme a las prioridades del usuario y la obtencin de
requerimientos viene de los usuarios que forman parte del equipo de
desarrollo.
Diseo e implementacin del software. Un diseo es una descripcin de
la estructura del software que se va a implementar. Se debe producir
software que cumpla con las especificaciones; una especificacin del
sistema se convierte en un sistema ejecutable. El resultado final del proceso
son especificaciones precisas de los algoritmos y estructuras de datos a
implementarse.
Validacin del software. Se debe validar el software para asegurar que
hace lo que el cliente desea. Se utiliza para mostrar que el sistema se
ajusta a las especificaciones cumpliendo las expectativas del usuario.
Evolucin del software. El software debe evolucionar para cubrir las
necesidades cambiantes del cliente. Se pueden hacer cambios al software
en cualquier momento durante o despus del desarrollo del sistema.
Por otra parte, un modelo del proceso del software es una representacin
abstracta de un proceso de software que se pueden utilizar para explicar
diferentes enfoques para el desarrollo del software.

19
Sommerville, Ian. Ingeniera del software. Sptima edicin. Ed. Pearson Educacin. Madrid. 2006.
p. 60.
20
Uno de los ms utilizados actualmente es el SCRUM. El concepto de SCRUM tiene su origen en
un estudio sobre los nuevos procesos de desarrollo utilizados en productos exitosos en Japn y los
Estados Unidos (Takeuchi, Hirotaka. The New Product Development Game. Harvard Business
Review, Enero-Febrero de 1986). En 1993 se realiz el primer SCRUM para desarrollo de software
(Jeff Sutherland, John Scumniotales y Jeff McKenna lo concibieron, lo ejecutaron y lo
documentaron) y en 1995 el proceso fue formalizado por Ken Schwaber para la industria de
desarrollo de software.
 13

Algunos de estos procesos son21:

El modelo en cascada. Considera las actividades fundamentales del
proceso de especificacin, desarrollo, validacin y evolucin, y los
representa como fases separadas del proceso. Una ventaja importante
consiste en la produccin de la documentacin en cada fase, mientras que
una desventaja es no poder dar una respuesta rpida a los cambios a los
nuevos requerimientos del cliente.
Desarrollo evolutivo. Este enfoque enlaza las actividades de
especificacin, desarrollo y validacin. La documentacin no se puede
generar fcilmente, pero el desarrollo del sistema es ms rpido y se le
puede presentar al cliente al poco tiempo de haber iniciado con la etapa de
especificacin.
Ingeniera del software basada en componentes. Este enfoque se basa
en la existencia de un nmero significativo de componentes reutilizables
(software que ya se encuentra desarrollado por terceros). El proceso del
desarrollo del sistema se enfoca en integrar estos componentes en el
sistema ms que en desarrollarlos desde cero. La ventaja principal es la
reduccin de software a desarrollarse reduciendo as los costos.
Las cuatro actividades bsicas de los modelos del proceso de software se
organizan de manera distinta en diferentes procesos del desarrollo; en el enfoque
en cascada estn organizadas en secuencia, mientras que en el desarrollo
evolutivo se entrelazan. Cmo se llevan a cabo estas actividades, depende del
tipo de software, de las personas y de la estructura organizacional implicada. No
hay una forma correcta o incorrecta de organizar estas actividades.
Estos modelos de procesos genricos se utilizan ampliamente en la prctica actual
de la ingeniera de software. A menudo se utilizan juntos; de hecho, el proceso
conocido como RUP 22(Rational Unified Process) combina elementos de todos
estos modelos.
Por otra parte, un mtodo de ingeniera de software es un enfoque estructurado
para el desarrollo de software cuyo propsito es el de facilitar la produccin de
software de alta calidad y a bajo costo. Algunos ejemplos son: Anlisis
estructurado (De Marco, 1978), JSD (Jackson, 1983), UML (Booch et al., 1999;
Rumbaugh et al., 1999).

21
Sommerville, Ian. Ingeniera del software. Sptima edicin. Ed. Pearson Educacin. Madrid. 2006.
p. 61.
22
RUP es un proceso de desarrollo de software desarrollado por la empresa Rational Software,
actualmente propiedad de IBM. Junto con el Lenguaje Unificado de Modelado UML, actualmente
constituye la metodologa estndar ms utilizada para el anlisis, diseo, implementacin y
documentacin de sistemas orientados a objetos.
 14

III La administracin de proyectos de software

La administracin de proyectos de software es una parte de la ingeniera del
software y es necesaria debido a que en muchas ocasiones, sino es que siempre,
existen restricciones de tiempo y presupuesto.
Los administradores de proyectos de software son la columna vertebral de una
larga red de informacin y son responsables de conducir el proyecto hacia un final
con xito. Las principales responsabilidades del administrador son:
La planificacin y la fijacin de los tiempos del desarrollo de los proyectos.
La supervisin del trabajo para asegurar que se lleva a cabo conforme a los
estndares requeridos.
La supervisin del progreso para comprobar que el desarrollo se ajusta al
tiempo previsto y al presupuesto.
Los administradores de proyectos de software hacen el mismo tipo de trabajo que
otros administradores de proyectos; sin embargo, la ingeniera de software es
diferente en varios aspectos, entre ellos:
El producto es intangible. El administrador de un proyecto de
construccin puede ver el producto mientras se est desarrollando. Si hay
un desfase en el calendario, el efecto en el producto es visible. El software
es intangible.
No hay procesos de software estndar. En muchas de las disciplinas de
la ingeniera hay un largo historial de conocimientos para la prueba y
verificacin de procesos. Sin embargo, los procesos de software varan de
una organizacin a otra.
Los proyectos grandes son nicos. Por lo general, los proyectos grandes
de software son diferentes de proyectos previos; por lo que aun cuando se
cuente con gran experiencia, sta no es suficiente para anticipar los
problemas. Adems, los rpidos cambios en la tecnologa y los nuevos
paradigmas de programacin hacen parecer obsoleta la experiencia previa.
Las lecciones aprendidas en esas experiencias pueden no ser transferibles a
los nuevos proyectos.
Por lo anterior, no es de sorprender que algunos proyectos de software se
retrasen, sobrepasen el presupuesto y/o se entreguen fuera de tiempo.
La administracin de proyectos de software contiene varias etapas, entre ellas:
Planificacin.

Calendarizacin.
 15

Administracin del riesgo.

Administracin de personal.

Administracin de los costos de software.

Administracin de la calidad.

Planificacin y calendarizacin
Esta etapa se realiza lo siguiente23:
Valorar las restricciones que afectan al proyecto. Por ejemplo: fecha
de entrega, recursos humanos disponibles, presupuesto, etctera.
Estimar los parmetros del proyecto. Estructura, tamao y distribucin
de funciones (Estructura de descomposicin del trabajo, EDT).
Definir Hitos. Estos son los puntos finales de una actividad del proceso del
software. Para establecer los hitos el proceso del software se debe dividir en
actividades bsicas con sus salidas correspondientes.
Definir entregables.

Preparar el calendario del proyecto. Es una de las tareas ms difciles;

se estima el tiempo y los recursos requeridos para completar las actividades
y se organizan en una sucesin coherente.
Existen diferentes tipos de planes que dependen del tipo de metodologa que se
siga para la administracin de proyectos de software; en algunas organizaciones
el plan del proyecto es un nico documento que incluye todos los diferentes tipos
de planes (Tabla 1)24. En otros casos, el plan se refiere nicamente al proceso de
desarrollo.

Plan Descripcin

Describe los procedimientos y los estndares de

Plan de calidad
calidad que se utilizarn en un proyecto.

Describe el enfoque, los recursos y la programacin

Plan de validacin
utilizados para la validacin del sistema

Plan de administracin de Describe los procedimientos para la administracin de

23
Sommerville, Ian. Ingeniera del software. Sptima edicin. Ed. Pearson Educacin. Madrid. 2006.
p. 89.
24
Idem. p. 88.
 16

Plan Descripcin

configuraciones configuraciones y las estructuras a utilizar.

Predice los requerimientos del mantenimiento del

Plan de mantenimiento sistema, los costos del mantenimiento y el esfuerzo
requerido.

Describe cmo se desarrollan las habilidades y

Plan de desarrollo del personal
experiencia de los miembros del equipo del proyecto.
Tabla 1. Tipo de plan

Como resultado de las actividades anteriores, se obtiene el Plan del proyecto, que
por lo general se presenta con una grfica de barras y su red de actividades.
La grfica de barras muestra quin es el responsable de cada actividad y cundo
debe comenzar y finalizar sta; mientras, la red de actividades muestra las
dependencias entre las diferentes actividades del proyecto.
Actualmente existen diferentes herramientas de software para la administracin
de proyectos, entre ellas: Microsoft Project, Microsoft Project Server, JIRA,
etctera.
Si el proyecto contina, se inicia con el ciclo Revisin-Actualizacin hasta el
trmino del mismo. Si el proyecto se retrasa, se tienen que renegociar con el
cliente las restricciones del mismo y las entregas. Si la negociacin no tiene xito,
se debe hacer una revisin tcnica del plan con el propsito de encontrar un
enfoque alternativo que se ajuste a las restricciones del proyecto y que cumpla
con las metas del calendario.

Administracin del riesgo

En el plan del proyecto se deben identificar los riesgos que podran afectar al
calendario del proyecto o a la calidad del software a desarrollar, y en
consecuencia emprender las acciones correspondientes para evitar esos riesgos;
se debe comprender el impacto de stos en el proyecto, en el producto y en el
negocio.
Aunque los riesgos de un proyecto dependen del proyecto mismo y del entorno
donde se desarrolla, muchos riesgos son universales. La Tabla 2 25 muestra
algunos de estos riesgos.

25
Idem. p. 96.
 17

Riesgo Tipo Descripcin

Personal con experiencia abandona el

Rotacin de personal Proyecto
proyecto antes de que finalice.

Habr un cambio de administracin en la

Cambio de administracin Proyecto
empresa cliente con diferentes prioridades.

No disponibilidad del El hardware esencial para el proyecto no

Proyecto
hardware ser entregado a tiempo.

Habr ms cambios en los requerimientos de

Cambio de requerimientos Proyecto y producto
lo esperado.

Retrasos en la Las especificaciones de las interfaces

Proyecto y producto
especificacin esenciales no estarn a tiempo.

Subestimacin del tamao Proyecto y producto El tamao del sistema se ha subestimado

La tecnologa fundamental sobre la que se

Cambio de tecnologa Negocio construir el sistema se sustituye por nueva
tecnologa.

Un producto competitivo se pone en venta

Competencia del producto Negocio
antes de que el sistema se complete.
Tabla 2. Posibles riesgos del software

Las etapas de la administracin del riesgo comprenden 26:

Identificacin de riesgos. Identificar los posibles riesgos para el
proyecto, el producto y el negocio.
Anlisis de riesgos. Valorar las probabilidades y consecuencias de los
riesgos identificados.
Planificacin de riesgos. Crear planes para abordar los riesgos, ya sea
para evitarlos o minimizar sus efectos.
Supervisin de riesgos. Valorar los riesgos de forma constante y revisar
los planes para la mitigacin de riesgos tan pronto como la informacin de
los riesgos est disponible.

Administracin de personal
Por lo general el administrador del proyecto no tiene una libre eleccin del
personal que trabajar en el mismo; en casos excepcionales se puede designar a

26
Idem. p. 97.
 18

las personas que mejor se adecuan a un trabajo, independientemente de sus

otras responsabilidades o de las consideraciones de presupuesto. La limitacin de
presupuesto restringe el nmero de costosos ingenieros con experiencia que
pueden trabajar en el proyecto.
La decisin de quines sern designados para un proyecto, por lo general, se lleva
a cabo utilizando tres tipos de informacin27:
El CV. Es la informacin suministrada por los candidatos acerca de sus
conocimientos y experiencia; esta suele ser la informacin ms fiable de la
que se dispone para juzgar qu candidatos son adecuados.
La entrevista. La informacin obtenida al entrevistar a los candidatos da
una buena visin de qu candidatos son buenos comunicadores y cundo
stos tienen buenas habilidades sociales. Sin embargo, las pruebas han
demostrado que los entrevistadores son obligados a aceptar o rechazar
candidatos haciendo rpidos juicios subjetivos. Por lo tanto las entrevistas
no son mtodos fiables para juzgar las capacidades tcnicas.
Recomendaciones. La opinin de algunas personas que han trabajado con
los candidatos puede ser objetiva cuando se conoce a la persona que hace
la recomendacin. De otro modo, las recomendaciones pueden no ser
ciertas, por lo que deben tener poco peso den la decisin a la hora de
formar un equipo.
La Tabla 328 muestra los factores que pueden influir en la decisin al momento de
seleccionar el personal para un proyecto de software. Los factores ms
importantes varan dependiendo del dominio de la aplicacin, del tipo de proyecto
y de las habilidades de los otros miembros del proyecto. En proyectos de larga
duracin es ms importante entender los conceptos y el dominio de la aplicacin
que los conocimientos especficos.

Factor Explicacin

Para desarrollar bien un sistema, los desarrolladores deben entender el

Experiencia en el
dominio de la aplicacin. Es esencial que algunos de los miembros del
dominio de la
equipo de desarrollo tengan alguna experiencia en el dominio de la
aplicacin
aplicacin.

Experiencia en la Este factor es importante si la programacin a bajo nivel es necesaria. En

plataforma otro caso, no es un atributo crtico.

Experiencia en el Normalmente esto slo es importante para proyectos de corta duracin

lenguaje de donde no existe tiempo suficiente para aprender un nuevo lenguaje.

27
Idem. p. 545.
28
Idem. p. 547.
 19

Factor Explicacin

Mientras que aprender el lenguaje propiamente dicho no es difcil,

programacin empezar a utilizar las libreras y componentes de forma competente
pueden llevar varios meses.

Habilidades para Esto es muy importante para ingenieros de software, los cuales tienen que
resolver resolver constantemente problemas tcnicos. Sin embargo, es casi
problemas imposible de juzgar sin conocer el trabajo del candidato.

Esto provee un indicador de los fundamentos bsicos que el candidato

debe conocer y de la habilidad para aprender. Este factor cada vez es ms
Soporte educativo
irrelevante, puesto que los ingenieros obtienen experiencia a travs de los
proyectos.

Esto es importante debido a que el personal del proyecto necesita

Habilidad de
comunicarse oralmente y por escrito con los otros ingenieros,
comunicacin
administradores y clientes.

La adaptabilidad se valora observando las diversas experiencias obtenidas

Adaptabilidad por los candidatos. Este es un atributo importante puesto que indica una
habilidad para aprender.

El personal de proyecto debe tener una actitud positiva con respecto a su

Actitud trabajo y debe estar deseoso de aprender nuevas habilidades. Este es un
atributo importante, pero a menudo muy difcil de valorar.

Este es un atributo importante pero difcil de valorar. Los candidatos deben

ser razonablemente compatibles con los otros miembros del equipo.
Personalidad
Ningn tipo de personalidad es ms o menos adecuada para la ingeniera
de software.
Tabla 3. Factores que determinan la seleccin de personal

Algunas compaas prueban a los candidatos con pruebas de aptitud a la

programacin y pruebas psicomtricas donde los candidatos completan una serie
de ejercicios en un periodo de tiempo relativamente breve. Las pruebas
psicomtricas estn dirigidas a conseguir el perfil psicolgico del candidato,
indicando sus capacidades y habilidades para ciertos tipos de tareas. Se duda si
las pruebas de aptitud proveen informacin til acerca de la capacidad para
resolver problemas. No parece que las habilidades necesarias para la resolucin
de problemas complejos sean comparables a las habilidades necesarias para
completar pruebas de aptitud simples29.

Administracin de los costos de software

29
Idem. p. 547.
 20

En las primeras etapas del proyecto se necesitan algunas estimaciones de costos

para establecer un presupuesto o para asignar el precio para el software a
desarrollar para algn cliente. Existen tres parmetros involucrados 30:
Los costos de hardware y software.

Los costos de viajes y capacitacin.

Los costos del esfuerzo.

Una vez iniciado el proyecto se deben actualizar regularmente las estimaciones de

tiempo y costo. Si los gastos actuales son significativamente mayores que los
estimados el administrador del proyecto debe tomar algunas decisiones. Al
respecto, el administrador del proyecto tiene que estimar la productividad del
personal involucrado en el proyecto de desarrollo de software. Estas estimaciones
de productividad se basan en la medicin de alguno de los atributos del software
y se divide el resultado entre el esfuerzo total requerido para el desarrollo.
Sin embargo, no existe una forma simple de realizar una estimacin precisa. Las
estimaciones iniciales se hacen partiendo de la definicin de requerimientos del
usuario que en muchas ocasiones son incompletos.
En aos recientes se han introducido nuevas tcnicas y mtodos de desarrollo de
software que pueden afectar las estimaciones que se basan nicamente en la
experiencia; si el administrador del proyecto de software no ha trabajado con
esas tcnicas, su experiencia previa no le ayudar a estimar los costos. Entre
stas tcnicas se tienen las siguientes:
Sistemas orientados a objetos.

Uso de servicios web.

Uso de ERP.

Uso de paquetes de software ajenos (componentes) en lugar de

desarrollar todo el software propio.

Administracin de la calidad
La calidad del software es un concepto complejo que no es directamente
comparable con la calidad de la manufactura de productos. En la manufactura, la
calidad viene dada por la similitud entre el producto desarrollado y su
especificacin (Crosby, 1979)31.

30
Idem. p. 562.
31
Idem. p. 588.
 21

La administracin de la calidad del software se divide en tres actividades

principales:
Garanta de la calidad. Es el proceso que define cmo lograr la calidad del
software al definir o seleccionar los estndares que deben ser aplicados
durante el desarrollo del software32.
Planificacin de la calidad. Es el proceso en el que se desarrolla un plan
de calidad para un proyecto, en el que se define la calidad del software
deseado y describe cmo evaluarlo. El plan de calidad depende del tamao
y del tipo de sistema que se desarrolle.
Control de la calidad. Es el proceso durante el cual se realiza la vigilancia
del proceso del desarrollo del software para asegurar que se siguen los
estndares establecidos en el proceso de Garanta de la calidad. Los pasos
clave para el proceso de medicin son: Seleccionar las medidas a realizar,
Seleccionar los componentes a evaluar, Medir las caractersticas de los
componentes, identificar las mediciones anmalas y analizar los
componentes anmalos33.
Un equipo independiente debe ser el responsable de la administracin de la
calidad y debe mantener informado al administrador del proyecto. Es
recomendable que el equipo de calidad no deba estar asociado con ningn grupo
de desarrollo.

32
Algunos ejemplos son: el estndar 830-1998 IEEE Recommended Practice for Software
Requirements Specifications, que se refiere a la Especificacin de Requisitos de Software y que
expresa la manera de organizar el documento de requerimientos (vase
http://standards.ieee.org/findstds/standard/830-1998.html); el estndar 730-2002 - IEEE Standard
for Software Quality Assurance Plans (http://standards.ieee.org/findstds/standard/730-2002.html),
que muestra el formato y el cmo se organiza el contenido del plan de aseguramiento de la
calidad del software .
33
Sommerville, Ian. Ingeniera del software. Sptima edicin. Ed. Pearson Educacin. Madrid. 2006.
p. 601.
 22

IV El administrador del proyecto

Algunas de las responsabilidades del administrador de proyectos de software son:

Redaccin de la propuesta. La propuesta describe los objetivos de
proyecto y cmo se llevara a cabo. Esta propuesta puede incluir: la
estimacin de tiempo y costos, la justificacin de quin debe realizar el
desarrollo del producto. La redaccin de la propuesta es una habilidad que
se adquiere con la prctica y la experiencia.
Planificacin y calendarizacin del proyecto. Se identifican las
actividades, hitos y entregas de un proyecto, se establece el orden de las
actividades y su duracin, se determina la manera en la que se relacionan
las actividades, etctera. Es decir, se bosqueja el plan del proyecto para la
consecucin de las metas.
Estimacin de costos del proyecto. Esta es una actividad que va
relacionada con la estimacin de los recursos requeridos para llevar a cabo
el plan del proyecto.
Supervisin y revisin del proyecto. Esta es una actividad continua. El
administrador del proyecto debe tener conocimiento del progreso del
proyecto y comparar los costos actuales contra los planificados. Aunque no
es comn, el resultado de una revisin puede tener como consecuencia la
cancelacin dl proyecto.
Redaccin y presentacin de informes. El administrador del proyecto es
el responsable de informar a los clientes sobre el proyecto, por lo que la
comunicacin efectiva tanto oral como escrita son habilidades esenciales en
un buen administrador.

El administrador del proyecto debe reflejar en el plan del proyecto la suficiente

holgura para que las contingencias, restricciones e hitos no se tengan que
negociar cada vez que se efecta el ciclo Revisin-Actualizacin.
Otro de los papeles del administrador del proyecto es motivar al personal del
proyecto; motivacin significa organizar el trabajo y su entorno para estimular a
las personas a trabajar de la forma ms efectiva y eficaz posible. Si las personas
no son motivadas, no se interesarn en el trabajo que hacen, stas trabajarn
 23

lentamente, cometern ms errores y no contribuirn a las metas del equipo ni

de la organizacin (Maslow, 1954)34.

34
Sommerville, Ian. Ingeniera del software. Sptima edicin. Ed. Pearson Educacin. Madrid. 2006.
p. 548.
 24

V Reflexin

Cada una de las reas exploradas en las secciones anteriores forma un cuerpo de
conocimientos en s mismo y forma parte de una o ms especializaciones de
estudio.
Es importante distinguir la aplicacin del proceso administrativo del da a da y del
proceso administrativo para los proyectos. Esta distincin permite al
administrador tomar en cuenta la temporalidad a la que se somete un proyecto y
que es diferente a la temporalidad de las actividades continuas de una empresa.
La administracin de proyectos de software se caracteriza por estar ligado al ciclo
de vida del desarrollo de software. Esto implica que se deben identificar de
manera adecuada las etapas del ciclo de software y saberlas distinguir de aquellas
pertenecientes a la administracin de proyectos.
 25

Bibliografa
Colmenar, Antonio et. al. Gestin de proyectos con Microsoft Project 2007.
Alfaomega Grupo Editor. Mxico. 2007.
Chamoun, Yamal. Professional Project Management, The Guide. Mc-GRaw
Hill Interamericana. Mxico. 2006.
Chrissis, Mary Beth et al. CMMI Gua para la integracin de procesos y la
mejora de productos. Carnegie Mellon University Estados Unidos. 2006.
Project Management Institute. A Guide to the Project Management Body of
Knowledge (PMBOK Guide). Cuarta edicin. Estados Unidos. 2008.
Sommerville, Ian. Ingeniera del software. Sptima edicin. Ed. Pearson
Educacin. Madrid. 2006.
St-Pierre, Armand et. al. Microsoft Project 98, gua prctica con ejercicios.
Ed. Trillas. Mxico. 2000.

Document license

LICENCIA DE USO

Software para Administracin de la Base de Conocimiento KWE 2.0 para la

Norma NMX-I-059-NYCE-2005 (MoProSoft)

Software para Autoevaluacin de la Norma NMX-I-059-NYCE-2005

(MoProSoft)

Esta licencia rige las condiciones de uso del Software para Administracin
de la Base de Conocimiento KWE 2.0 para la Norma NMX-I-059-NYCE-2005
(MoProSoft) y del Software para Autoevaluacin de la Norma NMX-I-059-
NYCE-2005 (MoProSoft) (conjuntamente el Software, salvo que se
mencionen de manera separada), independientemente de su forma de
acceso. Al acceder por cualquier va y/o instalar y/o usar el Software en
cualquier medida, Usted expresa su consentimiento a los trminos de la
presente licencia de uso (la Aceptacin). Esta licencia de uso constituye el
contrato ntegro y exclusivo entre Normalizacin y Certificacin Electrnica,
A.C. y Usted en relacin con los derechos de uso autorizado del Software.
Para estos efectos, en el presente contrato Usted en su carcter de usuario
por cualquier medio ser denominado como el Usuario, y NYCE es
Normalizacin y Certificacin Electrnica, A.C., con domicilio en Avenida
Lomas de Sotelo 1097, Colonia Lomas de Sotelo, C.P. 11200 en Mxico,
Distrito Federal.
 26

1. Por virtud del presente contrato de licencia de uso, NYCE otorga al

Usuario el derecho de uso del Software bajo los trminos y condiciones
establecidos en el presente contrato. El derecho que se otorga slo incluye
el uso del Software de forma personal por parte del Usuario, para los fines
para los cuales el Software est naturalmente diseado, con la
funcionalidad y especificaciones originales. NYCE slo autoriza el uso del
Software y/o cualquiera de sus aplicaciones o formas de operacin
ntegramente en la forma proporcionada y/u operada por NYCE.

2. NYCE se reserva la titularidad y ejercicio de todos los derechos sobre el

Software y/o cualquiera de sus componentes, programas y/o aplicaciones,
incluyendo aqullos de propiedad intelectual y cualquier presentacin o
forma de operacin, y prohbe expresamente la reproduccin permanente o
provisional del Software o cualquiera de sus componentes, programas o
aplicaciones, incluyendo cualquiera de sus presentaciones o formas de
operacin; la traduccin, adaptacin, arreglo o cualquier otra forma de
modificacin del portal o cualquiera de sus componentes, programas o
aplicaciones, incluyendo la reproduccin de cualquier obra resultante; la
distribucin, arrendamiento o cualquier otra forma de enajenacin y/o
facilitacin a terceros o aprovechamiento por s o por terceros, directa o
indirectamente bajo cualquier ttulo, diferente al uso personal exclusivo
otorgado bajo los trminos y condiciones de uso establecidos en el presente
contrato, as como la decompilacin y/o cualquiera proceso para revertir la
ingeniera o desensamblaje, salvo autorizacin previa y por escrito de
NYCE. Los derechos de uso referidos en esta licencia son los nicos
concedidos por NYCE en relacin con el Software, independientemente de la
forma de enajenacin por parte de NYCE y/o la forma de adquisicin por
parte del Usuario, con o sin contraprestacin monetaria reclamada por
NYCE y/o pagada por el Usuario.

3. El Usuario se obliga a hacer el correcto uso del Software y/o cualquiera

de sus aplicaciones o formas de operacin conforme a sus propsitos
naturales, y en consecuencia se obliga a no usar o intentar usar cualquier
recurso relacionado con ste, directa o indirectamente para la ejecucin o
intento de ejecucin de cualquier prctica contraria a los buenos usos
mercantiles o a la ley, incluyendo sin limitar cualquier prctica de remisin
masiva de correos electrnicos no solicitados (spamming), incluyendo
aqullos que tengan como objeto o efecto el bloqueo de servidores de la red
(mail bombing), as como cualquier prctica que pongan a prueba o
intenten poner a prueba la seguridad o integridad del propio Software o de
bienes o servidores en lnea, realizando o intentando realizar cualquier tipo
de acceso o accin que no resulte estrictamente necesaria para el disfrute
 27

del Software y/o cualquiera de sus aplicaciones o formas de operacin por

parte del Usuario conforme al presente contrato. La infraccin a la presente
disposicin dar derecho a NYCE de dar por terminado el contrato
inmediatamente. El Usuario asume la responsabilidad total y directa por
todas y cualquier reclamacin que pudiera surgir con motivo de los aspectos
aqu convenidos, y libera y se obliga a sacar en paz y a salvo a NYCE o en
su caso indemnizarla por cualquiera responsabilidad que pudiera reclamarse
a NYCE a este respecto.

4. El Usuario ser el nico y exclusivo responsable de la integridad de toda

la informacin de carcter privado y/o bases de datos bajo su generacin,
operacin, titularidad, manejo, tratamiento o cualquiera otra forma de
posesin o detentacin, bajo cualquier ttulo. El Usuario ser el nico
responsable del mantenimiento y creacin de sus propias copias de
seguridad sobre cualquier informacin en su posesin, as como de la
configuracin y de toda la informacin que use, publique o interacte con el
Software y/o cualquiera de sus aplicaciones o formas de operacin.
Asimismo el Usuario ser el responsable nico y exclusivo de la seguridad y
confidencialidad de sus propias claves de acceso, teniendo la obligacin y la
nica y exclusiva responsabilidad de guardarlas y custodiarlas en lugar
seguro con el fin de impedir el acceso a terceros no autorizados. NYCE no
efecta ninguna forma de retencin o monitoreo deliberado o voluntario de
informacin que eventual, necesaria o circunstancialmente resida o transite
temporalmente por bienes y/o servidores bajo el control razonable de
NYCE, y en consecuencia no asume ni puede asumir responsabilidad alguna
por dicha informacin en forma alguna.

5. El Usuario ser el nico y exclusivo responsable de la operacin o

interaccin de mecanismos de verificacin de identidad, seguridad en lnea,
o en general de seguridad informtica de cualquier tipo en relacin con el
uso del Software y/o cualquiera de sus aplicaciones o formas de operacin,
en la medida en que cualquiera de dichas funciones cumplan con la
legislacin aplicable vigente, y no contravengan las polticas y/o
procedimientos de NYCE o los trminos y condiciones de la presente
licencia.

6. NYCE no es responsable por cualquier habilitacin y/o configuracin

tcnica necesaria y/o conveniente para la operacin del Software por parte
del Usuario. Las partes convienen y reconocen la responsabilidad de NYCE
se limita a poner a disposicin del Usuario el uso del Software bajo los
trminos y condiciones del presente contrato de licencia de uso, y que en
consecuencia NYCE no es responsable de cualquier otro aspecto como la
interoperabilidad o compatibilidad del Software y/o de cualquier de sus
 28

componentes o aplicaciones en relacin con cualquier equipo, programa,

plataforma, datos, sistemas, portales o cualquier otro bien, configuraciones
o informacin del Usuario y/u operados por el Usuario, as como de los
posibles conflictos tcnicos que pudieran suscitarse por tales motivos, los
cuales son de la responsabilidad exclusiva del Usuario.

7. En todo caso el Usuario ser responsable de forma nica y exclusiva por

cualquier dao causado a la operacin del Software y/o cualquiera de sus
aplicaciones o formas de operacin derivada o relacionada con la
intervencin no autorizada de terceros directamente al Software y/o
cualquiera de sus aplicaciones o formas de operacin o sus componentes,
programas o aplicaciones, o a equipos, programas, plataformas, datos,
sistemas, portales o cualquier otro bien del Usuario y/u operados por el
Usuario que resulten en la generacin de conflictos y/o daos con la
operacin del Software y/o cualquiera de sus aplicaciones o formas de
operacin.

8. Salvo que existan causas ajenas al control de NYCE y/o que deriven de
circunstancias atribuibles al Usuario y/o cualquier otro aspecto como la
interoperabilidad o compatibilidad del Software y/o cualquiera de sus
aplicaciones o formas de operacin, y/o de cualquiera de sus componentes
o aplicaciones con cualquier equipo, programas, plataformas, datos,
sistemas, portales o cualquier otro bien del Usuario y/u operados por el
Usuario, NYCE declara que el Software y/o sus aplicaciones o formas de
operacin operarn dentro de parmetros comercialmente razonables. Para
operaciones en lnea, las partes convienen y reconocen que NYCE a su sola
discrecin, podr interrumpir temporalmente la operacin del Software de
forma controlada y deliberada, preferentemente en horas y/o das inhbiles,
para implementar mejoras o actualizaciones o ejecutar actividades de
reparacin de los medios tcnicos utilizados para su operacin, sin
responsabilidad.

9. Las partes convienen y reconocen que NYCE no ofrece garanta alguna

sobre el Software y/o cualquiera de sus aplicaciones o formas de operacin,
ni garantiza de forma alguna la adecuacin del Software y/o cualquiera de
sus aplicaciones o formas de operacin para un fin determinado o deseado
o esperado por el Usuario, ni de desempeo especfico en relacin con
objetivos determinados o deseados o esperados por el Usuario, de
expectativas de ventas, cumplimiento de obligaciones o de cualquier otra
clase, ni garanta o promesa alguna de cualquier otra naturaleza.

10. La presente licencia incluye el derecho de uso de versiones pblicas

posteriores proporcionadas por NYCE. NYCE se reserva el derecho de
 29

sustituir cualquier versin del Software y/o cualquiera de sus aplicaciones o

formas de operacin y/o cualquiera de sus componentes, programas y/o
aplicaciones por otras ms recientes o por cualesquiera otras que NYCE
estime ms convenientes a su solo juicio. Si el Usuario se negare a adoptar
cualquier versin del Software y/o cualquiera de sus aplicaciones o formas
de operacin y/o cualquiera de sus componentes, programas y/o
aplicaciones ms recientes o cualquier otra que NYCE estime ms
convenientes a su solo juicio, cualquiera de las partes tendr el derecho de
dar por terminado el contrato, sin responsabilidad para NYCE.

11. Para operaciones en lnea, NYCE no ser responsable de la no-

disponibilidad del Software y/o cualquiera de sus aplicaciones o formas de
operacin por cualquier circunstancia tcnica o de fuerza mayor o caso
fortuito, no atribuibles ni bajo la responsabilidad o control razonable de
NYCE, incluyendo sin limitar defectos de operacin actual o potencialmente
derivados de equipos, programas, plataformas, datos, sistemas, portales o
cualquier otro bien del Usuario y/u operados por el Usuario en conflicto con
la operacin del Software y/o cualquiera de sus aplicaciones o formas de
operacin, o cualquiera intervencin de terceros a bienes del Usuario o al
Software y/o cualquiera de sus aplicaciones o formas de operacin. NYCE
har los esfuerzos de buena fe y comercialmente razonables que estn bajo
su control, para mantener la disponibilidad del Software y/o cualquiera de
sus aplicaciones o formas de operacin ante el incidente de que se trate, en
el entendido de que no asumir costo alguno por las actividades de
restitucin o restablecimiento que debieren efectuarse con motivo de
cualquiera de las causas indicadas.

12. La presente licencia permanecer vigente durante un ao contado a

partir de la fecha de Aceptacin, y se renovar automticamente por
perodos iguales y sucesivos salvo que ocurra alguna de las causas de
terminacin previstas en el presente contrato. NYCE podr restringir el
derecho de uso del Usuario ante la infraccin por parte del Usuario de
cualquiera de las obligaciones o prohibiciones contenidas en la presente
licencia. A la terminacin del presente contrato por cualquier causa, el
Usuario se obliga a dejar de usar el Software y/o cualquiera de sus
aplicaciones o formas de operacin cualquier indicacin.

13. NYCE se hace nicamente responsable del Software para

Administracin de la Base de Conocimiento KWE 2.0 para la Norma NMX-I-
059-NYCE-2005 (MoProSoft) y Software para Autoevaluacin de la Norma
NMX-I-059-NYCE-2005 (MoProSoft), cualquier software diferente a este es
responsabilidad total de la empresa u organizacin que lo instale. El
directorio virtual proporcionado por NYCE puede tener instalado el Sistema
 30

Operativo Windows XP, Windows Vista y Windows 7, as como del

Manejador de Base de Datos SQL Server 2008 y el cual la institucin no se
responsabiliza de dichas aplicaciones, ya que son aplicaciones de prueba y
el cual el usuario final tendr que ingresar una licencia valida para su
activacin y registro antes las instituciones pertinentes.

14. En caso de que cualquier clusula del presente documento sea

declarada nula, las dems clusulas seguirn vigentes. El no ejercicio de
cualquier derecho conferido a NYCE bajo el presente Contrato, no se
entender en ningn caso como renuncia al derecho que le asista.

15. El presente contrato se rige por las leyes de Mxico. Para la resolucin de
cualquier interpretacin o controversia, las partes se someten expresamente a los
tribunales competentes en la ciudad de Mxico, D.F., y renuncian expresamente a
cualquier otro fuero o jurisdiccin que pudiere corresponderles con motivo de sus
domicilios presentes o futuros, o por cualquiera otra causa.