lunes, 17 de agosto de 2020

Integradora I

Viabilidad de los proyectos

Estudiar la viabilidad de un proyecto permite saber si este realmente aportará los beneficios que se esperan de él. No se trata de una formalidad burocrática, sino de una herramienta para la toma de decisiones estratégica.

El proyecto puede ser grande o pequeño, puede ser una iniciativa de software, una construcción o una mina de grandes dimensiones. Sea cual fuere su tamaño, analizar su viabilidad es incluso más importante que la planificación del mismo.

Para determinar la viabilidad de un proyecto se requiere previamente recopilar la siguiente información:

  • Identificar las limitaciones, restricciones y supuestos: por ejemplo, en un proyecto minero se presentan limitaciones geográficas y restricciones medioambientales, lo que conduce a determinar algunos supuestos en términos de costos, estudios adicionales, etc.
  • Establecer las oportunidades que se presentan: siguiendo en el caso de un proyecto minero, se debe detectar los volúmenes de mineral que se podría explotar, así como los precios a los que se podrían vender a futuro.
  • Definir los requisitos para desarrollar el proyecto: aquí se debe especificar los montos de inversión requeridos, las diversas autorizaciones con las que se debe contar, el número de trabajadores que han de participar en el proyecto, etc.
  • Evaluar las distintas opciones: no existe una sola manera de hacer realidad un proyecto. Es importante contar con varias opciones y definir la más eficiente.

La estructura del estudio de viabilidad de un proyecto

Un efectivo estudio de viabilidad de un proyecto debe contar por lo con los siguientes elementos:
  • Alcance del proyecto: para definir los límites y evitar desviaciones que alejen de los resultados esperados. Se debe definir el ámbito de aplicación del proyecto en forma clara, concisa y precisa.
  • Análisis de situación: para identificar las fortalezas y debilidades del proyecto tal como es visto en el momento de su formulación. Se debe emplear como hoja de ruta. Sus conclusiones deben encuadrarse en la planificación y no tomarse como prioridades a resolver inmediatamente.
  • Definición de requisitos: los integrantes del equipo que formula el proyecto deben aportar para definir todo lo que requiere la implementación del mismo.
  • Determinación del enfoque: previamente se analiza las distintas opciones de solución a cada problema y se evalúa la idoneidad de uso de las estructuras existentes y de las alternativas.
  • Evaluación de la viabilidad del proyecto: se examina la rentabilidad del enfoque seleccionado. Se comienza con el análisis del costo total estimado del proyecto. Es importante contar con e análisis de costo de otras opciones, además de la solución recomendada, para así tener una clara comparación económica. Se completa con un programa que muestre la ruta del proyecto, con fechas de inicio y de fin de las actividades. Es importante calcular el costo total del proyecto, lo cual será fundamental para determinar su viabilidad. Finalmente, se añade el análisis del costo/beneficio y de la rentabilidad de la inversión.

Administración de proyectos de TI

Cierre del proyecto

¿El proyecto acaba con la aceptación del último entregable?. Pues lo cierto es que no, una vez se han ejecutado, y aceptado por parte del cliente todos los entregables, aún queda una última cosa por hacer: realizar el cierre del proyecto.

¿Qué es el cierre del proyecto?

Formalmente, el cierre del proyecto es la última de las fases que componen el proceso de gestión del mismo, y aplica tanto al proyecto en su conjunto como a cada una de las fases de su ciclo de vida. De esta forma si tenemos un proyecto que se ejecuta en fases (por ejemplo: proyecto básico, proyecto constructivo, compras, ejecución, etc.), cada una de las fases debe incluir su proceso de aceptación y cierre, ajustado a sus características concretas. Por tanto, aunque el artículo está escrito en referencia al proyecto en su conjunto, lo comentado sería igualmente válido para una fase del mismo.

¿Por qué es importante realizar el cierre del poyecto?

