Unidad IV: Gestión de Proyectos de Software · La gestión del proyecto de software es el primer...

Unidad IV:Unidad IV:Gestión de Proyectos de Software

Milton J. NarváezUniversidad Don Bosco16 de Octubre de 2014

AGENDAAGENDA

SaludoAvisos generalesForo de discusión:Unidad IV: Gestión de Proyectos de SoftwareIntroducción4.1. Gestión de proyectos4.2. Métricas de procesos y proyecto4.2. Métricas de procesos y proyecto

4.2.1. Conceptos básicos de métricas de proceso y proyecto4.2.2. Medición de procesos de software

4.3. Estimación para proyectos de software4.4. Administración de personal4.5. Calendarización de proyectos de software4.6. Manejo de riesgos de la ingeniería de software (gestión del riesgo)4.7. Gestión de la calidad4.8. Gestión del cambio4.9. Aspectos legales de la ingeniería de software

•Conocer los beneficios de una adecuada gestión de proyectos.•Aplicar métricas en los diferentes procesos del desarrollo de software.•Hacer estimaciones básicas para el desarrollo de proyectos de software.

OBJETIVO DE LOS APRENDIZAJESOBJETIVO DE LOS APRENDIZAJES

La gestión es definida como “todas las actividades y tareas ejecutadas por una o

INTRODUCCIONINTRODUCCION

UNIDAD IV: GESTIÓN DE PROYECTOS DE SOFTWAREUNIDAD IV: GESTIÓN DE PROYECTOS DE SOFTWAREUNIDAD IV: GESTIÓN DE PROYECTOS DE SOFTWAREUNIDAD IV: GESTIÓN DE PROYECTOS DE SOFTWARE

La gestión es definida como “todas las actividades y tareas ejecutadas por una omás personas con el propósito de planificar y controlar las actividades de otrospara alcanzar un objetivo o completar una actividad que no puede ser realizada porotros actuando independientemente”.

No obstante, en el caso de la gestión de proyectos de desarrollo de software laadministración de las diferentes fases es diferente debido a la naturaleza lógica delproducto de software. En el caso del software la buena calidad del producto finalestá definida básicamente por un buen diseño de software.

4.1. Gestión de proyectos4.1. Gestión de proyectos

La gestión del proyecto de software es el primer nivel del proceso de ingeniería desoftware, porque cubre todo el proceso de desarrollo; para ello es necesariocomprender el ámbito del trabajo a realizar, los riesgos en los que se puedeincurrir, los recursos requeridos, las tareas a llevar a cabo, el esfuerzo (costo) aconsumir y el plan a seguir.


Gestión

Planificación Organización Equipo detrabajo

Dirección Control


Gestión


Dirección Control


trabajo

•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


Gestión


Dirección Control


trabajo

•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


Gestión


Dirección Control


trabajo

•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


Gestión


Dirección Control


trabajo

•Proveer liderazgo•Supervisar personal•Delegar autoridad•Motivar personal•Construir equipos•Coordinar actividades•Facilitar comunicaciones•Resolver conflictos•Manejar cambios•Documentar las decisiones de dirección


Gestión


Dirección Control


trabajo

•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

4.2. Métricas de procesos y proyecto4.2. Métricas de procesos y proyecto

Una métrica de software es una función cuyas entradas son datos del software (oel proceso del software) y cuya salida es un valor numérico único, que puede serinterpretado como el grado en que el software (o el proceso del software) posee unatributo 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 investigadorespuedan tomar las mejores decisiones (Pfleeger, 1997).

4.2. Métricas de procesos y proyecto4.2. Métricas de procesos y proyecto4.2.1. Conceptos básicos de métricas de proceso y p royecto4.2.1. Conceptos básicos de métricas de proceso y p royecto

Concepto Definición Relaciones

Atributo

Una propiedad mensurable,física o abstracta, quecomparten todas las entidadesde una categoría de entidad.

