Reyes Sánchez García/ abril 28, 2021/ Metodología y ágil/ 0 comentarios

Tiempo de lectura: 9 minutos

Es muy recomendable realizar el Estudio de Viabilidad del Sistema en Métrica V3 antes de comenzar a desarrollar la solución a nuestro problema. Para ello en Métrica V3 se recomienda analizar el estado inicial, los requisitos planteados y la solución actual para plantear varias opciones de solución. En cada uno de las soluciones se valorará el impacto que tendrá en la organización y los riegos asociados. Además, pero no menos importante se tendrá en cuenta la inversión a realizar en cada caso.

En conclusión, para saber cuál es la solución más adecuada a nuestras necesidades es necesario realizar unas cuantas actividades de estudio. A continuación revisaremos la propuesta de Métrica V3.

Índice de contenidos

Estudio de viabilidad del sistema de información
EVS 0 0

Establecimiento del alcance del sistema

En un primer momento se aconseja describir la situación inicial que ha planteado el usuario y analizar las posibles restricciones existentes basándonos en cuatro puntos:

económico

técnico

operativo

legal

Continuaremos estableciendo los objetivos generales del EVS con respecto a los puntos anteriores. El siguiente paso será, iniciar el estudio de los requisitos. Sin embargo, no será necesaria esta tarea si el objetivo está alineado con el del Plan de Sistema de información vigente. En este caso partimos del catálogo de requisitos y la arquitectura de información que se ha confeccionado en el PSI.

En tercer lugar, registraremos en el catálogo de requisitos, las posibles restricciones relativas a la paralelización con otros proyectos que puedan interferir. Tanto en planificación y lanzamiento. Para ello realizamos un análisis minucioso. Después de eso, si partimos de un Plan de Sistemas de Información revisaremos la arquitectura de la información propuesta. Para conocer el alcance del sistema, identificaremos los sistemas que quedan fuera de este estudio y determinamos las dependencias con otros proyectos. En último lugar, deben quedar identificadas las unidades organizativas (estructura y responsables).

Especificación del Alcance en la Viabilidad del Sistema en Métrica V3

Para conocer la Viabilidad del Sistema en Métrica V3 es necesario determinar las actividades y tareas a realizar, en función de los objetivos del EVS y el alcance del mismo. En primer lugar, se decidirá si se realiza o no el estudio de situación inicial. Posteriormente, se identifican los usuarios que van a participar en las unidades participativas (las afectadas por este EVS) y se determina cuál será el perfil y responsabilidad de cada uno. Sobre todo, no podemos olvidar comunicar el plan de trabajo a esos usuarios, donde se solicite su aceptación  y confirmación de participación.

Productos obtenidos

  • Descripción General del Sistema
    • Contexto del Sistema
    • Estructura organizativa
  • Catálogo de Objetivos de EVS:
    • Objetivos del Estudio de la Situación Actual
  • El Catálogo de Requisitos
    • Requisitos Relativos a Restricciones o Dependencias con Otros Proyectos
  • Catálogo de Usuarios
  • Plan de trabajo
EVS 0 0

Estudio de la situación actual para conocer la Viabilidad del Sistema en Métrica V3

Valoración e identificación de usuarios

Se debe realizar una valoración del estudio de situación inicial, y para ello partiremos de los objetivos establecidos y del contexto del sistema. Para hacer el análisis, se deben identificar los sistemas de información existentes y el nivel de detalle con el que se analizará para conocer el alcance del sistema. 

Si disponemos de Plan de Sistema, será nuestro punto de partida para el análisis de la arquitectura. En caso contrario o si la información no es fiable, se valorará si es necesario realizar los modelos lógicos y físicos del sistema afectado. Debes tener en cuenta que hay situaciones en las que el tiempo de vida de del SI o la circunstancia de una próxima obsolescencia de la tecnología utilizada desaconsejarían dedicar tiempo a esta tarea.

Después de eso, realizaremos sesiones de trabajo con Directores de Usuario y apoyo de profesionales que permitan recopilar la información relativa a los sistemas de información

Y en último lugar, se identificarán nuevamente los usuarios que participen en las unidades organizativas afectadas. De igual modo deben ser informados, y solicitar y recibir su aceptación en la participación.

Descripción del SI y Realización del Diagnostico

Primeramente, se llevan a cabo sesiones de trabajo con los usuarios seleccionados para realizar la descripción de los sistemas. Se parte, nuevamente, del nivel de detalles y el alcance establecidos anteriormente. En función de la información de la que partamos, si tenemos o no los conocimientos para la creación de los modelos lógicos y optaremos por una vía u otra. En segundo lugar, si tenemos la información, aplicaremos técnica de modelización con método descendente. En caso contrario, lo haremos de forma ascendente: se construyen los modelos lógicos a partir del modelo físico. 