Desde un punto de vista práctico y formal, la finalización de un proyecto significa la finalización de todos los compromisos, tanto con la propia organización como con personas externas a ella:

  • Certifica y oficializa que hemos cumplido con el alcance y los compromisos delante del cliente (para lo cual es necesario que antes del cierre se haya realizado la aceptación). Lo que implica que ya no deberemos hacer nada más en relación a este proyecto o pedido, y que cualquier nueva solicitud será tramitada como un nuevo proyecto.
  • Libera totalmente al equipo del proyecto, incluido al director del proyecto. Por lo que estos pueden asumir nuevos proyectos.
  • Supone el cierre administrativo y financiero de todos los compromisos y derechos adquiridos por el proyecto. Esto incluye el cierre de los contratos con proveedores y cliente, y el cierre financiero del proyecto dentro de la propia organización

Cierre del proyecto por aceptación

Como cualquier proceso, el cierre del proyecto está formado por un conjunto de pasos que deben realizarse para decir que este se ha completado en su totalidad. 

Conseguir la aceptación del proyecto

El veredicto sobre si los entregables han cumplido con el alcance debe ser emitido por el cliente, o el grupo que reciba la responsabilidad si se trata de un Handover. Por tanto el primer paso para iniciar el proceso de cierre es asegurarse de que hemos completado la aceptación externa de los entregablesy que esta aceptación se ha formalizado por escrito. 

Puede ocurrir que esta aceptación sea parcial, o que incluya una lista de puntos abiertos. En este caso, antes de continuar con el proceso deberemos cerrar estos puntos y obtener la aceptación definitiva. Aunque cerrar proyectos con puntos abiertos es algo habitual, si no queda claro que la resolución de estos puntos es responsabilidad del cliente o del siguiente equipo, el proyecto no puede considerarse como cerrado.

Cierre del contrato con el cliente (cierre final del proyecto).

Una vez recibida la aceptación formal del entregable final podemos proceder a facturar el proyecto, o la parte ligada a la entrega final. En este momento debemos autorizar la emisión de las facturas y seguir su pago.

Cierre de los contratos con proveedores.

Recibir la aceptación formal de un entregable implica que los proveedores que haya participado en su ejecución han completado su trabajo. Por tanto debemos también aceptar su trabajo, liberar los últimos pagos y proceder al cierre de los contratos, de acuerdo a los procesos administrativos existentes en la organización.

Liberación del equipo interno.

De igual forma que con los proveedores, el equipo interno que ha participado en el proyecto queda liberado en el momento de que el entregable final es aceptado. A partir de este punto, cualquier implicación adicional debería ser considerada como un nuevo encargo o garantía. Si la organización trabaja con órdenes de trabajo, esta liberación se oficializa con la aprobación y cierre de la orden de trabajo. 

Cierre financiero del proyecto.

Una vez realizados los puntos anteriores es necesario asegurarse de que estos han quedado totalmente reflejados en el estado financiero del proyecto, y en el caso de las facturas, que estas se han pagado o cobrado. Aunque la gestión de impagados no suele realizarla directamente el director del proyecto, el proyecto no puede cerrarse oficialmente hasta que todas las facturas han sido pagadas.

Cierre administrativo del proyecto.

Una vez que se ha liberado el equipo y se ha cerrado financieramente el proyecto (todos los ingresos y gastos están imputados y ejecutados), podemos cerrar el proyecto administrativamente. Esto habitualmente consiste en un proceso interno de la organización que debe ser hecho por el director del proyecto. La importancia práctica de esto es el hecho de informar formalmente a la organización sobre la finalización del proyecto, y el cálculo final de los resultados económicos del proyecto.

Lecciones aprendidas y documentación del proyecto.

Aunque por regla general la mayoría de los directores del proyecto no hacemos esta parte por falta de tiempo, o porque cuando acaba un proyecto ya estamos totalmente metidos en el siguiente, la verdad es que es muy importante para la organización. Las lecciones aprendidas y la documentación permiten ampliar y actualizar la base de datos de la empresa de cara a la planificación de nuevos proyectos, y suponen la base sobre la que trabajar los procesos de mejora.

lunes, 8 de junio de 2020

Integradora

ESTRUCTURACIÓN DEL PROYECTO DE TI

1. DESCRIPCIÓN DEL PROYECTO

