04-gesti n de proyectos de software (16oct13) · 2013. 11. 19. · la acción de gestionar implica...

Universidad Don Bosco (UDB) Facultad de Ingeniería / Escuela de Ingeniería en Computación

…/ 88 ... Aspectos administrativos (Gestión de p royectos de software)

UNIDAD IV: ASPECTOS ADMINISTRATIVOS (GESTION DE PRO YECTOS DE SOFTWARE)

CONTENIDOS 4.1. Administración de proyectos (Gestión de proyectos)

4.1.1. El ciclo de vida del proyecto 4.1.2. Áreas de Conocimiento de la Dirección de Proyectos según la Guía del PMBOK

4.2. Administración de personal 4.3. Métricas de procesos y proyecto

4.3.1. Conceptos básicos de métricas de proceso y proyecto 4.3.2. Medición de procesos de software

4.4. Estimación para proyectos de software 4.5. Calendarización de proyectos de software 4.6. Manejo de riesgos de la ingeniería de software (Gestión del riesgo) 4.7. Gestión de la calidad

4.7.1. Factores de calidad del estándar ISO 9126 4.8. Gestión del cambio

4.8.1. Ámbitos de aplicación 4.8.2. Agente del cambio 4.8.3. Actualización del software 4.8.4. Fases de la gestión del cambio

4.9. Aspectos legales de la ingeniería de software 4.9.1. Derecho informático 4.9.2. Relación contractual de tipo informático 4.9.3. Propiedad intelectual del software 4.9.4. Recomendaciones legales

OBJETIVOS DE LA UNIDAD • Aplicar los beneficios de una adecuada gestión de proyectos. • Aplicar técnicas de administración de personal durante el proceso de creación del software. • Aplicar métricas en los diferentes procesos del desarrollo de software. • Desarrollar estimaciones básicas durante la gestión de proyectos de software. • Aplicar diferentes técnicas para la calendarización de proyectos de software. • Conocer los alcances de la gestión de riesgos. • Aplicar la gestión de la calidad durante el proceso de desarrollo de software. • Aplicar diferentes técnicas para la gestión de cambio durante el proceso de desarrollo de software. • Identificar los diferentes aspectos legales a considerar por la Ingeniería de Software. INTRODUCCION La acción de gestionar implica “hacer diligencias conducentes al logro de un negocio o de un deseo cualquiera”1. Un proyecto es un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único. La naturaleza temporal de los proyectos indica un principio y un final definidos. El final se alcanza cuando se logran los objetivos del proyecto o cuando se termina el proyecto porque sus objetivos no se cumplirán o no pueden ser cumplidos, o cuando ya no existe la necesidad que dio origen al proyecto. Temporal no necesariamente significa de corta duración.

1 Diccionario de la Lengua Española, http://buscon.rae.es/.



En general, esta cualidad no se aplica al producto, servicio o resultado creado por el proyecto; la mayor parte de los proyectos se emprenden para crear un resultado duradero. Por otra parte, los proyectos pueden tener impactos sociales, económicos y ambientales que durarán mucho más que los propios proyectos. En el caso de los proyectos de ingeniería es la administración que se da a los mismos en sus diferentes etapas o fases hasta alcanzar el producto final deseado. La gestión es definida como “todas las actividades y tareas ejecutadas por una o más personas con el propósito de planificar y controlar las actividades de otros para alcanzar un objetivo o completar una actividad que no puede ser realizada por otros actuando independientemente”2. No obstante, en el caso de la gestión de proyectos de desarrollo de software la administración de las diferentes fases es diferente debido a la naturaleza lógica del producto de software. En el caso del software la buena calidad del producto final está definida básicamente por un buen diseño de software. 4.1. Administración de Proyectos (Gestión de proyec tos) Según la Guía del PMBOK3, la dirección de proyectos es la aplicación de conocimientos, habilidades, herramientas y técnicas a las actividades del proyecto para cumplir con los requisitos del mismo. Se logra mediante la aplicación e integración adecuadas de los 42 procesos de la dirección de proyectos, agrupados lógicamente, que conforman los 5 grupos de procesos. Estos 5 grupos de procesos son: • Iniciación, • Planificación, • Ejecución, • Seguimiento y Control, y • Cierre.

Figura 1. Procesos de la dirección de proyectos según la Guía del PMBOK

2 Gestión de Proyectos de Desarrollo de Software, Marcela Varas C.

3 La Guía de los Fundamentos para la Dirección de Proyectos (Guía del PMBOK®), validada por el Project Management Institute (PMI), es una norma reconocida en la profesión de la dirección de proyectos. Por norma se hace referencia a un documento formal que describe normas, métodos, procesos y prácticas establecidos.



La dirección de proyectos es la aplicación de conocimientos, habilidades, herramientas y técnicas a las actividades del proyecto para cumplir con los requisitos del mismo. La aplicación de conocimientos requiere de la dirección eficaz de los procesos apropiados. Un proceso es un conjunto de acciones y actividades interrelacionadas realizadas para obtener un producto, resultado o servicio predefinido. Cada proceso se caracteriza por sus entradas, por las herramientas y técnicas que puedan aplicarse y por las salidas que se obtienen. La gestión del proyecto de software es el primer nivel del proceso de ingeniería de software, porque cubre todo el proceso de desarrollo; para ello es necesario comprender el ámbito del trabajo a realizar, los riesgos en los que se puede incurrir, los recursos requeridos, las tareas a llevar a cabo, el esfuerzo (costo) a consumir y el plan a seguir. Las actividades de gestión están determinadas por: • Planificación: Predeterminación de un curso de acción para alcanzar los objetivos organizacionales. • Organización: Arreglo de las relaciones entre las unidades de trabajo para el cumplimiento de

objetivos y el otorgamiento de responsabilidad y autoridad para obtener esos objetivos. • Equipo de trabajo: Selección y entrenamiento de personas para puestos en la organización. • Dirección: Creación de una atmósfera que apoye y motive a la gente para alcanzar los resultados

finales deseados. • Control: Establecimiento, medición y evaluación del desempeño de las actividades a través de los

objetivos planeados.

Figura 2. Actividades de gestión de proyectos de software.

Las actividades que se derivan de la planificación son: • Fijar los objetivos y metas • Desarrollar estrategias • Desarrollar políticas • Anticipar futuras situaciones • Conducir un establecimiento de riesgos • Determinar posibles cursos de acción • Tomar decisiones de planificación • Fijar procedimientos y reglas • Desarrollar los planes del proyecto • Preparar presupuestos • Documentar los planes del proyecto La organización implica las siguientes actividades: • Identificar y agrupar las funciones, actividades y tareas del proyecto. • Seleccionar estructuras organizacionales • Crear posiciones organizacionales • Definir responsabilidades y autoridades • Establecer el perfil de cada puesto • Documentar las decisiones organizacionales



Las actividades que se derivan de la conformación de los equipos de trabajo son: • Llenar los puestos de la organización • Asimilar al personal recientemente asignado • Educar o entrenar al personal • Proveer de desarrollo general • Evaluar y valorar al personal • Compensar La dirección de un proyecto de ingeniería implica: • Proveer liderazgo • Supervisar personal • Delegar autoridad • Motivar personal • Construir equipos • Coordinar actividades • Facilitar comunicaciones • Resolver conflictos • Manejar cambios • Documentar las decisiones de dirección Las actividades de control son: • Desarrollar estándares de desempeño • Establecer sistemas de monitoreo y reportes • Medir y analizar resultados • Iniciar acciones correctivas • Recompensar y disciplinar • Documentar los métodos de control Dirigir un proyecto por lo general implica: • identificar requisitos, • abordar las diversas necesidades, inquietudes y expectativas de los interesados según se planifica y

