UNIDAD 1 Introducción a la gestión de proyectos.

UNIDAD 1

1.1. Conceptos básicos para la gestión de proyectos.

¿Qué es un proyecto?

Un proyecto es una secuencia de tareas con un principio y un final limitados por el tiempo, los recursos y los resultados deseados. Esto es, el proyecto tiene un resultado deseado, una fecha límite y un presupuesto (personal, suministros y dinero).

Características de un proyecto:

•  Temporal: Debe tener principio y fin.
•  Único: Carácter no repetitivo
•  Progresivo: Sigue una serie de etapas en su elaboración

¿Qué es la gestión de Proyectos? 

Es la aplicación de conocimiento, habilidades, herramientas y técnicas a las actividades de un proyecto, con el fin de cumplir sus requerimientos.

1.2. Fases de la gestión de proyectos.

 1.2.1. Planificación de proyectos.

Todo proyecto conlleva la realización de una serie de actividades para su desarrollo. La distribución en el tiempo de dichas actividades y la consideración de los recursos necesarios son las funciones a desarrollar en la planificación de proyectos. El objetivo de la planificación de proyectos es obtener una distribución de las actividades en el tiempo y una utilización de los recursos que minimice el coste del proyecto cumpliendo con las condiciones exigidos de: plazo de ejecución, tecnología a utilizar, recursos disponibles, nivel máximo de ocupación de dichos recursos. Por tanto la planificación de proyectos es una programación de actividades y una gestión de recursos para obtener un objetivo de coste cumpliendo con los condicionantes exigidos por nuestro cliente. 

La planificación enfoca su atención en las metas del proyecto, riesgos potenciales y problemas que puedan interferir con el cumplimiento de esas metas. 

1.2.2. Propuesta. 

La propuesta, memoria u oferta es la respuesta del proveedor externo a la petición que le hace el cliente. Si es un trabajo de un grupo formado dentro de la organización, el contenido es muy similar y puede dominarse memoria del proyecto o de otras maneras. Para la preparación de la propuesta, el grupo que la prepara debe revisar las especificaciones elaboradas por el cliente y celebrar reuniones con representantes de la organización, al menos de tres áreas: la parte administrativa y legal; la parte que encarga o administra el encargado del proyecto, y algunos usuarios clave. La propuesta debe ser dirigida por el jefe de proyecto que es el que asume la dirección del trabajo y que tenga una dotación adecuada de tiempo y recursos. 

1.2.3. Selección y Evaluación de personal. 

Selección.- 

Este servicio se refiere al proceso de elegir al personal que cuente con las competencias laborales y personales necesarias para cubrir vacantes existentes o proyectadas en su empresa dándole énfasis al lado humano de la competitividad. 

Evaluación.- 

Uno de los pasos dentro del proceso de selección de personal son las evaluaciones psicológicas. Las mismas tienen como objetivo describir a la persona en sus diferentes aspectos (intelectuales, cognitivos, emocionales, etc.) y se consideran predictores del desempeño laboral.

El proceso de software lo componen participantes que pueden clasificarse en cinco categorías:

• Gestores superiores: definen los aspectos de negocios que a menudo tienen una significativa influencia en el proyecto. 
• Gestores técnicos del proyecto: deben planificar, organizar y controlar a los profesionales que realizan el trabajo del software.
• Profesionales: proporcionan las capacidades técnicas para la ingeniería de un producto
• Clientes: especifica los requisitos para la ingeniería de software. 
• Usuarios finales: interaccionan con el software una vez que se ha entregado para la producción. 

1.2.4. Supervisión y Revisión del proyecto. 

La supervisión del proyecto es una actividad continua. El gestor debe tener conocimiento del progreso del proyecto y comparar el progreso con los costes actuales y los planificados. Se debe de tener una imagen clara de lo que pasa llevando a cabo una entrevista informal con el personal del proyecto. Durante un proyecto es normal tener varias revisiones formales de su gestión. Se hace la revisión completa del progreso y de los desarrollos técnicos del proyecto, y se tiene en cuenta el estado del proyecto junto con los propósitos de la organización que ha encargado el proyecto

1.2.5. Informes

Los gestores del proyecto tienen la necesidad de informar al cliente y contratistas sobre el proyecto. Tiene que redactar documentos concisos y coherentes que resuman la información crítica de los informes detallados del proyecto. Les debe ser posible presentar esta información durante las revisiones del progreso. 

