Notas del curso Administración de Proyectos

7/27/2019 Notas del curso Administracin de Proyectos

1/177

MATERIAL DIDCTICO

NOTAS DEL CURSOADMINISTRACIN DE PROYECTOS

AUTORES:Dra. Mara del Carmen Gmez FuentesDr. Jorge Cervantes Ojeda

Dr. Pedro Pablo Gonzlez Prez

Departamento de MatemticasAplicadas y SistemasIBSN: 978-607-477-824-3

Septiembre 2012


2/177

Notas d

AEste material tiene como principal objetivo apoyar el curso trimestral de Administracin deProyectos. Comnmente, cuando los alumnosinician estecurso,ya hanaprendido y puestoen prctica diversos paradigmas de desarrollo de software.Adems, han profundizado en el

estudio de anlisis de requerimientos y de las estrategias de calidad y pruebas ms comunes paraprocurar el xito de un proyecto. Sin embargo, les falta an integrar todos estos conceptos y verlosdesdelaperspectivadelaadministracindelproyectoensuconjunto.

En la vida laboral es comn, que la presin por entregar el producto a como de lugar y en una fechalmite, impida finalizar con xito un proyecto. Los conocimientos sobre la Administracin de

Proyectos podrn ser de gran ayuda cuando el futuro ingeniero de software se enfrente con estosproblemas.

MXICO, D.F. 2012

ADMINISTRACINDEPROYECTOS

Casa abierta al tiempo

UNIVERSIDAD AUTNOMA METROPOLITANAUNIDAD CUAJIMALPA


ADMINISTRACIN

DE PROYECTOS

Dra. Mara del Carmen Gmez Fuentes

Dr. Jorge Cervantes Ojeda

Dr. Pedro Pablo Gonzlez Prez

UNIVERSIDADAUTNOMAMETROPOLITANA

UNIDADCUAJIMALPA

Casaabiertaaltiempo

Notas

delcurso


3/177


UNIVERSIDAD AUTNOMA METROPOLITANA ANLISIS DE REQUERIMIENTOS

U N I V E R S I D A D A U T N O M A

M E T R O P O L I T A N AUnidad Cuajimalpa

Notas del curso:

Administracin deProyectos

Dra. Mara del Carmen Gmez Fuentes.Dr. Jorge Cervantes Ojeda.

Dr. Pedro Pablo Gonzlez Prez.

Septiembre 2012


4/177



EditoresMara del Carmen Gmez Fuentes

Jorge Cervantes OjedaPedro Pablo Gonzlez Prez

Departamento de Matemticas Aplicadas y Sistemas.Divisin de Ciencias Naturales e IngenieraUniversidad Autnoma Metropolitana, Unidad Cuajimalpa

Editada por:UNIVERSIDAD AUTONOMA METROPOLITANAProlongacin Canal de Miramontes 3855,Quinto Piso, Col. Ex Hacienda de San Juan de Dios,Del. Tlalpan, C.P. 14787, Mxico D.F.

NOTAS DEL CURSO: ADMINISTRACIN DE PROYECTOS

No est permitida la reproduccin total o parcial de este libro, ni sutratamiento informtico, ni la transmisin en ninguna forma o porcualquier medio, ya sea electrnico, mecnico, por fotocopia, por registrou otros mtodos, sin el permiso previo y por escrito de los titulares.

Primera edicin 2012

ISBN: 978-607-477-824-3

Impreso en MxicoImpreso por Publidisa Mexicana S. A. de C.V.Calz. Chabacano No. 69, Planta AltaCol. Asturias C.P.


5/177



1

Contenido

INTRODUCCIN ........................................................................................................................................... 3

OBJETIVOS ................................................................................................................................................... 5

CAPTULO I EL ESPECTRO DE LA ADMINISTRACIN DE PROYECTOS. ........................................................ 7

I.1 QU SIGNIFICA LA ADMINISTRACIN DE PROYECTOS? ...................................................................................... 7I.2 EL PERSONAL............................................................................................................................................ 8

I.3 EL PROBLEMA. ........................................................................................................................................ 10I.4 EL PROCESO DE LA ADMINISTRACIN DE UN PROYECTO. .................................................................................. 12I.5 PLANEACIN, RIESGOS Y HERRAMIENTAS. ..................................................................................................... 14

CAPTULO II EL PERSONAL. ................................................................................................................. 16

II.1 LOS PARTICIPANTES. ................................................................................................................................ 16II.2 LOS JEFES DE EQUIPO ............................................................................................................................... 17II.3 EL EQUIPO DE DESARROLLO DE SOFTWARE. ................................................................................................... 21II.4 ASPECTOS SOBRE LA COORDINACIN Y LA COMUNICACIN............................................................................... 24II.5 ERRORES CLSICOS RELACIONADOS CON LAS PERSONAS................................................................................... 26

CAPTULO III EL PROBLEMA ................................................................................................................. 30

III.1 ORIGEN DE UN PROYECTO .................................................................................................................... 30

III.2 MBITO DEL SOFTWARE. ...................................................................................................................... 31III.3 DESCOMPOSICIN DEL PROBLEMA PARA SOLICITAR LA APROBACIN DEL PROYECTO QUE LO RESOLVER. .............. 33III.4 ERRORES CLSICOS RELACIONADOS CON LA TECNOLOGA............................................................................ 34

CAPTULO IV EL PROCESO DE LA ADMINISTRACIN DE UN PROYECTO ................................................ 37

IV.1 CICLO DE VIDA DEL PROCESO DE ADMINISTRACIN DEL PROYECTO ................................................................ 37IV.2 TAXONOMA DE LOS MODELOS Y METODOLOGAS DE DESARROLLO DE SOFTWARE MS UTILIZADOS ..................... 44IV.3 ELECCIN DEL CICLO DE VIDA DEL PROYECTO ............................................................................................ 52IV.4 ADMINISTRACIN EFICIENTE DE UN PROYECTO.......................................................................................... 63IV.5 ERRORES CLSICOS RELACIONADOS CON EL PROCESO ................................................................................. 66

CAPTULO V PLANEACIN DEL PROYECTO .......................................................................................... 69

V.1 LA PLANIFICACIN DEL PROYECTO .......................................................................................................... 69V.2 ESTIMACIN...................................................................................................................................... 74V.3 MEDIDAS, MTRICAS E INDICADORES...................................................................................................... 80V.4 EL MODELO CONSTRUCTIVO DE COSTOS (COCOMO) .............................................................................. 85V.5 ERRORES CLSICOS RELACIONADOS CON EL PRODUCTO............................................................................... 96

CAPTULO VI ADMINISTRACIN BASADA EN RIESGOS ......................................................................... 98


6/177



2

VI.1 EL PROCESO DE LA GESTIN DE RIESGOS .................................................................................................. 98VI.2 ESTIMACIN DE LOS RIESGOS .............................................................................................................. 101VI.3 CONTROL DE RIESGO ......................................................................................................................... 104

CAPTULO VII HERRAMIENTAS PARA AUMENTAR LA PRODUCTIVIDAD .............................................. 108

VII.1 LAS HERRAMIENTAS PARA EL SOPORTE DE LA PRODUCTIVIDAD ................................................................... 108VII.2 PRINCIPALES TIPOS DE HERRAMIENTAS QUE EXISTEN EN EL MERCADO. ......................................................... 109VII.3 ADQUISICIN Y USO DE HERRAMIENTAS PARA EL SOPORTE DE LA PRODUCTIVIDAD ......................................... 111

CAPTULO VIII RECUPERACIN DE PROYECTOS. .................................................................................. 136

VIII.1 INTRODUCCIN................................................................................................................................ 136VIII.2 PANORAMA DEL DESARROLLO DE PROYECTOS DE SOFTWARE:CONCLUSIN VS.ABANDONO ........................... 137VIII.3 RECUPERACIN DE PROYECTOS DE SOFTWARE ....................................................................................... 138VIII.4 PROPUESTA DE UN PLAN PARA LA RECUPERACIN DE PROYECTOS DE SOFTWARE. ........................................... 143VIII.5 CONCLUSIONES DE LA PROPUESTA METODOLGICA................................................................................. 166

BIBLIOGRAFA .......................................................................................................................................... 170


7/177



3

Introduccin

Estas notas tienen el objetivo de apoyar el curso trimestral de Administracin deProyectos. Normalmente, cuando los alumnos inician este curso, ya han aprendido ypuesto en prctica diversos paradigmas de desarrollo de software, como desarrollo encascada, procesos evolutivos, reutilizacin de componentes o incluso el proceso unificadode desarrollo. Adems han profundizado en el estudio de anlisis de requerimientos y de lasestrategias de calidad y pruebas ms comunes para procurar el xito de un proyecto. Sinembargo, les falta integrar todos estos conceptos y verlos desde la perspectiva de laadministracin del proyecto en su conjunto.

En la actualidad sigue siendo elevado el nmero de proyectos de software que seabandonan o fracasan, sobre todo cuando stos son complejos e involucran miles o millonesde dlares para su realizacin. En la mayora de los casos, el fracaso se debe a que eltiempo utilizado para el desarrollo del proyecto hace que ste se convierta en no viable. Sehan hecho estudios acerca de los fracasos en los proyectos de software, por ejemplo[Mangione, 2003] y [McManus & Wood, 2004]. El fracaso de proyectos de softwarealgunas veces ha implicado la prdida de muchsimo dinero o incluso la prdida de vidashumanas por entregar productos defectuosos [Pfleger & Atlee, 2002; Weitzenfeld, 2004].Es comn que algunos desarrolladores de software piensen que tienen demasiado trabajocomo para dedicar un tiempo a aprender mtodos de trabajo eficaces que ayuden a resolver