Si es necesario describir el modelo físico, es recomendable hacer un Diagrama de Representación. En este se debe incluir:  los componentes físicos y las referencias cruzadas. Del mismo modo también es recomendable incluir la localización física y geográfica tanto de datos como módulos.

La última tarea de este bloque será analizar la información de los SI e identificar los siguientes puntos para  volcar la información en los requisitos:

problemas

deficiencias

mejoras

Si ya arrancamos con un Plan de sistema tomaremos como referenica esa valoración y si se tomó la decisión de no describir la situación actual, se debe presentar un diagnóstico global que pueda justificar la decisión tomada.

Productos obtenidos

  • Descripción de la Situación Actual:
    • Contexto del Sistema Actual
    • Descripción de los Sistemas de Información Actuales
    • La Descripción Lógica del Sistema Actual (opcional)
    • Modelos Físico del Sistema Actual (opcional)
    • Matriz de Localización Geográfica y Física de Módulos y Datos, incluidas las redundancias
    • Diagnóstico de Situación Actual
  • Catálogo de Usuarios
EVS 0 0

Definición de requisitos del sistema en Viabilidad del Sistema en Métrica V3

En un primer momento es necesario hacer una identificación de las directrices técnicas y de gestión. Gracias a ello podremos considerar los términos de referencia para el SI. Cuando partamos del Plan de Sistema de Información, ya dispondremos de ese marco como referencia. En caso contrario, se recogerá la información de procedimientos y estándares: políticas técnicas: Gestión de proyectos, desarrollo de sistemas y arquitectura del sistema. Además, se debe identificar la política de seguridad, y las directrices de planificación, gestión de cambios y gestión de calidad.

Identificación y catalogación de requisitos

En este párrafo se va a describir un punto muy importante: realizar las tareas de identificación y catalogación de los requisitos. Comenzaremos con la extracción de las necesidades a cubrir. Por tanto, será necesario realizar y planificar sesiones de trabajo con los usuarios seleccionados previamente. Si disponemos del Estudio de la situación Actual (EVS 2), partiremos de este documento para seleccionar la información relevante.

A posteriori se analizará esta información obteniendo un catálogo de requisitos donde podremos encontrar tanto requisitos funcionales, como no funcionales, como los relativos a la distribución geográfica y el entorno tecnológico. Se prestará especial atención a la catalogación, priorización y definición.

Productos obtenidos

  • Catálogo de Normas
  • Identificación de Requisitos
  • Catálogo de Requisitos
EVS 0 0

Estudio de alternativas de solución para saber la Viabilidad del Sistema en Métrica V3

Comenzaremos por analizar los requisitos para configurar las distintas opciones de solución. Si disponemos del Estudio de situación Actual, lo tomaremos como base también. Una vez planteadas las posibles soluciones, seguramente estarán categorizadas dentro de estas tres opciones:

productos estándar del mercado

desarrollos a medida

soluciones mixtas

Debes tener en cuenta que quizás sea necesario realizar una descomposición en subsistemas. Sobre todo cuanto nos encontramos con sistemas donde el alcance es muy amplio.

Descripción de las alternativas

En un primer momento,  se deben identificar los subsistemas y requisitos para una de las alternativas propuesta. Para realizar una buena descripción debes tener en cuenta la cobertura geográfica de  procesos y la gestión de comunicaciones y el control de red. Además, no puedes olvidar proponer la estrategia de implantación (cobertura global y geográfica).

En función del tipo de alternativa, tendríamos que preparar una documentación u otra. En ambos casos determinaremos el entorno tecnológico.

Para los desarrollos a medida, tendríamos que crear el modelo abstracto de datos y el modelo de procesos. Adicionalmente, si trabajamos con orientación a objetos es necesario la preparación del modelo de dominio y el modelo de negocio. En cambio, si nuestra opción está basada en un producto es necesario tener en cuenta su evolución, portabilidad, adaptabilidad y costes por licencias y estándares.

Productos obtenidos

  • Descomposición Inicial del Sistema en Subsistemas (opcional)
  • Alternativas de Solución a Estudiar
  • Catálogo de Requisitos (Actualizado)
  • Alternativas de Solución a Estudiar:
    • Catálogo de Requisitos (cobertura)
    • Modelo de Descomposición en Subsistemas
    • Matriz Procesos / Localización Geográfica
    • La Matriz Datos / Localización Geográfica
    • Entorno Tecnológico Y Comunicaciones
    • Estrategia de Implantación Global de Sistema
    • Descripción de Procesos Manuales