efectúa el proyecto, • equilibrar las restricciones contrapuestas del proyecto que se relacionan, entre otros aspectos, con: el

alcance, la calidad, el cronograma, el presupuesto, los recursos y el riesgo. 4.1.1. El ciclo de vida del proyecto El ciclo de vida del proyecto es un conjunto de fases del mismo, generalmente secuenciales y en ocasiones superpuestas, cuyo nombre y número se determinan por las necesidades de gestión y control de la organización u organizaciones que participan en el proyecto, la naturaleza propia del proyecto y su área de aplicación. Un ciclo de vida puede documentarse con ayuda de una metodología. El ciclo de vida del proyecto puede ser determinado o conformado por los aspectos únicos de la organización, de la industria o de la tecnología empleada. Mientras que cada proyecto tiene un inicio y un final definidos, los entregables específicos y las actividades que se llevan a cabo entre éstos variarán ampliamente de acuerdo con el proyecto. El ciclo de vida proporciona el marco de referencia básico para dirigir el proyecto, independientemente del trabajo específico involucrado. Los proyectos varían en tamaño y complejidad. Todos los proyectos, sin importar cuán pequeños o grandes, o cuán sencillos o complejos sean, pueden configurarse dentro de la siguiente estructura del ciclo de vida:



• inicio, • organización y preparación, • ejecución del trabajo y • cierre.

Figura 3. Ciclo de vida del proyecto.

4.1.2. Áreas de Conocimiento de la Dirección de Pro yectos según la Guía del PMBOK Gestión de la Integración del Proyecto Gestión del Alcance del Proyecto Gestión del Tiempo del Proyecto Gestión de los Costos del Proyecto Gestión de la Calidad del Proyecto Gestión de los Recursos Humanos del Proyecto Gestión de las Comunicaciones del Proyecto Gestión de los Riesgos del Proyecto Gestión de las Adquisiciones del Proyecto



Figura 4. Área de conocimiento de la gestión de proyecto según la Guía del PMBOK.

4.2. Administración de personal Para la correcta organización del personal dentro de un proyecto los gestores del mismo no solo necesitan conocer el número aproximado de personas que se requieren para llevarlo a cabo, sino también sus características para su asignación a las tareas que mejor se ajusten a cada uno. Además de ello habrá que tomar en cuenta sus habilidades personales de gestión, comunicación con el resto del equipo y nivel de responsabilidad. El recurso o activo más importante en una empresa es el constituido por el conjunto de personas que la componen. Las actividades de gestión relacionadas con el personal de la empresa se basan en dos aspectos principales: a. La gestión de la información relacionada con la plantilla Incluye información personal compuesta de: • Filiación completa. • Datos médicos.



• Historial laboral. • Datos relacionados con el salario y los incentivos. • Datos sobre la carrera profesional y el historial formativo. El nivel de mayor complejidad lo representa la posibilidad de realizar una planificación y optimización de la plantilla en función de los objetivos de la empresa, lo que implica el manejo y el análisis de la estructura organizativa. Así mismo, el sistema debería dar soporte al proceso de reclutamiento de nuevos empleados. b. La ejecución de la nomina El subsistema de recursos humanos es el que más cambios sufre como reacción a los cambios del entorno. La gestión de los recursos humanos ejerce sus actividades en todos los niveles de la jerarquía de la empresa. A nivel operativo se responsabiliza de: • Mantenimiento de datos de los empleados. • Inventario de cualificaciones de los empleados. • Inventario de puestos de trabajo existentes en la empresa y de las condiciones más adecuadas para

desempeñarlos. • Evaluación de los empleados. • Gestión de las solicitudes de empleo. La Guía del PMBOK define como un área de conocimiento de la gestión de proyecto a la gestión de Recursos Humanos, la cual está conformada por: • Plan de organización • Adquisición del personal • Equipo de desarrollo En un proyecto puede haber tanto individuos como organizaciones o empresas, cuyos intereses pueden afectar positiva o negativamente a la ejecución del proyecto o a un resultado satisfactorio o no del mismo. El equipo de dirección y gestión de un proyecto debe identificar a los implicados, determinar cuáles son sus necesidades y expectativas y gestionar las mismas (tarea de especial dificultad) para asegurar el éxito del proyecto. Implicados clave de un proyecto: • Director de proyecto. • Cliente. • Desarrolladores o empresa de desarrollo. • Sponsor.

Gestionar las expectativas de los implicados suele ser difícil porque a menudo tienen diferentes objetivos, que pueden estar enfrentados o en conflicto. Los roles y las responsabilidades de los distintos implicados en el proyecto, la mayoría de las veces, se superponen. La gestión de recursos humanos incluye los procesos necesarios para hacer más efectivo el uso de las personas involucradas en el proyecto. Esta gestión incluye a todos los implicados en el proyecto (clientes, sponsors, entre otros). Los principales procesos incluyen: • Plan de organización y planificación. Identificar, documentar y asignar roles y responsabilidades y

relaciones de los implicados. • Adquisición del personal. • Formación. • Motivación.



• Equipo de desarrollo y estructura del equipo. Barry Boehm presenta cinco principios para la selección de personal [Boehm, 1981]: • Máximo talento. Usar poco y buen personal. • Trabajo adecuado. Asignar tareas según la habilidad y motivación de la gente disponible. • Progresión profesional. Ayudar a la gente a actualizarse por sí misma en vez de obligarles a trabajar

donde más experiencia tienen o donde son más necesarios. • Equilibrado del equipo. Seleccionar a gente que se complemente y armonice con los demás. • Eliminar la inadaptación. Eliminar y reemplazar a los miembros problemáticos del equipo lo antes

posible. Otros factores que pueden marcar la diferencia son la habilidad de diseño del personal, la habilidad en programación, la experiencia en el entorno y la maquina y la experiencia en el área de aplicación. 4.3. Métricas de procesos y proyecto La medición es muy común en el mundo de la ingeniería. Se miden potencias, consumos, pesos, fuerzas, voltajes, niveles de ruido, entre otros. Desgraciadamente, la medición no es una práctica común en el mundo de la ingeniería de software. Una métrica de software es una función cuyas entradas son datos del software (o el proceso del software) y cuya salida es un valor numérico único, que puede ser interpretado como el grado en que el software (o el proceso del software) posee un atributo dado. Las métricas son un buen medio para entender, monitorizar, controlar, predecir y probar el desarrollo software y los proyectos de mantenimiento (Briand et al., 1996). En general, la medición persigue tres objetivos fundamentales (Fenton y Pfleeger, 1997): • Entender qué ocurre durante el desarrollo y el mantenimiento. • Controlar qué es lo que ocurre en nuestros proyectos. • Mejorar nuestros procesos y nuestros productos. Las métricas pueden ser utilizadas para que los profesionales e investigadores puedan tomar las mejores decisiones (Pfleeger, 1997). 4.3.1. Conceptos básicos de métricas de proceso y p royecto

Concepto Definición Relaciones

Atributo

Una propiedad mensurable, física o abstracta, que comparten todas las entidades de una categoría de entidad.

• Un atributo sólo puede pertenecer a una categoría de entidad.

• Una medición se realiza sobre los atributos de una entidad.

• Un atributo tiene definida cero, una o varias métricas.

• Un atributo está relacionado con uno o más conceptos medibles.

Métrica

Una forma de medir y una escala, definidas para realizar mediciones de uno o varios atributos.

• Una métrica está definida para uno o más atributos • Dos métricas pueden relacionarse mediante una

función de transformación. • El tipo de dicha función de transformación va a

depender del tipo de escala de ambas métricas. • Una métrica puede expresarse en una unidad (sólo

para métricas cuya escala sea de tipo intervalo o ratio).



Concepto Definición Relaciones

Medida Resultado de una medición. • Una medida es el resultado de una medición.