la mayora de los problemas relacionados con el tiempo de desarrollo, sin embargo,mientras continen sin aprender estos mtodos, no dejarn de trabajar a marchas forzadas nitendrn tiempo suficiente para su vida personal [McConnell, 1997].

Es importante que el futuro ingeniero de software est capacitado en la Administracinde Proyectos antes de que se integre por completo a la vida laboral, donde es comn, quela presin por entregar el producto a como de lugar y en una fecha lmite, impida finalizarcon xito un proyecto. El alumno debe saber que seguir un buen proceso de desarrollo desoftware, aplicando correctamente las normas de calidad, no garantiza que un proyecto seentregar trabajando correctamente y adems en el tiempo estimado, ya que existen otrosaspectos importantes que se deben tomar en cuenta.

El trabajo organizado de la siguiente manera. En el captulo I se da una visin global delos aspectos ms importantes de la administracin de un proyecto. El captulo II aborda losdiferentes aspectos a tomar en cuenta al trabajar con el personal que participa en elproyecto. La forma de estudiar los problemas para evaluar si stos deben o no, dar origen aun nuevo proyecto, se expone en el captulo III. En el captulo IV se estudia en detalle el


8/177



4

proceso de la administracin de un proyecto. El captulo V es una introduccin a los temasrelacionados con la planeacin de un proyecto. El captulo VI est dedicado a laadministracin basada en riesgos. En el captulo VII se mencionan algunas de las

herramientas existentes para aumentar la productividad y finalmente, el captulo VIII es unaintroduccin al tema de la recuperacin de proyectos.


9/177



5

ObjetivosQue al final del curso el alumno sea capaz de:

1. Comprender y ubicar la importancia de los elementos personal, problema y procesoen la administracin de proyectos de software.

2. Conocer los estndares, mtodos, tcnicas y herramientas para la administracin deproyectos de software.

3. Organizar equipos eficaces, motivados y coordinados.4. Obtener del cliente una especificacin clara y detallada de los objetivos que ste

persigue.5. Adaptar el proceso de desarrollo a las necesidades del cliente y a las peculiaridades

del personal.6. Administrar un proyecto de software.


10/177



6


11/177



7

Captulo I El espectro de la administracinde proyectos.

I.1 Qu significa la administracin de proyectos?

Administrar un proyecto consiste en planificar y dar seguimiento a los proyectos dedesarrollo de software utilizando los recursos necesarios para realizar el proyecto en elmenor tiempo posible y con un mnimo nmero de fallas. Esto no es fcil, ya que en laprctica se tienen limitaciones como son un nmero reducido de mano de obra, falta decapacitacin de los recursos humanos disponibles, equipo de cmputo insuficiente oinadecuado, etc. Para logar el xito de un proyecto es necesario ayudarse conconocimientos, habilidades, herramientas y tcnicas que estudiaremos a lo largo de estecurso.

Para medir el xito de un proyecto se toma en cuenta que los objetivos planteados selogren en el tiempo previsto y con el presupuesto asignado.

Segn [Briseo, 2003] los objetivos de la administracin de proyectos sonprincipalmente:

Terminar a tiempo. Dentro del presupuesto. Cumpliendo con los requerimientos.

Mientras que los elementos a administrar son: cliente, calidad, recursos, riesgos,comunicaciones, contrato y finanzas.

La administracin de un proyecto consiste en: Comunicar a las personas lo que deben hacer y cundo entregar resultados. Organizar el trabajo: dividirlo y programarlo en el tiempo. Supervisar todo el proceso para saber si se estn obteniendo los resultados

esperados.

La administracin exitosa de un proyecto requiere tomar en cuenta los siguientes cuatro

factores claves:1. El personal que intervendr.2. El producto que se entregar.3. El proceso que se aplicar.4. La tecnologa que se va a utilizar.


12/177



8

Comenzaremos con una exposicin sobre el personalque interviene en un proyecto, esteincluye a las personas que aprueban el proyecto, a los lderes o responsables del proyecto yal equipo de desarrolladores de software.

I.2 El personal

Cualquier organizacin que trate de mejorar su productividad de una manera seria yefectiva debe ocuparse en primer lugar, de los temas relacionados con el personal, como: lamotivacin, el equipo de trabajo, la seleccin y la formacin del mismo. Antes de comenzarcon estos temas, es interesante mencionar quienes son las personas que normalmente tomanla decisin de aprobar un proyecto de software.

I.2.1 Los que proponen el proyecto

La revisin de propuestas para proyectos se lleva a cabo en la mayora de lasorganizaciones porlos comits directivos. En general este tipo de comits esta conformadopor:

1. Miembros de alto nivel administrativo: como el vicepresidente ejecutivo, o elvicepresidente de produccin.

2. Gerentes departamentales: como gerente de ventas y mercadotecnia o gerente deldepartamento de crdito.

3. Gerentes tcnicos: como el gerente de investigacin y desarrollo o el coordinador decontrol de calidad.

4. Grupo de sistemas de informacin: como el gerente de procesamiento de datos, o eljefe analista de sistemas.

Es importante notar que este grupo no est dominado por los especialistas en sistemas desoftware, que son los que realmente tienen una idea del esfuerzo que significa laelaboracin del proyecto.

El comit recibe las propuestas y las evala. La mayor responsabilidad del comit estomar una decisin, y con frecuencia sta requiere de ms informacin que la contenida enla propuesta. Por consiguiente, a menudo se solicita ms informacin para reunir elementossuficientes. Las decisiones se toman con base a los costos del proyecto, su beneficio para laorganizacin y la factibilidad de llevarlos a cabo dentro de los lmites de la tecnologa con

la que cuenta la empresa.


13/177



9

I.2.2 Seleccin del personal para los equipos del proyecto

La seleccin de las personas que van a conformar el equipo de desarrollo del proyecto

implica otras habilidades por parte del administrador del proyecto que van ms all de sucapacitacin tcnica. Podra creerse que una slida formacin cientfica y tecnolgicagarantiza la capacidad para coordinar y llevar a buen trmino un proyecto de este tipo. Sinembargo se ha comprobado que el administrador de un proyecto requiere tambin dehabilidades que tienen que ver con su capacidad de establecer buenas relacionesinterpersonales y con su conocimiento de tcnicas de liderazgo [Robbins, 1996] junto conla facultad de detectar el talento y el tipo de personas con las que se cuenta para hacer unequipo de trabajo. Segn McConell, [Bohem, 1981] presenta los siguientes cinco principiospara la seleccin del personal que participar en un proyecto de software:

1. Mximo talento.- Significa usar poco y buen personal.2. Trabajo adecuado.- Asignar tareas segn la habilidad y motivacin de la gente

disponible.3. Progresin profesional.- Ayudar a la gente a actualizarse por s misma en vez de

obligarles a trabajar donde ms experiencia tienen o donde son ms necesarios.4. Equilibrar el equipo.- Seleccionar a personas que se complementen entre s y

armonicen con los dems.5. Eliminar la inadaptacin.- Aunque esto puede parecer muy duro, para que un

proyecto tenga xito ser necesario eliminar y remplazar a lo miembrosproblemticos del equipo lo antes posible.

I.2.3 La motivacin del personal

La motivacin es potencialmente el aliado ms fuerte para el desarrollo del proyecto, unapersona desmotivada es una persona aptica que no entregar nunca los mismos resultadosque una persona motivada.

(McConnell 1997)

Figura1.1: Es muy importante no confundirmotivacin con represin.


14/177



10

Cuando un coordinador no tiene el talento suficiente para manejar a las personas puederecurrir a argumentos represivos, como amenazas de cualquier tipo, las amenazas elevan elstress de las personas lo que a su vez las hace ms propensas a cometer errores. Otro error

comn es hacer que las personas se sientan incapaces por no haber cumplido con algnobjetivo en el plazo establecido. Desvalorizar a las personas baja su estado de nimo, lo quetrae como consecuencia su falta de inters por el trabajo.

Por otra parte, la motivacin genera un alto rendimiento y la obtencin de resultados,incluso mejores a las expectativas que el coordinador se haba formado. La motivacin noes una tarea fcil para el administrador del proyecto ya que no existe una frmula mgicapara motivar a los empleados, pues cada cabeza es un mundo y lo que funciona bien paraun tipo de personas podra resultar contraproducente para otras. Es aqu donde se puedeobservar la complejidad del problema al que se enfrenta un jefe que debe lidiar conpersonas para que entre todos logren un objetivo comn, que en el caso que nos conciernees la entrega de un producto de software funcionando correctamente y en el plazoestablecido.

Si bien no hay frmulas mgicas, el sentido comn nos indica que hay ciertos puntos quemotivan a cualquier ser humano, cabe sealar que el arte de dirigir un proyecto consiste enencontrar la forma de lograr:

Que la persona se sienta til y capaz de lograr el trabajo que se le haencomendado.

Que la persona sienta que su trabajo es reconocido y apreciado por los dems. Que la persona tenga inters por seguir aprendiendo cosas nuevas y seguirse

superando. Que la persona est dispuesta a cooperar con los dems miembros del equipo, a

aceptar comentarios constructivos y a compartir sus logros y conocimientos sinsentirse amenazado.

En el captulo II trataremos de una manera ms amplia los diferentes aspectos que hayque tomar en cuenta acerca del personal cuando se requiere administrar un proyecto.

I.3 El problema.

Desde un primer punto de vista, el problema es aquel que resuelve el proyecto, desde estepunto, podemos distinguir tres razones principales para proponer un proyecto [Senn,

1992]:1. Resolver un problema: actividades, procesos o funciones que no satisfacen losestndares de desempeo o las expectativas, por lo que es necesario emprender unaaccin que resuelva las dificultades, por ejemplo, disminuir el nmero excesivo deerrores en los datos de entrada.


