ING. DE SOFTWARE

Ing. Jorge Reyes

SoftwareSoftware

Gestión de Proyectos.

Software

La gestión de proyectos es la disciplina del planeamiento, la organización, la motivación, y el control de los recursos con el propósito de alcanzar uno o varios objetivos.

Un proyecto es un emprendimiento temporario diseñado a producir un único producto, servicio o resultado con un principio y un final definido (normalmente limitados en tiempo, y en costos o entregables), que es emprendido para alcanzar objetivos únicos, y que dará lugar a un cambio positivo o agregará valor.

Software

¿Qué es la Gestión de Proyectos?

La gestión de proyectos de software es una parte esencial de la ingeniería del software. La buena gestión no puede garantizar el éxito del proyecto. Sin embargo, la mala gestión usualmente lleva al fracaso del proyecto. El software es entregado tarde, los costes son mayores que lo estimados y los requerimientos no se cumplen.

Los gestores de software son responsables de la planificación y temporalización del desa rrollo de los proyectos. Supervisan el trabajo para asegurar que se lleva a cabo conforme a los estándares requeridos y supervisan el progreso para comprobar que el desarrollo se ajusta al tiempo previsto y al presupuesto.

Software

La administración de proyectos de software es necesaria debido a que la ingeniería de software profesional siempre está sujeta a restricciones organizacionales de tiempo y presupuesto.

El trabajo del gestor de proyectos de software es asegurar que éstos cumplan dichas restricciones y entregar software que contribuya a las metas de la compañía de desarrollo software.

Los gestores de software hacen el mismo tipo de trabajo que otros gestores. Sin embargo, la ingeniería del software es diferente en varios aspectos a otros tipos, lo que hace a la ges tión de software particularmente difícil.

Software

La naturaleza temporal de los proyectos se contrapone con las operaciones normales de cualquier organización, las cuales son actividades funcionales repetitivas, permanentes o semipermanentes que hacen a los productos o al servicio.

En la práctica, la gestión de estos dos sistemas suelen ser muy distintos, y requieren el desarrollo de habilidades técnicas y gestión de estrategias diferentes.

El primer desafío para la gestión de proyectos es alcanzar la meta del proyecto, y los objetivos dentro de las limitantes conocidas. Las limitantes o restricciones primarias son el alcance, el tiempo, la calidad y el presupuesto.

El desafío secundario, y el más ambicioso de todos, es optimizar la asignación de recursos de las entradas necesarias e integrarlas para alcanzar los objetivos predefinidos.

Software

Algunas de estas diferencias son las siguientes: El producto es intangible. El gestor de un proyecto de construcción de un

embarca dero o de uno de ingeniería civil puede ver el producto mientras se está desarrollando. Si hay un desfase en calendario, el efecto en el producto es visible de forma obvia: par tes de la estructura no están completas. El software es intangible. No se puede ver ni tocar. Los gestores de proyectos de software no pueden ver el progreso. Confían en otros para elaborar la documentación necesaria para revisar el progreso.

No existen procesos del software estándar. En las disciplinas de ingeniería con larga historia, el proceso se prueba y verifica. Para tipos particulares de sistemas, como puentes o edificios, el proceso de ingeniería se comprende bien. Sin embargo, los pro­cesos de software varían notablemente de una organización a otra. A pesar de que la comprensión del proceso del software se ha desarrollado de forma significativa en los últimos años, aún no se puede predecir con certeza cuándo un proceso particular tien de a desarrollar problemas. Esto es especialmente cierto cuando el proyecto software es parte un proyecto de ingeniería de un sistema grande.

A menudo los proyectos grandes son únicos. Por lo general, los proyectos grandes de software son diferentes de proyectos previos. En consecuencia, los gestores, aun cuan do cuenten con una amplia experiencia, ésta no es suficiente para anticipar los pro blemas. Más aún, los rápidos cambios tecnológicos en las computadoras y las comu nicaciones hacen parecer obsoleta la experiencia previa. Las lecciones aprendidas en esas experiencias pueden no ser transferibles a los nuevos proyectos. Software

Debido a estos problemas, no es sorprendente que algunos proyectos de software se retra sen, sobrepasen el presupuesto y se entreguen fuera de tiempo. A menudo, los sistemas de software son nuevos y tecnológicamente innovadores.

Frecuentemente los proyectos de in geniería innovadores (como los nuevos sistemas de transporte) también tienen problemas de temporalización. Dadas las mezclas de dificultades, es notable que muchos proyectos de soft ware sean entregados a tiempo y según lo presupuestado.

Software

Es imposible redactar una descripción estándar del trabajo de un gestor de software.

El tra bajo difiere enormemente dependiendo de la organización y del producto de software a desarrollar. Sin embargo, en algún momento, muchos gestores son responsables de algunas o de la totalidad de las siguientes actividades:

Redacción de la propuesta. Planificación y calendarización del proyecto. Estimación de costes del proyecto. Supervisión y revisión del proyecto. Selección y evaluación del personal. Redacción y presentación de informes.

Software

Actividades de gestión.

La primera etapa de un proyecto de software implica redactar una propuesta para realizar ese proyecto. La propuesta describe los objetivos del proyecto y cómo se llevaría a cabo. Por lo general, incluye estimaciones de coste y tiempo y justifica por qué el contrato del proyec to se le debe dar a una organización o a un equipo en particular.

La redacción de la propues ta es una tarea crítica, ya que la existencia de muchas organizaciones de software depende de las propuestas aceptadas y los contratos asignados. No existen guías para esta tarea; la redac ción de propuestas es una habilidad que se adquiere con la práctica y la experiencia.

Software

La planificación de proyectos se refiere a la identificación de actividades, hitos y entregas un proyecto. Por lo tanto, se debe bosquejar un plan para guiar el desarrollo hacia las metas del proyecto.

El objetivo de la planificación del proyecto de software es proporcionar un marco de trabajo que permite al gestor de planificación hacer estimaciones razonables de recursos, costos y planificación temporal.

Estas estimaciones se hacen dentro de un marco de tiempo limitado al comienzo de un proyecto de software, y deberían actualizarse regularmente a medida que progresa el proyecto.

Las estimaciones deberían definir los escenario del mejor caso, y peor caso de modo que los resultados del proyecto pueden limitarse. El objetivo de la planificación se logra mediante un proceso de descubrimiento de la información que lleve a estimaciones razonables.

Software