1.3 Fundamentos de Project Management Institute.

El Project Management Institute (PMI) es una organización internacional sin fines de lucro que asocia a profesionales relacionados con la Gestión de Proyectos. Desde principios de 2011, es la más grande del mundo en su rubro, dado que se encuentra integrada por más de 380.000 miembros en cerca de 170 países. La oficina central se encuentra en la localidad de Newtown Square, en la periferia de la ciudad de Filadelfia, en Pennsylvania (Estados Unidos). Sus principales objetivos son:

• Formular estándares profesionales en Gestión de Proyectos.
• Generar conocimiento a través de la investigación
• Promover la Gestión de Proyectos como profesión a través de sus programas de certificación. 

HERRAMIENTAS CASE

¿Qué es proyect libre?

Es el software de administración y gestión de proyectos de código abierto que continúa la trayectoria iniciada por la antigua y reconocida herramienta Openproj. Basado en el lenguaje de programación Java, es compatible con los sistemas operativos Windows, MacOS y GNU/Linux. 

Con ProjectLibre se pueden realizar diagramas de Gantt y gráficos PERT; además de diagramas RBS, de estructura analítica de recursos, y diagramas WBS, de estructura de descomposición del trabajo. Su interfaz de usuario, las pestañas de navegación y el procedimiento que emplea para construir un proyecto resultan familiares a las personas que han trabajado en anteriores ocasiones con Microsoft Project.

Aquí también es necesario ver cuáles dependen de otras y cómo se vinculan entre ellas. Finalmente, se asignan los recursos de forma detallada y para cada una de las actividades definidas. Añadir o eliminar tareas es sencillo, y también es posible observar cómo va avanzando la ejecución, reflejado mediante un porcentaje. La representación WBS (Work Breakdown Structure) posibilita ver la descomposición en tareas y subtareas de las fases del proyecto.

Ejemplo de herramienta case  

PROYECTO

SISTEMA DE CONTROL DE INVENTARIO DE LA ZAPATERÍA MARIOS"G"

OBJETIVO GENERAL

Diseñar un sistema para el control del inventario de la empresa zapatería “Marios G”  ubicada en la ciudad de Comitán de Domínguez Chiapas Barrio del cedro en el periodo comprendido (Agosto-Diciembre 2017) el cual permitirá realizar un efectivo control en tiempo  y orden de la mercancía.

       

ESTUDIO DE FACTIBILIDAD 

FACTIBILIDAD OPERATIVA

Permite a la zapatería  Marios “G” poner en funcionamiento un sistema de control de inventario de la mercancía dando un correcto funcionamiento y uso de dicho sistema, aplicando conocimientos de programación, diseño de base de datos y manejo del software para el desarrollo del sistema que estará sujeto a la capacitación necesaria que se le impartirá  al dueño, entre ellos el conocimiento en computación básica  para el uso del sistema.

UNIDAD 2  Gestión de calidad.

 Calidad del Software
La calidad del software es un concepto complejo que no es directamente comparable con la calidad de la manufactura de productos. En la manufacturación, la noción de calidad viene dada por la similitud entre el producto desarrollado y su especificación. En un mundo ideal, esta definición debería aplicarse a todos los productos, pero, para sistemas de software, existen estos problemas: 

1. La especificación se orienta hacia las características del producto que el consumidor quiere. Sin embargo, la organización desarrolladora también tiene requerimientos (como los de mantenimiento) que no se incluyen en la especificación.

2. No se sabe cómo especificar ciertas características de calidad (por ejemplo, mantenimiento) de una forma no ambigua. 

3. Es muy difícil redactar especificaciones concretas de software. Por lo tanto, aunque un producto se ajuste a su especificación, los usuarios no lo consideran un producto de alta calidad debido a que no responde a sus expectativas. 

Se deben reconocer estos problemas con la especificación del software y se tienen que diseñar procedimientos de calidad que no se basen en una especificación perfecta. En concreto, atributos del software como mantenibilidad, seguridad o eficiencia no pueden ser especificados explícitamente. Sin embargo, tienen un efecto importante en cómo es percibida la calidad del sistema.

2.1 La gestión de proyectos usando un marco de calidad 