15/177



11

2. Aprovechar una oportunidad: un cambio para mejorar el rendimiento econmico dela empresa y su competitividad, por ejemplo: un nuevo programa con mayornumero de vuelos directos y descuentos en el precio del pasaje.

3. Dar respuesta a directivos: proporcionar informacin en respuesta a rdenes,solicitudes o mandatos originados por una autoridad legislativa o administrativa;llevar a cabo tareas de cierta manera, o tambin cambiar la informacin.

Desde un segundo punto de vista, el problema puede ser visto como la administracin delproyecto en s, ya que esto representa todo un reto para el responsable del proyecto.

Para la administracin correcta es necesario poseer las siguientes habilidades: Liderazgo. Comunicacin. Negociacin.

Solucin de problemas. Capacidad de sntesis para el logro de objetivos.

Adems, son necesarios conocimientos tcnicos y administrativos que permitan aladministrador manejar las herramientas y tcnicas necesarias.

En la figura 1.2 se muestra un diagrama de las entradas y salidas cuando se tiene unaadministracin precisa en un proyecto de software, mientras que en la figura 1.3 serepresentan los problemas que surgen cuando la planificacin resulta ser demasiadooptimista.

Figura 1.2: Diagrama de un proyecto con una planificacin precisa (McConnell, 1997).


16/177



12

Figura 1.3: Diagrama de un proyecto con una planificacin excesivamente optimista (McConnell, 1997).

En el captulo III se aborda nuevamente el tema del problema con mayor profundidad.

I.4 El proceso de la administracin de un proyecto.

La administracin de proyectos tiene tres objetivos fundamentales: Terminar a tiempo. Dentro del presupuesto. Cumplir con los requerimientos.

Adems, es necesario administrar correctamente todos los factores que intervienen en eldesarrollo de un proyecto, los principales son: cliente, calidad, recursos, riesgos,comunicaciones, contrato y finanzas.

Para lograr los tres objetivos fundamentales, tomando en cuenta a todos los factores queintervienen, se ha establecido un proceso de la administracin proyectos [PMI, 2008] elcual consta de las fases o etapas que se ilustran en la figura 1.4. Como puede observarse,los subprocesos de planeacin y ejecucin se retroalimentan mutuamente.


17/177



13

Figura 1.4: Etapas de la administracin de proyectos [PMI, 2008].

Las fases o etapas permiten dividir el proyecto en subconjuntos lgicos que facilitan sudireccin, planificacin y control. El nmero de fases, la necesidad de establecerlas y elgrado de control aplicado dependen del tamao, la complejidad y el impacto potencial delproyecto. Independientemente de la cantidad de fases que compongan un proyecto, todasellas poseen caractersticas similares. Cuando las fases son secuenciales, el cierre de unafase termina con la entrega del trabajo producido para que ste sea la entrada de la siguientefase. La terminacin de cada fase representa un punto natural para re-evaluar el esfuerzo encurso y, en caso de ser necesario, para cambiar o terminar el proyecto. Estos puntos seconocen como salidas de fase, hitos, puertas de fase, puntos de decisin, puertas de etapa o

puntos de cancelacin [PMI, 2008].

El Project Management Body of Knowledge, (PMBOK

) es un documento escrito y

distribuido por el Project Management Institute (PMI

) de los Estados Unidos (www.pmi.org);el PMI es una organizacin profesional que se ha convertido en la referencia a nivel mundialpara la administracin de proyectos.

El iniciodel proyecto incluye la definicin de lo se debe lograr con el proyecto, plantearel alcance y la seleccin de los miembros iniciales del equipo. El alcance de un proyectodefine el tamao del proyecto, cuanto tiempo y cuantos recursos se requieren.

La planeacindel proyecto consiste en: perfeccionar el alcance, hacer un listado detareas y actividades para lograr las metas, definir una secuencia de actividades, desarrollarun calendario y elaborar un presupuesto. El plan del proyecto debe aprobarse segn lasnormas de calidad establecidas antes de proceder con la siguiente etapa.

Control

Inicio Cierre

laneacin

e ecucin


18/177



14

La ejecucin del proyecto incluye: dirigir al equipo, comunicarse con el cliente,proveedores y dems externos, resolver conflictos y asegurar los recursos necesarios(dinero, personal, equipo y tiempo).

El cierredel proyecto contempla una serie de actividades, tales como: reconocimiento de logros y resultados, cierre de las actividades y dispersin del equipo, aprendizaje de la experiencia del proyecto, revisin del proceso y resultados, redaccin del informe final, auditoras.

El controlse lleva a cabo a lo largo de toda la administracin del proyecto, lasactividades que corresponden al controldel proyecto son las siguientes:

Vigilar las desviaciones del plan.

Acciones correctivas. Recibir y evaluar cambios solicitados. Cambiar calendarios. Adaptar recursos. Regresar a la etapa de planeacin para hacer ajustes. Control de costos. Control de calidad. Informes de resultados. Comunicacin con los interesados.

En el captulo IV se estudia en detalle el proceso de la administracin de un proyecto.

I.5 Planeacin, riesgos y herramientas.

La planeacin o planificacin de un proyecto comprende lo siguiente: desarrollar un planpara la direccin del proyecto, recopilar los requerimientos, definir el alcance del proyecto,crear la estructura de desglose del trabajo, definir las actividades y darles una secuencia,hacer una estimacin de los recursos necesarios para llevar a cabo las actividades delproyecto y una estimacin de la duracin de cada actividad, desarrollar un cronograma,estimar los costos del proyecto, determinar el presupuesto, planificar la calidad, losrecursos humanos, las comunicaciones, la gestin de riesgos y las adquisiciones. En el

captulo V se da un panorama general de lo que es la planeacin de un proyecto y laintroduccin al modelo de estimacin de costos llamado COCOMO.

El desarrollo de proyectos complejos de software lleva implcita la existencia de ciertosriesgos que si no se toman en cuenta y se analizan con cuidado, retrasarnconsiderablemente la entrega del producto o incluso podran llegar a causar la cancelacin


19/177



15

del proyecto. En el captulo VI se abordan el proceso de gestin de riesgos, su estimacin, ysu control.

Existen herramientas para aumentar la productividad durante el proceso de la

administracin de proyectos, stas se concibieron con el fin de automatizar o apoyar una oms fases del ciclo de vida del desarrollo de sistemas de software. En el captulo VII seabordan estas herramientas.


20/177



16

Captulo II El personal.II.1 Los participantes.

Antes de empezar a planear un proyecto que involucra o que da soporte ya sea a una parteo a toda una empresa en general, es necesario tener un panorama general de lo que es unaempresa. Los organigramas se emplean con frecuencia para describir la forma en la queestn relacionados los diferentes componentes de una organizacin. En la figura 2.1 semuestra un ejemplo de organigrama.

Figura 2.1: organigrama de una empresa XYZ de fabricacin. (Senn 1992).

Como se puede observar, aunque un organigrama indica con precisin las relacionesformales entre los diferentes componentes de la organizacin tales como divisiones,departamentos, oficinas y empleados, no contienen informacin importante que es muynecesaria para el administrador del proyecto, quien debe investigar adems:

Interacciones entre las personas y los departamentos. Interdependencias: departamentos y otros componentes de la organizacin de

los cuales depende un elemento en particular.

Personas y funciones clave: Personas y elementos ms importantes en el sistemapara que ste tenga xito. Enlaces crticos de comunicacin: Determinar como es el flujo de informacin y

de instrucciones entre los distintos componentes de la organizacin.


21/177



17

II.2 Los jefes de equipo

II.2.1 Directivos y responsables tcnicos

Cuando un buen desarrollador de software lleva un tiempo considerable trabajando parauna empresa llega un momento en el que sube de nivel y de pronto se enfrenta al reto dedirigir a otras personas, es as que de realizar labores cien por ciento tcnicas, pasa adesempear labores de gestin y de direccin sobre sus compaeros de trabajo. En estasituacin es muy comn cometer uno o varios de los siguientes errores sealados por[McConnell, 1997]:

Tratar de competir en conocimientos con el equipo tcnico asignado. Atender ms las labores propias que a las del grupo.

Preocuparse ms por los requerimientos tcnicos que por los funcionales. Centrarse en continuar perfeccionando el perfil tcnico descuidando otras

disciplinas. Negarse a la necesidad de realizar labores de gestin y supervisin. Reportar a los responsables con excesivo nivel de detalle para demostrar nuestra

capacidad de trabajo.Es importante identificar estos problemas para as poder iniciar su solucin. La

capacitacin sobre temas tales como gestin de costos, de riesgos, de adquisiciones,tcnicas de valoracin, negociacin y motivacin es bsica cuando se pretende dirigir a unequipo. Probablemente, lo primero que aprender un nuevo dirigente es a incrementar sudisciplina, a optimizar el tiempo y a ayudarse de sencillas tcnicas y herramientas que le

permitan acumular conocimiento y no repetir trabajo innecesariamente. La figura 2.2muestra las diferentes habilidades que deben poseer los miembros de un equipo de trabajoen funcin del papel que desempean: mandos superiores, mandos medios o nivelesoperativos.


22/177



18

Figura 2.2: Habilidades de los equipos de trabajo (Subsecretara de la funcin pblica).

II.2.2 La motivacin.

En el apartado I.2 se mencion la importancia de la motivacin del personal. En estaseccin mencionaremos las diferentes personalidades y cual es la ms comn en los