La estimación del coste es una actividad relacionada con la estimación de los recursos requeridos para llevar a cabo el plan del proyecto.

En el principio el costo del software constituía un pequeño porcentaje del costo total de los sistemas basados en computadoras. Hoy en día el software es el elemento mas caro de la mayoría de los sistemas informáticos. Es una pequeña planeación sobre que es lo que va a ser mi proyecto. Una de las actividades cruciales del proceso de gestión del proyecto del software es la planificación.

Cuando se planifica un proyecto de software ese tiene que obtener estimaciones de esfuerzo humano requerido, de la duración cronológica del proyecto y del costo. Pero en muchos de los casos las estimaciones se hacen valiéndose de la experiencia pasada como única guía. Si un proyecto es bastante similar en tamaño y funciona un proyecto pasado es probable que el nuevo requiera aproximadamente la misma cantidad de esfuerzo, que dure aproximadamente lo mismo que el trabajo anterior. Si el proyecto es distinto entonces puede que las experiencias obtenidas no sean suficientes.

Software

La supervisión de proyecto es una actividad continua. El gestor debe tener conocimiento del progreso del proyecto y comparar el progreso con los costes actuales y los planificados. Aunque muchas organizaciones tienen mecanismos formales para supervisar, un gestor hábil podría formarse una imagen clara de lo que pasa llevando a cabo una entrevista informal con el personal del proyecto.

La supervisión informal predice problemas importantes del proyecto, y revela dificultades que pueden aparecer. Por ejemplo, las entrevistas diarias con el personal del proyecto pueden exteriorizar un problema en un fallo del software. Más que esperar un informe de atraso del proyecto, el gestor de software podría asignar algún experto para resolver el problema o po dría decidir si se vuelve a programar.

Software

Durante un proyecto, es normal tener varias revisiones formales de su gestión. Se hace la revisión completa del progreso y de los desarrollos técnicos del proyecto, y se tiene en cuenta el estado del proyecto junto con los propósitos de la organización que ha encargado el software.

El resultado de una revisión puede dar lugar a la cancelación del proyecto. El tiempo de desarrollo para un proyecto grande de software puede ser de varios años. Durante ese tiempo los objetivos organizacionales tienden obviamente a cambiar.

Estos cambios pueden signifi car que el software ya no se necesita o que los requerimientos originales del proyecto son inapropiados. La gestión puede decidir parar el desarrollo del software o cambiar el proyecto para adecuarlo a los cambios de los objetivos de la organización.

Software

Por lo general, los gestores de proyectos tienen que seleccionar a las personas para traba jar en su proyecto. De forma ideal, habrá personal disponible con habilidades y experiencia apropiada para trabajar en el proyecto. Sin embargo, en muchos casos, los gestores tienen que establecer un equipo ideal mínimo para el proyecto.

Las razones que explican esto son: El presupuesto del proyecto no cubre la contratación de personal con

sueldos altos. Se tiene que contratar personal con menos experiencia y menor sueldo.

El personal con experiencia apropiada no está disponible dentro o fuera de la organi zación. Es imposible reclutar nuevo personal para el proyecto. Dentro de la organiza ción, los mejores trabajadores ya se han asignado a otros proyectos.

La organización desea desarrollar las habilidades de sus empleados. El personal inex perto puede ser asignado al proyecto para aprender y adquirir experiencia.

Software

El gestor de software tiene que trabajar con estas restricciones al seleccionar al personal del proyecto. Sin embargo, todos estos problemas son probables a menos que exista un miem bro del proyecto que cuente con algo de experiencia en el tipo de sistema a desarrollar. Sin esta experiencia, probablemente se cometerán muchos errores pequeños.

Los gestores del proyecto son responsables de informar a los clientes y contratistas sobre el proyecto. Tienen que redactar documentos concisos y coherentes que resuman la informa ción crítica de los informes detallados del proyecto. Les debe ser posible presentar esta in formación durante las revisiones de progreso. En consecuencia, comunicarse efectivamente de forma oral y escrita es una habilidad esencial que un gestor de proyectos debe tener.

Software

La gestión efectiva de un proyecto de software depende de planificar completamente el progreso del proyecto.

El gestor del proyecto debe anticiparse a los problemas que puedan surgir, así como preparar soluciones a esos problemas. Un plan, preparado al inicio de un proyecto, debe utilizarse como un conductor para el proyecto.

Este plan inicial debe ser el mejor posible de acuerdo con la información disponible. Éste evolucionará conforme el proyecto progrese y la información sea mejor.

Software

Planificación del proyecto.

El plan del proyecto fija los recursos disponibles, divide el trabajo y crea un calendario de tra bajo.

En algunas organizaciones, el plan del proyecto es un único documento que incluye to dos los diferentes tipos de planes. En otros casos, este plan sólo se refiere al pro ceso de desarrollo. Otros pueden estar referenciados, pero son proporcionados por separado.

Software

El plan del proyecto.

Software

Plan de calidad. Describe los procedimientos y los estándares de calidad que se utilizaran en un proyecto.

Plan de validación. Describe el enfoque, los recursos y la programación utilizados para la validación del sistema.

Plan de gestión de configuraciones.

Describe los procedimientos para la gestión de configuraciones y las estructuras a utilizar.

Plan de mantenimiento. Predice los requerimientos del mantenimiento del sistema, los costes del mantenimiento y el esfuerzo requerido.

Plan de desarrollo del personal. Describe como se desarrollan las habilidades y experiencia de los miembros del equipo del proyecto.

Tipos de Plan.

Sin embar go, muchos planes incluyen las siguientes secciones: Introducción. Describe brevemente los objetivos del proyecto y expone las restriccio­

nes (por ejemplo, presupuesto, tiempo, etcétera) que afectan a la gestión del proyecto.

Organización del proyecto. Describe la forma en que el equipo de desarrollo está organizado, la gente involucrada y sus roles en el equipo.

Análisis de riesgo. Describe los posibles riesgos del proyecto, la probabilidad de que surjan estos riesgos y las estrategias de reducción de riesgos propuestas.

Requerimientos de recursos de hardware y software. Describe el hardware y el soft ware de ayuda requeridos para llevar a cabo el desarrollo. Si es necesario comprar hardware, se deben incluir las estimaciones de los precios y las fechas de entrega.

División del trabajo. Describe la división del proyecto en actividades e identifica los hitos y productos a entregar asociados con cada actividad.