Reconocer la problemática


Identificar un problema consiste en darse cuenta de que existe y que podemos darle una solución. Podemos detectar nosotros el problema (percatándonos de situaciones que podríamos mejorar), o puede ser el resultado de una propuesta. En cualquier caso, no basta con detectarlo, sino que debemos enunciarlo correctamente.
Definir un problema consiste especificar las condiciones iniciales que deben tener el objeto o sistema que vamos a desarrollar con el proyecto.
Fraccionar un problema consiste en descomponerlo en otros más sencillos para poder abordarlos mejor.
Para fraccionar un problema es necesario que tengamos clara cuál es su estructura, estudiar las características de las partes o subproblemas y establecer las relaciones entre estos subproblemas que permiten solucionar la necesidad inicial.
Podemos dividir, por ejemplo, un problema en varios más pequeños para trabajar de forma colaborativa en grupos de trabajo. Cada grupo tiene claramente identificado su subproblema, y definidas sus condiciones iniciales. A su vez, todos los subproblemas están relacionados entre sí, de forma que el proyecto conjunto es la unión relacionada de los proyectos parciales.

Los objetivos


Los objetivos son los resultados deseados que se esperan alcanzar con la ejecución de las actividades que integran un proyecto, empresa o entidad.

Características de los objetivos


• Medibles o cuantificables.
• Realista.
 • Limitados en el tiempo.
• Realizables.
 • Precisos.

Importancia de los objetivos


Serán nuestra ruta o guía de las actividades a realizar, por lo que dan direccionalidad al proyecto. Con base en los objetivos se realiza la evaluación de éxito o fracaso del proyecto.

Tipos de objetivos

Objetivo General

Esencia de lo que se espera del proyecto, donde se encierran las metas máximas. No siempre es medible.

Objetivos Específicos

Nivel de detalle mayor y complementarios con el general. Pueden ser metas parciales. (Gomez, s.f.)

El Alcance


Se utiliza para definir lo que está dentro y fuera de las fronteras de un proyecto, es decir el alcance de los puntos que entran y que no entran en el proyecto. Es acordado por todas las partes que integran el proyecto haciendo referencia también a los requerimientos.
Los requerimientos del negocio y análisis de la situación actual también deberán ser tomados en cuenta.
Algunos elementos que se deberán tomar en cuenta para el Alcance del proyecto son:
  • Procesos del ciclo de vida que están dentro y fuera del alcance.
  • Tipos de datos que están dentro y fuera del alcance (financieros, ventas, costos, empleados, etc.).
  • Fuentes de datos o bases de datos que están dentro y fuera del alcance (facturación, nómina, activos, etc.).
  • Organizaciones que están dentro y fuera del alcance (Recursos humanos, manufactura, proveedores, etc.).
  • Funcionalidades que están dentro y fuera del alcance (Soporte de decisiones, captura de datos, reportes de gestión, etc.).
El alcance de un proyecto pretende cumplir tres objetivos:
  1. Mejorar la exactitud en las estimaciones de costo y tiempo.
  2. Definir una línea de base para medición y control del proyecto.
  3. Facilitar la asignación de roles y responsabilidades. 

   Estándares y normas aplicables a proyecto de TI

Estándar


Es un conjunto de reglas que deben cumplir los productos, procedimientos o investigaciones que afirmen ser compatibles con el mismo producto. Los estándares ofrecen muchos beneficios, reduciendo las diferencias entre los productos y generando un ambiente de estabilidad, madurez y calidad en beneficio de consumidores e inversores. Los esfuerzos que se están realizando y los ya realizados han perseguido distintos objetivos que van desde la definición de API (Interface de Programación de Aplicaciones), los formatos de los ficheros con la información de parámetros biométricos, la encriptación de la información biométrica, la interacción entre dispositivos biométricos diferentes, etc.

Normas