Razones que justifican la medición del software son: • Para indicar la calidad del producto, • Para evaluar la productividad de la gente que desarrolla el producto, • Para evaluar los beneficios (en términos de productividad y calidad) derivados del uso de nuevos

métodos y herramientas de ingeniería de software, • Para establecer una línea base para la estimación y • Para ayudar a justificar el uso de nuevas herramientas o formación adicional. Las métricas pueden ser de proceso, de proyecto y de producto.

Figura 5. Métrica de procesos y proyectos de software.

La medición del proceso implica las mediciones de las actividades relacionadas con el software siendo algunos de sus atributos típicos el esfuerzo, el costo y los defectos encontrados.

Figura 6. Proceso GQM (Goal-Question-Metric).

GQM define un objetivo, refina este objetivo en preguntas y define métricas que intentan dar información para responder a estas preguntas. La medición puede englobarse en dos categorías: medidas directas y medidas indirectas. Entre las medidas directas del proceso de ingeniería de software se encuentra el costo y el esfuerzo aplicado. Entre las medidas directas del producto se encuentran las líneas de código producidas, velocidad de



ejecución y los defectos observados en un período de tiempo. Entre las medidas indirectas se encuentran la calidad, funcionalidad, eficiencia, facilidad de mantenimiento, entre otras. Las métricas de software se pueden clasificar como métricas orientadas a la función o métricas orientadas al tamaño. También se pueden clasificar según la información que entregan: métricas de productividad, las que se centran en el rendimiento del proceso de ingeniería de software, métricas de calidad, proporcionan una indicación de cómo se ajusta el software a los requisitos explícitos e implícitos del cliente y las métricas técnicas, que se centran más en el software que en el proceso a través del cual se ha desarrollado (por ejemplo grado de modularidad o grado de complejidad lógica). Los indicadores de proyecto permiten al administrador de software: • Evaluar el estado del proyecto en curso. • Realizar un seguimiento de los riesgos potenciales. • Detectar las áreas de problemas antes de que se conviertan en “críticas”. • Ajustar el flujo y las tareas de trabajo. • Evaluar la habilidad del equipo del proyecto en controlar la calidad de los productos de trabajo de la

ingeniería del software. 4.3.2. Medición de procesos de software La medición es una herramienta primaria para los administradores de software y de sistemas; para asegurar que los productos cumplan los objetivos definidos. Son un elemento clave en toda disciplina de ingeniería bien establecida. Cuando se integran en la totalidad de los procesos de administración de proyectos, ayudan al administrador del mismo a: Identificar los riesgos; llevar el seguimiento de problemas específicos; evaluar el impacto de dichos problemas en el costo del proyecto y en el desempeño de objetivos técnicos; desarrollar alternativas de solución y seleccionar el mejor enfoque para corregir los problemas. Las mediciones brindan la visión que el administrador del proyecto necesita para la toma de decisiones críticas para el éxito del mismo. La Mediciones Prácticas de Software y Sistemas (PSM, Practical Software and Systems Measurement) brinda a los administradores de proyectos la información cuantitativa necesaria para tomar decisiones que tengan un impacto en los costos, cronograma y objetivos técnicos de desempeño del proyecto.



Figura 7. Mediciones Prácticas de Software y Sistemas (PSM, Practical Software and Systems Measurement).

Figura 8. Gestión de procesos.

La gestión de proceso implica: definir el o los procesos, ejecutarlos y medirlos. La medición permite mejorar el proceso o controlar el proceso. Si el proceso se mejora se pueden redefinir nuevos procesos; en caso que los procesos sean controlados únicamente, se vuelven a ejecutar para su posterior medición.



Figura 9. Actividades de medición.

Figura 10. Gestión de procesos vrs. Gestión de proyectos.

4.4. Estimación para proyectos de software Una de las actividades cruciales del proceso de gestión es la planificación, la cual se basa en una buena estimación del esfuerzo requerido para realizar el proyecto, duración cronológica del proyecto y el costo.



Las técnicas más utilizadas para realizar estimaciones de costos y plazos son:

Técnica Descripción

Juicio experto El administrador del proyecto recurre a alguien que haya desarrollado aplicaciones similares para que realice una estimación de los recursos y tiempo a necesitar para el desarrollo.

Descomposición Consiste en dividir el problema en partes más pequeñas y estimar cada una por separado, utilizando un juicio experto o algún método más formal (como estimar sobre la base del tamaño en una métrica formal). Además, se suele realizar una estimación optimista (EO), otra más probable (EMP) y una pesimista (EP), y asignarle una probabilidad a cada una, obteniendo así nuestra estimación mediante: E=EO *Po + EMP*Pmp + EP*Pp; donde Po es la probabilidad asignada a la estimación optimista, Pmp la asignada a la más probable y Pp la asignada a la pesimista.

El presupuesto del proyecto incluye distintos tipos de costos: costo de instalación, personal, métodos y herramientas. Es oportuno considerar los costos ocultos, aquellos que en muchas ocasiones no son aparentes para los gerentes y desarrolladores, tales como: espacio físico adecuado para el desarrollo, nivel de ruido, interrupciones de personas ajenas al proyecto, entre otros. Para la mayoría de los proyectos el mayor componente del costo es el esfuerzo, el cual a su vez es el componente con mayor incertidumbre. Se debe determinar cuántos días – personal de esfuerzo se requerirán para completar el proyecto. La estimación de de los costos, cronograma y esfuerzo debe ser hecha tan temprano como sea posible durante el ciclo de vida del proyecto; pero la estimación debe hacerse repetidamente a lo largo del ciclo de vida para refinarse, basándose en información más completa sobre las características del proyecto. Causas de estimaciones inadecuadas: • Pedidos frecuentes de cambios por parte de los usuarios. • Tareas pasadas por alto. • Pérdida de comprensión de los usuarios de sus propios requerimientos. • Análisis insuficiente cuando se desarrolla una estimación. • Pérdida de coordinación del desarrollo de sistemas, servicios técnicos, operaciones, administración

de datos y otras funciones durante el desarrollo. • Pérdida de método adecuado o guías para la estimación. • Complejidad del sistema de aplicación propuesto. • Integración requerida con sistemas existentes. • Complejidad de los programas en el sistema. • Dimensión del sistema expresada como número de funciones o programas. • Capacidad de los miembros del equipo de proyecto. • Experiencia del equipo de proyecto con el sistema. • Frecuencia o alcance de cambios potenciales en los requerimientos del usuario. • Experiencia del equipo de proyecto con el lenguaje de programación. • Sistema de gestión de la base de datos. • Número de miembros del equipo de proyecto. • Extensión de estándares de la programación o documentación estándar. • Disponibilidad de herramientas tales como generadores de aplicación. • Experiencia del equipo con el hardware.



Pasos para fijar precios de manera efectiva