Programa del proyecto. Describe las dependencias entre actividades, el tiempo esti mado requerido para alcanzar cada hito y la asignación de la gente a las actividades.

Mecanismos de supervisión e informe. Describe la gestión de informes y cuándo deben producirse, así como los mecanismos de supervisión del proyecto a utilizar.

Software

El plan del proyecto debe revisarse regularmente durante el proyecto. Algunas partes, como el calendario del proyecto, cambiarán frecuentemente; otras serán más estables.

Para simplificarlas revisiones, se debe organizar el documento en secciones separadas que permi tan su reemplazo de forma individual conforme evoluciona el plan.

Software

Los gestores necesitan información para hacer su trabajo. Como el software es intangible, esta información sólo se puede proveer como documentos que describan el estado del software que se está desarrollando. Sin esta información, es imposible juzgar el progreso y no se pueden actualizar los costes y calendarios.

Cuando se planifica un proyecto, se debe establecer una serie de hitos —puntos finales de una actividad del proceso del software—. En cada uno, debe existir una salida formal, como un informe, que se debe presentar al gestor. Los informes de hitos no deben ser documentos amplios. Deben ser informes cortos de los logros en una actividad del proyecto.

Los hitos de ben representar el fin de una etapa lógica en el proyecto. Los hitos indefinidos como (80 % del código completo) son imposibles de validar y carecen de utilidad para la gestión del pro yecto. No podemos validar si se ha llegado a esta etapa debido a que la cantidad de código que se tiene que desarrollar no es precisa.

Software

Hitos y entregas.

Una entrega es el resultado del proyecto que se entrega al cliente. De forma general, se en trega al final de una fase principal del proyecto como la especificación, el diseño, etc. Como regla general, las entregas son hitos, pero éstos no son necesariamente entregas. Dichos hitos pueden ser resultados internos del proyecto que son utilizados por el gestor del proyec to para verificar el progreso del mismo pero que no se entregan al cliente.

Para establecer los hitos, el proceso del software debe dividirse en actividades básicas con sus salidas asociadas.

Software

Por ejemplo, la Figura muestra las actividades involucradas en la especificación de requerimientos cuando se utiliza la construcción de prototipos para ayudar a validar dichos requerimientos.

También se muestran las salidas principales de cada activi dad (los hitos del proyecto). Las entregas del proyecto, las cuales son entregadas al cliente, son la definición y especificación de requerimientos.

Software

Ésta es una de las tareas más difíciles para los gestores de proyectos. Los gestores estiman el tiempo y los recursos requeridos para completar las actividades y organizarlas en una suce sión coherente. A menos que el proyecto a calendarizar sea similar a otro anterior, las esti maciones previas son una base incierta para la calendarización del nuevo proyecto.

La esti mación del calendario se complica más por el hecho de que proyectos diferentes pueden utilizar métodos de diseño y lenguajes de implementación diferentes.

Si el proyecto es técnicamente complejo, las estimaciones iniciales casi siempre son opti mistas aun cuando los gestores traten de considerar las eventualidades. A este respecto, la ca lendarización del tiempo para la creación del software no es diferente a la de cualquier otro tipo de proyecto grande y complejo. Los nuevos aeroplanos, los puentes e incluso los nuevos modelos de automóviles se retrasan debido a problemas no anticipados. Por lo tanto, los ca lendarios se deben actualizar continuamente en la medida que se disponga de mejor informa ción acerca del progreso.

Software

Calendarización del proyecto.

La calendarización del proyecto (la Figura) implica separar todo el trabajo de un proyecto en actividades complementarias y considerar el tiempo requerido para completar di chas actividades.

Por lo general, algunas de éstas se llevan a cabo en paralelo. Debemos co ordinar estas actividades paralelas y organizar el trabajo para que la mano de obra se utilice de forma óptima. Deben evitarse situaciones en que el proyecto entero se retrase debido a que no se ha terminado una actividad crítica.

Software

Normalmente, las actividades del proyecto deben durar por lo menos una semana. Hacer sub divisiones más finas significa invertir una cantidad desproporcionada de tiempo en la estima ción y revisión de tablas. También es útil asignar una cantidad de tiempo máxima de 8 a 10 semanas para realizar cualquier actividad. Si lleva más tiempo, se deben hacer subdivisiones.

AI estimar la calendarización, los gestores no deben suponer que cada etapa del proyecto estará libre de problemas. Las personas que trabajan en él pueden enfermarse o renunciar, el hardware puede fallar y el software o hardware de soporte puede llegar tarde. Si el proyecto es nuevo y técnicamente complejo, ciertas partes podrían ser más complicadas y llevarían más tiempo del que se estimó originalmente.

Software

Como en los calendarios, los gestores deben estimar los recursos necesarios para completar cada tarea. El recurso principal es el esfuerzo humano que se requiere. Otros recursos pueden ser el espacio en disco requerido en un servidor, el tiempo requerido de hardware especializado, un simulador o el presupuesto para viajes del personal del proyecto.

Una buena regla práctica es estimar como si nada fuera a salir mal, y entonces incrementar la estimación para abarcar los problemas previstos. Con este mismo fin, a la estimación se le debe agregar un factor de contingencia adicional. Este factor extra de contingencia depende del tipo de proyecto, de los parámetros del proceso (fecha de entrega, estándares, etc.) y de la calidad y experiencia de los ingenieros de software que trabajen en el proyecto. Como regla, para los problemas previstos siempre debe agregarse un 30% a la estimación original y otro 20% para cubrir algunas cosas no previstas.

Por lo general, el calendario del proyecto se representa como un conjunto de gráficos que muestran la división del trabajo, las dependencias de las actividades y la asignación del personal. Por lo general, las herramientas de ges tión de software, como Microsoft Project, se utilizan para automatizar la producción de diagramas.

Software

Una tarea importante del gestor de proyectos es anticipar los riesgos que podrían afectar a la programación del proyecto o a la calidad del software a desarrollar y emprender acciones para evitar esos riesgos.

Los resultados de este análisis de riesgos se deben documentar a lo largo del plan del proyecto junto con el análisis de consecuencias cuando el riesgo ocurra.

Identi ficar éstos y crear planes para minimizar sus efectos en el proyecto se llama gestión de ries gos.

Software

Gestión de riesgos.

De forma simple, se puede concebir un riesgo como una probabilidad de que una circuns tancia adversa ocurra. Los riesgos son una amenaza para el proyecto, para el software que se está desarrollando y para la organización.