Son reglas de conductas que nos imponen un determinado modo de obrar o de abstenernos. Las normas pueden ser establecidas desde el propio individuo que se auto impone, y en este caso son llamadas normas autónomas, como sucede con las éticas o morales. Así, una persona ayuda a un necesitado porque se lo ordena su propia conciencia, y cuyo castigo también es personal, y está dado por el remordimiento.
Una norma es una regla que debe ser respetada y que permite ajustar ciertas conductas o actividades. Las normas se enfocan más en los procesos por los que tienen que pasar los productos y los estándares especifican la calidad con la que debe contar los productos.

¿Que son la serie de estándares ISO?


Las series de ISO 9000 son un grupo de 5 individualidades, pero relacionadas entre sí, siendo estándares internacionales de administración de la calidad y aseguramiento de la misma. Algunos de los beneficios que se alcanzan al instrumentar estas series en la empresa, son: La posibilidad de darle calidad al producto o servicio. Evitar costos de inspecciones finales, costos de garantías y procesos. Puede reducirse el número de auditorías de los clientes a los procesos de operación. Mayor aceptación por parte de los clientes y acogida en los mercados tanto nacionales como internacionales. Uno de estos modelos base son las normas estándares de calidad ISO 9000 que en especial han creado un interés masivo para la industria de software a causa de su aceptación a nivel internacional de muchas compañías importantes.

ISO 9001


Es la base del sistema de gestión de calidad ya que es una norma internacional y que se centra en todos los elementos de administración de calidad con los que una empresa debe contar para tener un sistema efectivo que le permita administrar y mejorar la calidad de sus productos o servicios. Los clientes se inclinan por los proveedores que cuentan con esta acreditación porque de este modo se aseguran de que la empresa seleccionada disponga de un buen sistema de gestión de calidad (SGC).

ISO 20000


Es un estándar para la gestión de servicios de TI, representa un consenso en la industria sobre los elementos que son indispensables para garantizar la efectividad de los servicios de TI. Provee una guía para la realización de auditorías y para la remediación de los hallazgos identificados, tomando como referencia las recomendaciones contenidas en las mejores prácticas internacionales.

ISO 27000


Es una familia de estándares internacionales para sistemas de Gestión de la seguridad de la información que proporcionan un marco de gestión de la seguridad de la información.

SPICE


Es un estándar importante iniciativa internacional para apoyar el desarrollo de una Norma Internacional para la Evaluación de Procesos de Software. El proyecto tiene tres objetivos principales: Para desarrollar un proyecto de trabajo para un estándar para la evaluación de procesos de software. Para llevar a cabo los ensayos de la industria de la norma emergente. Para promover la transferencia de tecnología de la evaluación de procesos de software en la industria mundial del software a nivel mundial. El estándar SPICE creciente en número de métodos de evaluación disponibles, y la creciente utilización de la técnica comercial en áreas sensibles, fueron los factores clave que impulsaron el desarrollo y la aceptación de una propuesta para desarrollar un estándar internacional para la evaluación de procesos de software. Una Norma Internacional sobre Evaluación de Procesos de Software ofrecerá los siguientes beneficios a la industria y los usuarios del software: Beneficios para la Industria del Software Los proveedores de software se someterá a un solo esquema de proceso de evaluación. Las organizaciones de desarrollo de software tendrán una herramienta para iniciar y sostener un proceso continuo de mejora. Los directores de programas tendrán un medio para garantizar que su desarrollo de software está en consonancia y apoya, las necesidades comerciales de la organización.

CMMI


Es un modelo de mejora de los procesos de construcción de software que provee los elementos necesarios para determinar su efectividad. Este modelo puede ser utilizado como guía para mejorar las actividades de un proyecto, área u organización, ya que proporciona un marco de referencia para evaluar la efectividad de los procesos actuales, facilitando con ello la definición de actividades, prioridades y metas para garantizar la mejora continua. Es el estándar más conocido para la mejora de procesos en mejora de procesos para el desarrollo de proyectos, gestión de proveedores y gestión de servicio. El CMMI establece cinco niveles de madures los cuales son:
Nivel 0: Incompleto El proceso no se realiza, o no se consiguen los objetivos.
Nivel 1: Inicial o ejecutando: Este es el nivel en donde todas las empresas que no tienen procesos, es donde el proceso se ejecuta y se logra su objetivo, así sea fuera de presupuesto y de cronograma.
Nivel 2: Repetible: Se da cuando el éxito de los resultados obtenidos se puede repetir.
Nivel 3: Definido: Significa que la forma de desarrollar proyectos está definida, establecida, documentada y que existen métricas.
Nivel 4: Administrado: Los proyectos usan objetivos medibles y cuantificables para alcanzar cubrir las necesidades de los clientes y la organización. Es decir, se usan métricas para gestionar la organización.
Nivel 5: Optimizado: Los procesos de los proyectos y de la organización están orientados a la mejora de las actividades, que mediante métricas son identificadas, evaluadas y puestas en práctica.