Un atributo sólo puede pertenecer a una categoría deentidad.Una medición se realiza sobre los atributos de unaentidad.Un atributo tiene definida cero, una o varias métricas.


de una categoría de entidad.Un atributo tiene definida cero, una o varias métricas.Un atributo está relacionado con uno o más conceptosmedibles.

Métrica

Una forma de medir y unaescala, definidas para realizarmediciones de uno o variosatributos.

Una métrica está definida para uno o más atributosDos métricas pueden relacionarse mediante una funciónde transformación.El tipo de dicha función de transformación va adepender del tipo de escala de ambas métricas.Una métrica puede expresarse en una unidad (sólo paramétricas cuya escala sea de tipo intervalo o ratio).

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 deluso de nuevos métodos y herramientas de ingeniería de software,•Para establecer una línea base para la estimación y


•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.



Proceso GQM (Goal-Question-Metric).



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.


•Ajustar el flujo y las tareas de trabajo.•Evaluar la habilidad del equipo del proyecto en controlar la calidad de losproductos de trabajo de la ingeniería del software.

4.2. Métricas de procesos y proyecto4.2. Métricas de procesos y proyecto4.2.2. Medición de procesos de software4.2.2. Medición de procesos de software



Gestión de procesos



Actividades de medición


4.2. Métricas de procesos y proyecto4.2. Métricas de procesos y proyecto4.2.2. Medición de procesos de software4.2.2. Medición de procesos de softwareGestión de procesos vrs. Gestión de proyectos


4.3. Estimación para proyectos de software4.3. 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


Técnica DescripciónJuicio experto El administrador del proyecto recurre a alguien que haya

desarrollado aplicaciones similares para que realice una estimaciónde los recursos y tiempo a necesitar para el desarrollo.

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

4.3. Estimación para proyectos de software4.3. Estimación para proyectos de software

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 ydesarrolladores, tales como: espacio físico adecuado para el desarrollo, nivel deruido, interrupciones de personas ajenas al proyecto, entre otros.


Para la mayoría de los proyectos el mayor componente del costo es el esfuerzo, elcual a su vez es el componente con mayor incertidumbre. Se debe determinarcuántos días – personal de esfuerzo se requerirán para completar el proyecto.

4.3. Estimación para proyectos de software4.3. Estimación para proyectos de softwareCausas 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.


•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.

4.4. 4.4. Administración de personalAdministración de personal

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 unaplanificación y optimización de la plantilla en función de los objetivos de laempresa, 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 nuevosempleados.


b. La ejecución de la nomina

El subsistema de recursos humanos es el que más cambios sufre como reacción alos 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 condicionesmá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 deproyecto a la gestión de Recursos Humanos, la cual está conformada por:• Plan de organización• Adquisición del personal• Equipo de desarrollo


Implicados clave de un proyecto:• Director de proyecto.• Cliente.• Desarrolladores o empresa de desarrollo.• Sponsor (patrocinador).

4.5. 4.5. Calendarización de proyectos de softwareCalendarización de proyectos de software

Realizar una estimación detallada empleando datos históricos de proyectosprevios. Determinar el esfuerzo y la duración estimada para el proyecto.

Aplicar un modelo de proceso incremental y desarrollar una estrategia deingeniería de software que entregará la funcionalidad crítica en la fecha límiteimpuesta, pero demorará otra. Documente el plan.


Reunirse con el cliente y, con la estimación detallada, explicarle por qué la fechalímite impuesta es irrealizable. Asegúrese de señalar que todas las estimacionesestán basadas sobre el desempeño en proyectos previos.

Ofrezca la estrategia de desarrollo incremental como alternativa.

4.5. 4.5. Calendarización de proyectos de softwareCalendarización de proyectos de software

La calendarización o Plan de Desarrollo de Software se hace con el propósito deproporcionar la información necesaria para controlar el proyecto. En él se describeel enfoque de desarrollo del software.

Es una actividad que distribuye estimaciones de esfuerzo a través de la duraciónplanificada del proyecto, al asignar el esfuerzo a tareas específicas de ingeniería