1. Determina el salario por hora Es importante determinar un salario por hora, para esto existe esta simple fórmula: (Costos + Salario) ÷ Horas trabajadas por año = Salario por hora Para usar esta fórmula por ejemplo si tu quieres ganar $60,000 dólares al año, y gastas $10,000 al año por ejemplo en hosting, stock de fotografías y videos, fuentes, etc., y trabajas normalmente 40 horas semanales (2,000 horas al año), entonces el salario por hora debe ser de (10,000 + 60,000) ÷ 2,000 = $35/hr., esto es lo que se debería usar cómo guía para fijar los precios de los proyectos. 2. Fija los precios base para determinados tipos de proyecto Por ejemplo si eres un diseñador web que ofreces los servicios de diseño y codificación, tu lista de servicios sería algo parecida a esta: Diseño de Logotipo Diseño de sitio web (diseño solamente en formato .psd) Diseño de sitio web (diseño + codificación en xHTML+CSS, menos de 7 páginas) Creación de un skin para un foro (diseño solamente en formato .psd) Diseño de blog (diseño + codificación en un theme de WordPress) Ahora que tenemos nuestra lista de servicios, debemos determinar un nivel de complejidad para cada uno, que puede ir desde 1 hasta 5 para el más complejo, si para ti es más fácil diseñar un logotipo puedes asignarle un 1 (1.1) en el nivel de complejidad y si hacer un theme de wordpress es más difícil puedes asignarle un 5 (1.5). La fórmula es la siguiente: (Salario por hora x Tiempo estimado para terminar) x nivel de complejidad = Precio base Por ejemplo vamos a crear el diseño de un sitio web + la codificación. El nivel de complejidad vamos a ponerlo en 3. Esto quedaría así: ($35 x 15 horas) x 1.3 = $682.5. Ahora solo tenemos que redondear la cantidad por ejemplo $650 está bien. 3. Fijar precios para características adicionales Nunca falta el cliente que a la mitad del proyecto se le ocurre pedir una característica adicional, ya sea desde un sistema de login hasta una presentación en flash, para determinar el precio se sigue el mismo procedimiento que para el punto anterior. 4. Fijar precios para el trabajo externo (outsourci ng) Algo que se debe tener en cuenta a la hora de hacer una cotización es conocer nuestros límites, no le vamos a decir a nuestro cliente que podemos hacer las mil maravillas y a la hora de la entrega del trabajo decirle que no pudimos, no hay algo más embarazoso, una buena práctica para cotizar el trabajo externo es utilizar la siguiente fórmula: (Cotización del contratista externo x 1.10) = Precio Básicamente es aumentar el 10% al costo de la cotización externa.



4.5. Calendarización de proyectos de software La gestión de proyectos de software no puede ser efectiva si no se parte de un plan o una calendarización de las actividades que se van a desarrollar, los tiempos de duración, el personal involucrado y la precedencia con relación a otras actividades dentro del mismo proyecto; no obstante, muchas veces una mala planeación lleva al fracaso del proyecto. En este caso la recomendación es: • Realizar una estimación detallada empleando datos históricos de proyectos previos. Determinar el

esfuerzo y la duración estimada para el proyecto. • Aplicar un modelo de proceso incremental y desarrollar una estrategia de ingeniería de software que

entregará la funcionalidad crítica en la fecha límite impuesta, pero demorará otra. Documente el plan. • Reunirse con el cliente y, con la estimación detallada, explicarle por qué la fecha límite impuesta es

irrealizable. Asegúrese de señalar que todas las estimaciones están basadas sobre el desempeño en proyectos previos.

• Ofrezca la estrategia de desarrollo incremental como alternativa. La calendarización o Plan de Desarrollo de Software se hace con el propósito de proporcionar la información necesaria para controlar el proyecto. En él se describe el enfoque de desarrollo del software. Es una actividad que distribuye estimaciones de esfuerzo a través de la duración planificada del proyecto, al asignar el esfuerzo a tareas específicas de ingeniería de software. Los usuarios del Plan de Desarrollo del Software son: • El jefe del proyecto, el cual lo utiliza para organizar la agenda y necesidades de recursos, y para

realizar su seguimiento. • Los miembros del equipo de desarrollo que lo utilizan para entender lo que deben hacer, cuándo

deben hacerlo y qué otras actividades dependen de ello. En la calendarización de proyecto puede utilizar técnicas y / o herramientas tales como: • PERT (técnica de evaluación y revisión de programa). • CPM (método de la ruta crítica).

Diagrama PERT Diagrama CPM (método de la ruta crítica)

Figura 11 y 12. Ejemplos genéricos de diagrama de PERT y diagrama CPM

Para la construcción del cronograma puede utilizar el Diagrama de Gantt, así como los Diamantes o hitos.



Figura 13. Ejemplo genérico de un Diagrama de Gantt

4.5.1. Actividades de la planificación del proyecto de software La primera actividad de la planificación del proyecto de software es determinar el ámbito del software. Se deben evaluar la función y el rendimiento que se asignaron al software durante la ingeniería del sistema de computadora, para establecer un ámbito de proyecto que no sea ambiguo, ni incomprensible para directivos y técnicos. Se debe delimitar la declaración del ámbito del software. El ámbito del software describe el control y los datos a procesar, la función, el rendimiento, las restricciones, las interfaces y la fiabilidad. Se evalúan las funciones descritas en la declaración del ámbito, y en algunos casos se refinan para dar más detalles antes del comienzo de la estimación. Dado que las estimaciones del costo y de la planificación temporal están orientadas a la función, muchas veces es útil llegar a un cierto grado de descomposición. Las consideraciones de rendimiento abarcan los requisitos de tiempo de respuesta y de procesamiento. Las restricciones identifican los límites del software originados por el hardware externo, por la memoria disponible y por otros sistemas existentes. Al principio de un proyecto de software las cosas siempre están un poco borrosas. Se ha definido una necesidad y se han enunciado las metas y objetivos básicos, pero todavía no se ha establecido la información necesaria para definir el ámbito (prerrequisito para la estimación). La técnica utilizada con más frecuencia para acercar al cliente y al desarrollador, y para hacer que comience el proceso de comunicación es establecer una reunión o una entrevista preliminar. La primera reunión entre un ingeniero de software (el analista) y el cliente puede compararse a la primera cita entre adolescentes. Ninguna persona sabe lo que decir o preguntar; ambos están preocupados por si lo que dicen es mal interpretado; ambos están pensando hasta dónde podrían llegar (probablemente los dos tienen aquí diferentes expectativas); ambos quieren quitárselo pronto de encima; pero al mismo tiempo quieren que salga bien. Sin embargo, se debe iniciar la comunicación. Gause y Weinberg [GAU89] sugieren que el analista comience haciendo preguntas de contexto libre. Es decir, una serie de preguntas que lleven a un entendimiento básico del problema, las personas que están interesadas en la solución, la naturaleza de la solución que se desea y la efectividad prevista del primer encuentro. El primer conjunto de cuestiones de contexto libre se centran en el cliente, en los objetivos globales y en los beneficios. Por ejemplo, el analista podría preguntar: • ¿Quién está detrás de la solicitud de este trabajo? • ¿Quién utilizará la solución? • ¿Cuál será el beneficio económico de una buena solución? • ¿Hay otro camino para la solución?



Las preguntas siguientes permiten que el analista comprenda mejor el problema y que el cliente exprese sus percepciones sobre una solución: • ¿Cómo caracterizaría [el cliente] un resultado “correcto” que se generaría con una solución

satisfactoria? • ¿Con qué problema(s) se afrontará esta solución? • ¿Puede mostrarme (o describirme) el entorno en el que se utilizará la solución? • ¿Hay aspectos o limitaciones especiales de rendimiento que afecten a la forma en que se aborde la

solución? La última serie de preguntas se centra en la efectividad de la reunión. Gause y Weinberg las llaman “metacuestiones” y proponen la lista siguiente (abreviada): • ¿Es usted la persona apropiada para responder a estas preguntas? • ¿Son “oficiales” sus respuestas? • ¿Son relevantes mis preguntas para su problema? • ¿Estoy realizando muchas preguntas? • ¿Hay alguien más que pueda proporcionar información adicional? • ¿Hay algo más que debiera preguntarle? Una vez se ha identificado el ámbito (con la ayuda del cliente), es razonable preguntarse: “¿Podemos construir el software de acuerdo a este ámbito? ¿Es factible el proyecto?”. Con frecuencia, las prisas de los ingenieros de software sobrepasan estas preguntas (o están obligados a pasarlas por los clientes o gestores impacientes), solo se tienen en cuenta en un proyecto condenado desde el comienzo. La segunda tarea de la planificación del desarrollo de software es la estimación de los recursos requeridos para acometer el esfuerzo de desarrollo de software. La Figura 10 ilustra los recursos de desarrollo en forma de pirámide. En la base de la pirámide de recursos se encuentra el entorno de desarrollo -herramientas de hardware y software- que proporciona la infraestructura de soporte al esfuerzo de desarrollo. En un nivel más alto se encuentran los componentes de software reutilizables los bloques de software que pueden reducir drásticamente -los costos de desarrollo y acelerar la entrega-. En la parte más alta de la pirámide está el recurso primario -el personal-.