desarrolladores de software, cmo motivar y finalmente lo que hay que evitar para no bajarla moral de los participantes de un proyecto de software.

Existe una prueba llamada Myers Briggs Type Indicator (MBTI). E1 MBTI mide laspreferencias de las personas en cuatro dimensiones y propone una clasificacin usandoletras. Las categoras son:

Extraversin (E) o introversin (I). Sentido (S) o intuicin (N). Pensamiento (T) o sentimiento (F). Opinin (J) o percepcin (P).

En MBTI existen 16 tipos de personalidad. Sin demasiada sorpresa, dos estudios intensoshan encontrado que los profesionales de las computadoras son mucho ms introvertidosque las personas en general, segn [McConnell, 1997]. Introvertidos en el contexto delMBTI simplemente significa que la persona est ms interesada en el mundo interior de lasideas que en el mundo externo de las personas y cosas. Los desarrolladores en general estnms interesados en la posibilidad de superacin que los dems grupos, y menos interesados

Alto

Ba o

Compe ten ci as tcn ic as

Niveles operativos Mandos medios Niveles superiores

Competenciasadminist rat ivas


23/177



19

en la posicin social y el reconocimiento segn dichos estudios. Los mismos estudiosdescubrieron que el 80% de los profesionales de las computadoras prefieren el pensamiento(T) sobre el sentimiento (F), comparados con el 50% de las personas en general. Los T

prefieren tomar decisiones basadas en unas bases lgicas e impersonales ms que envalores personales subjetivos. Esta inclinacin lgica y planificada se refuerza por laspreferencias de los profesionales de las computadoras en la opinin (J) sobre la percepcin(P) (las dos terceras partes de los profesionales de las computadoras son J, comparados conla mitad de las personas en general). Los J tienden a vivir de una forma ordenada yplanificada, mientras que los P tienden a ser ms flexibles y adaptables.La implicacin de esta preferencia es clara: Si desea apelar a un desarrollador, ser mejorutilizar argumentos lgicos. Por ejemplo, mucho de lo que se ha escrito sobre la motivacinsugiere que una clave para la productividad excepcional es establecer objetivosaparentemente imposibles. Esto funciona para los Fs, quienes podran encontrar talesobjetivos inspiradores. Pero los T rechazarn tales objetivos por ser ilgicos. sta es unarazn de que es raro el grupo de desarrolladores que responda positivamente a un objetivode planificacin imposible.

Para cada tipo de personalidad funcionan diferentes formas de motivacin. La motivacinpuede proporcionar ideas generales, pero tendr ms xito si se identifica cual es lamotivacin ms efectiva para cada individuo. Preguntar a las personas lo que piensan es degran ayuda.

Los cinco factores que ms influyen en la motivacin del desarrollador segn[McConnell, 1997] son: realizacin, posibilidad de superacin, el trabajo en s, vidapersonal y oportunidad de supervisin tcnica.

Figura 2.3 La motivacin de un desarrollador de software(McConnell, 1997)


24/177



20

II.2.3 La desmotivacin.

El lder debe tomar en cuenta la personalidad lgica de los desarrolladores de software,adelantar artificialmente la fecha de entrega para cubrirse o una presin irrazonable(figura 2.4) hace que los desarrolladores pierdan el respeto a sus directivos.

Figura 2.4: La presin irrazonable en la planificacin puede hacerque los desarrolladores pierdan el respeto a sus directivos (McConnell, 1997)

El exceso de estrs en los participantes de un proyecto los hace generar ms errores. Espreferible hacer un compromiso con las personas para que trabajen correctamente durantesu jornada de ocho horas con la recompensa de irse temprano que presionar para que haganmuchas horas extras y/o trabajo durante vacaciones y fines de semana. La falta deesparcimiento y de un descanso adecuado genera personas malhumoradas, fatigadas eindispuestas con una fuerte tendencia a producir un trabajo de mala calidad, adems tiendena perder mucho tiempo hablando por telfono, platicando con sus compaeros o jugando enInternet.


25/177



21

Figura 2. 5: Circulo vicioso de presin en la planificacin (McConnell, 1997).Otros destructores de la moral:

Manipulacin de los directivos: dar informacin falsa acerca de fechas lmite.Presin excesiva de la planificacin: presentar a los desarrolladores una fecha lmite

imposible.Falta de apreciacin de los esfuerzos del desarrollador: menospreciar el trabajo de laspersonas es una manera segura de desmotivarla.

Participacin de directivos sin preparacin tcnica: Si un directivo reconoce su falta depreparacin tcnica y reconoce las capacidades del equipo que dirige y sin embargo tienehabilidades para la coordinacin y la motivacin, entonces hay probabilidades de xito,pero, si intenta meterse en decisiones tcnicas que no comprende perder el respeto de sussubordinados y de esta manera ser muy difcil dirigirlos.Lemas, posters, discursos y otros mtodos de motivacin excesivos: pueden resultar

insultantes para la inteligencia del desarrollador de software, con los que funciona mejorun ligero toque.

II.3 El equipo de desarrollo de software.

Para organizar al equipo de trabajo es necesario hacer que su tamao y la estructuraconcuerde con el tamao del proyecto, las caractersticas del producto que se va a entregary los objetivos de planificacin. Segn [McConnell, 1997], el responsable del proyecto desoftware ocupa el papel de productor de una obra de teatro.

l es el responsable de obtener financiamiento, de coordinar, y asegurarse de que todo elmundo esta en el sitio correcto en el momento adecuado. Sin una cuidadosa seleccin depersonal y una direccin estricta, algunos proyectos caen en la mediocridad o incluso

fracasan. E1 modelo de teatro resulta particularmente apropiado para equipos softwaredominados por fuertes personalidades.Todo el mundo sabe que los actores y las actrices son temperamentales, y algunos

desarrolladores de software tambin tienen reputacin de prima donna. Si dentro de unproyecto hay un papel suficientemente importante, y slo puede desempearlo undesarrollador determinado, el director puede decidir si va a entenderse con la prima


26/177



22

donna para la buena marcha del proyecto. Pero si el resto del reparto tambin es potente,puede prescindir de la prima donna para tener un desarrollo tranquilo del proyecto. Elmodelo de teatro es un modelo adecuado para proyectos multimedia modernos. Mientras

anteriormente los proyectos software necesitaban integrar las contribuciones de variosdesarrolladores de software, ahora tienen que integrar las contribuciones de diseadoresgrficos, escritores, productores de vdeo, productores de audio, editores, ilustradores,coordinadores de contenido y varios desarrolladores de software, es decir hay que coordinaa grandes equipos.

As como en las obras de teatro, cuando se contrata al personal se le asigna un rolespecfico, a algunos solo les interesan los papeles principales (diseo), otros aceptancualquier papel mientras no sea el del villano (por ejemplo, para algunos las bases dedatos), a otros no le importa hacer el papel del malo y puede que algn actor est contratadoen otra obra a otro horario y no pueda invertir mucho tiempo, as que le acomoda un papelsecundario (pruebas, por ejemplo). Es muy importante que el responsable del proyectotenga en cuenta lo anterior para no indisponer a los participantes cambiando los papeles, yaque despus surgen los reproches como: Yo dije que hara cualquier cosa menos bases dedatos y eso es precisamente lo que me pusieron a hacer! que hago yo haciendointerfaces de usuario?, esto nunca funcionar correctamente si no consideran en eldiseo!.

Cuando los roles no estn bien definidos y las habilidades de los participantes no soncomplementarias se corre el riesgo de que todos quieran imponer su voluntad.

El responsable tcnico es aquella persona que tiene alguna responsabilidad de gestindentro de un equipo de desarrolladores de software. Habitualmente, a esta persona se leasigna este papel en base a su experiencia tcnica ms que a su experiencia de gestin. Por

lo general, al responsable tcnico le resulta difcil diferenciar entre desarrollo tcnico ygestin, y puede hundir el proyecto si no cumple bien su papel (por estar poco integradocon el equipo o mal relacionado con sus superiores).Los directivos y los responsables tcnicos no trabajan siempre en una estrecha relacin.Hay muchos problemas (superposicin de responsabilidades, motivacin, relaciones con losclientes, baja calidad, poca coincidencia en los objetivos del proyecto, etc.) que puedenmejorarse cuando tienen una comunicacin efectiva sobre los temas con los que estntrabajando. Uno de los mayores obstculos para un rendimiento efectivo de la figura delresponsable tcnico es la falta de una divisin clara de responsabilidades entre elresponsable tcnico y el director. En teora, el responsable tcnico es el responsable deltrabajo tcnico, y es responsable de un solo equipo. El director es responsable de ladireccin de los aspectos no tcnicos del equipo, y es responsable de dos o ms proyectos.Desde el punto de vista del equipo, el papel del director consiste en liberar al responsabletcnico gestionando ciertas tareas no tcnicas. Desde el punto de vista de la organizacin, elpapel del director es controlar el equipo para que se adapte a los objetivos de laorganizacin. Como los detalles especficos de las relaciones entre responsable tcnico ydirector son tan variables, resulta til que ambos discutan sus funciones al principio del


27/177



23

proyecto. Esto ayuda a evitar choques de responsabilidad en los que ambas personaspiensan que son responsables de lo mismo, y vacos de responsabilidad, en los que ambaspersonas creen que el responsable es el otro. Como las funciones especficas pueden variar

dependiendo del proyecto en cuestin, puede usarse lo sugerido por [McConnell, 1997] enla figura 2.3 como punto de partida para definir las responsabilidades del director y delresponsable tcnico y aclarar la divisin de responsabilidades en un proyecto determinado.

Figura 2.6: Responsabilidades del director y del responsable tcnico de un proyecto(McConnell, 1997).