La gestión de la calidad provee una comprobación independiente de los procesos de desarrollo software. Los procesos de gestión de la calidad comprueban las entregas del proyecto para asegurarse que concuerdan con los estándares y metas organizacionales. El equipo de garantía de calidad debe ser independiente del equipo de desarrollo para que puedan tener una visión objetiva del software. Ellos transmitirán los problemas y las dificultades al gestor principal de la organización.
Un equipo independiente de calidad garantiza que los objetivos organizacionales y la calidad no sean comprometidos por consideraciones de presupuesto o agenda. Una suposición subyacente de la gestión de calidad es que la calidad del proceso de desarrollo afecta directamente a la calidad de los productos derivados. La siguiente figura muestra una aproximación basada en proceso para conseguir la calidad del producto

Hay un vínculo claro entre la calidad del proceso y del producto en producción debido a que el proceso es relativamente fácil de estandarizar y monitorizar. El software no se manufactura, sino que se diseña. El desarrollo de software es un proceso más creativo que mecánico. La calidad del producto, también se ve afectada por factores externos, como la novedad de una aplicación o la presión comercial para sacar un producto rápidamente

La gestión de la calidad del proceso implica: 

1. Definir estándares de proceso. 
2. Supervisar el proceso de desarrollo para asegurar que se sigan los estándares. 
3. Hacer informes del proceso para el gestor del proyecto y para el comprador del software. 

2.2 Estándares y Métricas de calidad en la ingeniería de SW 

Un problema de la garantía de la calidad basada en el proceso es que el equipo de garantía de la calidad (QA) insista en unos estándares de proceso independientemente del tipo de software a desarrollar. El gestor principal debe intervenir para asegurar que el proceso de calidad ayude al desarrollo del producto en lugar de impedirlo.


Podemos definir dos tipos de estándares como parte del proceso de garantía de calidad
: 
1. Estándares de producto. Se aplican sobre el producto software que se comienza a desarrollar. Incluyen estándares de documentación, como cabecera de comentarios estándar para definición de clases, y estándares de codificación. 

2. Estándares de proceso. Definen los procesos que deben seguirse durante el desarrollo del software. Pueden incluir definiciones de procesos de especificación, diseño y validación, así como una descripción de los documentos que deben escribirse en el curso de estos procesos. Existe una relación muy cercana entre los estándares de producto y los estándares de proceso. Los estándares de producto se aplican a las salidas del proceso software y. en muchos casos, los estándares de proceso incluyen actividades de proceso específicas que garantizan que se sigan los estándares de producto.



2.3.1 CMM 

CMM es una aplicación del sentido común para el gerenciamiento de procesos y conceptos de mejora de la calidad del desarrollo y mantenimiento del software, es además una guía desarrollada por y para la comunidad profesional del software. 

• Un modelo para la mejora organizacional. 
• Una estructura confiable y consistente para evaluar y mejorar las capacidades de una organización.

¿Porque surge CMM? 

Crisis del software de principios de los 80, debido a una falta de eficiencia en los procesos de desarrollo de programas. 

¿Qué puedo hacer con CMM?

•  Ayudar a la comunicación, al establecer un lenguaje común en el ámbito organizacional 
• Facilitar poner el foco de atención en cuestiones críticas 
• Proveer recomendaciones generales
• Ayudar a priorizar acciones de mejora 

El CMM ha demostrado su impacto en la calidad del software producido bajo sus directrices. Las limitaciones más determinantes en CMM es que sólo es un modelo de referencia, es decir, sólo describe los procesos clave que una organización debe tener, y no explica cómo se deben implementar estos.

2.3.2 MOPROSOFT

 Modelo de Procesos para la Industria del Software

Modelo para la mejora y evaluación de los procesos de desarrollo y mantenimiento de sistemas y productos de software. Desarrollado por la Asociación Mexicana para la Calidad en Ingeniería de Software a través de la Facultad de Ciencias de la Universidad Nacional Autónoma de México (UNAM) y a solicitud de la Secretaría de Economía para obtener una norma mexicana que resulte apropiada a las características de tamaño de la gran mayoría de empresas mexicanas de desarrollo y mantenimiento de software. Moprosoft es el nombre del modelo en la comunidad universitaria y profesional, y la norma técnica a la que da contenido es la NMX-059/01-NYCE-2005 que fue declarada Norma Mexicana el 15 de agosto de 2005 con la publicación de su declaratoria en el Diario oficial de la Federación. Moprosoft considera que los modelos de evaluación y mejora CMMI eI SO/IEC 15504 no resultan apropiados para empresas pequeñas y medianas de desarrollo y mantenimiento de software. Sobre las áreas de procesos de los niveles 2 y 3 del modelo SW-CMM e inspirándose en el marco de ISO/IE 15504 se ha desarrollado este modelo