Figura 14. Recursos del proyecto.

Cada recurso queda especificado mediante cuatro características: descripción del recurso, informe de disponibilidad, fecha cronológica en la que se requiere el recurso, tiempo durante el que será aplicado el recurso. Las dos últimas características pueden verse como una ventana temporal. La disponibilidad del recurso para una ventana específica tiene que establecerse lo más pronto posible. 4.6. Manejo de riesgos de la ingeniería de software (Gestión del riesgo) En su libro sobre análisis y gestión del riesgo, Robert Charette [CHA89] presenta la siguiente definición de riesgo: en primer lugar, el riesgo afecta a los futuros acontecimientos. El hoy y el ayer están más allá de lo que nos pueda preocupar, pues ya estamos cosechando lo que sembramos previamente con nuestras acciones del pasado. La pregunta es, podemos, por tanto, cambiando nuestras acciones actuales, crear una oportunidad para una situación diferente y, con suerte, mejor para nosotros en el futuro. Esto significa, en segundo lugar, que el riesgo implica cambio, que puede venir dado por cambios de opinión, de acciones, de lugares... [En tercer lugar,] el riesgo implica elección, y la incertidumbre que entraña la elección. Por tanto, el riesgo, como la muerte y los impuestos, es una de las pocas cosas inevitables en la vida.



Cuando se considera el riesgo en el contexto de la ingeniería del software, los tres pilares conceptuales de Charette se hacen continuamente evidentes. El futuro es lo que nos preocupa -¿qué riesgos podrían hacer que nuestro proyecto fracasara?-. El cambio es nuestra preocupación ¿cómo afectarán los cambios en los requisitos del cliente, en las tecnologías de desarrollo, en las computadoras a las que va dirigido el proyecto y a todas las entidades relacionadas con él, al cumplimiento de la planificación temporal y al éxito en general?. Para terminar, debemos enfrentarnos a decisiones -¿qué métodos y herramientas deberíamos emplear, cuánta gente debería estar implicada, cuánta importancia hay que darle a la calidad?-. 4.6.1. Estrategias de riesgo La mayoría de los equipos de software confían solamente en las estrategias de riesgo reactivas. En el mejor de los casos, la estrategia reactiva supervisa el proyecto en previsión de posibles riesgos. Los recursos se ponen aparte, en caso de que pudieran convertirse en problemas reales. Pero lo más frecuente es que el equipo de software no haga nada respecto a los riesgos hasta que algo va mal. Después el equipo vuela para corregir el problema rápidamente. Este es el método denominado a menudo “de bomberos”. Cuando falla, “la gestión de crisis” [CHA92] entra en acción y el proyecto se encuentra en peligro real. Una estrategia considerablemente más inteligente para el control del riesgo es ser proactivo. La estrategia proactiva empieza mucho antes de que comiencen los trabajos técnicos. Se identifican los riesgos potenciales, se evalúa su probabilidad y su impacto y se establece una prioridad según su importancia. Después, el equipo de Software establece un plan para controlar el riesgo. El primer objetivo es evitar el riesgo, pero como no se pueden evitar todos los riesgos, el equipo trabaja para desarrollar un plan de contingencia que le permita responder de una manera eficaz y controlada. A lo largo de lo que queda de este capítulo, estudiamos la estrategia proactiva para el control de riesgos. 4.6.2. Riesgo de software Aunque ha habido amplios debates sobre la definición adecuada para riesgo de software, hay acuerdo común en que el riesgo siempre implica dos características [HIG95]: • Incertidumbre: el acontecimiento que caracteriza al riesgo puede o no puede ocurrir; por ejemplo, no

hay riesgos de un 100 por 100 de probabilidad'. • Pérdida: si el riesgo se convierte en una realidad, ocurrirán consecuencias no deseadas o pérdidas. Cuando se analizan los riesgos es importante cuantificar el nivel de incertidumbre y el grado de pérdidas asociado con cada riesgo. Para hacerlo, se consideran diferentes categorías de riesgos. Los riesgos del proyecto amenazan al plan del proyecto; es decir, si los riesgos del proyecto se hacen realidad, es probable que la planificación temporal del proyecto se retrase y que los costes aumenten. Los riesgos del proyecto identifican los problemas potenciales de presupuesto, planificación temporal, personal (asignación y organización), recursos, cliente y requisitos y su impacto en un proyecto de software. Los riesgos técnicos amenazan la calidad y la planificación temporal del software que hay que producir. Si un riesgo técnico se convierte en realidad, la implementación puede llegar a ser difícil o imposible. Los riesgos técnicos identifican problemas potenciales de diseño, implementación, de interfaz, verificación y de mantenimiento. Además, las ambigüedades de especificaciones, incertidumbre técnica, técnicas anticuadas y las “tecnologías punta” son también factores de riesgo. Los riesgos técnicos ocurren porque el problema es más difícil de resolver de lo que pensábamos. Los riesgos del negocio amenazan la viabilidad del software a construir. Los riesgos del negocio a menudo ponen en peligro el proyecto o el producto. Los candidatos para los cinco principales riesgos del negocio son: (1) construir un producto o sistema excelente que no quiere nadie en realidad (riesgo de mercado);



(2) construir un producto que no encaja en la estrategia comercial general de la compañía (riesgo estratégico); (3) construir un producto que el departamento de ventas no sabe cómo vender; (4) perder el apoyo de una gestión experta debido a cambios de enfoque o a cambios de personal (riesgo de dirección); (5) perder presupuesto o personal asignado (riesgos de presupuesto). Es extremadamente importante recalcar que no siempre funciona una categorización tan sencilla. Algunos riesgos son simplemente imposibles de predecir. Otra categorización general de los riesgos ha sido propuesta por Charette [CHA89]. Los riesgos conocidos son todos aquellos que se pueden descubrir después de una cuidadosa evaluación del plan del proyecto, del entorno técnico y comercial en el que se desarrolla el proyecto y otras fuentes de información fiables (por ejemplo: fechas de entrega poco realistas, falta de especificación de requisitos o de ámbito del software, o un entorno pobre de desarrollo). Los riesgos predecibles se extrapolan de la experiencia en proyectos anteriores (por ejemplo: cambio de personal, mala comunicación con el cliente, disminución del esfuerzo del personal a medida que atienden peticiones de mantenimiento). Los riesgos impredecibles son el comodín de la baraja. Pueden ocurrir, pero son extremadamente difíciles de identificar por adelantado. 4.6.3. Identificación del riesgo La identificación del riesgo es un intento sistemático para especificar las amenazas al plan del proyecto (estimaciones, planificación temporal, carga de recursos, etc.). Identificando los riesgos conocidos y predecibles, el gestor del proyecto da un paso adelante para evitarlos cuando sea posible y controlarlos cuando sea necesario. Existen dos tipos diferenciados de riesgos para cada categoría: riesgos genéricos y riesgos específicos del producto. Los riesgos genéricos son una amenaza potencial para todos los proyectos de software. Los riesgos específicos de producto sólo los pueden identificar los que tienen una clara visión de la tecnología, el personal y el entorno específico del proyecto en cuestión. Para identificar los riesgos específicos del producto, se examinan el plan del proyecto y la declaración del ámbito del software y se desarrolla una respuesta a la siguiente pregunta: “¿Qué características especiales de este producto pueden estar amenazadas por nuestro plan del proyecto?”. Un método para identificar riesgos es crear una lista de comprobación de elementos de riesgo. La lista de comprobación se puede utilizar para identificar riesgos y se centra en un subconjunto de riesgos conocidos y predecibles en las siguientes subcategorías genéricas: • Tamaño del producto: riesgos asociados con el tamaño general del software a construir o a modificar. • Impacto en el negocio: riesgos asociados con las limitaciones impuestas por la gestión o por el