IEEE (Institute of Electrical and Electronics Engineers)


Es un método de establecimiento y mejora del trabajo en equipo para procesos software, una asociación técnico-profesional mundial dedicada a la estandarización, entre otras cosas. Con cerca de 400.000 miembros y voluntarios en 160 países, es la mayor asociación internacional sin ánimo de lucro formada por profesionales de las nuevas tecnologías, como ingenieros eléctricos, ingenieros en electrónica, científicos de la computación, ingenieros en informática, matemáticos aplicados, ingenieros en biomédica, ingenieros en telecomunicación e ingenieros en Mecatrónica. Su creación se remonta al año 1884, contando entre sus fundadores a personalidades de la talla de Thomas Alva Edison, Alexander Graham Bell y Franklin Leonard Pope. En 1963 adoptó el nombre de IEEE al fusionarse asociaciones como el AIEE (American Institute of ElectricalEngineers) y el IRE (Institute of Radio Engineers). Según el mismo IEEE, su trabajo es promover la creatividad, el desarrollo y la integración, compartir y aplicar los avances en las tecnologías de la información, electrónica y ciencias en general para beneficio de la humanidad y de los mismos profesionales. Algunos de sus estándares son:
· VHDL
· POSIX
·IEEE 1394
·IEEE 488
·IEEE 802
·IEEE 802.11
·IEEE 754
Mediante sus actividades de publicación técnica, conferencias y estándares basados en consenso, el IEEE produce más del 30% de la literatura publicada en el mundo sobre ingeniería eléctrica, en computación, telecomunicaciones y tecnología de control, organiza más de 1000conferencias al año en todo el mundo, y posee cerca de 900 estándares activos, con otros 700 más bajo desarrollo.

PSP


El proceso personal del software es un método de auto conocimiento, que permite estimar cuando se tarda un individuo en realizar una aplicación de software, para así calcular el presupuesto y asegurar la operatividad de los desarrollos. PSP se concentra en las prácticas de trabajo de los ingenieros en una forma individual.
El PSP se caracteriza porque es de uso personal y se aplica a programas pequeños de menor de 10.000 líneas de código. El PSP sirve para producir software de calidad, donde cada ingeniero debe trabajar en la necesidad de realizar trabajo de calidad.

TSP


Team software process es un método de establecimiento y mejora del trabajo en equipo para procesos de software. Es un proceso para equipos de software, a través del cual se contribuyen equipos de alto rendimiento, capaces de comprometerse con el plan y administración del desarrollo de software, así como de producir productos de calidad y a bajo costo, logrando el mejor desempeño posible.

Moprosoft


Es una norma mexicana, basada en procesos para las industrias de software, la cual sirve para estandarizar operaciones y prácticas en gestión de ingeniería de software, para así elevar la capacidad de las organizaciones de ofrecer servicios con calidad y alcanzar niveles internacionales de competitividad. Está enfocado a las PyMes de la Industria de Software en México. Está dirigido a las empresas o áreas internas dedicadas al desarrollo y/o mantenimiento de software.

domingo, 7 de junio de 2020

Administración de proyectos de TI

Administración de recursos humanos del proyecto de T.I.

 Definición de roles y perfiles de los actores involucrados

     Roles