Si la alternativa incluye desarrollo:
  • Modelo Abstracto de Datos / Modelo de Procesos
  • El Modelo de Negocio / Modelo de Dominio (en caso de Orientación a Objetos)
Si la alternativa incluye un producto software estándar de mercado: Añadido: Orientación a objetos
  • Descripción del Producto
  • Evolución del Producto
  • Costes Ocasionados por Producto
  • Estándares del Producto
  • Descripción de Adaptación (si es necesaria)
EVS 0 0

Valoración de las alternativas

Para hacer una valoración de las alternativas se deben tener tres puntos en cuenta: analizar la inversión, analizar el riesgo y hacer una planificación que conviva con el resto de los proyectos existentes en la organización. 

Iniciaremos la actividad realizando un análisis del coste/beneficio del sistema. Determinaremos el coste  ponderando tanto beneficio tangible como intangibles. En otras palabras, estableceremos la viabilidad económica de cada alternativa. Continuaremos con una identificación y valoración de los riesgos. Esto consiste en hacer una selección de los factores de situaciones a tener en cuenta. Por ejemplo, debido a una alta complejidad o por la incertidumbre que tiene asociada.

Planificación en la Viabilidad del Sistema en Métrica V3

En último lugar se debe realizar una planificación para cada alternativa. El objetivo de esta tarea es poder garantizar el cumplimiento de plan de trabajo. Para ello se debe definir el enfoque más adecuado a cada opción, sincronizando este con el resto de proyecto o eventos que pudiera tener en curso la organización.

Productos obtenidos

  • Valoración de Alternativas:
    • Impacto en la Organización de Alternativas
    • Coste / beneficio de Alternativas
    • Valoración de Riesgo
  • Plan de Trabajo de Cada Alternativa:
    • Enfoque del Plan de Trabajo de Cada Alternativa
    • Planificación de Cada Alternativa
EVS 0 0

Selección de la solución

La última actividad del Estudio de Viabilidad del Sistema en Métrica V3 es seleccionar la solución. Para ello se envía al Comité de Dirección todas las alternativas propuestas (adjuntando toda la documentación) para que este pueda analizar la situación y de una preselección. Además, confirmará la fecha de presentación.

En la presentación se debatirán las alternativas con el comité, exponiendo las ventajas e inconvenientes y realizando las modificaciones necesarias que solicite la dirección. 

Finalmente se seleccionará la solución final y se dará su aprobación formal o se descartará debido a alguna inviabilidad por alguno o varios de los siguientes motivos.

económicos

incumplimiento de los requisitos en plazos razonables

incumplimiento de cobertura de requisitos

Productos obtenidos

  • Plan de Presentación de Alternativas
  • Solución Propuesta:
    • Descripción de la solución
      • Modelo de Descomposición en Subsistemas
      • La Matriz Procesos / Localización Geográfica
      • Matriz Datos / Localización Geográfica
      • Entorno Tecnológico y Comunicaciones
      • Estrategia de Implantación Global del Sistema
      • Descripción de Procesos Manuales
      Si la alternativa incluye desarrollo:
      • Modelo Abstracto de Datos / Modelo de Procesos
      • El Modelo de Negocio / Modelo de Dominio
      Si la alternativa incluye un producto software estándar de mercado:
      • Descripción del Producto
      • Evolución del Producto
      • Costes Ocasionados por Producto
      • Estándares del Producto
      • Descripción de Adaptación (si es necesaria)
      • Contexto del Sistema (con la Definición de las Interfaces en Función de la Solución)
      • Impacto en la Organización de la Solución
      • Coste / Beneficio de la Solución
      • Valoración de Riesgos de la Solución
      • Enfoque del Plan de Trabajo de la Solución
      • Planificación de la Solución
  • Aprobación de la solución

Conclusión: Es imprescindible realizar el Estudio de Viabilidad del Sistema en Métrica V3

Si realizas el Estudio de Viabilidad del Sistema podrás encontrar la mejor solución para la nueva necesidad de tu sistema o por lo menos, descartar las opciones si no son aconsejables para tu organización. Realizando cada una de las actividades que se recomienda en Métrica V3 te aseguras un procedimiento minucioso que te aportará mucha información de las alternativas de solución.

Si te ha gustado la entrada de blog, o si te tienes alguna información a añadir deja un comentario. Y si te ha resultado interesante la entrada, puedes suscribirte al boletín del blog y recibirás en tu correo las novedades.

Referencias

Para cualquier duda, puedes consultar la fuente original en la documentación incluida en la PAE. Esta metodología fue desarrollada en 2001 por el Ministerio de Hacienda y Función Pública y promovido por Consejo Superior de la informática.

Quizás te puede interesar

 
Compartir esta entrada

Dejar un Comentar

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*
*