de software.

En la calendarización de proyecto puede utilizar técnicas y / o herramientas talescomo:•PERT (técnica de evaluación y revisión de programa).•CPM (método de la ruta crítica)

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

4.5. 4.5. Calendarización de proyectos de softwareCalendarización de proyectos de software4.5.14.5.1. Actividades de planificación de proyectos de software. Actividades de planificación de proyectos de soft ware

Proyecto de Software

Actividades


Determinar el ámbito del Software Estimación de recursos requeridos

El ámbito del software describe el control y los datos a procesar, la función, el rendimiento, las restricciones, las interfaces y la fiabilidad.

4.6. 4.6. Gestión de riesgoGestión de riesgo

En su libro sobre análisis y gestión del riesgo, Robert Charette [CHA89] presenta lasiguiente definición de riesgo: en primer lugar, el riesgo afecta a los futurosacontecimientos . El hoy y el ayer están más allá de lo que nos puedapreocupar, pues ya estamos cosechando lo que sembramos prev iamente connuestras acciones del pasado. La pregunta es, podemos, por t anto,cambiando nuestras acciones actuales, crear una oportunidad para una


cambiando nuestras acciones actuales, crear una oportunidad para unasituación diferente y, con suerte, mejor para nosotros en el futuro. Estosignifica, en segundo lugar, que el riesgo implica cambio , que puede venirdado por cambios de opinión, de acciones, de lugares... [En t ercer lugar,] elriesgo 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 c osasinevitables en la vida.

4.6. 4.6. Gestión de riesgoGestión de riesgo4.6.14.6.1. Estrategias de riesgo. Estrategias de riesgo

Estrategias de riesgo proactivas

Una estrategia considerablemente más inteligenteEmpieza mucho antes de que comiencen lostrabajos técnicos.Se identifican los riesgos potenciales.Se evalúa su probabilidad y su impacto y se

Estrategias de riesgo reactivas

Se supervisa el proyecto en previsión de posiblesriesgos.Los recursos se ponen aparte, en caso de quepudieran convertirse en problemas reales.El equipo de software actúa cuando algo va mal


Se evalúa su probabilidad y su impacto y seestablece una prioridad según su importancia.El equipo de Software establece un plan paracontrolar el riesgo.El primer objetivo es evitar el riesgoDesarrollo de un plan de contingencia que lepermita responder de una manera eficaz ycontrolada.

El equipo de software actúa cuando algo va mal(método denominado a menudo “de bomberos”).

4.6. 4.6. Gestión de riesgoGestión de riesgo4.6.24.6.2. Riesgo de software. Riesgo de software

Aunque ha habido amplios debates sobre la definición adecuada para riesgo desoftware, hay acuerdo común en que el riesgo siempre implica dos características:

Incertidumbre: el acontecimiento que caracteriza al riesgo puede o no puedeocurrir; 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 nodeseadas o pérdidas.

Cuando se analizan los riesgos es importante cuantificar el nivel de incertidumbrey el grado de pérdidas asociado con cada riesgo.

4.6. 4.6. Gestión de riesgoGestión de riesgo4.6.24.6.2. Riesgo de software. Riesgo de software

Los riesgos técnicos ocurren porque el problema es más difícil de resolver de loque pensábamos. Los riesgos del negocio amenazan la viabilidad del software aconstruir. Los riesgos del negocio a menudo ponen en peligro el proyecto o elproducto. Los candidatos para los cinco principales riesgos del negocio son:

(1) construir un producto o sistema excelente que no quiere nadie en realidad