Estas categorías de riesgos se definen como se muestra a continuación: Riesgos del proyecto. Éstos afectan la calendarización o los recursos del

proyecto. Un ejemplo podría ser la pérdida de un diseñador experimentado.

Riesgos del producto. Éstos afectan a la calidad o al rendimiento del software que se está desarrollando. Un ejemplo podría ser que el rendimiento en un componente que hemos comprado sea menor que el esperado.

Riesgos del negocio. Estos afectan a la organización que desarrolla o suministra el soft ware. Por ejemplo, que un competidor introduzca un nuevo producto es un riesgo de negocio.

Software

Por supuesto, estos tipos no son exclusivos entre sí. Si un programador experto abandona el proyecto, esto es un riesgo para el proyecto (debido a que la entrega del sistema se puede retrasar), para el producto (debido a que un sustituto puede no ser tan experto y cometer mu chos errores) y para el negocio (debido a que esa experiencia puede no contribuir a negocios futuros).

Los riesgos que pueden afectar a un proyecto dependen del propio proyecto y del entorno organización al donde se desarrolla. Sin embargo, muchos riesgos son universales.

Software

Software

Algunos riesgos son:

La gestión de riesgos es importante particularmente para los proyectos de software debi do a las incertidumbres inherentes con las que se enfrentan muchos proyectos.

Estas incertidumbres son el resultado de los requerimientos ambiguamente definidos, las dificultades en la estimación de tiempos y los recursos para el desarrollo del software, la dependencia en las habilidades individuales, y los cambios en los requerimientos debidos a los cambios en las ne cesidades del cliente.

Es preciso anticiparse a los riesgos: comprender el impacto de éstos en el proyecto, en el producto y en el negocio, y considerar los pasos para evitarlos.

En el caso de que ocurran, se deben crear planes de contingencia para que sea posible aplicar acciones de recuperación.

Software

El proceso de gestión de riesgos. Éste comprende varias etapas:

Identificación de riesgos. Identificar los posibles riesgos para el proyecto, el producto y los negocios.

Análisis de riesgos. Valorar las probabilidades y consecuencias de estos riesgos.

Planificación de riesgos. Crear planes para abordar los riesgos, ya sea para evitarlos o minimizar sus efectos en el proyecto.

Supervisión de riesgos. Valorar los riesgos de forma constante y revisar los planes para la mitigación de riesgos tan pronto como la información de los riesgos esté dis ponible.Software

El proceso de gestión de riesgos, como otros de planificación de proyectos, es un proceso iterativo que se aplica a lo largo de todo el proyecto.

Una vez que se genera un conjunto de planes iniciales, se supervisa la situación. En cuanto surja más información acerca de los ries gos, éstos deben analizarse nuevamente y se deben establecer nuevas prioridades. La preven ción de riesgos y los planes de contingencia se deben modificar tan pronto como surja nueva información de los riesgos.

Los resultados del proceso de gestión de riesgos se deben documentar en un plan de ges tión de riesgos. Éste debe incluir un estudio de los riesgos a los que se enfrenta el proyecto, un análisis de éstos y los planes requeridos para su gestión. Si es necesario, puede incluir al gunos resultados de la gestión de riesgos; por ejemplo, planes específicos de contingencia que se activan si aparecen dichos riesgos.

Software

Ésta es la primera etapa de la gestión de riesgos. Comprende el descubrimiento de los posi bles riesgos del proyecto. En principio, no hay que valorarlos o darles prioridad en esta etapa aunque, en la práctica, por lo general no se consideran los riesgos con consecuencias menores o con baja probabilidad.

Esta identificación se puede llevar a cabo a través de un proceso de grupo utilizando un en foque de tormenta de ideas o simplemente puede basarse en la experiencia. Para ayudar al proceso, se utiliza una lista de posibles tipos de riesgos.

Software

Identificación de riesgos.

Hay al menos seis tipos de riesgos que pueden aparecer: 1. Riesgos de tecnología. Se derivan de las tecnologías de software o

de hardware utili zadas en el sistema que se está desarrollando.

2. Riesgos de personal. Riesgos asociados con las personas del equipo de desarrollo.

3. Riesgos organizacionales. Se derivan del entorno organizacional donde el software se está desarrollando.

4. Riesgos de herramientas. Se derivan de herramientas CASE y de otro software de apo yo utilizado para desarrollar el sistema.

5. Riesgos de requerimientos. Se derivan de los cambios de los requerimientos del clien te y el proceso de gestionar dicho cambio.

6. Riesgos de estimación. Se derivan de los estimados administrativos de las caracterís ticas del sistema y los recursos requeridos para construir dicho sistema.

Software

La Figura proporciona algunos ejemplos de riesgos posibles en cada una de estas ca tegorías. El resultado de este proceso debe ser una larga lista de riesgos que podrían presen tarse y afectar al producto, al proceso o al negocio.

Software

Durante este proceso, se considera por separado cada riesgo identificado y se decide acerca de la probabilidad y la seriedad del mismo.

No existe una forma fácil de hacer esto —recae en la opinión y experiencia del gestor del proyecto—. No se hace una valoración con núme ros precisos sino en intervalos:

La probabilidad del riesgo se puede valorar como muy bajo (< 10%), bajo (10-25%), mo derado (25-50%), alto (50-75%) o muy alto (>75%).

Los efectos del riesgo pueden ser valorados como catastrófico, serio, tolerable o insig nificante.

Software

Análisis de riesgos.

El resultado de este proceso de análisis se debe colocar en una tabla, la cual debe estar or denada según la seriedad del riesgo. La Figura (análisis de riesgo) ilustra esto para los riesgos identificados en la Figura (riesgos y tipos de riesgos). Obviamente, aquí es arbitraria la valoración de la probabilidad y seriedad.

En la práctica, para hacer esta valoración se necesita información detallada del proyecto, el proceso, el equipo de desarrollo y la organización.

Por supuesto, tanto la probabilidad como la valoración de los efectos de un riesgo cambian conforme se disponga de mayor información acerca del riesgo y los planes de gestión del mis mo se implementen. Por lo tanto, esta tabla se debe actualizar durante cada iteración del pro ceso de riesgos.

Software

Figura analisis de riesgos:

Software

Una vez que los riesgos se hayan analizado y clasificado, se debe discernir cuáles son los más importantes que se deben considerar durante el proyecto. Este discernimiento debe de pender de una combinación de la probabilidad de aparición del riesgo y de los efectos del mis mo. En general, siempre se deben tener en cuenta todos los riesgos catastróficos, así como to dos los riesgos serios que tienen más que una moderada probabilidad de ocurrir.