2.4 Impacto de la calidad en tiempo, costo y alcance del proyecto 

El alcance de un proyecto llamado también alcance del trabajo es el trabajo que debe hacerse para que el cliente se convenza de que las entregas (las cosas por hacer), es decir el producto u objetos tangibles que han de suministrarse) cumplan con los requisitos o criterios de aceptación acordados al comenzar el proyecto. Por ejemplo, el alcance podría ser el trabajo de limpiar el suelo, de construir una casa y de poner la jardinería ornamental según las especificaciones hechas por el cliente y aceptadas por el contratista.

Por estructuración se entiende la facilidad con que las funciones pueden ser compartimentalizadas y la naturaleza jerárquica de la información a tratar. A medida que el grado de estructuración aumenta, la posibilidad de estimar con precisión mejora y, por consiguiente, el riesgo disminuye. Bajo el concepto de la administración de proyectos, se asignan representantes de cada uno de los departamentos funcionales de las divisiones al equipo asignado al proyecto. 

Análisis de riesgo y tipos de riesgos de un proyecto

La existencia de riesgos es inherente a cualquier actividad humana en tanto que absolutamente todo lo que realizamos en la vida está sometido a un determinado grado de incertidumbre. A la hora de ejecutar un proyecto, por muy buena que sea la planificación realizada, el conocimiento del ámbito y contexto en el que se desarrolla el proyecto y las previsiones sobre el futuro, también siempre existe un cierto margen para el error, que tiene su representación en los riesgos.

Se entiende por riesgo cualquier modificación en el entorno de mercado o en el producto que puede tener influencia sobre el proyecto que se está desarrollando.

Este cambio de circunstancias y de necesidades de los clientes no necesariamente tiene por qué ser un inconveniente para nuestro proyecto. Si estamos preparados para hacer frente a estos cambios, las consecuencias sobre el resultado de nuestro proyecto serán mínimas.

Incluso, si somos capaces de reaccionar adecuadamente ante este riesgo, podemos sacar beneficio de ello y mejorar nuestro producto, nuestras ventas, o la satisfacción de nuestros clientes.

Por tanto, la mejor manera de reducir la exposición a riesgos es realizar una adecuada planificación. En ella, los riesgos se deben abordar desde una perspectiva realista que permita su conocimiento y el trazado de planes de actuación en caso de que se presenten. En ningún caso se debe ignorar la existencia de los riesgos, sino que se deben controlar.

Ademá de una buena planificación, es necesario que el director de proyectos y la dirección de la empresa en su conjunto sepan cómo actuar ante la aparición de riesgos. La gestión adecuada de una situación de riesgo permitirá convertir las debilidades en fortalezas

 Tipos de riesgos

Los objetivos de la gestión de riesgos son identificar, dirigir y eliminar las fuentes de riesgo antes de que empiecen a afectar a la finalización satisfactoria de un proyecto software.

El riesgo siempre implica dos características:

Incertidumbre: el acontecimiento que caracteriza al riesgo puede o no puede ocurrir.
Pérdida: si el riesgo se convierte en una realidad, ocurrirán consecuencias no deseadas o pérdidas.


Para cuantificar el nivel de incertidumbre y el grado de pérdidas asociado con cada riesgo se consideran diferentes categorías de riesgos:

Riesgos del proyecto: o Afectan a la planificación temporal y al coste del proyecto. o Identifican problemas potenciales de presupuesto, calendario, personal, recursos.
Riesgos técnicos: o Amenazan la calidad y la planificación temporal del software que hay que producir. o Identifican posibles problemas de diseño, implementación, interfaz, verificación y mantenimiento.
Riesgos del negocio: o Amenazan la viabilidad del software. o Los principales riesgos de negocio son:
Riesgo de mercado
Riesgo estratégico
Riesgo de ventas
Riesgo de dirección
Riesgo de presupuesto


Se puede hacer otra categorización de los riesgos en función de su facilidad de detección:


Riesgos conocidos: son aquellos que se pueden predecir después de una evaluación del plan del proyecto, del entorno técnico y otras fuentes de información fiables.
Riesgos predecibles: se extrapolan de la experiencia de proyectos anteriores.
Riesgos impredecibles: pueden ocurrir, pero es extremadamente difícil identificarlos por adelantado.

La gestión continuada de los riesgos permite aumentar su eficiencia:

Evaluar continuamente lo que pueda ir mal
Determinar qué riesgos son importantes o Implementar estrategias para resolverlos
Asegurar la eficacia de las estrategias


Elementos de la gestión de riesgos:
Estimación de riesgos:

Identificación de riesgos: lista de riesgos capaces de romper la planificación del proyecto.
Análisis de riesgo: medición de la probabilidad y el impacto de cada riesgo, y los niveles de riesgo de los métodos alternativos.
Priorización de riesgos: lista de riesgos ordenados por su impacto.
Control de riesgos:
Planificación de la gestión de riesgos: plan para tratar cada riesgo significativo.
Resolución de riesgos: ejecución del plan.
Monitorización de riesgos: comprobación del progreso del control de un riesgo e identificación de la aparición de nuevos riesgos.


Identificación de riesgos

Constituye un intento sistemático para especificar las amenazas al plan del proyecto.
Las incertidumbres sobre diferentes características del proyecto se transforman en riesgos que pueden ser descritos y medidos.
Un método para identificar los riesgos es crear una lista de comprobación de elementos de riesgo que debe contener dos categorías de riesgos:

Riesgos específicos del producto: para identificarlos se examina el plan del proyecto y la declaración del ámbito del software.

Riesgos genéricos: Son comunes a todos los proyectos de software. Para identificarlos se crean las siguientes subcategorías:

amaño del producto
Impacto en el negocio
Características del cliente
Definición del proceso
Entorno de desarrollo
Tecnología a construir
Tamaño y experiencia de la plantilla.

Análisis de riesgos

Es el proceso de examinar los riesgos en detalle para determinar su extensión, sus interrelaciones y su importancia.


Las actividades básicas son:

Evaluación: mejor comprensión del riesgo. Se cuantifican los siguientes conceptos:
Impacto: pérdida que ocasiona el riesgo.
Probabilidad: probabilidad de que ocurra el riesgo.
Marco de tiempo: periodo de tiempo en el que es posible mitigar el riesgo.

Protocolo

NOMBRE DE LA EMPRESA

Zapatería Marios ”G”

ANTECEDENTES

Antecedentes Actualmente la empresa no cuenta con un sistema automatizado para llevar un control de inventario donde se llevan a cabo los registros de entradas y salidas de la mercancía en una libreta escrito a mano, donde se tiene el control del modelo, color y talla de los zapatos en existencia. Cuando el cliente llega a la zapatería es atendido por el empleado y pide un modelo de zapato que le agrade en exhibición, se lo mide para ver si le queda, en este caso si le gusta y decide llevarlo le paga al dueño en efectivo y se hace entrega de los zapatos. En el caso de no tener la talla del zapato que el cliente pide, se le pregunta si desea ver otros modelos similares al anterior, si le gusta algún modelo se lo mide y si decide llevarlo pasa a caja a liquidar. Si no se llegara a contar con algún modelo o talla solicitada se realiza una lista escrita en una libreta a mano de la mercancía faltante para realizar un pedido.

PLANTEAMIENTO DEL PROBLEMA

Planteamiento del problema: Zapatería “Marios G” se inició posteriormente el 20 de junio de 2013 en el ramo zapatero, a partir de una necesidad y oportunidad de trabajo pues anteriormente no contaba con los recursos necesarios para iniciar su negocio solicitando un pequeño préstamo y utilizando el dinero para invertirlo en zapatos para vender ofreciendo a amigos familiares y conocidos. Se Constituyó la empresa de comercialización con fines de beneficiar a la población y como organización busca el bienestar-beneficio reciproco clientes-empresa. Para cumplir con las necesidades de los clientes con buenos productos de calidad y de bajo y accesible precio en el mercado para obtener el mayor reconocimiento entre sus competidores. Ideando tal negocio pensando en una mejor y efectiva satisfacción del cliente como única fuente de ingreso para la empresa mediante el expendio a ellos, haciendo que su clientela se sienta mejor y la empresa surja y se desarrolle dependiendo de las expectativas preestablecidas. Como empresa debe adecuarse al mercado, buscar adquirir productos de garantía de sus productos y así  tener el respaldo como proveedores, para dar seguridad a los clientes. La entidad se creó con una finalidad de brindar atención y comercialización de productos de acuerdo a la demando del consumidor Actualmente está  Ubicado en 8ª calle norte oriente  Barrio del cedro atención directamente de su propietario Sr. Mario Luis Gómez Morales donde puede observar y adquirir el calzado que más le guste. La zapatería actualmente realiza su control de inventario de forma manual donde se registra sus compras, ventas, clientes y  proveedores de tal manera que no tiene un buen manejo de su mercancía e invierte mucho tiempo en realizar sus registros.   Una posible solución a este problema es desarrollar un sistema de inventario que de respuesta y que además permita facilitar el manejo de control de inventario de la zapatería Marios “G”, combinando todos los elementos y adecuándolo a la necesidad de la empresa