28/177



24

II.4Aspectos sobre la coordinacin y la comunicacin.

II.4.1 El equipo de trabajo.

Los equipos grandes plantean problemas especiales de comunicacin y coordinacin, amedida que se incrementa el nmero de participantes en un proyecto, aumenta tambin elnmero de canales de comunicacin y la necesidad de coordinacin.

Un proyecto con dos personas slo tiene una va de comunicaciones. Un proyecto concinco personas tiene 10 vas. Un proyecto con nueve personas tiene 45, suponiendo quetodo el mundo hable con todo el mundo (ver figura 2.7). Cuantas ms vas decomunicaciones tenga un proyecto, ms tiempo se emplear en las comunicaciones, y habrms oportunidades de que se produzcan errores en la comunicacin. Un proyecto con 1.200vas de comunicacin tiene demasiados caminos para funcionar correctamente, y en la

prctica, los proyectos con 50 personas no estn organizados de modo que todo el mundo secomunique con todo el mundo. Los proyectos grandes requieren mtodos de organizacinque formalicen y simplifiquen las comunicaciones. La formalizacin de las comunicacioneses un elemento importante para tener xito en grandes proyectos. Todos los mtodos parasimplificar las comunicaciones se basan en la creacin de algn tipo de jerarqua, es decir,crear grupos pequeos que funcionen como equipos, y luego asignar responsables dentro dedichos grupos para interactuar entre s y con la directiva.

Figura 2. 7: Vas de comunicacin en funcin del nmero de programadores

(McConnell, 1997).

[McConnell, 1997] recomienda lo siguiente para optimizar la comunicacin: Formar un conjunto de equipos de negocios, y luego designar un representante encada equipo para comunicarse con los otros grupos.


29/177



25

Formar un conjunto de equipos con jefe programador, y hacer responsable de lacomunicacin con otros grupos al programador de reserva. Formar equipos para desarrollar una o un grupo de funcionalidades, y hacer

responsable de la comunicacin con otros grupos al representante de gestin deprogramas. Debe haber una sola persona responsable de que todos los equipos conformen unabuena solucin global.

-Un ao para construir - bien! Manos a la obra,una casa aqu? porque tengo prisa!

No hay problema!

Figura 2. 8: Fallas en la comunicacin (McConnell, 1997).

Figura 2.9: Responsabilidades de los lderes de proyecto (Briseo, 2003)

Las personas dentro de un proyecto necesitan saber: Qu tareas deben hacer. Cundo las deben llevar a cabo. Qu productos deben entregar (documentos, cdigo, etc.)


30/177



26

II.5 Errores clsicos relacionados con las personas.

A continuacin se describen algunos de los errores clsicos relacionados con las personassegn [McConnell, 1997]:

Motivacin dbil.- Estudio tras estudio se ha mostrado que la motivacinprobablemente tiene mayor efecto sobre la productividad y la calidad queningn otro factor [Boehm, 1981]. Es importante no tomar medidas quebajen la moral: como dar muchos nimos al principio para pedir horas extrasen la mitad del proyecto, o como irse de vacaciones mientras el equipo haestado trabajando incluso los das festivos, o dar recompensas al final delproyecto que resulten ser de menos de lo que las personas deberan ganar porcada hora extra.

Personal mediocre.- Despus de la motivacin, la capacidad individual delos miembros del equipo, as como sus relaciones como equipo,probablemente tienen la mayor influencia en la productividad [Boehm,1981]. No hay que escatimar esfuerzos en buscar a personal realmente capazaunque sea a costa de invertir ms tiempo en la bsqueda.

Empleados problemticos incontrolados.- El personal problemticotambin representa una amenaza a la velocidad de desarrollo. El manejoincorrecto de un empleado problemtico casi siempre ocasiona quejas de losdems miembros de un equipo. Cuando se tiene un empleado de este tipo ysus compaeros lo manifiestan, hay que tener cuidado, pues es muy probable

que posteriormente otros tengan que re-hacer el trabajo de ese empleado. Hazaas.- Algunos directivos dan ms aplausos a los alardes de gran

capacidad que a los progresos firmes y consistentes y a los informessignificativos de progreso, cuando se le da ms importancia a estas actitudesque a los informes del estado exactos, que a veces son pesimistas, losdirectivos de estos proyectos no pueden tomar medidas correctivas alrespecto, es ms, ni siquiera saben que tienen que emprender accionescorrectivas hasta que el dao ya est hecho.

Aadir ms personal a un proyecto retrasado .- ste es quizs el ms

clsico de los errores clsicos. Cuando un proyecto se alarga, aadir msgente puede quitar ms productividad a los miembros del equipo existente dela que aaden los nuevos miembros, ya que se puede perder ms tiempo delque se pretende ahorrar, en capacitar a los nuevos miembros paraincorporarlos y hacerlos realmente productivos.


31/177



27

Oficinas repletas y ruidosas.- La mayora de los desarrolladores consideransus condiciones de trabajo como insatisfactorias. Los trabajadores que estnen oficinas silenciosas y privadas tienden a funcionar significativamente

mejor que aquellos que ocupan cubculos en salas ruidosas y repletas. Losentornos repletos y ruidosos alargan los planes de desarrollo.

Figura 2.10: Ambiente improductivo

(McConnell, 1997)


32/177



28

Figura 2.11: Diseos de oficinas productivas segn IBM(IBM Systems Journal, vol 17, nm. 1)

(McConnell 1997)

Fricciones entre los clientes y los desarrolladores.- Las fricciones entre losclientes y los desarrolladores pueden presentarse de distintas formas. A losclientes puede parecerles que los desarrolladores no cooperan cuando no quierencomprometerse con el plan de desarrollo que desean los clientes o cuando fallanal entregar lo prometido. A los desarrolladores puede parecerles que los clientesno son razonables porque insisten en planes irreales o cambios en losrequerimientos despus de que stos ya han sido fijados. Pueden sersimplemente conflictos de personalidad entre dos grupos. E1 principal efecto deesta friccin es la mala comunicacin, y los efectos secundarios de la malacomunicacin incluyen el pobre entendimiento de los requerimientos, pobrediseo de la interfaz de usuario y, en el peor caso, el rechazo del cliente a

aceptar el producto acabado. En algunos casos, las fricciones entre clientes ydesarrolladores de software llegan a ser tan severas que ambas partes consideranla cancelacin del proyecto. Para remediar estas fricciones se consume tiempo ydistraen tanto a desarrolladores como a clientes del trabajo real en el proyecto.

Expectativas poco realistas.- Una de las causas ms comunes de friccionesentre los desarrolladores y sus clientes o los directivos son las expectativas pocorealistas. La incapacidad para corregir expectativas irreales es una de lasprincipales fuentes de problemas. En algunos casos, los directivos o losdesarrolladores de un proyecto se buscan problemas al pedir fondos basndoseen estimaciones de planificacin demasiado optimistas, en las que prometenentregar demasiadas funcionalidades en muy poco tiempo. El no entregar un

proyecto en el tiempo estimado hace que parezca un proyecto malo. Falta de un promotor efectivo del proyecto.- Para lograr buenos resultados se

necesita un promotor del proyecto de alto nivel capaz de llevar a cabo unaplanificacin realista, el control de cambios y la introduccin de nuevosmtodos de desarrollo. Sin un promotor ejecutivo efectivo, el resto del personalde alto nivel de la empresa puede forzar a que se acepten fechas de entregairreales o hacer cambios que debiliten el proyecto.

Falta de participacin de los implicados.-. La cooperacin estrecha entre losparticipantes de un proyecto slo se produce cuando todos se involucran, estoincluye a los promotores, ejecutivos, responsables del equipo, miembros delequipo, personal de ventas, usuarios finales y clientes.

Falta de participacin del usuario.- Cuando no se involucra al usuario desde elprincipio se corre el riesgo de no comprender bien los requerimientos delproyecto, as que ser muy probable que se consuma tiempo en modificarrequerimientos que finalmente lo retrasarn.

Poltica antes que desarrollo.- Es importante evitar grupos que se dediquen acultivar solamente las relaciones con los directivos, o grupos que mantienen


33/177



29

cerradas las fronteras a los que no son miembros del equipo. Tampoco es buenotener personas que hagan un poco de todo, ya que el que mucho abarca pocoaprieta. Lo mejor es que en un ambiente de cooperacin mutua, existan personas

dedicadas a explorar y reunir informacin y otros que coordinen a los equipos detrabajo y establezcan las relaciones con los directivos. Ilusiones.- Un ejemplo tpico de ilusin es el caso en el que ninguno de los

miembros del proyecto cree realmente que ste pueda completarse de acuerdocon el plan que tienen, pero piensan que quizs si trabajan duro y nada va mal, ytienen un poco de suerte, sern capaces de concluir con xito. Otro caso comnes el del equipo que no hace mucho trabajo para la coordinacin de las interfacesentre las distintas partes del producto, pero tienen una buena comunicacin paraotras cosas, y como consideran que las interfaces son relativamente simples,probablemente solo necesitarn un da o dos para eliminar los errores. Otroejemplo de ilusin es contar con un desarrollador de poco talento y/o poca

experiencia y creer que puede compensar con mucho trabajo lo que le falta y queprobablemente acabar a tiempo.Las ilusiones no son slo optimismo. Realmente consisten en cerrar los ojos yesperar que todo funcione cuando no se tienen las bases razonables para pensarque ser as. Las ilusiones al comienzo del proyecto llevan a grandesexplosiones al final. Impiden llevar a cabo una planificacin coherente y puedenser la raz de ms problemas en el software que todas las otras causascombinadas.