El concepto está vinculado a la función o papel que cumple alguien.
Un equipo de desarrollo de software está compuesto por lo menos de los siguientes roles de TI:
·         Gerente de Proyecto
·         Líder de Proyecto
·         Analista de Sistemas
·         Diseñador
·         Ingeniero de Software
·         Responsable de Calidad
·         Responsable de Pruebas
·         Administrador de la Configuración del Proyecto
·         Cliente

 Responsabilidades


Se define como la contribución activa y voluntaria al mejoramiento social, económico y ambiental por parte de las empresas, generalmente con el objetivo de mejorar su situación competitiva, valorativa y su valor añadido.
Responsabilidades de los siguientes roles de TI:
Gerente de Proyecto
Es el responsable de la definición del proyecto y de la asignación de recursos al mismo. Da soporte a las tareas de estimación y definición de las actividades contenidas en los planes y realiza la revisión y aprobación de los mismos.
Líder de Proyecto
Es el responsable de atender las necesidades de los Analistas de Sistemas, Arquitectos, Ingenieros de Software, Capacitadores, Responsable de pruebas, Testers, Responsable de calidad, Administradores de la configuración del proyecto y Administradores de la configuración global, brindando una solución a los requerimientos que soliciten. Establece el control de los avances del proyecto, asignaciones de trabajo, juntas de seguimiento y sobre todo dar buena cara y tener contento al cliente. En resumen, este rol es el responsable de llevar a buen término la ejecución del proyecto.
Analista de Sistemas
Es el encargado del diseño del sistema: Análisis general, análisis detallado, diagrama conceptual, diseño y generación de la base de datos y normalización de la misma, documento de flujo de operación y especificaciones funcionales.
Recuerda la mayor parte del éxito de un proyecto está en el buen entendimiento y especificación de los requerimientos. No solo basta con tomar nota de lo que requieren los usuarios funcionales, un analista debe de convertirse en un consultor de negocios que proponga mejoras y soluciones a las necesidades del cliente.
Diseñador
¿El verdugo de los desarrolladores? Bueno él es el responsable de la creación de un concepto de sistema que ayude a cumplir los objetivos de negocio fijados por los interesados, asegurándose que el sitio cumpla con las características de accesibilidad, navegabilidad, interactividad y usabilidad que garanticen una experiencia agradable al usuario. Hoy en día el diseño se ha vuelto fundamental para que un buen sistema de software invite a ser usado por sí solo. Ya no solo basta que un diseñador te genere plantillas como imágenes (png, jpg, etc), y las pase a construir a los desarrolladores dándoles la responsabilidad de la generación de los HTMLS (hablando de web), sino que las organizaciones cada vez esperan más sobre este rol, la exigencia de que el mismo diseñador sea el responsable de generar el HTML de esos diseños tan sofisticados y modernistas ya se da por hecho incluso que trabajen ya en mente con marcos de trabajo responsivos y dinámicos.
Ingeniero de Software
¿Un ser que habla en ceros y unos, un todo poderoso, intocable, el héroe y el destino está en sus manos? Bueno algo así y nada lejano a la realidad, sin estas personas el software no podría generar más software, por lo tanto, su principal responsabilidad es definir y mantener el código fuente de uno o varios componentes, garantizando que cada componente implemente la funcionalidad correcta. Tiene responsabilidad por la integridad de uno o más subsistemas de implementación y de sus contenidos a lo largo del desarrollo. Es también responsable de asegurarse que el código generado esté libre de errores por medio de la ejecución de pruebas unitarias del código construido.
Responsable de Calidad
¿Inspectores, auditores, el verdugo de los líderes? Pues gracias a este rol los proyectos van encaminados a buen éxito ya que su principal responsabilidad es de garantizar el cumplimiento de los compromisos hechos con el proyecto desde el punto de vista del proceso a seguir. Si un proyecto de desarrollo no cuenta con una metodología con procesos y procedimientos bien ejecutados la probabilidad de éxito se vuelve baja y tiende al caos y heroísmo y buena fe de los integrantes del proyecto para sacarlo adelante.
Responsable de Pruebas
¿Otro verdugo o un aliado del desarrollador?, gánatelo como aliado, aprende de los issues que te reporta, hazlos tuyos, documéntalos corrígelos y que no te vuelvan a pasar. Esta persona tiene como responsabilidad garantizar que se cumplan los requerimientos funcionales establecidos para el producto y el que el producto esté libre de fallas, por medio de la planeación y ejecución de las pruebas a todo el software construido. Es el encargado de dar el visto bueno de que un producto o aplicación pueda pasar a un ambiente productivo, su responsabilidad es tan grande que se juega parte del éxito del proyecto en el.
Administrador de la Configuración del Proyecto
¿Y dónde están las especificaciones del proyecto, cuál es la versión final, porque no tengo acceso a esa información, donde están los cambios que hice a mí página?  Por lo tanto, este rol es responsable del versionamiento y ubicación de cada producto de trabajo del proyecto que permita asegurar la disponibilidad de los mismos en un repositorio de proyecto incluyendo el código y la documentación generada durante el ciclo del proyecto.
Cliente
¿El cliente?, si claro el cliente, para la consecución exitosa de las actividades y fases del proyecto, es indispensable la participación de personas clave del cliente relacionadas al proyecto; así como también del personal de Sistemas.
Las personas por parte del cliente que se identifiquen para participar en el proyecto deberán tener el tiempo suficiente para agendar entrevistas con los Analistas de Sistemas, con la finalidad de que se revisen y se especifiquen las reglas de negocio y procesos críticos. Su participación es muy importante durante las fases de análisis, diseño, pruebas y capacitación.
Es responsabilidad por parte del cliente designar a un líder de proyecto de su parte que funja como el canal principal sobre el cual se estarán llevando acuerdos, notificaciones, reuniones de avance y autorización de requerimientos, así como de la aceptación del producto y proyecto.
El líder de proyecto que representa al cliente es responsable de establecer los requerimientos, revisarlos y autorizarlos a fin de definirlos como base para la construcción del software.
Es también responsable de la verificación y validación del producto de software entregado a fin de que permita aceptar de conformidad la entrega del producto y cierre formal del proyecto.

 Actores involucrados en el proyecto de T.I.

