Historial de página

...

El peticionario deberá indicar el área de SSCC o el nodo provincial para el que solicita el proyecto. Este dato es fundamental porque indicará la categoría que tiene el proyecto en la herramienta corporativa. Además, es también importante que indique si el proveedor del proyecto debe tener usuario en la herramienta.

Completar propiedades del proyecto

Una vez que el proyecto está dado de alta en la herramienta, es necesario seguir informando todos los datos que aun son necesarios. Esta actividad es llevada a cabo por los Coordinadores (pueden ser más de uno, se incluirán en el grupo gestores-propiedades) de cada área, y esos datos en la herramienta son llamados "propiedades" del proyecto

Descripción: breve indicación del objetivo principal del proyecto.

Promotor del proyecto: opcionalmente puede indicarse quién promociona el proyecto. Puede ser o no miembro del equipo provincial o de la propia STIC.

Responsable del proyecto: idem a la propiedad anterior. Es fundamental que esté informado en el caso en que se creen tareas con validación, ya que será el encargado de validar el trabajo

Área TIC: las áreas TIC definidas son:

• Desarrollo
• Sistemas
• Puesto usuario
• I+D+i
• Gestión 
• Seguridad

Cada área centralizada o nodo provincial podrá decidir si quiere o no usar todas las áreas TIC definidas. Además, podrán establecer una diferentes grupo de proyectos para cada una de esas áreas. Por ejemplo, podrían considerarse dentro del área de desarrollo los proyectos .net, los de explotación de datos, etc.

Grupos de proyectos

Centros de gestión: desplegable en el que aparecen los centros de gestión de cada área o nodo provincial. Al igual que las áreas TIC y los grupos de proyectos se configuran para cada categoría, es decir, son definidos por cada área centralizada/nodo provincial.

Prioridad

Estado

Usuarios de terceros que participan en el proyecto: usuarios con licencia en la herramienta  que van a tener permiso para interactuar en el proyecto. Es importante tener en cuenta que:

• todos los usuarios que se muestran como terceros visualizan el proyecto, pero sólo aquellos que son seleccionados son los posibles asignados de las tareas.
• si la empresa de soporte provincial participa como proveedor, hay que indicar si tiene o no visibilidad en otras tareas que no sean de soporte provincial.

Nombre empresa proveedora

Nombre persona de referencia proveedor

Así mismo, es fundamental indicar quién va a ser el Responsable del proyecto. Tendrá un papel fundamental a la hora de indicar las propiedades y la estructura tanto del proyecto como de su espacio asociado.

Otros datos imprescindibles en el alta de un proyecto son:

• Si es provincial, el área STIC (SISTEMAS, PUESTO USUARIO, IMPLANTACIÓN/PROYECTOS, GESTIÓN, SEGURIDAD, I+d+i) y el grupo de proyectos dentro de cada área STIC. Cada provincia tiene clasificados los grupos de proyectos dentro de sus diferentes áreas TIC. En los espacios provinciales puede verse la clasificación que tiene cada una.
• Si es centralizado, y pertenece al área SCSD, hay que indicar el área de negocio a la que pertenece y la línea de proyectos. Cada área de negocio tiene definidas líneas de proyecto.
• Usuarios que partcipan en el proyecto. Hay que tener en cuenta:
  • Los usuarios que partcipan lo hacen siempre como proveedores, ya que todo el personal perteneciente a la STIC y a la oficina técnica de proyectos ya partcipan por defecto. En el caso de que se trate de proyectos provinciales de las áreas Implantación/proyectos o I+D+i interviene siempre el proveedor de la Oficina de Interoperabilidad, ya que serán los encargados de acometer las tareas de integración. Hay que tener en cuenta que los proveedores acceden a las herramientas de gestión de proyectos y de conocimiento con usuarios genéricos, no nominales.

• • Si la empresa de soporte provincial participa como proveedor, hay que indicar si tiene o no visibilidad en otras tareas que no sean de soporte provincial. En el caso de tener visibilidad, la tendrá también en el espacio asociado al proyecto.

Completar propiedades del proyecto. Responsable de proyecto

Una vez que el proyecto está dado de alta en la herramienta, es necesario seguir informando todos los datos que aun son necesarios. Esta actividad es llevada a cabo por el Responsable de Proyecto.

Descripción: breve indicación del objetivo principal del proyecto.

Promotor del proyecto: opcionalmente puede indicarse quién promociona el proyecto. Puede ser o no miembro del equipo provincial o de la propia STIC.

Centros de gestión: desplegable en el que aparecen los centros de gestión de cada área o nodo provincial. Al igual que las áreas TIC y los grupos de proyectos se configuran para cada categoría, es decir, son definidos por cada área centralizada/nodo provincial.