mercado. • Características del cliente: riesgos asociados con la sofisticación del cliente y la habilidad del

desarrollador para comunicarse con el cliente en los momentos oportunos. • Definición del proceso: riesgos asociados con el grado de definición del proceso del software y su

seguimiento por la organización de desarrollo. • Entorno de desarrollo: riesgos asociados con la disponibilidad y calidad de las herramientas que se

van a emplear en la construcción del producto. • Tecnología a construir: riesgos asociados con la complejidad del sistema a construir y la tecnología

punta que contiene el sistema. • Tamaño y experiencia de la plantilla: riesgos asociados con la experiencia técnica y de proyectos de

los ingenieros del software que van a realizar el trabajo.



Tabla 4. Evaluación global del riesgo del proyecto.

4.7. Gestión de la calidad El American Heritage Dictionary, define la calidad como “una característica o atributo de algo”. Como un atributo de un elemento, la calidad se refiere a las características mensurables -cosas que se pueden comparar con estándares conocidos como longitud, color, propiedades eléctricas, maleabilidad, etc.-. Sin embargo, el software en su gran extensión, como entidad intelectual, es más difícil de caracterizar que los objetos físicos. No obstante, sí existen las medidas de características de un programa. Entre estas propiedades se incluyen complejidad ciclomática, cohesión, número de puntos de función, líneas de código y muchas otras. Cuando se examina un elemento según sus características mensurables, se pueden encontrar dos tipos de calidad: calidad del diseño y calidad de concordancia. La calidad de diseño se refiere a las características que especifican los ingenieros de software para un elemento. El grado de materiales, tolerancias y las especificaciones del rendimiento contribuyen a la calidad del diseño. Cuando se utilizan materiales de alto grado y se especifican tolerancias más estrictas y niveles más altos de rendimiento, la calidad de diseño de un producto aumenta, si el producto se fabrica de acuerdo con las especificaciones. La calidad de concordancia es el grado de cumplimiento de las especificaciones de diseño durante su realización. Una vez más, cuanto mayor sea el grado de cumplimento, más alto será el nivel de calidad de concordancia.



En el desarrollo del software, la calidad de diseño comprende los requisitos, especificaciones y el diseño del sistema. La calidad de concordancia es un aspecto centrado principalmente en la implementación. Si la implementación sigue el diseño, y el sistema resultante cumple los objetivos de requisitos y de rendimiento, la calidad de concordancia es alta. 4.7.1. Control de calidad El control de cambios puede equipararse al control de calidad. Pero, ¿cómo se logra el control de calidad? El control de calidad es una serie de inspecciones, revisiones y pruebas utilizadas a lo largo del proceso del software para asegurar que cada producto cumple con los requisitos que le han sido asignados. El control de calidad incluye un bucle de realimentación (feedback) del proceso que creó el producto. La combinación de medición y realimentación permite afinar el proceso cuando los productos de trabajo creados fallan al cumplir sus especificaciones. Este enfoque ve el control de calidad como parte del proceso de fabricación. Las actividades de control de calidad pueden ser manuales, completamente automáticas o una combinación de herramientas automáticas e interacción humana. Un concepto clave del control de calidad es que se hayan definido todos los productos y las especificaciones mensurables en las que se puedan comparar los resultados de cada proceso. El bucle de realimentación es esencial para reducir los defectos producidos.

Figura 15. Costo relativo de corregir un error.

4.7.2. Factores de calidad del estándar ISO 9126 El estándar ISO 9126 se desarrolló como un intento de identificar los atributos de calidad para el software de computadora. El estándar identifica seis atributos clave de la calidad: • Funcionalidad : el grado en que el software satisface las necesidades que indican los siguientes

subatributos: idoneidad, exactitud, interoperabilidad, cumplimiento y seguridad. • Confiabilidad : la cantidad de tiempo en que el software está disponible para usarlo según los

siguientes subatributos: madurez, tolerancia a fallas y facilidad de recuperación.



• Facilidad de uso : la facilidad con que se usa el software de acuerdo con los siguientes subatributos: facilidad de comprensión, facilidad de aprendizaje y operabilidad.

• Eficiencia : el grado en que el software emplea en forma óptima los recursos del sistema, como lo

indican los siguientes subatributos: comportamiento en el tiempo, comportamiento de los recursos. • Facilidad de mantenimiento : la facilidad con la que se repara el software de acuerdo con los

siguientes subatributos: facilidad de análisis, facilidad de cambio, estabilidad y facilidad de prueba. • Portabilidad : La facilidad con la que se lleva el software de un entorno a otro según los siguientes

atributos: adaptabilidad, facilidad para instalarse, cumplimiento y facilidad para reemplazarse. Los ISO 9126 no necesariamente se prestan a la medición directa; sin embargo, proporcionan una base valiosa para las medidas indirectas y una lista de verificación excelente para evaluar la calidad de un sistema. 4.8. Gestión del cambio La mayoría de las organizaciones quieren un cambio ejecutado con la menor resistencia. Para que esto ocurra, el cambio debe ser aplicado con un enfoque estructurado de manera que la transición de un tipo de comportamiento a otra organización amplia será suave. Gestión del cambio es un conjunto de procesos que se emplea para asegurar que los cambios significativos se llevan a cabo en forma ordenada, controlada y sistemática a efecto el cambio organizacional. 4.8.1. Ámbitos de aplicación 1. Para mejorar la gestión de los cambios en curso: * Asimilación de las nuevas tecnologías de la comunicación * Procesos de mejora de la calidad * Reestructuraciones * Fusiones * Absorciones * Acomodación a las nuevas circunstancias de la globalización 2. Para potenciar la capacidad de cambio de la organización. Las técnicas de gestión del cambio se utilizan también para asistir los procesos de transformación que tienen como objetivo específico la potenciación de la flexibilidad de la organización y su capacidad de respuesta rápida a situaciones nuevas.



Figura 16. Gestión del cambio en las organizaciones.

4.8.2. Agente del cambio En el análisis del desarrollo organizacional es necesario contar con un buen agente de cambio, que es aquella persona que actúa en forma deliberada sobre el entorno a fin de facilitar o propiciar la implantación del cambio proyectado. Al respecto, Roger Tessier (1973), agrega, toda persona o sistema que contribuye mediante una acción directa o indirecta a la implantación del cambio constituye un agente de cambio. En general, el agente del desarrollo organizacional, es un consultor externo al sistema. En este caso el consultor puede pertenecer al cuadro ejecutivo de la empresa (consultor interno) o si no de afuera (consultor externo). Pero ambos actuaran como externos al sistema objetivo. 4.8.3. Actualización del software Partimos de la opinión de que las actualizaciones de software en las empresas, actúan como agentes de cambio en la cultura organizacional. Con frecuencia que los esfuerzos de cambio no producen los resultados esperados, y si ocasionan una serie de consecuencias involuntarias y poco útiles. Con lo cual se disponen los recursos para mitigar el impacto de los efectos no deseados, en lugar de enfocarlos en concretar los resultados planificados. Se considera que la resistencia al cambio es la principal causa de desvíos y/o fracasos en los procesos de actualización de software, por lo tanto considerar el factor humano es fundamental para alcanzar el éxito; pues, las personas no se adaptan al cambio tan solo como resultado del cambio de tecnología. La humanización del proceso de implementación de software persigue: • Para crear un contexto de posibilidades de aceptación, de colaboración y de compromiso con los