Boehm (Boehm, 1988) recomienda identificar y supervisar los (10 riesgos más altos), pero este número parece demasiado arbitrario. El número exacto de riesgos a supervisar debe de pender del proyecto. Pueden ser cinco o 15. No obstante, el número apropiado debe ser ma nejable.

Un número muy grande de riesgos requiere obtener mucha información. De los ries gos identificados en la Figura (analisis de riesgos), conviene considerar los ocho que tienen consecuencias serias o catastróficas.

Software

El proceso de planificación de riesgos considera cada uno de los riesgos clave que han sido identificados, así como las estrategias para gestionarlos. Otra vez, no existe un proceso sen cillo que nos permita establecer los planes de gestión de riesgos. Depende del juicio y de la experiencia del gestor del proyecto. La Figura (estrategia de gestión de riesgos) muestra posibles estrategias para los ries gos que han sido identificados en la Figura (análisis de riesgos).

Estas estrategias seguidas pueden dividirse en tres categorías. 1. Estrategias de prevención. Siguiendo estas estrategias, la probabilidad de que el

ries go aparezca se reduce. Un ejemplo de este tipo de estrategias es la estrategia de evita ción de defectos en componentes de la Figura (estrategia de gestión de riesgos).

2. Estrategias de minimización. Siguiendo estas estrategias se reducirá el impacto del ries go. Un ejemplo de esto es la estrategia frente a enfermedad del personal de la Figura (estrategia de gestión de riesgos).

3. Planes de contingencia. Seguir estas estrategias es estar preparado para lo peor y te ner una estrategia para cada caso. Un ejemplo de este tipo de estrategia es el mostra do en la Figura (estrategia de gestión de riesgos) con la estrategia para problemas financieros.

Software

Planificación de riesgos.

Puede verse aquí una analogía con las estrategias utilizadas en sistemas críticos para ase gurar fiabilidad, protección y seguridad. Básicamente, es mejor usar una estrategia para evi tar el riesgo. Si esto no es posible, utilizar una para reducir los efectos serios de los riesgos. Finalmente, tener estrategias para reducir el impacto del riesgo en el proyecto y en el producto.

Software

La supervisión de riesgos normalmente valora cada uno de los riesgos identificados para de cidir si éste es más o menos probable y si han cambiado sus efectos. Por supuesto, esto no se puede observar de forma directa, por lo que se tienen que buscar otros factores para dar indicios de la probabilidad del riesgo y sus efectos. Obviamente, estos factores dependen de los tipos de riesgo.

La Figura (factores de riesgo) da algunos ejemplos de los factores que ayudan en la valora ción de estos tipos de riesgos.

Software

Supervisión de riesgos.

La supervisión de riesgos debe ser un proceso continuo y, en cada revisión del progreso de gestión, cada uno de los riesgos clave debe ser considerado y analizado por separado.

Software

Es esencial una buena gestión de proyectos de software para que los proyectos de ingeniería de software se desarrollen a tiempo y según presupuesto.

La gestión de proyectos de software es diferente a la gestión de otro tipo de ingenierías. El software es in tangible. Los proyectos pueden ser nuevos o innovadores, por lo que no existe un conjunto de experiencias para guiar su gestión. El proceso del software no se comprende del todo.

Los gestores de software tienen diversos papeles. Sus actividades más significativas son la planificación, es timación y calendarización de los proyectos. La planificación y la estimación son procesos iterativos. Tienen continuidad a lo largo del proyecto. En cuanto se tenga más información, se deben revisar los planes y calen darios.

Software

Puntos clave.

Un hito de un proyecto es el resultado predecible de una actividad en el que se debe presentar un informe del progreso a la gestión. Los hitos ocurren de forma frecuente en un proyecto de software. Una entrega es un hito que se entrega al cliente del proyecto.

La calendarización de proyectos implica la creación de varias representaciones gráficas de partes del plan del proyecto. Éstas incluyen redes de actividades que muestran las interrelaciones de las actividades del proyec to y gráficos de barras que muestran la duración de dichas actividades.

Se deben identificar y valorar los riesgos mayores del proyecto para establecer su probabilidad y consecuen cias para éste. En cuanto a los riesgos más probables y potencialmente serios, se deben hacer planes para anularlos, gestionarlos o tratarlos. Estos riesgos se deben analizar de manera explícita en cada reunión del progreso del proyecto.

Software

Espectro de Gestión.

Software

La gestión eficaz de un proyecto de software se centra en las cuatro P’s: personal, producto, proceso y proyecto.

El orden no es arbitrario. El gestor que se olvida de que el trabajo de ingeniería del software es un esfuerzo humano intenso nunca tendrá éxito en la gestión de proyectos.

Software

Espectro de Gestión.

Un gestor que no fomenta una minuciosa comunicación con el cliente al principio de la evolución del proyecto se arriesga a construir una elegante solución para un problema equivocado.

El administrador que presta poca atención al proceso corre el riesgo de arrojar métodos técnicos y herramientas eficaces al vacío. El gestor que emprende un proyecto sin un plan sólido arriesga el éxito del producto.

Software

Personal. La necesidad de contar con personal para el desarrollo del software