Pregunta ¿es necesario actualizar una base de datos? ¿Cuál es la importancia de actualizar una base de datos?

NOMBRE DEL PROYECTO

Sistema de control de inventario de la zapatería Marios “G” (SCI)

LINEA DE INVESTIGACIÓN

Desarrollo de Software

Automatización de Procesos mediante el uso de sistemas digitales y redes de computadora

OBJETIVO GENERAL Diseñar un sistema para el control del inventario de la empresa zapatería “Marios G”  ubicada en la ciudad de Comitán de Domínguez Chiapas Barrio del cedro en el periodo comprendido (Agosto-Diciembre 2017) el cual permitirá realizar un efectivo control en tiempo  y orden de la mercancía.

OBJETIVOS ESPECÍFICOS           Elaborar un sistema que permita llevar el control del inventario en la zapatería “Marios G”.           Diseñar e implementar  en el sistema  un  módulo de compras           Diseñar e implementar en  el sistema un  módulo de ventas           Diseñar e implementar en el sistema un  módulo de clientes            Diseñar e implementar en el sistema un módulo de proveedores           Diseñar e implementar en el sistema un módulo de seguridad           Instalación del software propuesto para el control del inventario en la Zapatería “Marios G”

HIPÓTESIS Respuesta tentativa de lo que va a suceder con la implementación del proyecto Se pretende implementar el uso de la tecnología al desarrollar un sistema automatizado que estará diseñado para llevar el inventario de la zapatería, este sistema podrá llevar las existencias de zapatos que posee el negocio, que la llevarán a cumplir los objetivos establecidos, y los métodos adecuados de control que servirán para  establecer el avance en los planes de la organización la cual está dispuesta a aceptar y a administrar el cambio como una oportunidad para el crecimiento.

JUSTIFICACIÓN La base de toda empresa  es el control de los productos que entran y salen; de aquí la importancia del manejo del inventario por parte de la misma. Este manejo permitirá a la empresa mantener el control oportunamente, así como también conocer al final del periodo un estado confiable de la situación económica de la empresa. La creación de este sistema permitirá  llevar el control del inventario adecuándolo  a las necesidades de la Zapatería “Marios G” S.A. de C.V. logrará que los usuarios estén satisfechos por la rapidez al momento de solicitar un pedido y compra  sobre la mercancía existente.

Unidad 3. Planificación de proyecto

3.1 Objetivo del proyecto

 Todo proyecto conlleva la realización de una serie de actividades para su desarrollo. La distribución en el tiempo de dichas actividades y la consideración de los recursos necesarios son las funciones a desarrollar en la planificación de proyectos. El objetivo de la planificación de proyectos es obtener una distribución de las actividades en el tiempo y una utilización de los recursos que minimice el coste del proyecto cumpliendo con los condicionantes exigidos de: plazo de ejecución, tecnología a utilizar, recursos disponibles, nivel máximo de ocupación de dichos recursos, etc. Por lo tanto la planificación de proyectos es una programación de actividades y una gestión de recursos para obtener un objetivo de coste cumpliendo con las condiciones exigidos por nuestro cliente. 

3.2 Estimaciones de tiempo

 Entre el inicio de una actividad y su fiscalización transcurre un determinado periodo de tiempo, periodo de tiempo que no conoceremos con exactitud hasta que no finalice dicha actividad. Si planificar es fundamentalmente prever se hace imprescindible realizar una previsión, estimación, del tiempo que transcurrirá entre el inicio y el final de cada una de las actividades que componen el proyecto al objeto de confeccionar el programa del proyecto "a priori".

