CONTRATACION DE PROYECTOS INFORMATICOS

Un proyecto surge o debe surgir cuando se identifica un problema o una oportunidad en el negocio, en cualquiera de las áreas de la organización, es decir, mejorar el servicio al cliente, reducir el tiempo de desarrollo de un nuevo producto o los plazos de entrega de los proveedores, mejorar el control financiero interno, facilitar la identificación de nuevos talentos en la empresa y desarrollar los recurso humanos.


TERMINOS DE REFERENCIA


Poseen especificaciones técnicas, objetivos y estructura de cómo se ejecuta un estudio o proyecto, estos son creado antes del diseño del proyecto, después de que este sea aprobado dicho documento en el que describe la idea del proyecto, el director los documenta, una vez aprobado dicho documento por el director el proyecto ya tendrá una definición clara, es decir, a donde se quiere llegar.



LICITACIONES






La licitación es una invitación para proveedores distintos para proporcionar un claro y buen servicio al licitante.


COMO SE RESUELVEN LAS LICITACIONES

El comprador establece las bases para la participación siguiendo unos requisitos como los son:



  • Establecimiento del proveedor reglamentado

  • Declaraciones de impuestos al corriente

  • Capacidad para proporcionar lo que se licita


Los licitantes, es decir, los proveedores presentan las propuestas divididas en dos técnicas y económicas donde se reúnen en juntas para tratar aclaraciones y fallo donde el licitante asigna el pedido formulado al proveedor a la mejor propuesta.



METODO PERT


Es básicamente un método para analizar las tareas involucradas en completar un proyecto dado, especialmente el tiempo para completar cada tarea, e identificar el tiempo mínimo necesario para completar el proyecto total.


La parte más famosa de PERT son las Redes PERT, diagramas de líneas de tiempo que se interconectan. PERT está diseñado para proyectos de gran escala, que se ejecutan de una vez, complejos y no rutinarios.


PRINCIPIOS





  • Principio de designación sucesiva: se nombra a los vértices según los números naturales, de manera que no se les asigna número hasta que han sido nombrados todos aquellos de los que parten aristas que van a parar a ellos.
  • Principio de unicidad del estado inicial y el final: se prohíbe la existencia de más de un vértice inicial o final. Sólo existe una situación de inicio y otra de terminación del proyecto.
  • Principio de designación unívoca: no pueden existir dos aristas que tengan los mismos nodos de origen y de destino. Normalmente, se nombran las actividades mediante el par de vértices que unen. Si no se respetara este principio, puede que dos aristas recibieran la misma denominación.


Requisitos de los trabajadores.


Ser personal investigador o personal científico o técnico.


Requisitos de la empresa


Podrán celebrar estos contratos los organismos públicos de investigación, las instituciones sin ánimo de lucro que realicen actividades de investigación y desarrollo tecnológico y las Universidades públicas que sean beneficiarias de ayudas o subvenciones públicas para la contratación temporal de personal investigador, científico o técnico, para el desarrollo de nuevos programas o proyectos singulares de investigación que no puedan llevar a cabo con personal propio; todo ello de acuerdo con lo que establezca sus respectivos estatutos. Formalización, duración y jornada.

  • Estos contratos se regirán por lo establecido en la normativa específica para los contratos de obra o servicio determinado.
  • La actividad desarrollada por los investigadores, o por el personal científico o técnico, será evaluada anualmente, pudiendo ser resuelto el contrato en el supuesto de no superarse favorablemente dicha evaluación.
COCOMO

Es un modelo matemático de base empírica utilizado para estimación de costes de software. Incluye tres submodelos, cada uno ofrece un nivel de detalle y aproximación, cada vez mayor, a medida que avanza el proceso de desarrollo del software: básico, intermedio y detallado.

CARACTERÍSTICAS



Pertenece a la categoría de modelos de subestimaciones basados en estimaciones matemáticas. Está orientado a la magnitud del producto final, midiendo el "tamaño" del proyecto, en líneas de código principalmente.

INCONVENIENTES



  • Los resultados no son proporcionales a las tareas de gestión ya que no tiene en cuenta los recursos necesarios para realizarlas.
  • Se puede desviar de la realidad si se indica mal el porcentaje de líneas de comentarios en el código fuente.
  • Es un tanto subjetivo, puesto que está basado en estimaciones y parámetros que pueden ser "vistos" de distinta manera por distintos analistas que usen el método.
  • Se miden los costes del producto, de acuerdo a su tamaño y otras características, pero no la productividad.
  • La medición por líneas de código no es válida para orientación a objetos.
  • Utilizar esta modelo puede resultar un poco complicado, en comparación con otros métodos (que también sólo estiman).



0 Responses