procesos de cambio, logrando así neutralizar dicha resistencia. • Para anticipar los desafíos que las personas deberán afrontar con el cambio y mitigar su impacto. • Para favorecer que las personas se involucren con el nuevo software, en lugar de la natural tendencia

a luchar en contra del mismo.

Consideraciones para gestionar el cambio durante un proceso de actualización de software: • Escuchar y asistir las inquietudes de la gente respecto de este cambio. • Desarrollar capacidad de convivencia con los cambios. • Accionar desde una mirada sistémica de la empresa • Generar Trabajo en equipo • Facilitar la adquisición de Competencias de Liderazgo al servicio. • Promover la Comunicación y la coordinación de acciones efectivas.



• Impulsar la Alineación y compromiso responsable con las estrategias, planificaciones, métodos, reglas e instructivos de procedimientos.

• Detectar y rediseñar las prácticas recurrentes que no llevan a los resultados esperados. • Fomentar la Creación de nuevas acciones para anticiparse y mitigar los desafíos previstos como

consecuencia de la actualización de software • Tomar en cuenta y trabajar con las emociones y estados de ánimo que el proceso dispara en las

personas • Brindar nuevas interpretaciones del conflicto y de los obstáculos. 4.8.4. Fases de la gestión del cambio • Fase 1. - DEFINICIÓN de los objetivos del proyecto así como una visión de cuál será la situación final

tras el desarrollo del proyecto. Creación del equipo global de trabajo. • Fase 2. - DIAGNÓSTICO de la situación actual • Fase 3. - DESARROLLO del plan de acciones (incluyendo el plan de comunicación interna), así como

los objetivos concretos que alcanzará. Creación de los equipos de trabajo. • Fase 4. - IMPLANTACIÓN DEL CAMBIO en las fases definidas. • Ejecución del plan de FORMACIÓN. • Fase 5. - SEGUIMIENTO de la solución y CONTROL. 4.9. Aspectos legales de la ingeniería de software El Ingeniero de Software dentro de su desempeño en la consecución de desarrollar productos a la medida de los clientes, eficaces y satisfactorios en todos los sentidos, generalmente se ve en la necesidad de generar relaciones contractuales que determinarán la finalización amistosa de ambas partes. Para ello es necesario que el Ingeniero de Software posea determinados conocimientos jurídicos. Esta creciente necesidad de tener cada día más fundamentos legales que respalde su quehacer, han dado origen a la informática jurídica. 4.9.1. Derecho informático Es una ciencia que se desprende del Derecho, para el estudio no sólo de las normas jurídicas que dictaminan y regulan el ambiente informático, sino que también abarca en ese estudio a todo el material doctrinario y jurisprudencial que trate esta materia, para lograr un mejor control, aplicación y vigencia del ámbito informático y las relaciones jurídicas generadas de la informática, entre ellas las contractuales. Dentro del concepto de derecho informático nos encontramos con la contratación informática que es aquella en la que, una de las partes se obliga a entregar un bien informático o a prestar un servicio informático, en favor de otra persona que se obliga a pagar por la contraprestación del bien o servicio un precio. Diferencia respecto de la contratación electrónica La Contratación electrónica, es aquella que se realiza a través de medios electrónicos e informáticos, sin que su objeto principal sean los bienes informáticos. Bienes informáticos Todos aquellos elementos que forman el sistema (computadora), en cuanto al hardware, ya sea la unidad central de proceso o sus periféricos y todos aquellos equipos que tienen una relación directa de uso respecto a ellos que, en su conjunto, conforman el soporte físico del elemento informático, así como bienes inmateriales que proporcionan las órdenes, datos, procedimientos e instrucciones, en el tratamiento automático de la información y que, en su conjunto conforman el soporte lógico del elemento informático.



Servicios informáticos Son todos aquellos que sirven de apoyo y complemento a la actividad informática en relación a la afinidad directa con ella. Bienes intangibles o inmateriales Son aquellos que carecen de entidad corporal y que son creación intelectual de la inteligencia, los cuales pueden ser sujetos de constituir derechos reales sobre ellos. 4.9.2. Relación contractual de tipo informático

Figura 17. Relación contractual de tipo informático.

Contratos de servicios informáticos • Consultorías informáticas • Auditorías informáticas • Auditoría jurídica de los entornos informáticos • Formación de personal o Servicios de Formación • Seguridad informática • Contratación de personal informático (Outsourcing) Características generales de los Contratos informát icos Complejidad. Importante relación directa entre el asesor legal y el técnico informático Larga etapa de negociación Estrecha colaboración entre el cliente usuario y el proveedor. Licencia de uso Objeto: Cesión del derecho de uso y determinación de condiciones de uso.



Territorialidad Posibilidad de sublicenciamiento. Condiciones. Declaratoria de Titularidad. Total o software base. Propiedad Intelectual. Preferentemente inscrito en el Registro. Tipo de licencia: • Upgrade: depende de la potencia de la máquina • Simultánea o concurrente • Individual

Condiciones de actualización • Mantenimiento (incluido o no). Contrato autónomo. O accesorio cuando forma parte del precio. • Acceso a fuentes • Uso de copia de seguridad • Facultad de auditoría

Desarrollo de software - ejecución de obra (incluso parametrizaciones) Contrato más cerrado posible Circunstancias de desarrollo y utilización Determinación del orden cronológico de actividades Anexo del contrato. – Análisis funcional – Análisis Orgánico – Depuración: Calidad. Mecanismos de aceptación. – Entrega: Plazos: Escalonado, Final. Naturaleza jurídica de la obra creada Penalizaciones por retrasos. (Unidad de tiempo-hombre de la totalidad del precio) BILATERAL Mecanismos de pruebas y certificaciones Mecanismos de correcciones Responsabilidad Laboral Garantía al usuario. Limitaciones. Seguros o fianzas Mantenimiento: Preventivo, Evolutivo o Correctivo Pactar la propiedad Intelectual Determinar Titularidad y derechos (Patrimoniales) Plan de contingencias Scrow de código fuente • Condiciones de acceso al código fuente • Procedimiento para acceder. Lo más detallado posible. • Nombre del depositante (persona natural o jurídica). • Designación del depositario • Responsabilidades • Fuerza Mayor o caso fortuito • Declaración de titularidad • Naturaleza económica del contrato: oneroso o gratuito • Obligaciones, responsabilidades y Sanciones.

Distribución • Suministrador • Designación Distribuidor • Usuario o usuarios • Territorialidad



• Exclusividad o no • Vigencia del contrato • Facultades del distribuidor • Tipo de bienes • Si son intangibles: Facultades de cesión de licencias • Posibilidad de nombramiento de sub-distribuidores • Determinación de la persona que dará los mantenimientos • Lista de precios y formas de entrega. Forma de modificar los mismos. • Instalación y procedimiento de demostraciones y soporte • Formación y capacitación • Reconocimiento de la Titularidad. Si es posible el registro. • Propiedad Intelectual • Facturación e impuestos

Otros contratos que deben de considerarse • Arrendamiento de servicios para registros de nombres de dominio • Acceso a Internet • Contrato de diseño de páginas WEB (considerar como programa de ordenador) • Contrato de Albergue de Pagina WEB o Hosting • Contrato de acceso a correo electrónico