(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 lacompañía (riesgo estratégico);(3) construir un producto que el departamento de ventas no sabe cómo vender(riesgo de venta);(4) perder el apoyo de una gestión experta debido a cambios de enfoque o acambios de personal (riesgo de dirección);(5) perder presupuesto o personal asignado (riesgos de presupuesto).

4.6. 4.6. Gestión de riesgoGestión de riesgo4.6.34.6.3. Identificación del riesgo. Identificación del riesgo

La identificación del riesgo es un intento sistemático para especificar las amenazasal plan del proyecto (estimaciones, planificación temporal, carga de recursos, etc.).Identificando los riesgos conocidos y predecibles, el gestor del proyecto da unpaso adelante para evitarlos cuando sea posible y controlarlos cuando seanecesario.


Un método para identificar riesgos es crear una lista de comprobación deelementos de riesgo. La lista de comprobación se puede utilizar para identificarriesgos y se centra en un subconjunto de riesgos conocidos y predecibles en lassiguientes subcategorías genéricas:


Tamaño del producto: riesgos asociados con el tamaño general del software aconstruir o a modificar.Impacto en el negocio: riesgos asociados con las limitaciones impuestas por lagestión o por el mercado.Características del cliente: riesgos asociados con la sofisticación del cliente y lahabilidad del desarrollador para comunicarse con el cliente en los momentos


habilidad del desarrollador para comunicarse con el cliente en los momentosoportunos.Definición del proceso: riesgos asociados con el grado de definición del procesodel software y su seguimiento por la organización de desarrollo.Entorno de desarrollo: riesgos asociados con la disponibilidad y calidad de lasherramientas que se van a emplear en la construcción del producto.Tecnología a construir: riesgos asociados con la complejidad del sistema aconstruir y la tecnología punta que contiene el sistema.Tamaño y experiencia de la plantilla: riesgos asociados con la experiencia técnicay de proyectos de los ingenieros del software que van a realizar el trabajo.



Evaluación global del riesgo del proyecto.

4.7. 4.7. Gestión de calidadGestión de calidad

El American Heritage Dictionary, define la calidad como “una característica oatributo de algo”. Como un atributo de un elemento, la calidad se refiere a lascaracterísticas mensurables -cosas que se pueden comparar con estándaresconocidos como longitud, color, propiedades eléctricas, maleabilidad, etc.-. Sinembargo, el software en su gran extensión, como entidad intelectual, es más difícilde caracterizar que los objetos físicos. No obstante, sí existen las medidas de


de caracterizar que los objetos físicos. No obstante, sí existen las medidas decaracterísticas de un programa. Entre estas propiedades se incluyen complejidadciclomática, cohesión, número de puntos de función, líneas de código y muchasotras.

4.7. 4.7. Gestión de calidadGestión de calidad4.7.14.7.1. Control de calidad. Control de calidad

El control de cambios puede equipararse al control de calidad. Pero, ¿cómo selogra el control de calidad? El control de calidad es una serie de inspecciones,revisiones y pruebas utilizados a lo largo del proceso del software para asegurarque cada producto cumple con los requisitos que le han sido asignados. El controlde calidad incluye un bucle de realimentación (feedback) del proceso que creó el


de calidad incluye un bucle de realimentación (feedback) del proceso que creó elproducto. La combinación de medición y realimentación permite afinar el procesocuando 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, completamenteautomáticas o una combinación de herramientas automáticas e interacciónhumana.

4.7. 4.7. Gestión de calidadGestión de calidad4.7.14.7.1. Control de calidad. Control de calidad


4.7. 4.7. Gestión de calidadGestión de calidad4.7.24.7.2. Factores de calidad del estándar ISO 9126. Factores de calidad del estándar ISO 9126

El estándar ISO 9126 se desarrolló como un intento de identificar los atributos decalidad para el software de computadora. El estándar identifica seis atributos clavede la calidad:

Funcionalidad: el grado en que el software satisface las necesidades que indicanlos siguientes subatributos: idoneidad, exactitud, interoperabilidad, cumplimiento y


los siguientes subatributos: idoneidad, exactitud, interoperabilidad, cumplimiento yseguridad.Confiabilidad: la cantidad de tiempo en que el software está disponible para usarlosegún los siguientes subatributos: madurez, tolerancia a fallas y facilidad derecuperación.Facilidad de uso: la facilidad con que se usa el software de acuerdo con lossiguientes subatributos: facilidad de comprensión, facilidad de aprendizaje yoperabilidad.

4.7. 4.7. Gestión de calidadGestión de calidad4.7.24.7.2. Factores de calidad del estándar ISO 9126. Factores de calidad del estándar ISO 9126

Eficiencia: el grado en que el software emplea en forma óptima los recursos delsistema, 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 deacuerdo con los siguientes subatributos: facilidad de análisis, facilidad de cambio,estabilidad y facilidad de prueba.


estabilidad y facilidad de prueba.Portabilidad: La facilidad con la que se lleva el software de un entorno a otro segúnlos siguientes atributos: adaptabilidad, facilidad para instalarse, cumplimiento yfacilidad 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 deverificación excelente para evaluar la calidad de un sistema.

4.8. 4.8. Gestión del cambioGestión del cambio

Gestión del cambio es un conjunto de procesos que se emplea para asegurar quelos cambios significativos se llevan a cabo en forma ordenada, controlada ysistemática a efecto el cambio organizacional.

44..88..11.. ÁmbitosÁmbitos dede aplicaciónaplicación

1. Para mejorar la gestión de los cambios en curso:


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.

La técnicas de gestión del cambio se utilizan también para asistir los procesos detransformación que tienen como objetivo específico la potenciación de laflexibilidad de la organización y su capacidad de respuesta rápida a situacionesnuevas.

4.8. 4.8. Gestión del cambioGestión del cambio4.8.14.8.1. Ámbitos de aplicación. Ámbitos de aplicación


Gestión del cambioGestión del cambio* Mejorar la gestión de los cambios en curso:Asimilación de las nuevas tecnologías de

la comunicaciónProcesos de mejora de la calidadReestructuracionesFusionesAbsorcionesAcomodación a las nuevas circunstancias

de la globalización* Cambio organizacional* Capacidad de respuesta rápida a situaciones nuevas

* Resistencia al cambioCausa de desvíos y/o fracasos

4.8. 4.8. Gestión del cambioGestión del cambio4.8.24.8.2. Agente del cambio. Agente del cambio

En el análisis del desarrollo organizacional es necesario contar con un buen agentede cambio, que es aquella persona que actúa en forma deliberada sobre el entornoa fin de facilitar o propiciar la implantación del cambio proyectado. Al respecto,Roger Tessier (1973), agrega, toda persona o sistema que contribuye medianteuna acción directa o indirecta a la implantación del cambio constituye un agente de


una acción directa o indirecta a la implantación del cambio constituye un agente decambio.

En general, el agente del desarrollo organizacional, es un consultor externo alsistema. En este caso el consultor puede pertenecer al cuadro ejecutivo de laempresa (consultor interno) o si no de afuera (consultor externo). Pero ambosactuaran como externos al sistema objetivo.

4.8. 4.8. Gestión del cambioGestión del cambio4.8.34.8.3. Actualización del software. 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 resultadosesperados, y si ocasionan una serie de consecuencias involuntarias y poco útiles.


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 nodeseados, en lugar de enfocarlos en concretar los resultados planificados.

Se considera que la resistencia al cambio es la principal causa de desvíos y/ofracasos en los procesos de actualización de software, por lo tanto considerar elfactor humano es fundamental para alcanzar el éxito; pues, las personas no seadaptan al cambio tan solo como resultadodel 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 decompromiso con los procesos de cambio, logrando así neutralizar dicharesistencia.• Para anticipar los desafíos que las personas deberán afrontar con el cambio y


• Para anticipar los desafíos que las personas deberán afrontar con el cambio ymitigar su impacto.• Para favorecer que las personas se involucren con el nuevo software, en lugar dela natural tendencia a luchar en contra del mismo.


Consideraciones para gestionar el cambio durante un proceso de actualización desoftware:•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


•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 resultadosesperados.•Fomentar la Creación de nuevas acciones para anticiparse y mitigar los desafíosprevistos como consecuencia de la actualización de software•Tomar en cuenta y trabajar con las emociones y estados de ánimo que el procesodispara en las personas•Brindar nuevas interpretaciones del conflicto y de los obstáculos.

4.8. 4.8. Gestión del cambioGestión del cambio4.8.44.8.4. Fases de la gestión del cambio. Fases de la gestión del cambio

Fase 1. - DEFINICIÓN de los objetivos del proyecto así como una visión.de cual será la situación final tras el desarrollo del proyecto. Creación delequipo global de trabajo.Fase 2. - DIAGNÓSTICO de la situación actualFase 3. - DESARROLLO del plan de acciones (incluyendo el plan decomunicación interna), así como los objetivos concretos que alcanzará.


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. 4.9. Aspectos legales de la ingeniería de softwareAspectos legales de la ingeniería de software4.9.14.9.1. Derecho informático. Derecho informático

Es una ciencia que se desprende del Derecho, para el estudio no sólo de lasnormas jurídicas que dictaminan y regulan el ambiente informático, sino quetambién abarca en ese estudio a todo el material doctrinario y jurisprudencial quetrate esta materia, para lograr un mejor control, aplicación y vigencia del ámbitoinformá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óninformática que es aquella en la que, una de las partes se obliga a entregar un bieninformático o a prestar un servicio informático, en favor de otra persona que seobliga 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 medioselectrónicos e informáticos, sin que su objeto principal sean los bienesinformáticos.



Bienes informáticos

Todos aquellos elementos que forman el sistema (computadora), en cuanto alhardware, ya sea la unidad central de proceso o sus periféricos y todos aquellosequipos que tienen una relación directa de uso respecto a ellos que, en suconjunto, conforman el soporte físico del elemento informático, así como bienesinmateriales que proporcionan las órdenes, datos, procedimientos e instrucciones,en el tratamiento automático de la información y que, en su conjunto conforman elsoporte lógico del elemento informático.


Servicios informáticos

Son todos aquellos que sirven de apoyo y complemento a la actividad informáticaen relación a la afinidad directa con ella.

Bienes intangibles o inmateriales


Bienes intangibles o inmateriales

Son aquellos que carecen de entidad corporal y que son creación intelectual de lainteligencia, los cuales pueden ser sujetos de constituir derechos reales sobreellos.

4.9. 4.9. Aspectos legales de la ingeniería de softwareAspectos legales de la ingeniería de software4.9.24.9.2. Relación contractual de tipo informático. Relación contractual de tipo informático



Contratos de servicios informáticos

· Consultorías informáticas· Auditorias informáticas· Auditoria jurídica de los entornos informáticos


· Auditoria 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áticos

Complejidad. Importante relación directa entre el asesor legal y el técnicoinformáticoLarga etapa de negociación


Larga etapa de negociaciónEstrecha 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.


parte del precio.· Acceso a fuentes· Uso de copia de seguridad· Facultad de auditoría.

Desarrollo de software - ejecución de obra (incluso paramet rizaciones)

· Contrato más cerrado posible· Circunstancias de desarrollo y utilización· Determinación del orden cronológico de actividades· Anexo del contrato.



· 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

Desarrollo de software - ejecución de obra (incluso paramet rizaciones)

· Garantía al usuario. Limitaciones.· Seguros o fianzas· Mantenimiento: Preventivo, Evolutivo o Correctivo· Pactar la propiedad Intelectual



· 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

Scrow de código fuente· 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

Distribución

· 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



· 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 paginas WEB (considerar como programa de ordenador)· Contrato de Albergue de Pagina WEB o Hosting· Contrato de acceso a correo electrónico

4.9. 4.9. Aspectos legales de la ingeniería de softwareAspectos legales de la ingeniería de software4.9.34.9.3. Propiedad intelectual del software. 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 elCONVENIO DE BERNA.

Definición de Programa de Ordenador según el Art . 32 LFPPI


Definición de Programa de Ordenador según el Art . 32 LFPPI

Art. 32. Programa de ordenador, ya sea programa fuente o programa objeto, es laobra literaria constituida por un conjunto de instrucciones expresadas mediantepalabras, códigos, planes o en cualquier otra forma que, al ser incorporadas en undispositivo de lectura automatizada, es capaz de hacer que un ordenador, o sea,un aparato electrónico o similar capaz de elaborar informaciones, ejecutedeterminada tarea u obtenga determinado resultado. Se presume que es productordel programa de ordenador, la persona que aparezca indicada como tal en la obrade 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 underecho de propiedad exclusivo, que se llama derecho de autor.

Art. 5. El derecho de autor comprende facultades de orden abstracto, intelectual y


Art. 5. El derecho de autor comprende facultades de orden abstracto, intelectual ymoral que constituyen el derecho moral; y facultades de orden patrimonial queconstituyen el derecho pecuniario.

Derechos morales

Art. 6. El derecho moral del autor es imprescriptible e inalienable y comprende lassiguientes 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;

4.9. 4.9. Aspectos legales de la ingeniería de softwareAspectos legales de la ingeniería de software4.9.34.9.3. Propiedad intelectual del software. Propiedad intelectual del softwareDerechos morales· La de retractarse, o sea de recuperar la obra, modificarla o corregirla despuésde que haya sido divulgada, pero esta facultad no podrá ejercerla sin indemnizar altitular de sus derechos, por los daños y perjuicios que con ello se le causen. Estafacultad se extingue con la muerte del autor;· La de conservar y reivindicar la paternidad de la obra;


· 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 laobra 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 untercero o sobre una obra que haya sido desfigurada;· La de salvaguardar la integridad de la obra oponiéndose a cualquierdeformació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 ode su reputación como autor.· La violación de cualquiera de las facultades anteriores, dará lugar a reparacióndel daño e indemnización de perjuicios.


Derecho pecuniario o patrimonial

Art. 7. El derecho pecuniario del autor es la facultad de percibir beneficioseconómicos provenientes de la utilización de las obras y comprendeespecialmente las siguientes facultades:


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 porcausa de muerte.

4.9. 4.9. Aspectos legales de la ingeniería de softwareAspectos legales de la ingeniería de software4.9.44.9.4. Recomendaciones legales. Recomendaciones legales

· Registrar y realizar depósito en el Registro de Propiedad Intelectual, que lleva elRegistro de Comercio de los códigos fuentes o ejecutables (preferentemente), delos programas de ordenador que deseen obtener una protección frente a terceros.

· Depositar los en medios magnéticos no reescribibles.


· Depositar los en medios magnéticos no reescribibles.

· Dependiendo de la importancia y costo del producto realizar un procedimientopara garantizar (seguridad legal), la propiedad intelectual del bien y la prueba de lamisma.

Bienes materiales informáticos

· LA PROTECCIÓN JURIDICA, está determinada por la LFPPI, como unacreació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 sirvade apoyo para la misma.

4.9. 4.9. Aspectos legales de la ingeniería de softwareAspectos legales de la ingeniería de software4.9.44.9.4. Recomendaciones legales. Recomendaciones legales


de apoyo para la misma.· La celebración de contratos sobre bienes físicos deben de seguir las mismasreglas 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

“Pregúntate si lo que estás haciendo hoy te acerca a l “Pregúntate si lo que estás haciendo hoy te acerca a l “Pregúntate si lo que estás haciendo hoy te acerca a l “Pregúntate si lo que estás haciendo hoy te acerca a l lugar en el que quieres estar mañana”lugar en el que quieres estar mañana”

J. BROWN, E.U.J. BROWN, E.U.

Milton J. NarváezUniversidad Don Bosco

16 de octubre de 2014

Unidad IV: Gestión de Proyectos de Software · La gestión del proyecto de software es el primer...

Documents

Transcript of Unidad IV: Gestión de Proyectos de Software · La gestión del proyecto de software es el primer...