Prioridad

Estado

Nombre empresa proveedora

Nombre persona de referencia proveedor

Teléfono proveedor

Correo electrónico proveedor

...

Tipo de plantilla: indica la posibilidad de la plantilla que se crea para gestionar la documentación y el conocimiento asociado al proyecto, Hay dos posibilidades: simple y compleja. En el momento en que se crea el esapcio de CONFLUENCE, quedará enlazado al proyecto medinate la misma clave.

Creación de espacio para el proyecto 

...

Información relevante: en esta sección hay un apartado, Datos básicos, que siempre va a estar actualizado de forma automática con los datos que se hayan registrado en la herramienta de gestión. Cualquier modificación de los mismos debe hacerse desde esa herramienta y no mediante edición de la página.

El resto de la plantilla lo explicaremos a la hora de ver cómo se hace el seguimiento y control del proyecto.

Cada espacio correspondiente a un proyecto tiene un enlace con un espacio "padre" que se configurará dependiendo del área centralizada o nodo provincial que gestione el proyecto.

Ejecución del proyecto

Sea cual sea el estado del proyecto, se podrán crear tareas del mismo que serán asignadas o bien a uno de los miembros del área centralizada/nodo provincial que gestiona el proyecto o bien a uno de los usuarios terceros  que se hayan incluido como usuarios del proyecto. Si el proveedor o proveedores del proyecto no tienen usuario, la ejecución y gestión de sus tareas deberá asumirlas un integrante del área centralizad/nodo provincial.

Cualquier tarea (excepto las tareas de soporte provincial) puede ser dividida en subtareas con el mismo ciclo de vida que las tareas de las que se originan. Tanto en tareas como en subtareas pueden ir registrándose trabajo, de manera que si para cada una de ella se tiene una estimación de trabajo, puede controlarse la evolución de lo estimado frente a lo incurrido.

Existe la posibilidad de que se gestionen tareas que el proveedor ejecuta normalmente en una entidad de otro tipo de proyecto (de aplicación, de plataforma). Por ejemplo,  un proyecto del área de Sistemas en el que una tarea es la construcción de una plataforma. En estos casos, la tarea podrá enlazarse con la entidad en la que el proveedor hace el trabajo mediante un tipo de enlace especial, 

• Desde la entidad del proyecto a una entidad de proyectos de tipo aplicación, plataforma o soporte provincial: "Se desarrolla en"
• Desde la tarea del proyecto de aplicación,  plataforma o soporte provincial a la entidad del proyecto: "Se gestiona en". 

Tipos de tareas del proyecto

Los proyectos de un área centralizada o nodo provincial se gestionan en base a tareas que, como hemos comentado anteriormente, pueden ser creadas y ejecutadas por integrantes del equipo del área/nodo o bien por el o los proveedores que se hayan definido para el proyecto concreto. Hay cuatro tipo de tareas:

• Tarea general

En este tipo de tareas puede especificarse:

• • Qué se quiere hacer
  • Quién debe hacerlo
  • Fechas orientativas de comienzo y fin de la tarea
  • Área TIC por si no coincide con la del proyecto
  • Centros de gestión, por si no coinciden con los del proyecto
  • Esfuerzo requerido
  • Fecha de compromiso de la tarea
  • Con quién está comprometida
  • Si es o no prioritaria para la Subdirección
  • Posibles solicitudes de NWT con las que la tarea pudiera estar relacionada

Una vez creada y asignada a su responsable, éste la ejecutará y resolverá, pudiendo solicitar información al creador de la tarea. Existe la posibilidad de que en cualquier momento la tarea quede bloqueada, reanudándose una vez se haya resuelto el motivo que la bloqueó.

Mientras la tarea esté resolviéndose, su responsable podrá registrar trabajo en ella. El responsable del proyecto determinará "las unidades" del trabajo que se realiza, horas, HBS, etc.

...

En cualquier estado será posible descomponer una tarea en subtareas a las que se podrá poner fechas orientativas y hacer una estimación del esfuerzo. Al igual que en las tareas, podrá registrarse trabajo mientras estén resolviéndose. 

Una tarea no podrá darse por resuelta mientras no lo están todas sus subtareas.

• Tarea con validación

Los campos en la creación son exactamente iguales que en la tarea general. En cuanto al flujo, la única diferencia es que una vez que se resuelve la tarea, el usuario que la resuelve decidirá quién debe validar si la resolución de la misma es o no correcta. En el caso de que lo sea, la tarea se cerrará. Si por el contrario la resolución no es correcta, volverá a estar en resolución para que su asignado la corrija.