34/177



30

Captulo III El problemaDefinicin de Proyecto: Segn la gua del Project Management Institute [PMI, 2008] unproyecto es un esfuerzo temporal para crear un producto, servicio o resultado nico. Lanaturaleza temporal de los proyectos indica un principio y un final definidos. El final sealcanza cuando se logran los objetivos del proyecto o cuando se termina el proyecto porquesus objetivos no se cumplirn o no pueden ser cumplidos, o cuando ya no existe lanecesidad que dio origen al proyecto. Temporal no necesariamente significa de cortaduracin. Todo proyecto crea un producto, servicio o resultado nico.

III.1Origen de un proyecto

La competitividad creciente, el constante cambio tecnolgico y la globalizacin hanobligado a las empresas a reaccionar con rapidez ante los cambios del entorno y es ascomo alguno o varios de los factores de lafigura 3.1 desencadenan la necesidad de llevar acabo la gran mayora de los proyectos:

Figura 3.1: El origen del proyecto (Subsecretara de la Funcin Pblica, Senn, 1992).

Una necesidad del mercado.- Modificar u optimizar los procesos existentes.Una necesidad de negocios.- Fusiones entre empresas, adquisiciones.El requerimiento de un cliente o proveedor.- Cambiar algo que ya existe o agregar nuevasfuncionalidades.Un avance tecnolgico.- Nuevas plataformas tecnolgicas.


35/177



31

Un requerimiento legal.- Disposiciones gubernamentales o ambientales ms estrictas.

Una vez que surge la necesidad del proyecto, es necesario analizar el mbito del software

que se utilizar y posteriormente definir el problema a resolver descomponindoloadecuadamente.

III.2mbito del software.

La primera actividad de gestin de un proyecto es la determinacin del mbito delsoftware [Pressman, 2006]. Es necesario determinar si el nuevo producto se desarrollardentro de un contexto ms grande y que restricciones tendr, tambin hay que identificarlos datos de entrada y los que el usuario requiere visualizar y por ltimo hay que identificarlas funciones que realiza el software para transformar datos de entrada en salida.

Existen varios criterios para clasificar los proyectos de software, por ejemplo, McConnellos clasifica en 3 diferentes: 1) Software de sistemas: sistema operativo, controladores dedispositivos, compiladores y bibliotecas de cdigo, tambin software empotrado(embebido), firmware, sistemas en tiempo real y software cientfico. 2) Software degestinsistemas internos que se utilizan en una nica empresa (nmina, contabilidad, control dealmacn). 3 Software Prt--porter paquetes de software que se venden comercialmente.Mientras que [Wiegers, 2006] clasifica los proyectos de software en: aplicacionesinteractivas para usuarios, incluyendo aplicaciones web y kioscos de ventas, aplicacionescomputacionalmente intensivas, almacenamiento de datos, procesamiento por lotes yproductos hardware con software embebido.

El software que da soporte a una empresa puede agruparse segn [Senn, 1992] en trescategoras principales que se describen a continuacin:

1.- Sistema para el procesamiento de transacciones: Sustituye los procedimientosmanuales por otros basados en computadora. Trata con procesos de rutina bienestructurados. Incluye aplicaciones para el mantenimiento de registros.

Una transaccin es cualquier suceso o actividad que afecta a toda la organizacin.Las transacciones ms comunes son: facturacin, entrega de mercanca, pago aempleados y depsito de cheques. Los tipos de transacciones cambian para cadaempresa en particular, sin embargo el procesamiento de transacciones incluyesiempre las siguientes actividades:

Clculos. Clasificacin. Ordenamiento. Almacenamiento y recuperacin. Generacin de resmenes.


36/177



32

2.- Sistema de informacin administrativa: Proporciona 1a informacin que serempleada en los procesos de decisin administrativos. Ayuda cuando se presentansituaciones de decisin bien estructuradas y es posible anticipar los requerimientos

de informacin ms comunes.Si bien los sistemas de transacciones estn orientados hacia operaciones, lossistemas de informacin administrativa ayudan a los directivos a tomar decisiones yresolver problemas. Se debe identificar la informacin necesaria para formulardecisiones y desarrollar sistemas de informacin que produzcan reportes de formaperidica en un formato diseado especficamente para ello.

3.- Sistema para el soporte de decisiones: proporciona informacin a los directivosque deben tomar decisiones sobre situaciones particulares. Apoyan la toma dedecisiones en circunstancias que no estn bien estructuradas.

Una decisin se considera no estructurada si no existen procedimientos claros paratomarla y tampoco es posible identificar con anticipacin todos los factores quedeben considerarse en la decisin. Un factor clave en el uso de este tipo de sistemases determinar la informacin necesaria, que en estos caso es difcil encontrar, puesconforme se adquiere la informacin puede ocurrir que el gerente se d cuenta deque necesita ms informacin, por lo tanto este tipo de sistemas debe tener unaflexibilidad mayor que la de los otros. Los sistemas para el soporte de decisionesayudan pero no reemplazan al criterio del directivo.

III.2.1Ventajas del desarrollo de proyectos de software

El desarrollo de proyectos de software debe traer consigo por lo menos una de lassiguientes ventajas:

Mejora de la comunicacin: el objetivo principal es acelerar el flujo de informaciny mensajes entre localidades remotas as como dentro de oficinas. La falta decomunicacin es una fuente comn de dificultades que afectan tanto a clientes comoa empleados. Sin embargo, los sistemas de informacin bien desarrollados amplanla comunicacin y facilitan la integracin de funciones individuales.

Reduccin o monitoreo de los costos: uso de la capacidad de cmputo para procesardatos con un costo menor del que es posible con otros mtodos al mismo tiempoque se mantiene la exactitud de los clculos. Tambin puede determinarse laevolucin de costos de mano de obra, bienes e instalaciones en relacin con loesperado.

Aumento en la capacidad: mayor velocidad de procesamiento, incremento en elvolumen de los datos manejados por el sistema y recuperacin ms rpida de lainformacin.


37/177



33

Control: mayor exactitud y mejora en la consistencia de los datos. Salvaguardardatos importantes de tal forma que solo el personal autorizado tenga acceso a ellos.

Ventaja competitiva: atraer clientes modificando los servicios proporcionados de tal

forma que ellos no opten por cambiar de proveedor. Mejorar los acuerdos con losproveedores. Introduccin de nuevos productos que utilizan sistemas de software.

III.3Descomposicin del problema para solicitar la aprobacin delproyecto que lo resolver.

Para abordar correctamente el problema que un nuevo sistema va a resolver, es importantedescomponerlo y estudiarlo desde sus diferentes perspectivas. A continuacin semencionan los principales puntos que se deben incluir al hacer la solicitud de aprobacin deun proyecto de software.

Definicin del problema. Detalles del problema.

Importancia del problema.

Solucin propuesta.

Una vez que se ha definido el problema con todo y sus detalles, se ha determinado que suimportancia amerita solucin y se ha propuesto el desarrollo de un proyecto de softwarecomo solucin a dicho problema, es necesario someter a evaluacin la solicitud delproyecto. Cuando se evala la solicitud de un proyecto se procura satisfacer los siguientesobjetivos:

Determinacin de lo que se requiere: por qu se requiere? existe alguna razn

diferente a la identificada por el solicitante? Determinar del tamao del proyecto: se trata de un nuevo desarrollo o de la

modificacin de un sistema que ya existe? Evaluar los costos y beneficios de diversas opciones. Determinar la factibilidad tcnica y operacional de las diferentes alternativas. Reportar hallazgos a la administracin y formular recomendaciones que esbocen

la aceptacin o rechazo de la propuesta.

En la figura 3.2 se muestra el formato de una carta del proyecto usado por laSubsecretara de la Funcin Pblica, en este formato se presenta la propuesta del proyectoante un comit que se encargar de determinar si es viable o no llevarlo a cabo.


38/177



34

Figura 3.2: Carta del proyecto (Subsecretara de la Funcin Pblica).

III.4Errores clsicos relacionados con la tecnologa

Segn [McConnell, 1997], los errores tpicos relacionados con el uso correcto o incorrecto

de la tecnologa moderna son los que se mencionan a continuacin:

Sndrome de la panacea.- Sucede cuando se confa demasiado en las supuestasventajas de tecnologas con las que el equipo de desarrollo no ha trabajado antes(generadores de informes, diseo orientado a objetos, nuevos ambientes dedesarrollo). Es probable que la nueva tecnologa s sea muy buena, sin embargono sea la ms apropiada para el ambiente de desarrollo del proyecto enparticular.

Sobreestimacin de las ventajas del empleo de nuevas herramientas omtodos.- Las organizaciones mejoran raramente su productividad a grandessaltos, sin importar cuntas herramientas nuevas o mtodos empleen ni tampoco

lo buenos que stos sean. Los beneficios de las nuevas tcnicas tienen sucontraparte, pues es necesario aprender a utilizarlas para aprovecharlas almximo y hacer esto lleva su tiempo. Las nuevas tcnicas implican nuevosriesgos, que slo se descubren usndolas. Normalmente las mejoras son lentas ycontinuas en lugar de obtenerse grandes saltos. Un caso especial desobreestimaciones de las mejoras se produce cuando se reutiliza cdigo deproyectos anteriores. Este tipo de reutilizacin puede ser una tcnica muyefectiva, pero el tiempo que se gana no es tan grande como se espera.

Cambiar de herramientas a mitad del proyecto .- Es un viejo recurso que raravez funciona. Cuando estamos a la mitad de un proyecto, la curva deaprendizaje, rehacer el trabajo y los inevitables errores cometidos con una