Existe una técnica, de base estadística, para la estimación del tiempo de ejecución de una actividad. En esta técnica se consideran tres tipos de tiempos: duración optimista = O, duración Pesimista = P, duración más probable = M, de los que se obtienen el tiempo que se utilizara en el programa y que se basa en cubrir el 50% de probabilidad de que se de esa duración, utilizando la formula estadística de: TPERT = (1XOp + 4XM + 1XP)/6. Las duraciones optimistas, pesimista y más probable se obtiene de la consulta a los técnicos responsables de las actividades en base a su experiencia. Otra posibilidad se basa en el tratamiento Heurístico o Experimental de la información proveniente de otros proyectos, de forma que podamos obtener cual es el tiempo medio empleado en realizar un metro de zanja en terreno cohesivo duro, o cuánto tiempo cuesta diseñar una placa de circuito impreso con 100 patillas.

3.3 Estimaciones de costos 

Elaboración del presupuesto basado en los recursos, calculados en cantidad, tiempo y costos. Los cosos pueden ser de tres tipos: Inversión, que son los bienes durables necesarios para ejecutar el proyecto, se adquiere por única vez para todo el ciclo de vida del proyecto, operación, son los insumos y gastos menores que se realizan en el transcurso del proyecto: materiales de oficina, alquileres, licencias y viáticos. Son gastos fungibles y son perdurables en el tiempo. En el presupuesto de toda obra hay que tener en cuenta la existencia de dos tipos de costes: 

• Costes directos
•  Costes indirectos

Costos directos 

Son los correspondientes a los distintos elementos que intervienen directamente en la ejecución de cada una de las unidades de obra. Estará constituido por: 

• Mano de obra 
•  Materiales
• Maquinaria 

3.4 Estimación de personal requerido

 Definición dl personal y recursos humanos, para esto es necesario determinar cualitativamente, los recursos humanos necesarios para cada etapa del proyecto. Administrador de la plataforma virtual persona con conocimientos de administración de redes, encargado de soporte, mantenimiento y administración.

3.5 Análisis de riesgos 

Evento o circunstancia cuya probabilidad de ocurrencia es incierta, pero que, en caso de aparecer, tiene un efecto (positivo o negativo) sobre los objetivos de un proyecto.

 Exposición al Riesgo ER = Probabilidad ocurrencia riesgo × Perdida asociada estimada Esquema General de la Gestión de Riesgos 

3.5.1 Tipos de riesgos

 El riesgo del proyecto tiene su origen en la incertidumbre que está presente en todos los proyectos. Amenaza al éxito de todo proyecto. Gestión de riesgos = serie de pasos que ayudan a comprender y manejar la incertidumbre que implica el desarrollo de todo proyecto.

Identificación del riesgo Analizar cada riesgo y establecer probabilidad de ocurrencia y el daño que causará si ocurre. Realizar una clasificación de los riesgos según su probabilidad de ocurrencia y el impacto que pudiese causar. Desarrollar un plan de para determinar qué acciones tomar en cuenta a aquellos riesgos con gran probabilidad de que ocurran. La organización debe estar comprometida a tratar la gestión de riesgos de forma pro activa y consistente durante todo el proyecto. Riesgos en el software Probabilidad de que curra, pérdidas producto rendimiento poder dar mantenimiento proceso de producción, tiempo de desarrollo coste.

Riesgo en el software 

• Riesgos del proyecto
• Incremento en costos
• Desbordamiento organizativo
• Riesgos técnicos 
• Riesgos del mercado 
• De mercado 
•  De estrategia 
• De ventas
• De gestión 
• De presupuesto

Identificación de riesgos

• Grupos de riesgos -Genéricos: Son comunes a todos los proyectos, son una amenaza potencial para todo el proyecto de software.

Componentes del riesgo 

• Se identifican cuatro componentes del riesgo en un proyecto software. -Rendimiento -Coste -Mantenibilidad -Planificación.

Evitar del riesgo

•  Definir las estrategias necesarias para evitar que el riesgo no se produzca. 
• Tomar las medidas encaminadas para que, aun cuando se produzca, se minimicen sus efectos. Supervisión del riesgo
•  Definir los indicadores que influyen en la probabilidad de que el riesgo se produzca. 
• Monitorizar la efectividad real de las acciones encaminadas a evitar el riesgo.