...

Además, existen páginas dentro de esa sección para las lecciones aprendidas, los resúmenes ejecutivos y las actas del proyecto. Cabe mencionar los aparatados de Sistemas e Infraestructura y de Gestión del proyecto que contienen páginas donde debe incluirse la información oportuna del proyecto

Sistemas e infraestructura

• 00.- Instalación y Configuración
• 01.- Documentación Infraestructura
• 02.- Usuarios Administradores
• 03.- Seguridad: VPN, Firewall, Antivirus y Sonda
• 04.- Sistema de Respaldo y Monitorización
• 05.- Redes y Comunicaciones
• 06.- Contactos y Soporte
• 10.- Correos y Notas

Gestión del proyecto

• 00.- Check list de Gestión Proyecto
• 01.- Informe Seguridad USTIC
• 02.- Integración
• 03.- Manuales instalación y usuario
• 04.- Plan de Contingencias
• 05.- Correos

Puesta en marcha del proyecto

El Responsable del proyecto tendrá que hacer las labores propias de puesta en marcha del proyecto:

• Establecer estructura para el proyecto/espacio:

Es importante saber cómo van a clasificarse  las tareas:

• • Mediante componentes: bloques temáticos o funcionales en los que puede descomponerse el proyecto. Deben ser definido y creados por el Responsable de proyecto, de manera que cada tarea debe pertenecer a uno o a n bloques. Las posibles subtareas de esa tarea heredarán por defecto los de la padre, auqnue pueden cambiarse.
  • Mediante etiquetas: las etiquetas, si bien son útiles y fáciles de manejar, son comunes a todo el sistema. Es buena práctica establecer las etiquetas que van a usarse en el proyecto por todos los participantes en el mismo.
  • Mediante tipos de tareas: lo mismo que las tareas de soporte provincial tienen establecisos tipos y subtipos de tareas en base a la naturaleza de las mismaa, pueden establecerse tipos de tareas para cada proyecto. Por ejemplo, en el caso de los proyectos de áreas centralizadas, todos los proyectos tiene tareas/subtareas generales y con validación de tipo hito, riesgo, problema o decisión.
  • Establecer temáticas grandes en el proyecto que conllevarán tareas. Estas temáticas deberán ser definidas como épicas.
• Hacer el primer resumen ejecutivo para explicar porqué la necesidad de acometer el proyecto:
  • Business case preliminar que lo origina
  • Alcance
  • Recursos necesarios
  • Motivos por los que e acomete el proyecto
  • Valor que aportará a la STIC
  • Plazo de ejecución estimado.

Ejecución del proyecto

Una vez que se pone en marcha el proyecto, se comenzarán a crear tareas que irán asociadas con páginas en ele spacio correspondiente. Hya que tener en cuenta que si el proveedor de un determinado proyecto no va a entrar en la herramienta, las tareas deberán estar asignadas a algún integrante del proyecto que se encargue de actualizarlas.

Cualquier tarea puede ser dividida en subtareas con el mismo ciclo de vida o no que las tareas de las que se originan. Tanto en tareas como en subtareas pueden ir registrándose trabajo, de manera que si para cada una de ella se tiene una estimación de trabajo, puede controlarse la evolución de lo estimado frente a lo incurrido.

Existe la posibilidad de que se gestionen tareas que el proveedor ejecuta normalmente en una entidad de otro tipo de proyecto (de aplicación, de plataforma). Por ejemplo,  un proyecto del área de Sistemas en el que una tarea es la construcción de una plataforma. En estos casos, la tarea podrá enlazarse con la entidad en la que el proveedor hace el trabajo mediante un tipo de enlace especial, 

• Desde la entidad del proyecto a una entidad de proyectos de tipo aplicación, plataforma o soporte provincial: "Se desarrolla en"
• Desde la tarea del proyecto de aplicación,  plataforma o soporte provincial a la entidad del proyecto: "Se gestiona en". 

Es importante establecer enlaces entre las diferentes tareas del proyecto, Caben destacar:

• Enlace de bloqueo, lo que impedirá que la tarea bloqueada camie de estado hasrta que no finalice la bloquente.
• Enlace de dependencia. Tiene dos ventajas:
  • Todas las tareas dependientes de una se informan en el campo Dependencias.
  • Cuiando acaba una tarea dependiente, aparece un mensaje de alerrta indicando que es posible tener que actualizar la original.

Tipos de tareas del proyecto