altamente preparado y motivado se viene discutiendo desde los años 60 (por ejemplo, [COUSO, WíT94, DEM981). De hecho, el (factor humano) es tan importante que el Instituto de Ingeniería del Software ha desarrollado un Modelo de Madurez de la Capacidad de Gestión de Personal (MMCGP) (para aumentar la preparación de organizaciones del software para llevar a cabo las cada vez más complicadas aplicaciones ayudando a atraer, aumentar, motivar, desplegar y retener el talento necesario para mejorar su capacidad de desarrollo de software).

El modelo de madurez de gestión de personal define las siguientes áreas clave prácticas para el personal que desarrolla software: reclutamiento, selección, gestión de rendimiento, entrenamiento, retribución, desarrollo de la carrera, diseño de la organización y del trabajo y desarrollo cultural y de espíritu de equipo.

El MMCGP es compañero del modelo de madurez de la capacidad software, que guía a las organizaciones en la creación de un proceso de software maduro.

Software

LOS PARTICIPANTES. El proceso de software lo integran participantes que pueden

clasificarse dentro de una de cinco categorías:1. Gestores ejecutivos: definen los aspectos del negocio que

usualmente tienen una influencia significativa en el proyecto.

2. Gestores del proyecto : quienes planifican, motivan, organizan y controlan a los profesionales que realizan el trabajo del software.

3. Profesionales: quienes proporcionan las habilidades técnicas necesarias para realizar la ingeniería de un producto o aplicación.

4. Clientes: quienes especifican los requisitos para la ingeniería del software y otros elementos que tienen un interés mínimo en el resultado.

5. Usuarios finales: quienes interactúan con el software una vez que se libera para su uso productivo.

Software

LIDERES DE EQUIPO. La gestión del proyecto es una actividad

intensamente humana, por lo tanto, los profesionales competentes con frecuencia no son buenos líderes de equipo. Simplemente no tienen la mezcla correcta de habilidades con el personal.

Weinberg sugiere un modelo MOI de liderazgo, basado en la Motivación Organización e Innovación.

Otra visión de las características que definen un gestor de proyecto eficiente resalta 4 rasgos clave: Resolución de problemas, Dotes de gestión, Incentivos e Influencia y fomento de la cultura de equipo.

Software

EL EQUIPO DE SOFTWARE. Existen casi tantas estructuras organizacionales de profesionales para

el desarrollo de software como organizaciones que tiene el mismo fin. La estructura organizacional no puede ser fácilmente modificada.

Las preocupaciones acerca de las consecuencias prácticas y políticas de cambio organizacional no están dentro del ámbito de responsabilidad del gestor del proyecto de software. Sin embargo, la organización de la gente directamente involucrada en un proyecto de software está dentro del ámbito del gestor del proyecto.

Los factores de proyecto que deberían considerarse cuando se planifica la estructura de los equipos de ingeniería del software son:

La dificultad del problema que se resolverá. El tamaño del programa resultante en líneas de código o puntos de función. La vida del equipo. El grado en el que el problema puede separarse en módulos. La calidad y confiabilidad requeridas del sistema que se construirá. La rigidez de la fecha de entrega. El grado de sociabilidad que requiere el proyecto.

Software

Constantine, sugiere 4 paradigmas organizacionales para los equipos de ingeniería de software: Paradigma cerrado, estructura un equipo a lo largo

de una jerarquía tradicional de autoridad. Estos equipos pueden trabajar mejor cuando producen software muy similar a los proyectos anteriores, pero será menos probable que sean innovadores.

Paradigma aleatorio, estructura un equipo libremente y depende de la iniciativa individual de los miembros del equipo. Cuando se requieren innovación o adelantos tecnológicos, los equipos que siguen el paradigma aleatorio serán excelentes, pero no son recomendables cuando se requiere desempeño ordenado.

Software

Paradigma abierto, el trabajo se desarrolla en colaboración. La sólida comunicación y la toma de decisiones basada en el consenso son las marcas características de los equipos de paradigma abierto. Las estructuras de equipo de paradigma abierto se adecuan bien a la solución de problemas complejos, pero no pueden desempeñarse de manera tan eficiente como otros equipos.

Paradigma sincrónico, organiza a los miembros del equipo para trabajar en partes del problema con poca comunicación activa entre ellos.

Software

EQUIPOS AGILES. La filosofía ágil alienta la satisfacción del cliente y la temprana

entrega incremental de software; pequeños equipos de trabajo enormemente motivados; métodos informales; mínimos productos de trabajo de ingeniería del software y simplicidad global de desarrollo.

El enfoque ágil subraya la competencia individual en conjunción con la colaboración del grupo como factores de éxito cruciales para el equipo.

Para aprovechar en forma eficiente las competencias de cada miembro del equipo y fomentar la colaboración eficaz a lo largo de un proyecto de software, los equipos ágiles son “auto organizados”. Un equipo auto organizado no necesariamente mantiene una sola estructura de equipo, sino que más bien aprovecha elementos de los paradigmas aleatorio, abierto y sincrónico.

Software

CONFLICTOS DE COORDINACION Y COMUNICACIÓN. Existen muchas razones por las cuales los

proyectos de software se vuelven problemáticos.

La escala de muchos esfuerzos de desarrollo es grande, lo que conduce a complejidad, confusión y dificultades significativas en la coordinación de los miembros del equipo.

Software

Producto. Antes de poder planificar un proyecto, se deberían establecer los objetivos y el

ámbito del producto, se deberían considerar soluciones alternativas e identificar las dificultades técnicas y de gestión. Sin esta información, es imposible definir unas estimaciones razonables (y exactas) del coste; una valoración efectiva del riesgo, una subdivisión realista de las tareas del proyecto o una planificación del proyecto asequible que proporcione una indicación fiable del progreso.

El desarrollador de software y el cliente deben reunirse para definir los objetivos del producto y su ámbito. En muchos casos, esta actividad empieza como parte del proceso de ingeniería del sistema o del negocio y continúa como el primer paso en el análisis de los requisitos del software. Los objetivos identifican las metas generales del proyecto sin considerar cómo se conseguirán (desde el punto de vista del cliente).

El ámbito identifica los datos primarios, funciones y comportamientos que caracterizan al producto, y, más importante, intenta abordar estas características de una manera cuantitativa.

Una vez que se han entendido los objetivos y el ámbito del producto, se consideran soluciones alternativas.

Software

Ámbito del software. La primera actividad de gestión de un proyecto de software es la

determinación del ámbito de software. El ámbito se define al responder las siguientes preguntas:

CONTEXTO ¿Cómo encaja el software que se desarrollará en un sistema más grande, producto o contexto de negocios, y qué restricciones se imponen como resultado del contexto?

OBJETIVOS DE INFORMACION ¿Qué objetos de datos visibles al usuario producen como resultado del software? ¿Qué objetos de datos se requieren de entrada?

FUNCION Y DESEMPEÑO ¿Qué funciones realiza el software para transformar los datos de entrada en salida? ¿Existen algunas características de desempeño especiales que deban abordarse?

El ámbito del proyecto de software no debe ser ambiguo ni incomprensible a niveles de gestión y técnico. Se debe acotar un enunciado del ámbito del software, es decir, se establecen de manera explícita los datos cuantitativos, se anotan las restricciones o limitaciones y se describen los factores que reducen riesgos.Software

Descomposición del problema. La descomposición del problema, a veces llamada partición o

elaboración del problema, es una actividad que se asienta en el núcleo del análisis de requisitos de software. La descomposición se aplica en dos grandes áreas:

La funcionalidad que debe entregarse. El proceso que se empleará para entregarlo.

Un problema complejo se divide en problemas menores que resultan más manejables. Ésta es la estrategia que se aplica cuando comienza la planificación del proyecto.

Las funciones de software se evalúan y refinan para proporcionar más detalles antes del comienzo de la estimación. Puesto que las estimaciones de costo y planificación temporal están funcionalmente orientadas, con frecuencia es útil cierto grado de descomposición.

Software

Proceso. Un proceso de software  proporciona la estructura desde la que se puede

establecer un detallado  plan para el desarrollo del software.

Un pequeño número de actividades estructurales se puede aplicar a todos los proyectos de software, sin tener en cuenta su tamaño o complejidad.

Diferentes conjuntos de tareas -tareas, hitos, productos del trabajo y puntos de garantía de calidad- permiten a las actividades estructurales adaptarse a las características del proyecto de software y a los requisitos del equipo del proyecto.

Finalmente, las actividades protectoras -tales como garantía de calidad del software, gestión de la configuración del software y medición- cubren el modelo de proceso.

Las actividades protectoras son independientes de las estructurales y tienen lugar a lo largo del proceso.

Software

El problema que se presenta es seleccionar el modelo de proceso apropiado para que un equipo de proyecto someta al software a ingeniería.

El gestor de proyectos debe decidir cuál modelo de proceso es más apropiado para:

Los clientes que han solicitado el producto y el personal que hará el trabajo.

Las características del producto mismo. El ambiente del proyecto en el que trabaja el equipo de software.

Cuando se ha seleccionado un modelo de procesos entonces el equipo define un plan de proyecto preliminar con base en el conjunto de actividades del marco del trabajo del proceso.

Una vez que se establece el plan preliminar, comienza le descomposición del proceso.

Software

Combinación del producto y el proceso. La planeación del proyecto comienza con la

combinación del producto y del proceso. Cada función que el equipo de software someterá a ingeniería debe pasar a través del conjunto de actividades del marco de trabajo definidas para una organización de software.

Descomposición del proceso. Un equipo de software debe tener un grado

significativo de flexibilidad al elegir el modelo de procesos de software que sea mejor para el proyecto y las tareas de ingeniería de software que integren el modelo de procesos una vez elegido.

Software

Enfoque secuencial lineal: para realizar un proyecto relativamente pequeño similar a otros que se hayan realizado.

Modelo de desarrollo rápido de aplicaciones: utilizado cuando existen restricciones de tiempo muy ceñidas.

Estrategia Incremental: utilizado cuando la fecha límite es tan ceñida que la funcionalidad completa no puede alcanzarse. Proyectos con otras características conducirán a la búsqueda de otros modelos.

Una vez elegido el modelo de proceso, el marco de trabajo respectivo se adapta a él. Podrá aplicarse el marco de trabajo genérico: comunicación, planificación, modelado, construcción y despliegue. Funcionará para modelos lineales, iterativos e incrementales, así como evolutivos e incluso para modelos concurrentes o de ensamble de componentes.

La descomposición del proceso comienza cuando el gerente de proyecto pregunta ¿Cómo lograremos esta actividad del marco de trabajo?

Software

Proyecto. Dirigimos los proyectos de software planificados y controlados por

una razón principal -es la Única manera conocida de gestionar la complejidad-. Y todavía seguimos esforzándonos. En 1998, los datos de la industria del software indicaron que el 26% de proyectos de software fallaron completamente y que el 46% experimentaron un desbordamiento en la planificación y en el coste. Aunque la proporción de éxito para los proyectos de software ha mejorado un poco, nuestra proporción de fracaso de proyecto permanece más alto del que debería ser.

Para evitar el fracaso del proyecto, un gestor de proyectos de software y los ingenieros de software que construyeron el producto deben eludir un conjunto de señales de peligro comunes; comprender los factores del éxito críticos que conducen a la gestión correcta del proyecto y desarrollar un enfoque de sentido común para planificar, supervisar y controlar el proyecto.

Software

La gestión de un proyecto de software exitoso requiere entender que puede salir mal. John Reel define10 señales que indican que un proyecto de sistemas de información está en peligro:

1. El personal de software no entiende las necesidades de sus clientes.

2. El ámbito del producto está mal definido.

3. Los cambios se gestionan mal.

4. La tecnología elegida cambia.

5. Las necesidades comerciales cambian, o están mal definidas.

6. Los plazos de entrega no son realistas.

7. Los usuarios se resisten.

8. Se pierde el patrocino.

9. El equipo de proyecto carece de personal.

10. Los gestores evitan las mejores prácticas y las lecciones aprendidas.Software

¿Cómo actúa un gestor para evitar los problemas mencionados?

Sugiere un enfoque de sentido común de 5 partes para proyectos de software:

1. Comience con el pie derecho: Entender bien el problema para establecer bien los objetivos y expectativas. Construir el equipo correcto y darle a éste autonomía, autoridad y tecnología.

2. Mantenga el ímpetu: El gestor de proyecto debe proporcionar incentivos, el equipo debe resaltar la calidad en cada tarea que realiza y los gestores ejecutivos deben hacer lo posible por mantenerse fuera del camino del equipo.

3. Rastree el progreso: En un proyecto de software el progreso se rastrea conforme se elaboran los productos de trabajo(código fuente-modelos) y se aprueban como parte de una actividad de aseguramiento de calidad

4. Tomar decisiones inteligentes: Las decisiones del gestor de proyecto y del equipo de software deben encaminarse para mantenerlo simple.

5. Realice un análisis de resultados: Establezca un mecanismo consistente para extraer lecciones aprendidas por cada proyecto.

Software

Medidas, Métricas e Indicadores.

Software

Software

Las Medidas, métricas e indicadores son muy importantes, porque ayudan al desarrollador en la toma de decisiones ya sea para caracterizar, evaluar, predecir, e incluso mejorar el producto.

Medidas: proporciona una indicación cuantitativa de la extensión, cantidad, dimensiones, capacidad o tamaño de algunos atributos de un proceso o producto.

Ejemplo: Un programa tiene 10.000 LDC (líneas de código).

Muchas veces las personas confundimos los términos Medida y Medición pues consideramos que es lo mismo, esto es un error ya que La medición es el acto de determinar una medida.

Ejemplo: Lenin será el encargado de medir las líneas de código de cada módulo del sistema.

La Utilidad de la medida del software radica en poder asegurar la calidad, cuantificar los atributos que constituyen la calidad para el usuario final, de ahí surgen los resultados cuantitativos.

Software

Métrica: es una indicación medible de algún aspecto cuantificable de un sistema: alcance, riesgo, costo, tiempo.

Características de una métrica útil: Medible Independiente Controlable Precisa

Ejemplo: la productividad de este proyecto fue de 500 (LDC/persona-mes).

Software

DESVENTAJAS DE LAS METRICAS Uno de los problemas que tienen las métricas es que no

existe un esquema de criterios generalmente aceptado (un estándar). Como no hay acuerdo en los criterios involucrados, abundan las propuestas de métricas que abordan la calidad con criterios propios.

Otro problema de las métricas es que no proporcionan información por sí solas y a veces en vez de claridad aportan confusión a la contraparte del modelador dentro del proceso. Esto se debe a que muchas métricas no guardan relación con los intereses de las partes, y el indicador de la calidad de un esquema se construye generalmente con todas ellas.

Software

Indicador: es una métrica o combinación de métricas que proporcionan una visión profunda del proceso del software, del proyecto de software o del producto en sí.

Ejemplo: la productividad media de nuestra empresa es de 500(LDC/pm) y en el último proyecto ha sido de 250(LDC/pm).

Los indicadores del proyecto permiten al gestor: Evaluar el estado del proyecto en curso. Seguir la pista de riesgos potenciales.

Software

Las mediciones del mundo físico se pueden categorizar de dos maneras: medidas directas (por ejemplo: la longitud de un tornillo) y medidas indirectas (por ejemplo: la «calidad» de los tornillos producidos, medidos contando los artículos defectuosos).

Las métricas del software se pueden categorizar de forma similar.

Software

Mediciones del software.

Medidas Directas: En el proceso de ingeniería se encuentran el costo, y el esfuerzo aplicado, las líneas de código producidas, velocidad de ejecución, el tamaño de memoria y los defectos observados en un determinado periodo de tiempo.

Medidas Indirectas: Se encuentra la funcionalidad, calidad, complejidad, eficiencia, fiabilidad, facilidad de mantenimiento, etc.

El coste y el esfuerzo requerido para construir el software, el número de líneas de código producidas, y otras medidas directas son relativamente fáciles de reunir. Sin embargo, la calidad y funcionalidad del software, o su eficiencia o mantenimiento son más difíciles de evaluar y sólo pueden ser medidas indirectamente.

Software

Métricas Orientadas al Tamaño: provienen de la normalización de las medidas de calidad y/o productividad considerando el «tamaño» del software que se haya producido.

Métricas Orientadas a la Función: las métricas del software orientadas a la función utilizan una medida de la funcionalidad entregada por la aplicación como un valor de normalización. Ya que la funcionalidad no se puede medir directamente, se debe derivar indirectamente mediante otras medidas directas.

Las métricas orientadas a la función fueron propuestas por primera vez por Albretch, quien sugirió una medida llamada punto de función.­

Los puntos de función se derivan con una relación empírica según las medidas contables (directas) del dominio de información del software y las evaluaciones de la complejidad del software.

Software

Los puntos de función se calculan completando la tabla siguiente:

Software

Métricas ampliadas de punto de función: la medida de punto de función se diseñó originalmente para aplicarse a aplicaciones de sistemas de información de gestión. Por esta razón, la medida del punto de función era inadecuada para muchos sistemas de ingeniería y sistemas empotrados (que enfatizan función y control).

Para remediar esta situación se ha propuesto un número de extensiones a la métrica del punto de función básica.

Software

Métricas para la calidad del software. Un buen ingeniero de software utiliza mediciones la

calidad del análisis y los modelos del diseño, el código fuente y los casos de prueba que se han creado al aplicar la ingeniería del software.

Para lograr esta evaluación de calidad en tiempo real, el ingeniero debe utilizar medidas técnicas, que evalúan la calidad con objetividad no con subjetividad.

El gestor de proyectos también debe evaluar la calidad objetivamente y no subjetivamente.

Software

Medida de la calidad. Aunque hay muchas medidas de la calidad de software, la corrección, facilidad de

mantenimiento, integridad y facilidad de uso proporcionan indicadores útiles para el equipo del proyecto.

Corrección: Es el grado en el que el software lleva a cabo su función requerida. La medida mas común de corrección es defectos por KLDC.

Facilidad de mantenimiento: Es la facilidad con la que se puede corregir un programa si se encuentra un error. No hay forma de medir directamente la facilidad de mantenimiento, por consiguiente se deben utilizar medidas indirectas. Una simple métrica orientada el tiempo es el tiempo medio de cambio (TMC), es decir el tiempo que se tarda en analizar la petición del cambio. Hitachi ha utilizado una métrica orientada al coste para la capacidad de mantenimiento llamada desperdicios, que es el coste en corregir defectos encontrados después de haber distribuido el software a sus usuarios finales.

Integridad: Mide la capacidad de un sistema para resistir ataques (tanto intencionales como accidentales) contra su seguridad. Para medir la integridad se tienen que definir dos atributos adicionales amenaza (probabilidad de que un ataque de un tipo determinado ocurra en un tiempo determinado). La seguridad es la probabilidad de que se pueda repeler el ataque de un tipo determinado.

Software

Objetivos y metas (el proyecto debe ser o hacerse viable, sustentable y medible, con talentos y recursos asignados, sin estrés y con buen clima laboral y contractual)

Calendario de actividades (debe tener un programa detallado de actividades en función del tiempo -o plan de trabajo- con alcance, metas, talentos y recursos...)

Complejidad manejable (hace sencillo lo complejo, inter relacionando con visión de totalidad los múltiples elementos componentes y las inter relaciones entre ellos)

Administra recursos (especifica y logra disponibilidad de talentos (conocimientos y competencias), capital y esfuerzo humano de diversas áreas de la organización, comunidad, etc.)

Organización matricial (define estructura, sistemas, valores, símbolos, personas y talentos, asigna responsabilidades y recursos: talentos y logros vs. compensaciones fijas y variables; x ej. consultor, coach, facilitador, ejecutor, diseñador, gerente, patrocinador, cliente interno, etc.)

Sistema de comunicación y control (sistema manual o automatizado de registro y difusión de documentación e información sobre marcha del proyecto, precisando desviaciones y correctivos)

Software

Características.