Un actor es todo individuo que se encuentra o forma parte de un grupo, organización, entidad, corporativo, público, social o privado, que tenga relación directa o indirecta con el proyecto a ejecutar.

lunes, 6 de abril de 2020

LISTAS DE VERIFICACIÓN


Qué es una hoja de verificación

Una hoja de verificación o de chequeo es una herramienta impresa a modo de formato, utilizada para recoger y compilar de forma estructurada datos asociados a un proceso o situación particular definida. Los datos reunidos representan una entrada para el uso de otras herramientas de control de calidad como el diagramHTTPa de Pareto o dispersión. En este sentido, la hoja de verificación es una herramienta genérica utilizada para multitud de propósitos que van más allá de la calidad.

Para qué sirve una hoja de verificación

¿Cuál es la función de una hoja de verificación? Un personaje icono en el campo de la calidad se hizo antes la misma pregunta. La función de una hoja de verificación varía de acuerdo al tipo de hoja. Esto es lo que dice Kaoru Ishikawa:
  • Para cuantificar los defectos por producto
  • Para cuantificar defectos por localización
  • Para cuantificar defectos por causa (maquina o trabajador)
  • Para realizar un seguimiento a las actividades de un proceso (lista de verificación)
Así pues, la hoja de chequeo es una puerta de entrada para otras herramientas de control de calidad. Sin datos, no habrá solución, de ahí su importancia.

Ventajas de las hojas de verificación

·         Proporciona datos fáciles de comprender.
·         Los datos son obtenidos mediante un proceso simple y eficiente que puede ser aplicado a cualquier área de la organización.
·         Reflejan rápidamente las tendencias y patrones subyacentes en los datos. (Gehisy, 2017)

Tipos de hoja de verificación

No hay tipos establecidos de hojas de verificación de manera formal, sin embargo, si podemos definir ciertos usos comunes, los cuales se resumen en tres:
  • Hoja para registro de datos
  • Hoja de lista de chequeo
  • Hoja de localización