herramienta totalmente nueva, normalmente anulan cualquier beneficio posible. Falta de control automtico del cdigo fuente.- Una falla en la utilizacin del

control automtico del cdigo fuente expone a los proyectos a riesgosinnecesarios. Cuando los desarrolladores trabajan sobre una misma parte de unprograma sin control automtico, deben coordinar su trabajo manualmente.Tericamente deberan coordinarse para poner la ltima versin de cada archivo

CARTA DEL PROYECTONOMBRE DEL PROYECTO:

RESPONSABLE DEL PROYECTO::

OBJETIVO:

BENEFICIOS:

DESCRIPCIN:

PRIORIDAD:

JUSTIFICACIN:

PRODUCTOS:

APROBACIN:


39/177



35

del cdigo fuente en el directorio maestro y verificarlo con los dems antes decopiarla. Sin embargo, muy a menudo sucede que alguno sobre-escribe eltrabajo de otro, esto ocasiona que se desarrolle cdigo nuevo con interfaces

desfasadas, y despus se tiene que redisear el cdigo al descubrir que se hautilizado una versin equivocada. Tambin sucede que los usuarios avisan deerrores que no podemos reproducir porque no hay forma de volver a crear loselementos que han utilizado.


40/177



36


41/177



37

Captulo IV El proceso de laadministracin de un proyecto

IV.1Ciclo de vida del proceso de administracin del proyecto

As como el desarrollo de software se divide en varias fases, tambin la administracin deun proyecto se divide en fases las cuales en su conjunto son conocidas como el ciclo devida de la administracin del proyecto. Como se expuso en el captulo I.4, las fases delproceso de la administracin de un proyecto son: el inicio, la planeacin, la ejecucin y elcierre. Adems se lleva un controldurante el desarrollo de todo el proyecto. En la figura4.1 se puede apreciar una grfica del nivel de actividad del administrador del proyectodurante el ciclo de vida de la administracin del proyecto

Figura 4.1: ciclo de vida del proceso de administracin de un proyecto(Subsecretara de la funcin pblica).

IV.1.1El inicio

El iniciodel proyecto incluye poner en claro qu se debe lograr con ste, plantear elalcance y la seleccin de los miembros iniciales del equipo, la conformacin de un equipode personas adecuado influir mucho en el desarrollo posterior. El alcance de un proyectodefine su tamao del proyecto, el tiempo y los recursos que se requieren.

Los recursos necesarios se deben aprobar durante esta fase y se debe determinar la fechaen la que estarn disponibles para poder empezar. Otras actividades importantes en esta

1. Inicio*

2. Planeacin*

3. E ecucin*

4. Control*5. Cierre*

INICIO TIEMPO

*Etapas delproyecto

TERMINO

NIVEL

DE

A

CVID

AD


42/177



38

etapa son: la definicin de los factores de riesgo y la definicin del o los modelos dedesarrollo de software que se utilizarn.

Al terminar la fase de inicio, adems del contrato, se debe contar con el Acta deConstitucin del proyecto y el documento del Enunciado del Alcance. Al final del inicio delproyecto se debe formalizar la aceptacin del alcance del proyecto, si despus surgencambios stos se aceptan o rechazan mediante un proceso de control. Cuando hay una maladefinicin del alcance, lo ms probable es que el costo del proyecto sea muy alto.

En la tabla 4.1 se especifica lo que debe incluir cada uno de los documentos segn laGua de los fundamentos para la Direccin de Proyectos del Project Management Institute.

Tabla 4.1: Elementos del Acta de Constitucin y del Enunciado del Alcance [PMI, 2008].

IV.1.2La planeacin

La planeacindel proyecto consiste en: perfeccionar el alcance, hacer un listado de tareasy actividades para lograr las metas, definir una secuencia de actividades, desarrollar uncalendario, elaborar un presupuesto, establecer fechas de entregas parciales (hitos) y hacerun plan de emergencia, para que cada participante sepa que hacer en el caso de un cambioen las prioridades o en las tareas.

El plan del proyecto debe aprobarse segn las normas de calidad establecidas antes deproceder con la siguiente etapa. Dependiendo del tamao del proyecto, el proceso deplaneacin puede resultar bastante complejo, esto se expone con ms detalle en el captuloV. En la figura 4.2 podemos observar grficamente las etapas de la administracin delproyecto y todas las actividades de la etapa de planeacin.


43/177



39

Figura 4.2: Etapas de la administracin de proyectos (Briseo, 2003).

IV.1.3La ejecucin

La ejecucin del proyecto incluye: dirigir al equipo, comunicarse con el cliente,proveedores y dems externos, resolver conflictos y asegurar los recursos necesarios(dinero, personal, equipo y tiempo). Como se puede apreciar en la figura 4.1 el proceso deejecucin en la administracin de un proyecto es el que requiere de mayor actividad porparte del administrador.

El monitoreo del proyecto es una de las actividades ms importantes de la ejecucin de laadministracin. Un buen sistema de monitoreo debe contener los siguientes cuatro puntosfundamentales:

1.- Un estndarpara lograr un desempeo aceptable.2.- Un mtodo para medirel desempeo actual.3.- Un mtodo para compararel desempeo actual contra el estndar.4.- Un mtodo de retroalimentacin.

En la prctica, como se puede apreciar en la figura 4.3, las etapas de planeacin yejecucin se retroalimentan una a la otra constantemente.

Figura 4.3: Metodologa de la administracin de proyectos (Briseo, 2003)

IV.1.4El cierre


44/177



40

El cierr edel proyecto contempla una serie de actividades como: reconocimiento de logros y resultados, cierre de las actividades y dispersin del equipo,

aprendizaje de la experiencia del proyecto, revisin del proceso y resultados, redaccin del informe final, auditoras.

El cierre de un proyecto se puede clasificar segn se ilustra en la figura4.4:

Figura 4.4: El cierre de un proyecto. (Subsecretara de la funcin pblica)

El cierre administrativo comprende las siguientes actividades:

La elaboracin y entrega de un Reporte final el cual debe contener:

El presupuesto.

El programa.

Las evidencias.

Las lecciones aprendidas El Reporte de control de cambios.

La entrega de los Archivos del proyecto.

Un Plan de transicin entre el proyecto que finaliza y el siguiente.

El cierre del contrato abarca la recopilacin de lo siguiente: Archivos de contrato. Manuales, planos. Bitcoras. Comunicados. Lecciones aprendidas.

Y finalmente la entrega del producto consiste en entregar el sistema, servicio o resultadofinal al cliente.

IV.1.5El control

Cierre del proyecto

Cierre administrativo

Cierre del contrato

Entrega del producto


45/177



41

El controlse lleva a cabo a lo largo de toda la administracin del proyecto, lasactividades que corresponden al controldel proyecto son las siguientes:

Vigilar las desviaciones del plan.

Acciones correctivas. Recibir y evaluar cambios solicitados. Cambiar calendarios. Adaptar recursos. Regresar a la etapa de planeacin para hacer ajustes. Control de costos. Control de calidad. Informes de resultados. Comunicacin con los interesados.

Es muy importante que el administrador sepa que:

IV.1.6La norma IEEE-1058 para la Planificacin de Proyectos de Software

La direccin de proyectos es una tarea integradora que requiere que cada proceso delproducto y del proyecto est alineado y conectado de manera adecuada con los dems, a finde facilitar la coordinacin. Normalmente, las acciones tomadas durante un proceso afectan

a ese proceso y a otros relacionados. Una direccin de proyectos exitosa incluye dirigiractivamente estas interacciones a fin de cumplir con los requisitos del patrocinador, elcliente y los dems interesados. En determinadas circunstancias, ser necesario repetirvarias veces un proceso o conjunto de procesos para alcanzar el resultado requerido [PMI,2008].

Durante la ejecucin del proyectose debe controlar el trabajo y no alos trabajadores.


46/177



42

Figura 4.5: Diagrama de estados de la Administracin de un Proyecto [Luckey & Phillips, 2006].

Como se observa en lafigura 4.5, la administracin de un proyecto puede modelarse conun diagrama de estados, el controlse hace en paralelo a la ejecucin para verificar que elproyecto se esta llevando a cabo conforme al plan.

Si el proyecto es un xito es mrito de todo el equipo, pero si el proyecto falla solo esculpa del administrador del proyecto [Luckey & Phillips, 2006].

La norma IEEE-1058 [IEEE-1058,1993] para la Planificacin de Proyectos de Softwarees un estndar internacional que especificar cual debe ser el contenido y el formato parapresentar el Plan de Administracin de un Proyecto de software. A continuacin se muestrael formato general de la IEEE-1058.

Pgina del ttulo Hoja de revisin Prefacio Tabla de contenidos Lista de figuras

Lista de tablas 1. Introduccin.1.1. Visin general del proyecto.1.2. Entregables del proyecto.1.3. Evolucin del PGPS.1.4. Materiales de referencia.


47/177



43

1.5. Definiciones y acrnimos. 2. Organizacin del proyecto.

2.1. Modelo de procesos.

2.2. Estructura organizativa.2.3. Fronteras e interfaces organizativas.2.4. Responsabilidades

3. Procesos de gestin.3.1. Objetivos y Prioridades de la Gestin.3.2. Supuestos, dependencias y restricciones.3.3. Gestin de Riesgos.3.4. Mecanismos de supervisin y control.3.5. Plan de personal.

4. Procesos tcnicos.4.1. Mtodos, herramientas y tcnicas.4.2. Documentacin del software.4.3. Funciones de soporte al proyecto.

5. Paquetes de trabajo, calendario y presupuesto.5.1. Paquetes de trabajo.5.2. Dependencias.5.3. Requerimientos de recursos.5.4. Presupuesto y distribucin de recursos.5.5. Calendario.