Los proyectos de un área centralizada o nodo provincial se gestionan en base a tareas que, como hemos comentado anteriormente, pueden ser creadas y ejecutadas por integrantes del equipo del área/nodo o bien por el o los proveedores que se hayan definido para el proyecto concreto. Hay cuatro tipo de tareas:

• Tarea general

En este tipo de tareas puede especificarse:

• • Qué se quiere hacer
  • Quién debe hacerlo
  • Fechas orientativas de comienzo y fin de la tarea
  • Área TIC por si no coincide con la del proyecto
  • Centros de gestión, por si no coinciden con los del proyecto
  • Esfuerzo requerido
  • Fecha de compromiso de la tarea
  • Con quién está comprometida
  • Si es o no prioritaria para la Subdirección
  • Posibles solicitudes de NWT con las que la tarea pudiera estar relacionada

Una vez creada y asignada a su responsable, éste la ejecutará y resolverá, pudiendo solicitar información al creador de la tarea. Existe la posibilidad de que en cualquier momento la tarea quede bloqueada, reanudándose una vez se haya resuelto el motivo que la bloqueó.

Mientras la tarea esté resolviéndose, su responsable podrá registrar trabajo en ella. El responsable del proyecto determinará "las unidades" del trabajo que se realiza, horas, HBS, etc.

En cualquier estado será posible descomponer una tarea en subtareas a las que se podrá poner fechas orientativas y hacer una estimación del esfuerzo. Al igual que en las tareas, podrá registrarse trabajo mientras estén resolviéndose. 

Una tarea no podrá darse por resuelta mientras no lo están todas sus subtareas.

• Tarea con validación

Los campos en la creación son exactamente iguales que en la tarea general. En cuanto al flujo, la única diferencia es que una vez que se resuelve la tarea, el usuario que la resuelve decidirá quién debe validar si la resolución de la misma es o no correcta. En el caso de que lo sea, la tarea se cerrará. Si por el contrario la resolución no es correcta, volverá a estar en resolución para que su asignado la corrija.

...

• Tarea MCMI

son tareas específicas del modelo corporativo del marco de implantaciones (marco normativo para la ejecución de cualquier proceso de implantación en el ámbito del SAS, independientemente del producto implantado). Si quieres conocer el MCMI, pincha aquí.
En este tipo de tareas debe especificarse 

• • Qué se quiere hacer
  • Quién debe hacerlo
  • Fechas orientativas de comienzo y fin de la tarea
  • Área TIC por si no coincide con la del proyecto
  • Centros de gestión, por si no coinciden con los del proyecto
  • Esfuerzo requerido
  • Fecha de compromiso de la tarea
  • Con quién está comprometida
  • Si es o no prioritaria para la Subdirección
  • Posibles solicitudes de NWT con las que la tarea pudiera estar relacionada
  • Fase MCMI:  son las fases que cubren todo el ciclo de vida de la implantación. Es un desplegable con los valores:
    • APS: Fase de obtención de información sobre la situación de partida
    • RP:  Reingeniería de procesos
    • PRE: Preimplantación
    • IMP: Implantación
    • ARR: Arranque
    • CON: Consolidación
    • EXT: Extensión
    • PN3: Transferencia del soporte a los proveedores del servicio N3

Image Removed

• • Área MCMI: son las áreas de conocimiento en las que se categorizan las actividades de una determinada fase de la implantación. Es un desplegable con los valores
    • FUNC: Área de conocimiento Funcional
    • FORM: Área de conocimiento de Formación
    • MIGR: Área de conocimiento de Migración
    • INTE: Área de conocimiento de Integración
    • SIST: Área de conocimiento de Sistemas e Infraestructura
    • AYED: Área de Análisis y Explotación de Datos
    • GEST: Área de Gestión

Image Removed

Una vez creada y asignada a su responsable, éste la ejecutará y resolverá, pudiendo solicitar información al creador de la tarea. Existe la posibilidad de que en cualquier momento la tarea quede bloqueada, reanudándose una vez se haya resuelto el motivo que la bloqueó.

Mientras la tarea esté resolviéndose, su responsable podrá registrar trabajo en ella. El responsable del proyecto determinará "las unidades" del trabajo que se realiza, horas, HBS, etc.

En cualquier estado será posible descomponer una tarea en subtareas a las que se podrá poner fechas orientativas y hacer una estimación del esfuerzo. Al igual que en las tareas, podrá registrarse trabajo mientras estén resolviéndose. 

Una tarea no podrá darse por resuelta mientras no lo están todas sus subtareas.

• Historia de usuario

son tareas destinadas a desglosar requisitos de proyectos de desarrollo cuando la gestión de los mismo se hace con metodología ágil. La información que debe especificarse en este tipo de tareas es:

...