Algunos ejemplos son:
Hoja de chequeo con escala de medición: Con ella evaluamos la forma de distribución de probabilidad para construir después una distribución de frecuencia. En este tipo de hoja clasificamos la medición según una serie de categorías o parámetros, además nos permite trazar límites de especificación.

Hoja de chequeo de frecuencia: Con esta hoja definimos las categorías y recogemos los datos anotando el número de veces que se presentan.


Hoja de chequeo con clasificación: También llamada hoja de verificación por tipo de defecto. En esta hoja, definimos una serie de categorías a ser ubicadas en la primera columna y en la primera fila, de tal manera que los datos reunidos sean clasificados de acuerdo al cruce de columna y fila.

Hoja de chequeo de localización: En ella se presenta uno o más esquemas del objeto de medición, en el cual señalamos la ubicación del defecto.

Lista de chequeo: Los aspectos a comprobar se enumeran y en-listan de tal forma que, al detectarse un evento asociado a uno de los aspectos, se pueda marcar según corresponda.
  

Cómo hacer una hoja de verificación

No hay una forma definida para hacer una hoja de verificación. Esta va a depender de la situación a analizar, por lo cual cada quien es responsable de diseñar su propia hoja. Sin embargo, sí que hay unos lineamientos a tener en cuenta para lograr nuestra hoja de verificación, veamos cuáles son.
Paso 1: Establecemos el contexto sobre el cual vamos a medir los datos. Básicamente lo que hacemos aquí es planear, y una de las mejores herramientas para apoyarnos es el 5w+2h.
  • Qué
  • Por qué
  • Cuándo
  • Dónde
  • Quién
  • Cómo
  • Cuánto.
Paso 2: Creamos el formato de la hoja, el cual estará diseñado de acuerdo al 5w+2h del paso anterior.
Paso 3: Recolectar los datos. Es importante que los datos se recolecten como se definió en el cómo, cuándo y dónde del paso 1. Así aseguramos la pertinencia de los datos recolectados.

Ejemplo de hoja de verificación

“Su compu aquí” es un negocio que presta servicio técnico a computadores. El dueño ha decidido caracterizar el tipo de errores que se presentan, su frecuencia y el número de errores que puede solucionar un técnico por periodo de tiempo. Veamos cómo lo hizo.
Paso 1:
  • Qué: Clasificar los defectos de tienen los clientes en su computador y la eficacia en la solución por parte del personal.
  • Por qué: Prestar un mejor servicio de acuerdo al tipo de defecto y capacitar al personal nuevo en los defectos más frecuentes.
  • Cuándo: Los datos se tomarán por tres semanas.
  • Dónde: Los datos se tomarán en el salón de reparaciones.
  • Quién: Los datos serán tomados por el ingeniero de producto y se evaluarán tres técnicos.
  • Cómo: Los datos serán tomados a través de hojas de chequeo, según la siguiente clasificación:
·         Una cruz: Defectos en la board
·         Un circulo: Defectos en el monitor
·         Un triángulo: Defectos de ventilación
·         Una equis: Defectos por software o de virus
  • Cuánto: Se tomarán los datos de 50 clientes o hasta que se cumpla el tiempo estipulado.
Paso 2:
Fíjate en lo definido en el paso 1. Requerimos clasificar datos según la semana, la parte del computador y el número de servicios prestados por cada técnico. Podemos adaptar varios tipos de hojas de verificación.

Paso 3: Y así luce el formato diligenciado. Con esto podemos determinar el número de servicios según la clasificación definida, cuántos servicios realizó cada técnico y la semana en que lo hicieron.

Con estos datos ya podemos tomar decisiones respectivas o adelantar otros estudios con otras herramientas de análisis y priorización de problemas. Por ejemplo:
  • ¿Por qué el técnico 2 no tiene el mismo rendimiento que el técnico 1 y el 3?
  • ¿Cuánto tiempo toma realizar las reparaciones de cada tipo?
  • ¿Qué puedo hacer para hacer más rápido las reparaciones de monitor?
(Ingenio Empresa, 2016)

Integradora I

Viabilidad de los proyectos Estudiar la viabilidad de un proyecto permite saber si este realmente aportará los beneficios que se esperan de ...