Componentes adicionales ndice Apndices

Para mayor informacin consultar [IEEE-1058,1993].


48/177



44

IV.2Taxonoma de los modelos y metodologas de desarrollo desoftware ms utilizados

IV.2.1 Relacin entre procesoy modelodel software

Un proceso de desarrollo de software es el conjunto estructurado de las actividadesrequeridas para elaborar un sistema de software, estas actividades son: especificacin derequerimientos, diseo, codificacin, validacin (pruebas) y mantenimiento. Al proceso dedesarrollo de software tambin se le conoce como ciclo de vida del software porquedescribe la vida de un producto de software; primero nace con la especificacin de losrequerimientos, luego se ejecuta la implantacin, que consiste en su diseo, codificacin ypruebas, posteriormente el producto se entrega, y sigue viviendo durante su utilizacin y

mantenimiento. Cuando el ciclo de vida es evolutivo, estas actividades se llevan a cabocclicamente. La vida del sistema de software termina cuando ste se deja de utilizar. Sedice que el producto evoluciona cuando se le hacen modificaciones que generan nuevasversiones.Por otra parte, un modelo de desarrollo de software es una representacin abstracta deeste proceso [Sommerville, 2006]. Un modelo de desarrollo de SW determina el orden en elque se llevan ejecutan las actividades del proceso de desarrollo de SW, es decir, es elprocedimiento que se sigue durante el proceso.

Hay una gran variedad de paradigmas o modelos de desarrollo de software. Los librosms conocidos de ingeniera de software [Braude, 2003; McConnell, 1997; Pfleger, 2002;Pressman, 2002; Sommerville, 2006; Weitzenfeld, 2004] explican solo los que consideran

ms importantes y el problema en ellos es que las opiniones acerca de cual es la lista demodelos que debe considerarse son diversas. Sommerville [2006], clasifica todos losprocesos de desarrollo de software en tres modelos o paradigmas generales que no sondescripciones definitivas de los procesos del software sino ms bien, son abstracciones delos modelos que se pueden utilizar para desarrollar software, y son los siguientes:

a) Modelos en cascada. Las actividades fundamentales del proceso de desarrollo desoftware se llevan a cabo como fases separadas y consecutivas. Estas actividades son:especificacin (anlisis y definicin de requerimientos), implantacin (diseo, codificacin,validacin) y mantenimiento. Los modelos en cascada constan bsicamente de 5 fases queson:Anlisis y definicin de requerimientos. Se trabaja con los clientes y los usuarios finales delsistema para determinar el dominio de aplicacin y los servicios que debe proporcionar elsistema as como sus restricciones. Con esta informacin se produce el documento deEspecificacin de Requerimientos del Sistema.

Diseo del sistema y del software. Durante el proceso de diseo del sistema se distinguencuales son los requerimientos de software y cuales los de hardware. Despus se establece


49/177



45

una arquitectura completa del sistema. Durante el diseo del software se identifican lossubsistemas en los cuales estar compuesto el sistema y se describe cmo funciona cadauno y las relaciones entre stos.

Implementacin y validacin de unidades. Consiste en codificar y probar los diferentessubsistemas por separado. La prueba de unidades implica verificar que cada una cumpla suespecificacin (proveniente del diseo).Integracin y validacin del sistema. Una vez que se prob que funciona individualmentecada una de las unidades, stas se integran para formar un sistema completo que debecumplir con todos los requerimientos del software. Cuando las pruebas del sistemacompleto son exitosas, ste se entrega al cliente.Funcionamiento y mantenimiento. El sistema se instala y se pone en funcionamientoprctico. El mantenimiento implica corregir errores no descubiertos en las etapas anterioresdel ciclo de vida y mejorar la implantacin de las unidades del sistema para darle mayorrobustez (y no nuevas funcionalidades).

b) Modelos de desarrollo evolutivo. Los modelos evolutivos son iterativos. Secaracterizan por la forma en que permiten a los ingenieros de software desarrollar versionescada vez ms completas del sistema. Los modelos evolutivos iteran sobre las actividades deespecificacin, desarrollo y validacin. Un sistema inicial se desarrolla a partir de losrequerimientos prioritarios o los que estn mejor definidos. Esta primera versin se refinaen una nueva iteracin en base a las peticiones del cliente para producir un sistema quesatisfaga sus necesidades. Sommerville [2006] define dos tipos de desarrollo evolutivo:

b.1) Desarrollo exploratorio. Se le presenta al cliente la implementacin de la parte delos requerimientos que se entendi bien para recibir sus comentarios y, en base a stos,refinar el sistema hasta que se logra desarrollar el sistema adecuado.

b.2) Prototipos desechables. Para descubrir o terminar de comprender los requerimientosdel cliente se construye un prototipo con funcionalidad simulada y, si ste no es lo que elcliente espera, se construye otro prototipo (posiblemente desde cero) en base a unadefinicin mejorada de los requerimientos para el sistema. El diseo del prototipo delsistema va evolucionando segn se vayan entendiendo los requerimientos aunque lafuncionalidad siga siendo simulada. Cuando se aclaran los requerimientos se completa lafuncionalidad segn el ltimo prototipo.

c) Modelos de componentes reutilizables. Se basa en la existencia de un nmerosignificativo de componentes reutilizables. El reuso de los componentes tiene comofinalidad usar de nuevo ideas, arquitecturas, diseos o cdigo de una aplicacin paraconstruir otras. El proceso de desarrollo del sistema se enfoca en integrar estoscomponentes en el sistema en lugar de desarrollarlos desde cero.

Segn Sommerville [2006], en la mayora de los proyectos existe algo de reutilizacin desoftware. Por lo general, esto sucede informalmente cuando las personas que trabajan en elproyecto conocen diseos de cdigo similares al requerido. Los buscan, los modifican


50/177



46

segn lo creen necesario y los incorporan en el sistema. Las etapas de especificacin derequerimientos y de validacin son comparables con los otros procesos, sin embargo, lasetapas intermedias en el proceso orientado a la reutilizacin son diferentes. Estas etapas

son:Anlisis de componentes. Consiste en encontrar componentes que sirvan para implementarla Especificacin de Requerimientos. En general los componentes que se utilizan soloproporcionan parte de la funcionalidad requerida por lo que se necesita modificarlos.Modificacin de requerimientos. Con la informacin que se tiene de los componentes yaidentificados, se analizan los requerimientos. Si es posible, se modifican los requerimientospara que concuerden con los componentes disponibles. Si las modificaciones no sonposibles entonces se lleva a cabo nuevamente el anlisis de componentes para buscarsoluciones alternativas.Diseo del sistema con reutilizacin. Se disea o se reutiliza un marco de trabajo para elnuevo sistema teniendo en cuenta los componentes que se reutilizan y los componentes quesern completamente nuevos.Desarrollo e integracin. El software que no se tiene disponible y que no se puede adquirirexternamente se desarrolla integrando los componentes reutilizables disponibles. En estemodelo, la integracin de los sistemas es parte del desarrollo ms que una actividadseparada.Los tres paradigmas o modelos de procesos genricos: cascada, evolutivo y componentes

reutilizables, se utilizan ampliamente en la prctica actual de la ingeniera del software. Nose excluyen mutuamente y a menudo se utilizan juntos, especialmente para el desarrollo desistemas grandes [Sommerville, 2006]. El problema es que en la literatura no se hace unaclasificacin explcita que ubique cada modelo o metodologa dentro de alguna de estasclases abstractas. En la siguiente seccin hacemos esta clasificacin para los modelos msrepresentativos.

IV.2.2 El Proceso Unificado Racional

IBM Rational propone el desarrollo de software basado en las mejores prcticasrecopiladas en innumerables proyectos exitosos. Es una metodologa que llama al procesode desarrollo de software: Rational Unified Process (RUP) llamado en espaol el ProcesoUnificado Racional. El RUP es un modelo de proceso hbrido ya que rene elementos delos modelos de procesos genricos: cascada, evolutivo y reutilizacin [Sommerville, 2006],adems propone buenas prcticas para la especificacin y el diseo. El proceso unificado sedescribe desde tres perspectivas:

1.- Una perspectiva dinmica.- Muestra las fases del modelo sobre el tiempo.2.- Una perspectiva esttica.- Muestra las actividades que tienen lugar durante el proceso

de desarrollo, se denominanflujos de trabajo.3.- Una perspectiva prctica.- Sugiere buenas prcticas a utilizar durante el proceso.


51/177



47

En cuanto a laperspectiva prctica, se recomiendan seis buenas prcticas aconsejables enel desarrollo de sistemas: Desarrollar el software de forma iterativa (entregando primerolos requerimientos ms importantes), Gestionar los requerimientos (analizando el impacto

de los cambios en el sistema antes de aceptarlos y documentando los cambios aceptados),Utilizar arquitecturas basadas en componentes (en la mayor medida posible), modelar elsoftware visiblemente ( con modelos grficos como UML), verificar la calidad delsoftware, controlar los cambios del software ygestionar los cambios del software usandoherramientas de gestin de configuraciones.El Proceso Unificado no es un proceso apropiado para todos los tipos de desarrollo, sinembargo representa una nueva generacin de procesos genricos [Sommerville, 2006]. Lasinnovaciones ms importantes son la separacin de fases y los flujos de trabajo, y elreconocimiento de que la utilizacin del software en un entorno de usuario es parte delproceso. Las fases son dinmicas y tienen objetivos. Los flujos de trabajo son estticos yson a

Notas del curso Administración de Proyectos

Documents

Transcript of Notas del curso Administración de Proyectos