3.5.2 Identificación, Impacto y proyección del riesgo 

• Identificación de riesgo Un método para identificar riesgos es crear una lista de comprobación de elementos de riesgo. La lista se puede usar para identificar riesgos y se enfoca en un subconjunto de riesgos conocidos y predecibles en las siguientes categorías:
• Tamaño del producto (PS). Riesgo asociados con el tamaño del software a contruir o modificar.
• Impacto en el negocio (BU). Riesgos asociados por las limitaciones impuestas por la administración o el mercado. 
• Características del cliente (CU). Riesgos asociados con la sofisticación del cliente y la habilidad del desarrollador para comunicarse con él
• Definición del proceso. Riesgo asociado con el grado de definición del proceso y su seguimiento.
• Medio ambiente de desarrollo (DE). 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 (TE). Riesgos asociados con la complejidad del sistema y la tecnología punta que contiene el sistema.
• Tamaño y experiencia de la plantilla (ST). Riesgos asociados con la experiencia técnica y de proyectos del equipo que va a realizar el trabajo.

3.5.3 Evaluación del riesgo

 Es el proceso de ordenar los riesgos en función de su importancia para determinar cuáles se deben solucionar antes y a cuáles hay que asignarle más recursos. Las condiciones y prioridades pueden cambiar a lo largo del proyecto por lo que el análisis y asignación de prioridades debe realizarse de manera continuada aprovechando la información disponible en cada momento. (feedback, retroalimentación). 

Control de riesgos:

• Planificación de la gestión de riesgos: plan para tratar cada riesgo significativo. Supervisor de riesgos: comprobación del progreso del control de un riesgo e identificación de la aparición de nuevos riesgos.

3.5.4 Estrategias frente al riesgo


 Las estrategias de riesgo deben de ser muy clara. Por un lado están las reactivas, cuyo método es evaluar las consecuencias del riesgo cuando este ya se ha producido (ya no es un riesgo) y actuar en consecuencia. Este tipo de estrategias acarrea consecuencias negativas, al poner el proyecto en peligro. Y por el otro las pre activas, que aplican el método de evaluación previa y sistemática de los riesgos y sus posibles consecuencias, a la par que conforman planes de contingencias para de evitar y minimizar las consecuencias. Consecuentemente, este tipo de estrategias permite lograr un menor tiempo de reacción ante la aparición de riesgos impredecibles. 1. Reactivas, cuyo método es evaluar las consecuencias del riesgo cuando este ya se ha producido (ya no es un riesgo) y actuar en consecuencia. Este tipo de estrategias acarrea consecuencias negativas, al poner el proyecto en peligro. 2. Pre activas, que aplican el método de evaluación previa y sistemática de los riesgos y sus posibles consecuencias, a la par que conforman planes de contingencias para de evitar y minimizar las consecuencias. Consecuentemente, este tipo de estrategias permite lograr un menor tiempo de reacción ante la aparición de riesgos impredecibles. Se considera que la estrategia más factible para enfrentar los riesgos es el pre activo y se considera necesario la realización de los análisis de riesgos de forma temprana, sistemática, formal y profunda


3.6 Análisis de la viabilidad del proyecto

• Objetivo del estudio de Viabilidad “Recopilar suficientes datos para que los directivos a su vez, tengan los elementos necesarios para decidir si debe procederse a realizar un estudio de sistemas”. Los datos para el estudio de viabilidad se “pueden” recopilar mediante las entrevistas, sin dejar de abordar el problema correcto. El tiempo dedicado al estudio de viabilidad deberá ser bastante reducido y abarcar diversas actividades. El analista de software funge como catalizador y experto de soporte técnico, identificando en primer lugar dónde se pueden mejorar los procesos. Desde una perspectiva optimista, las oportunidades se pueden considerar como la contraparte de los problemas. 
• Las mejoras a los sistemas se pueden definir como cambios que darán como resultados beneficios crecientes y valiosos, por ejemplo:

 1. Aceleración de un proceso.
 2. Optimización de un proceso al eliminar pasos innecesarios o duplicados.
 3. Combinación de procesos. 
4. Reducción de errores en la captura de información mediante la modificación de formularios y pantallas de despliegue. 
5. Reducción de almacenamiento redundante. 
6. Reducción de salidas redundantes.
7. Mejora en la integración de sistemas y subsistemas.