4.9.3. Propiedad intelectual del software Según la legislación salvadoreña el software es considerado una obra literaria (Art. 13 de la Ley de Fomento y Protección a la Propiedad Intelectual (LFPPI) y el CONVENIO DE BERNA. Definición de Programa de Ordenador según el Art. 3 2 LFPPI Art. 32. Programa de ordenador, ya sea programa fuente o programa objeto, es la obra literaria constituida por un conjunto de instrucciones expresadas mediante palabras, códigos, planes o en cualquier otra forma que, al ser incorporadas en un dispositivo de lectura automatizada, es capaz de hacer que un ordenador, o sea, un aparato electrónico o similar capaz de elaborar informaciones, ejecute determinada tarea u obtenga determinado resultado. Se presume que es productor del programa de ordenador, la persona que aparezca indicada como tal en la obra de la manera acostumbrada, salvo prueba en contrario. Protección jurídica del software Art. 4. El autor de una obra literaria, artística o científica, tiene sobre ella un derecho de propiedad exclusivo, que se llama derecho de autor. Art. 5. El derecho de autor comprende facultades de orden abstracto, intelectual y moral que constituyen el derecho moral; y facultades de orden patrimonial que constituyen el derecho pecuniario. Derechos morales • Art. 6. El derecho moral del autor es imprescriptible e inalienable y comprende las siguientes

facultades: • La de publicar su obra en la forma, medida y manera que crea conveniente; • La de ocultar su nombre o usar seudónimo en sus publicaciones; • La de destruir, rehacer, retener o mantener inédita la obra;

La de retractarse, o sea de recuperar la obra, modificarla o corregirla después de que haya sido divulgada, pero esta facultad no podrá ejercerla sin indemnizar al titular de sus derechos, por los daños y perjuicios que con ello se le causen. Esta facultad se extingue con la muerte del autor;

• La de conservar y reivindicar la paternidad de la obra;



• La de oponerse al plagio de la obra; • La de exigir que su nombre o su seudónimo se publique en cada ejemplar de la obra o se mencione

en cada acto de comunicación pública de la misma; • La de oponerse a que su nombre o su seudónimo aparezca sobre la obra de un tercero o sobre una

obra que haya sido desfigurada; • La de salvaguardar la integridad de la obra oponiéndose a cualquier deformación, mutilación,

modificación o abreviación de la obra o de su título, incluso frente al adquirente del objeto material de la obra; y

• La de oponerse a cualquier utilización de la obra en menoscabo de su honor o de su reputación como autor.

• La violación de cualquiera de las facultades anteriores, dará lugar a reparación del daño e indemnización de perjuicios.

Derecho pecuniario o patrimonial Art. 7. El derecho pecuniario del autor es la facultad de percibir beneficios económicos provenientes de la utilización de las obras y comprende especialmente las siguientes facultades: • La de reproducir la obra; • La de ejecutar y representar la creación; • La de difundir la obra por cualquier medio; • La de distribución de la obra; y • La de importar, exportar o autorizar la importación o la exportación de copias de sus obras

legalmente fabricadas. Art. 8. El derecho pecuniario puede transferirse a cualquier título o trasmitirse por causa de muerte. 4.9.4. Recomendaciones legales Registrar y realizar depósito en el Registro de Propiedad Intelectual, que lleva el Registro de Comercio de los códigos fuentes o ejecutables (preferentemente), de los programas de ordenador que deseen obtener una protección frente a terceros. Depositar los en medios magnéticos no reescribibles. Dependiendo de la importancia y costo del producto realizar un procedimiento para garantizar (seguridad legal), la propiedad intelectual del bien y la prueba de la misma. Bienes materiales informáticos LA PROTECCIÓN JURIDICA, está determinada por la LFPPI, como una creación o invento, a través de la propiedad industrial o patentes (Art.107). Cualquier bien tangible, complementario a la actividad informática, o que sirva de apoyo para la misma. La celebración de contratos sobre bienes físicos debe de seguir las mismas reglas del derecho común con las especialidades respecto de los bienes muebles. Ejemplos: – Arrendamiento simple – Compraventa – Leasing financiero – Retroleasing – Comodato – Especialidades sobre los mismos o contratos accesorios Mantenimiento Instalación Llave en mano o traslado de equipos especializados



“ Aspectos administrativos (Gestión de proyectos de s oftware) ” Segunda Edición. Octubre de 2013. Elaborado y Presentado por Milton José Narváez Sandino, Ingeniero en Computación y Sistemas, para la asignatura Ingeniería de Software. Universidad Don Bosco (UDB) – Facultad de Ingenierí a – Escuela de Ingeniería en Computación (EIC).

FUENTES DE CONSULTA

BIBLIOGRAFIA BOOCH, GRADY; RUMBAUGH, JAMES; JACOMSON, IVAR (2007). El lenguaje unificado de modelado, Manual de referencia. Segunda edición, Editorial Pearson Addison Wesley. BRUGGE, BERND (2001). Ingeniería de software orientada a objetos, Editorial Pearson Prentice Hall. BARRIENTOS HERBERT (__). Metodología para el desarrollo de las herramientas informáticas de la REyE, San José, Costa Rica. IEEE (2004). Guide to the Software Engineering Body of Knowledge, 2004 version. A project of the IEEE Computer Society and Professional Practices Committee. LAWRENCE PFLEEGER, SHARI (2002). Ingeniería de software – Teoría y práctica, primera edición, Editorial Pearson Prentice Hall. PROJECT MANAGEMENT INSTITUTE (2008). Guía de los fundamentos para la dirección de proyectos (Guía del PMBOK). Cuarta edición. PFLEEGER, SHARI LAWRENCE (2002). Ingeniería de software – Teoría y práctica, primera edición, Editorial Pearson Prentice Hall. PRESSMAN, ROGER S. (2006). Ingeniería de software, un enfoque práctico, sexta edición. Editorial McGrawHill, México. RUIZ GONZÁLEZ, FRANCISCO; MOLINA TEJEDOR, MIGUEL ANGEL (2000). Gestión de Recursos Humanos en Proyectos Informáticos. Universidad de Castilla-La Mancha, Escuela Superior de Informática, Planificación y Gestión de Sistemas de Información. SÁNCHEZ, SALVADOR; SICILIA, MIGUEL ÁNGEL; RODRÍGUEZ, DANIEL (2012). Ingeniería del Software. Un enfoque desde la guía SWEBOK, Primera Edición, Editorial Alfaomega. SCHACH, STEPHEN R. (2005). Análisis y diseño orientado a objetos con UML y el proceso unificado. Editorial McGraw-Hill. SCHACH, STEPHEN R. (2002). Ingeniería de software clásica y orientada a objetos, sexta edición. Editorial McGrawHill, México. SOMMERVILLE, IAN (2005). Ingeniería de software, sexta edición, Editorial Pearson Addison Wesley. MURCH, R. (2000). Project Management: Best Practices for IT Professionals, Prentice-Hall, Columbus.



INTERNET Paul Hensgen. Manual de Umbrello UML Modeller. Citado de internet del URL: http://docs.kde.org/kde3/es/kdesdk/umbrello/index.html. Sinnexus. Sistemas de Soporte a la Decisión (DSS). Citado de internet en el URL: http://www.sinnexus.com/business_intelligence/sistemas_soporte_decisiones.aspx. Oscar M. Fernández Carrasco, Delba García León y Alfa Beltrán Benavides. Un enfoque actual sobre la calidad del software. Citado de internet del URL: http://eprints.rclis.org/archive/00002231/01/aci05395.htm. Universidad de Belgrano, Argentina. Criterios de calidad del software. Citado de internet del URL: http://www.ub.edu.ar/catedras/ingenieria/ing_software/ubftecwwwdfd/calidadsw/criterios.htm. Universidad de Granada. Pruebas. Departamento de Lenguajes y Sistemas Informáticos. Citado de internet del URL: http://lsi.ugr.es/~arroyo/inndoc/doc/pruebas/pruebas_d.php.

04-gesti n de proyectos de software (16oct13) · 2013. 11. 19. · la acción de gestionar implica...

Documents