1437279867

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

METODOLOGÍA para DESARROLLO de SISTEMAS de INFORMACIÓN

Gestión de Proyectos

Teoría.doc

23/03/2011

1

ÍNDICE OBJETIVO .................................................................................................................................... 4 ALCANCE ..................................................................................................................................... 4 LA EVOLUCIÓN DEL SOFTWARE ............................................................................................. 4 UNA PERSPECTIVA INDUSTRIAL ............................................................................................. 5 OBREROS DE LA FÁBRICA DE SOFTWARE. .......................................................................... 6 EL SOFTWARE ............................................................................................................................ 6 CARACTERÍSTICAS DEL SOFTWARE ...................................................................................... 6 ORGANIZACIÓN DEL EQUIPO DEL PROYECTO ................................................................... 10 ROLES DEL INGENIERO DEL SOFTWARE ............................................................................. 11 EQUIPO DE PROYECTO ........................................................................................................... 11 RESPONSABILIDADES ............................................................................................................. 12 INGENIERÍA DEL SOFTWARE .................................................................................................. 19 MODELOS DE PROCESO DEL SOFTWARE ........................................................................... 20 PRODUCTO Y PROCESO ......................................................................................................... 23 DIAGRAMA RESUMEN .............................................................................................................. 24 DIAGRAMA DE FASES .............................................................................................................. 25 DIAGRAMA DE ETAPAS, TAREAS Y ENTREGABLES POR FASE ....................................... 27 IMPLANTACIÓN Y CIERRE DEL PROYECTO ......................................................................... 35 DESCRIPCIÓN DE LAS FASES ............................................................................................. 38 FASE: ESTUDIO PRELIMINAR .............................................................................................. 39 FASE: ESTUDIO FACTIBILIDAD ........................................................................................... 40 FASE: DESCRIPCIÓN DE NECESIDADES ........................................................................... 46 DESCRIPCIÓN DE FASES ........................................................................................................ 47 FASE: DESCRIPCIÓN DE NECESIDADES .......................... ¡ERROR! M ARCADOR NO DEFINIDO. FASE: DISEÑO GLOBAL ....................................................................................................... 55 FASE: PROCESO DE COMPRAS ......................................... ¡ERROR! M ARCADOR NO DEFINIDO. FASE: DISEÑO DETALLADO ................................................................................................ 60 FASE: DISEÑO DETALLADO ................................................................................................ 61 FASE: CONSTRUCCIÓN ........................................................................................................ 74 FASE: CONSTRUCCIÓN ........................................................................................................ 75

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

FASE: PRODUCCIÓN ............................................................................................................. 91 FASE: BALANCE DEL PROYECTO....................................................................................... 95

CARPETA DE PROYECTOS ..................................................................................................... 97 FASE: DESCRIPCIÓN DE NECESIDADES ............................................................................................................. 97 FASE: ESTUDIO DE FACTIBILIDAD ..................................................................................................................... 101 FASE: DISEÑO GLOBAL ...................................................................................................................................... 108 FASE: DISEÑO DETALLADO................................................................................................................................ 115 FASE: CONSTRUCCIÓN ....................................................................................................................................... 136 FASE: IMPLANTACIÓN......................................................................................................................................... 148 FASE: PRODUCCIÓN............................................................................................................................................ 151 FASE: BALANCE DEL PROYECTO ...................................................................................................................... 152

ANEXO: MODELO DE PLAN DE PROYECTO ....................................................................... 153 ACUERDO DE SERVICIO DE PROYECTO ............................................................................................................ 156 CONTRATO DE SERVICIO DE PRODUCCIÓN ..................................................................................................... 162 MODELO ÚNICO DE CONTRATO DE SERVICIO .................................................................................................. 168

GLOSARIO ............................................................................................................................... 179

3 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

OBJETIVO Y ALCANCE OBJETIVO El objetivo de esta publicación es generar una guía para la gestión de proyectos informáticos basados en el desarrollo de software y brindar un enfoque práctico para establecer los lineamientos generales, el marco metodológico y los responsables en la gestión de un proyecto a lo largo de todo el ciclo de vida del mismo.. Pretende servir a estudiantes y profesionales, brindando una introducción completa al tema de la ingeniería de software. El formato y estilo de esta primera edición está orientada tanto a los aspectos teóricos, como a los prácticos; ya que se incluye fichas y documentos que se utilizan en los proyectos de desarrollo de software.

ALCANCE El alcance de esta guía abarca los aspectos metodológicos involucrados desde la identificación de necesidades y la consecuente creación del proyecto hasta la puesta en producción del software, incluyendo su administración y soporte.

LA EVOLUCIÓN DEL SOFTWARE Roger S. Pressman, dice en su obra que el Software es a la vez un producto y el vehículo de entrega de un producto. Como producto puede residir en un teléfono celular inteligente o una computadora central donde produce, transforma, adquiere, modifica muestra y transmite información tan compleja como un bit o una presentación multimedia. Como vehículo para hacer entrega del producto actúa como la base de control de una PC (Sistema Operativo), la comunicación de información (Redes) y creación y control de otros programas (Entornos y herramientas de programación). A lo largo de mi carrera he leído en no poca bibliografía que la programación es “un arte”, y quizás en algún modo lo sea, pero este “arte” no tiene nada de intuitivo ya que se basa en teorías sólidas y metodologías probadas y adoptadas por la industria del software; de acuerdo a las necesidades / motivaciones de las empresas que consume este “arte” (el software). Es por ello que quienes estamos en el área de la enseñanza, debemos orientar y ayudar a quienes quieren ser expertos en esta profesión fascinante a contextualizar el concepto de “arte”. Esta publicación pretende que los alumnos comprendan, dominen y fundamentalmente apliquen técnicas y herramientas para crear desarrollos sólidos y perdurables con base en una documentación orientada a la calidad, ya que es esto lo que las empresas requieren y necesitan del software. En lo que a mí respecta (y desde ya pido disculpas a quienes opinen diferente) el software antes que creativo debe ser eficiente y eficaz, es decir cumplir con las necesidades de los usuarios y que permita ser construido y mantenido con el mínimo costo y esfuerzo posible. El software ha sufrido una serie de cambios importantes desde los años 50 del siglo pasado de la mano de avances tecnológicos impresionantes. En el comienzo de la era informática el desarrollo de software se realizaba prácticamente sin planificación y con un esfuerzo enorme, el hardware era de propósito general y el software se diseñaba a medida; la falta de documentación en los antiguos sistemas los hacía poco menos que inentendibles para quienes no habían participado en su diseño y desarrollo.

4 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

Con el advenimiento de facilidades como la multiprogramación y los sistemas multiusuario se abrió un nuevo mundo de aplicaciones, lo que generó una mayor sofisticación del hardware y software. Luego aparecieron los sistemas de tiempo real y la primera generación de sistemas de gestión de bases de datos. El software a partir de allí se estableció como producto y tuvo una amplia distribución. Los aspectos de depuración comenzó a tener relevancia ya que la mayor complejidad y diversidad en los sistemas provocaron la aparición de fallas y como consecuencia de esto nació el mantenimiento. Mayor complejidad, demanda, fallas y necesidades especificas, dio lugar al software personalizado. El mantenimiento de este software dio lugar a una crisis en la construcción del software. Luego los sistemas de tiempo real y la primera generación de sistemas de gestión de bases de datos aparecieron los sistemas distribuidos y las redes de área local y global que provocaron una importante presión sobre los desarrolladores de software. La aparición del microprocesador (ejemplo la familia PIC) produjo muchos productos “inteligentes” (partes de automóviles, robots, artefactos del hogar, etc.) y la aparición de la computadora personal con su formidable y rápido acceso para él público masivo impactó fuertemente en el desarrollo del software. Hace ya mucho tiempo se supero el concepto de las computadoras individuales y se oriento al uso colectivo de computadoras y software. Los entornos centralizados pasaron a ser cliente/servidor, la aparición de Internet facilitó la aparición de las tecnologías orientadas a objetos, los sistemas expertos y el software de inteligencia artificial. Como seguramente el lector podrá percibir en la muy apretada síntesis hasta aquí desarrollada, los problemas relacionados con el software han persistido a lo largo de la evolución de los sistemas informáticos y lastimosamente continúan aumentando. Los motivos del aumento en la problemática del desarrollo del software tiene múltiple aristas. 1. Las empresas requieren un software que explote más y mejor el hardware (que día a día es más sofisticado y especifico) 2. Los desarrolladores se ven expuestos a esta “carrera” (en términos de adquirir habilidades) para satisfacer la demanda de este nuevo software. 3. Las empresas y aún los individuos comunes se han hecho dependientes al software. (imaginen no más lo que significa el uso de los productos como Cajeros automáticos, Pagos de servicios, Compras vía internet, o Webs Banking si fallaran) 4. La comunidad de desarrolladores lucha por la construcción de un software confiable. 5. Lo anteriormente mencionado impacta en la habilidad de soportar el desarrollo con diseños pobres, documentación inadecuada y falta de recursos apropiados.

Una perspectiva industrial Al principio el software se utilizaba para gestionar el hardware que era el factor principal en el presupuesto del proyecto. Por tal motivo, se aplicaron controles, métodos y herramientas conocidas como ingeniería del hardware y el software no era más que un añadido. En relación con lo mencionado, es muy lógico que a la programación se la asociara a “un arte” ya que existía muy pocos métodos formales. Actualmente la construcción del software es en cuanto al costo de un proyecto el elemento mas importante. Cabe aquí cuestionar (en función de orientar al lector novel) ¿ Por qué se demora tanto tiempo en crear el software?, ¿ Por qué es tan oneroso?, ¿ Porque el software cuando se implementa no se encuentra libre de errores? (lo que aumenta el costo de mantenimiento de los sistemas).

5 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

Estas y otras muchas cuestiones han determinado la necesidad de pensar a la construcción del software a verlo más lejos del romántico arte y adoptar conceptos de una “ciencia dura” como la ingeniería del software.

Obreros de la fábrica de software. Los “obreros del bit”, nuestros queridos ingenieros del software deben poseer herramientas metodológicas basadas en teorías sólidas para lograr la creación y renovación de aplicaciones. El ingeniero del software debe tener métodos y herramientas para asegurar la calidad y el mantenimiento de los costos dentro de la razonabilidad que las empresas puedan destinar de su presupuesto para obtener un software que sea sustentable. Las aplicaciones que utilizan datos críticos de la organización debe tener una consideración particular por parte del ingeniero de sistema (y por ende técnicas y herramientas específicas) a fin de resguardar lo más precioso que tiene una empresa (sus datos y el software que contiene las reglas de su negocio). Un aspecto sobre el cual los ingenieros del software deben tener especial atención es la criticidad en cuanto al uso de los sistemas en una empresa. La salida de servicio de sistemas sensibles de una organización implica la pérdida de enormes sumas de dinero. En este aspecto los ingenieros del software deberán comprender y utilizar las recomendaciones de entes dedicados al aseguramiento de la calidad y productividad como las normas ISO e ITIL. Sin la intención de que lo expuesto sea toda las “preocupaciones” que los ingenieros deban atender (de hecho no se mencionó aspectos de seguridad y conectividad entre otros), es necesario que el lector comprenda la multiplicidad de aspectos que deberá resolver como “obrero del bit”; de allí la necesidad de apegarse a los métodos, el desarrollo de técnicas y el estricto uso de las herramientas de diseño y construcción de un software.

El software Hasta ahora, se ha mencionado al software como un sustantivo “mágico” de gran importancia y complejidad pero ¿que es exactamente el software y que significado le damos cuando hablamos de él? La definición estricta indica que el software es:  Instrucciones que cuando se ejecutan proporcionan la función y el rendimiento deseados.  Estructuras de datos que permiten a los programas manipular adecuadamente información  Documentos que describen la operación y uso de programas. Creo conveniente y estimo necesario considerar algo más que la mencionada definición formal y para ello exploraremos los siguientes aspectos.

Características del software Cuando el ingeniero del software construye un software mediante el proceso creativo (análisis, diseño, construcción, etc.) se traduce finalmente en una forma física. El software es un elemento del sistema que es lógico en lugar de físico por lo tanto: a) El software se desarrolla, no se fabrica. La fase de construcción del software depende de la completitud de la fase de descripción de las necesidades y cuando digo completitud me refiero a que no puede existir faltantes en cuanto a la funcionalidad pretendida como a la documentación detallada de cada función pretendida. Es necesario comprender el concepto “de lo general a lo particular” ya que el desarrollador NECESITA todos los detalles funcionales para proceder a la escritura del código y NO DEBE 6 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García “crear intuitivamente” la funcionalidad del sistema (en esto me baso en cuestionar el concepto de “arte”). Para asegurar el desarrollo del software, es necesario el apego irrestricto al uso de una metodología y utilización de sus herramientas. b) El software no se estropea. La falla en el software es consecuencia directa de los defectos en el análisis y diseño del mismo refiriéndonos a la funcionalidad que se espera que cumpla. No es menos importarte (es crucial) efectuar un buen diseño de las pruebas que será sometido el software para asegurar su funcionalidad antes de su puesta en producción. Como un componente vital que se incluye en el proceso de pruebas es diseñar un adecuado circuito para resolver las no conformidades que se detecten a fin de que estos se resuelvan. Es muy importante que el lector observe que los defectos no detectados del software, hacen que el mismo falle durante las primeras etapas de su vida, de allí la necesidad de una estrategia consistente para evitar la aparición de errores en la puesta en producción. Es muy obvio que el ingeniero del software pondrá especial atención a la corrección (sin introducir nuevos errores), para asegurar que estos no vuelven a aparecer. Lamentablemente el software en producción, se deteriora. ¿el motivo? El software esta sometido a las solicitudes de cambios por mantenimiento. Las solicitudes de cambio por mantenimiento puede ser por nuevas necesidades o correctivos a funciones existentes. La introducción de solicitudes de cambios puede generar nuevos defectos que antes de que desaparezcan se solicita un nuevo cambio que introduce nuevos errores y así sucesivamente; esto provoca que el mantenimiento del software tiene una complejidad que debe ser tenida muy en cuenta. c) Componentes del Software Cuando se diseña nuevo software se utilizan los llamados CI‟s,(ítems Componentes) estos componentes estándares pueden ser reutilizables y son creados por el ingeniero del software para utilizarlo en diferentes lugares de la aplicación. La reutilización de componentes (CI‟s), permite minimizar la tasa de errores (un componente siempre se comporta de igual modo) y redunda en una mayor productividad (generado una sola vez es utilizado en múltiples lugares). d) Aplicaciones del Software El software puede construirse siempre que se haya previamente definido un conjunto especifico de pasos procedimentales (algoritmo). Se debe tener en cuenta el contenido, es decir el significado y forma de la información de entrada y salida. Otro aspecto es el determinismo, predecibilidad del orden y del tiempo de llegada de los datos; los datos llegan en orden y se ejecuta un proceso. e) Software de gestión El procesamiento de información comercial es el área de mayor desarrollo de aplicaciones. Los sistemas (inventarios, producción, contables, facturación, RRHH, etc.) han evolucionado hacia el software de sistemas de información de gestión (conocidos como ERP) que accede a una o más bases de datos donde está contenida la información comercial para facilitar la toma de decisiones. f) Crisis en el desarrollo del software. La definición de crisis como el punto decisivo sobre los problemas que un ingeniero del software deberá afrontar en el desarrollo del software, no se limita al software que no funciona, si no que abarca los problemas asociados a como desarrollar software, como mantener el software existente y como afrontar la demanda creciente.

ESTRUCTURA DE LA GUÍA DE GESTIÓN

7 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

Con el propósito de generar una metodología que acompañe el esfuerzo del ingeniero del software en la creación de aplicaciones a continuación se presenta la estructura de la misma. Niveles de Desagregación Esta guía propone 3 niveles de desagregación, donde la entidad FASE es la que reviste mayor peso como entidad. Las etapas comprendidas en cada fase, se desarrollan en forma secuencial, mientras que las tareas de una misma, pueden ejecutarse en forma paralela. FASE ETAPA TAREA

Cada fase se define a través de: - etapas - hitos FASES I M P L A N T A C I O N

ETAPAS

PREPARACIÓN IMPLANTACIÓN

PUESTA EN PRODUCCIÓN

FORMALIZACIÓN PUESTA EN PRODUCCIÓN

HITO 5 : SISTEMA EN PRODUCCIÓN

Cada etapa se define a través de: - sus tareas, - entregables (los principales entregables de las tareas de una misma etapa) - el coordinador (la figura responsable de coordinar todas las tareas dentro de esta etapa) ETAPAS

PREPARACIÓN IMPLANTACIÓN

TAREAS

ENTREGABLES

- Ejecución de Confiabilización de Datos - Conversión de Datos - Aprobación de Conversión de Datos - Carga Inicial y Parametrización - Capacitación - Comunicación

- Aprobación Conversión Datos

Cada tarea se define a través de: - su descripción, - los inputs, - los outputs (o entregables) - los actores (lista de participantes de la tarea) y - el responsable (figura responsable de ejecutar esta tarea)

8 de 181

COORDINADOR

Líder Funcional

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

4.3.1.1 Descr i p ció n de Req uer im i en t o s Fu n ci on ales Elaboración del Documento de Especificaciones Funcionales, donde se describen y/o especifican en forma detallada las necesidades de los usuarios. Este documento incluirá la definición de los procesos a implementar. INPUT OUTPUT - Descripción de la - Especificación Necesidad Funcional - Procesos de Negocio

ACTORES - Líder funcional - Líder informática - Usuarios

RESPONSABLE - Líder funcional

Cada entregable se define a través de: - Nombre - Objetivo - Contenido - Responsable NOM BRE Descripción de la Necesidad OBJETIVO Describir el objetivo y alcance de la necesidad de un nuevo sistema o una modificación CONTENIDO Proyecto:............................................................................................... Responsable:.........................................Sector:...................................... Participantes:......................................................................................... -

Objetivo del Proyecto Alcance del Proyecto Breve Descripción Funcional Beneficios esperados / Motivación Procesos / Sub-procesos impactados Reemplaza sistema/s actual/es? A cuál/es? Fecha requerida de implantación Documentación asociada

RESPONSA BLE Líder Funcional

Hitos En la finalización de la mayoría de las fases, se desarrollan tareas de revisión, análisis, aprobación y/o convalidación de los principales entregables de las mismas. Estas tareas, por su relevancia, determinan en sí mismas el cierre de la fase. Luego del cierre de la fase y considerando el resultado global de la misma, se conforma una instancia de validación. Por lo tanto, cada hito se define a través de: - Tarea de cierre de la fase - Los inputs, - Los outputs (o entregables) - Los actores (lista de participantes) - El responsable (figura responsable del hito) - Check list A su vez, los hitos se pueden clasificar en: - Hitos de Go- No Go: Aquellos hitos donde se decide la continuación, interrupción y/o postergación de un proyecto - Hitos de Validación: Aquellos hitos donde se validan y se controla la realización de las tareas y de los entregables de una fase.

ORGANIZACIÓN DEL PROYECTO

9 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

CONCEPTOS SOBRE GESTIÓN DE PROYECTOS EL ESPECTRO DE LA GESTIÓN La gestión eficaz de un proyecto de software se centra en las tres „pes‟: personal, problema y proceso. Personal El modelo de Madurez de gestión de personal define las siguientes áreas prácticas clave para el personal que desarrolla soft:  Reclutamiento  Selección  Gestión de rendimiento  Entrenamiento  Retribución  Desarrollo de la carrera  Diseño de la organización y del trabajo  Desarrollo cultural y espíritu de equipo. Los participantes El proceso del software lo componen participantes que pueden clasificarse en una de cinco categorías: 1. Gestores superiores 2. Gestores (técnicos) del proyecto 3. Profesionales 4. Clientes 5. Usuarios finales Para ser eficaz, el equipo del proyecto debe organizarse de manera que maximice las habilidades y capacidades de cada persona. Éste es el trabajo del jefe del equipo. Los jefes del equipo Cuando seleccionamos a alguien para dirigir un proyecto de software se tienen en cuenta las siguientes habilidades, propuestas por el modelo MOI:  Motivación  Organización  Ideas e innovación Otro punto de vista de las características que definen a un gestor de proyecto eficiente resalta cuatro apartados clave:  Resolución del problema  Dotes de gestión  Incentivo de los logros  Influencia y construcción de espíritu de equipo El equipo de software La mejor estructura de equipo depende del estilo de gestión de una organización, el número de personas que compondrá el equipo, sus niveles de preparación y la dificultad general del problema. Se sugieren tres organigramas de equipo genéricos: Descentralizado democrático DD). No tiene un jefe permanente, se nombran coordinadores de tareas a corto plazo. La comunicación entre los miembros es horizontal. Descentralizado controlado (DC). Tiene un jefe definido que coordina tareas y jefes secundarios con responsabilidades sobre sub tareas. Comunicación entre subgrupos e individuos es horizontal. Vertical a lo largo de la jerarquía de control. Centralizado controlado (CC). El jefe del equipo se encarga de la resolución de problemas a alto nivel y la coordinación interna del equipo. La comunicación entre el jefe y los miembros es vertical.

10 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

Paradigmas de organización para equipos de ingeniería de software: Paradigma cerrado: estructura al equipo con una jerarquía tradicional de autoridad. Paradigma aleatorio: estructura al equipo libremente y depende de la iniciativa individual de los miembros del equipo. Paradigma abierto: estructura el equipo de manera que consiga algunos de los controles asociados con el paradigma cerrado. Paradigma sincronizado: se basa en la compartimentación natural de un problema y organiza los miembros del equipo para trabajar en partes del problema con poca comunicación activa entre ellos. Aspectos sobre la coordinación y la comunicación Hay muchos motivos por los que los proyectos de software pueden tener problemas: la escala (tamaño), la incertidumbre, la interoperatividad (comunicación soft nuevo con el anterior). Las técnicas de coordinación se categorizan de la siguiente manera:  Formal, enfoque impersonal: incluyen documentos, entregas memorandos técnicos, etc.  Formal, procedimientos interpersonales: actividades de garantía de calidad. Incluyen reuniones de revisión de estado e inspecciones de diseño y de código.  Informal, procedimientos interpersonales: incluyen reunioes de grupo para divulgación de información, resolución de problemas, definición de requisistos etc..  Comunicación electrónica: videoconferencia, correos electronicos.  Red interpersonal: discusiones informales con personas que no están en el proyecto pero que pueden tener experiencia.

ORGANIZACIÓN DEL EQUIPO DEL PROYECTO Los ingenieros del software están habilitados para cumplir cualquier rol en los equipos de implantación, producción o quality assurance (Aseguramiento de calidad). Es importante que el lector comprenda el alcance de los roles a fin de determinar los conocimientos que debe adquirir para desarrollar adecuadamente las tareas del rol.

ROLES DEL INGENIERO DEL SOFTWARE En esta sección se definen los roles que intervienen en un Equipo de Proyecto. Los mismos no se encuentran asociados a un sector o persona específica de la organización, sino que, en cambio, se definen de manera tal que, de acuerdo al tipo de proyecto, su envergadura y cantidad de entidades involucradas, una persona podrá adoptar más de un rol o por el contrario un rol podrá estar compuesto por más de una persona. Cabe destacar, que independientemente de los roles específicos, cada integrante del equipo del proyecto deberá garantizar el cumplimiento de las normas de la empresa.

EQUIPO DE PROYECTO El siguiente diagrama describe una propuesta genérica de la constitución del Equipo del Proyecto. Cabe señalar, que el Comité Director definirá la organización particular para cada proyecto, de acuerdo a la envergadura del mismo.

11 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

COM ITÉ DIRECTOR

RESPONSABLE FUNCIONAL

OWNER DEL PROYECTO

RESPONSABLE INFORM ÁTICO

COM ITÉ EJECUTIVO

Q U A L I T Y

A S S U R A N C E

LÍDER FUNCIONAL

EXPERTO EN PROCESOS DE NEGOCIO RESPONSABLE CAPACITACIÓN EXPERTO ECONÓM ICO/ FINA NCIERO

LÍDER INFORM ÁTICO

RESPONSABLE SOPORTE AL CAM BIO EXPERTO EN CALIDA D ADM INISTRA DOR FUNCIONAL

EXPERTO INFORM ÁTICO EXPERTO SEGURIDAD INFORM ÁTICA EXPERTO TECNOLÓGICO PROVEEDOR (INTERNO o EXTERNO)

EXPERTO EN REDES EQUIPO DE IM PLANTACIÓN

SOPORTE USUARIOS

SOPORTE FUNCIONAL

ADM INISTRA DOR FUNCIONAL

SOPORTE TÉCNICO

U S U A R I O S F I N A L E S

SOPORTE APLICATIVO

SOPORTE SEGURIDAD

EQUIPO DE PRODUCCIÓN

RESPONSABILIDADES COMITÉ DIRECTOR Integrado por los responsables ejecutivos de las áreas funcionales, informáticas y de calidad. Sus principales responsabilidades son: -

Monitorear el avance del Plan Director de Sistemas de Información Aprobar el lanzamiento de los Proyectos informáticos Identificar los aspectos estratégicos del Proyecto Garantizar consistencia entre los objetivos de la Organización y los objetivos de los Proyectos Monitorear el avance de los Proyectos Establecer prioridades y conciliación de conflictos de intereses entre áreas. Designar integrantes del Comité Ejecutivo.

El Comité Director podrá delegar sus responsabilidades de acuerdo a la envergadura del proyecto. COMITÉ EJECUTIVO Integrado por los roles Owner del Proyecto, Responsable Funcional, Responsable Informático y los Usuarios Finales. Sus principales responsabilidades son:

12 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

-

Participar de la planificación, administración y el control del Proyecto informático. Garantizar el compromiso de las áreas involucradas y la disponibilidad oportuna del personal clave requerido. Acordar expectativas, alcances, objetivos, esquemas de implantación y planes de trabajo al inicio del Proyecto. Asegurar que el Proyecto sea consistente con las pautas y alcances fijados. Determinar orientación a adoptar para llevar a cabo el Proyecto. Validar documentos y/o productos a obtener en cada fase. Definir responsabilidades de las entidades sobre el equipo de implantación en función de la naturaleza de cada Proyecto. Interactuar con el Comité Director y el equipo de implantación.

EQUIPO DE IMPLANTACIÓN Integrado por los roles Líder Funcional, Líder Informático, Responsable de Soporte al Cambio, Responsable de Capacitación, Experto tecnológico, Experto informático, Experto en Procesos de Negocio, Experto Económico/Financiero, Experto en Calidad, Experto en Seguridad Informática, Experto en Redes, Administrador Funcional y el Proveedor (Interno o Externo). Sus principales responsabilidades son: -

Generar y ejecutar el diseño global y detallado, los análisis técnicos y funcionales, los planes de trabajo y estrategias de implantación. Informar el avance del proyecto al Comité Ejecutivo. Implementar bajo la coordinación del Líder Informático, los elementos informáticos (hardware, software de base y de aplicación, redes, capacitación técnica). Poner en marcha los nuevos procedimientos definidos bajo la responsabilidad del Líder Funcional.

EQUIPO DE PRODUCCIÓN Integrado por los roles Administrador Funcional, Soporte Usuarios, Soporte Funcional, Soporte Técnico, Soporte en Seguridad y Soporte Aplicativo. Sus principales responsabilidades son: -

Brindar soporte funcional, a través de asesoramiento Realizar la administración de los sistemas en producción Reparar y restaurar el servicio Asegurar la consistencia de la información Monitorear la performance de la operación del sistema luego de su puesta en marcha Evaluar cumplimiento de los objetivos del sistema Identificar cambios y mejoras potenciales Detectar desvíos

OWNER DEL PROYECTO Sus principales responsabilidades son: -

Identificar las necesidades en uno o más procesos de negocio de la organización que requiera la solución informática correspondiente. Al ser el principal beneficiario del proyecto, es el responsable de “velar” en términos generales por el cumplimiento de la metodología.

RESPONSABLE FUNCIONAL Sus principales responsabilidades son: -

Asesorar al Comité Director con respecto a las decisiones estratégicas vinculadas con la funcionalidad del Sistema y con sus aspectos económicos. Coordinar esfuerzos de todos los servicios involucrados en el Proyecto. Establecer los recursos funcionales requeridos para el Proyecto, y elevar necesidades respecto a los recursos no funcionales necesarios para el éxito del Proyecto. Participar de la definición de esquemas de acceso, seguridad y controles. Validar tareas de prueba piloto e implantación. 13 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

-

Garantizar la coherencia global del Sistema desde el punto de vista funcional (definiendo procedimientos funcionales, evaluando impactos en la Organización, etc.). Junto al Usuario final evaluar beneficios e impactos del Proyecto (en procesos y sistemas) en áreas usuarias priorizando las necesidades. Definir los lineamientos generales del Plan de Capacitación del Sistema junto al Responsable Informático. Validar el Business Plan del Proyecto. Definir y revisar el Acuerdo de Servicio de Proyecto en conjunto con el Responsable Informático. Participar en el aseguramiento de la logística necesaria para soportar el Sistema. Identificar, en conjunto con el Usuario Final, los impactos organizacionales que genera un cambio de Sistemas/Procesos, la población afectada y el dimensionamiento respecto de las tareas, competencias y localizaciones necesarias previas al cambio.

LÍDER FUNCIONAL Sus principales responsabilidades son: -

Preparar las especificaciones funcionales y los requerimientos del Usuario para los Sistemas en desarrollo. Administrar y documentar los requerimientos de acceso, seguridad y controles. Validar diseños funcionales y detallados. Asegurar la capacitación de los usuarios finales Participar y aprobar de las pruebas del producto. Supervisar al equipo de implantación en sus aspectos funcionales. Coordinar la prueba piloto desde el punto de vista funcional, organizacional, participar de la logística (elegir sitios pilotos y su preparación) Coordinar los soportes funcionales locales y la asistencia funcional. Fijar objetivos de explotación y seguimiento. Evaluar, en la fase de Prueba, si las aplicaciones y entorno satisfacen los requerimientos funcionales. Interactuar principalmente con el Responsable Funcional y Líder informático. Elaborar el Business Plan del Proyecto junto al Responsable Funcional. Participar en la elaboración de los manuales de usuarios

RESPONSABLE INFORMÁTICO Sus principales responsabilidades son: -

-

-

Proveer el Sistema Solución o nuevo Sistema a desarrollar, garantizando la coherencia global respecto del resto de los Sistemas de información existentes y proyectados de la compañía. Definir los lineamientos del Plan de Capacitación junto con el Responsable Funcional. Participar de la definición del esquema de planificación, administración y control del Proyecto: - planes de trabajo informático y estimación de costos del Proyecto; - establecer recursos informáticos requeridos para el Proyecto; - elevar necesidades de recursos no informáticos para el éxito del Proyecto; - definir las premisas/supuestos del proyecto. Informar al Comité Ejecutivo periódicamente sobre el avance del desarrollo, implantación, desvíos, factores críticos identificados, soluciones propuestas, etc. Participar en la evaluación técnico/económico de las alternativas de las soluciones propuestas. Definir aspectos informáticos del Proyecto, siendo el nexo con los restantes roles del área informática. Definir los servicios informáticos a contratar. Interactuar principalmente con el Líder Informático y el Responsable Funcional Definir y revisar el Acuerdo de Servicio del Proyecto en conjunto con el Responsable Funcional.

14 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

LÍDER INFORMÁTICO Sus principales responsabilidades son: -

Garantizar que el Proyecto, desde el punto de vista informático se realice en tiempo y forma cumpliendo los objetivos y planes de trabajo aprobados por el Comité Ejecutivo. Definir la arquitectura informática y el desarrollo del Sistema. Nexo con los proveedores involucrados, intermediando entre estos y el Líder Funcional. Asegurar capacitación informática del equipo de implantación. Garantizar el cumplimiento de los aspectos informáticos del proyecto (requerimientos, desarrollo, etc.) Definir las especificaciones detalladas del nuevo Sistema o producto. Definir los ambientes de desarrollo, prueba, capacitación y operación del Sistema. Asegurar la logística informática necesaria para soportar el Sistema y sus sucesivas versiones. Definir desarrollo de adecuaciones necesarias para soportar las especificaciones funcionales recibidas y las de integración con otros Sistemas existentes y/o planificados. Monitorear el avance y calidad de las tareas e informar y corregir los desvíos. Organizar el Proyecto y preparar los planes de trabajo. Interactuar principalmente con el Responsable Informático y el Líder Funcional.

USUARIO FINAL Sus principales responsabilidades son: -

Colaborar y validar la definición de los requerimientos Participar y validar las pruebas funcionales del sistema Evaluar el sistema una vez implantado.

QUALITY ASSURANCE Sus principales responsabilidades son: -

Determinar los estándares de calidad adecuados para el proyecto y cómo satisfacerlos Asegurar la aplicación de una metodología común y un conjunto de estándares compartidos por todos los equipos del proyecto. Evaluar periódicamente la realización total del proyecto. Colaborar con los líderes del proyecto para detectar y anticipar posibles desvíos y problemas. Participar en la elaboración y seguimiento de Plan de Calidad del Proyecto

RESPONSABLE SOPORTE AL CAMBIO Sus principales responsabilidades son: -

Analizar y definir las acciones necesarias para abordar el impacto organizacional generado por la implementación del Proyecto. - Plan de Distribución Dotacional - Plan de Comunicación

RESPONSABLE CAPACITACIÓN Sus principales responsabilidades son: -

Definir la Estrategia de Capacitación Definir el Plan de Capacitación a Capacitadores, Usuarios Finales y Administradores Funcionales. Ejecutar el Plan de Capacitación a Capacitadores, Usuarios Finales y Administradores Funcionales. Asegurar la logística necesaria para impartir la capacitación (manuales, materiales, salas, puestos de trabajo, etc.) Elaborar los requerimientos para el ambiente de capacitación.

15 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

EXPERTO TECNOLÓGICO Este rol estará llevado a cabo por un grupo de expertos de distintas especialidades. Sus principales responsabilidades son: -

Asegurar que el sistema a implantar respete los lineamientos del Plan Tecnológico de la Compañía. Participar de los estudios de mercado, del análisis de productos y de la identificación de alternativas. Colaborar en las pruebas en maqueta. Garantizar la coherencia tecnológica de las ofertas presentadas por los proveedores respecto de la tecnología actual y proyectada.

EXPERTO INFORMÁTICO Este rol estará llevado a cabo por un grupo de expertos de distintas especialidades. Sus principales responsabilidades son: -

Colaborar en el análisis costo/beneficio de un proyecto. Participar en el análisis de requerimientos técnicos/funcionales del proyecto Colaborar en la elaboración de pliegos Definir el plan de contingencia / recuperación de desastres informático. Participar en las pruebas del sistema en general con especial participación en las pruebas de performance, volumen y stress. Realizar las pruebas de compatibilidad. Estudiar y definir el capacity planning Definir normas técnicas para la operación del sistema (backups, transmisiones, verificación de equipos, etc.) y controlar que sean cumplidas en la instalación. Ejecutar el pasaje a producción Evaluar tiempos y costos de terceros y propios relacionados con el proyecto. Verificar el parque informático para determinar si la tecnología actual de la empresa está preparada para dicho proyecto. Convalidar y evaluar los aspectos técnicos/informáticos de las ofertas de proveedores con respecto al pliego de compra Confeccionar el Plan de Pruebas Técnicas y testeo de las mismas, concluyendo en las recomendaciones técnicas pertinentes. Definición del Plan de Trabajo Detallado

EXPERTO EN SEGURIDAD INFORMÁTICA Sus principales responsabilidades son: -

-

Participar del estudio de factibilidad técnico. Realizar las recomendaciones necesarias de seguridad ya fijadas y específicas para el proyecto en particular en su comienzo, con el objetivo que sean incorporadas al pliego de compra. Verificar el cumplimiento de los requerimientos y normas de seguridad en el análisis de las ofertas. Participar de las distintas pruebas, para verificar efectivamente que se hayan realizado las recomendaciones esperadas. Aprobar o no desde el punto de vista de la seguridad del sistema la puesta en producción del mismo.

EXPERTO EN PROCESOS DE NEGOCIO Sus principales responsabilidades son: -

Brindar asesoramiento sobre el proceso impactado por la solución informática Analizar el impacto del proyecto en el proceso impactado Realizar el análisis de alto nivel de todos los nuevos proyectos, evaluando los impactos en los sistemas y en otros proyectos en curso Participar en la elaboración de los manuales de procesos. 16 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

EXPERTO EN CALIDAD El experto en calidad es la persona responsable de asegurar la orientación del proyecto hacia los clientes Sus principales responsabilidades son: -

Colaborar en la definición de indicadores Colaborar en la elaboración del Plan de Calidad Asesorar en metodologías Introducir conceptos de aseguramiento de la calidad Realizar mediciones de satisfacción

EXPERTO ECONÓMICO/FINANCIERO Sus principales responsabilidades son: -

Colaborar en el Análisis Costo Beneficio y en el Business Plan de las alternativas de solución.

EXPERTO EN REDES Este rol estará llevado a cabo por un grupo de expertos de distintas especialidades. Sus principales responsabilidades son: -

Evaluar el impacto que produce incorporar un nuevo flujo de datos, en equipos y vínculos de comunicación. Definir los protocolos de comunicación, las rutas básicas y alternativas, los anchos de banda requeridos, los mecanismos de backup para routers y vínculos, y los sistemas de estadísticas para monitoreo del estado de salud de la red.

ADMINISTRADOR FUNCIONAL Las funciones y responsabilidades del Administrador Funcional están descriptas en el Manual de Normas y Procedimientos vigentes de la Compañía. En general, sus principales responsabilidades son: -

Asesorar acerca de la información que brinda el Sistema y sus funciones en general. Definir y habilitar nuevos perfiles y usuarios Controlar los Procesos Rutinarios inherentes al sistema Coordinar las actividades de capacitación necesarias una vez que el sistema está en producción.

SOPORTE USUARIOS Sus principales responsabilidades son: -

Recibir las consultas y reclamos del usuario Responsable del primer nivel de asistencia al usuario Diagnosticar el problema, resolver y/o derivar

SOPORTE FUNCIONAL Sus principales responsabilidades son: -

Recibir las consultas y reclamos sobre el funcionamiento de un sistema Diagnosticar el problema, resolver y/o derivar Identificar nuevos requerimientos y derivarlos al Administrador Funcional

SOPORTE TÉCNICO Normalmente, este rol estará soportado por un grupo de especialistas de distintas disciplinas y sectores. Sus principales responsabilidades son:

17 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

-

Recibir las consultas e incidentes técnicos Diagnosticar el problema, resolver y/o derivar Verificar y velar por el mantenimiento operativo: - Hardware - Software de base - Bases de Datos - Conectividad - Ambiente Operativo

SOPORTE APLICATIVO Sus principales responsabilidades son: -

Ejecutar las modificaciones necesarias sobre el aplicativo (como respuesta a incidentes o debido a nuevas funcionalidades) Realizar las pruebas correspondientes Mantener la gestión de configuración del aplicativo Documentar los cambios en los manuales de sistemas y de usuario

SOPORTE SEGURIDAD Este rol estará soportado por un grupo de especialistas de distintas disciplinas y sectores. Sus principales responsabilidades son: -

Asegurar la integridad y coherencia de los datos Asegurar la confidencialidad: identificación, autenticación y control de accesos. Recibir, resolver y derivar consultas de inherentes a seguridad Realizar el mantenimiento del sistema de solicitud de claves de accesos

ADMINISTRACIÓN Y CONTROL DEL PROYECTO Desde un punto de vista macro, se pueden identificar las siguientes pautas para la 1 administración y control del Proyecto. Cada proyecto definirá: - La Composición del Grupo de Trabajo, esquema, responsabilidades - Cronograma consensuado - Periodicidad de reuniones de seguimiento - Modalidad del informe de seguimiento que mínimamente deberá contener: - Estado - Puntos de atención - Decisiones a tomar - Acciones, indicando responsables y fechas - Próximos Pasos - Control Presupuestario

Notas: 1 La administración y control del proyecto deberán ser profundizados en la 2° etapa junto con la definición de las herramientas comunes a utilizar para la administración y control.

18 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

INTODUCCIÓN A LA METODOLOGÍA Definimos un proceso de software como un marco de trabajo de las fases, etapas y tareas que se requieren para construir software de alta calidad.

INGENIERÍA DEL SOFTWARE Proceso, métodos y herramientas La ingeniería del software es una tecnología multicapa. Los cimientos que son la base de la ingeniería del software están orientados hacia la calidad. El fundamento de la ingeniería del software es la capa proceso. El proceso define un marco de trabajo para un conjunto de áreas clave de proceso (ACPs) que se debe establecer para la entrega efectiva de la tecnología de la ingeniería del software. Los métodos de la ingeniería del software indican como construir técnicamente el software. Estos abarcan tareas que incluyen el análisis de requerimientos, diseño global, diseño detallado, construcción, pruebas, puesta en producción y mantenimiento. Las herramientas de la ingeniería del software proporcionan un soporte automático o semiautomático para el proceso y para los métodos. Cuando se integran herramientas para que la información creada por una herramienta la pueda utilizar otra, se establece un sistema de soporte para el desarrollo del software llamado ingeniería del software asistida por computadora (Computer-aided software engineering CASE).

Una visión general de la ingeniería del software El trabajo que se asocia a la ingeniería del software se puede dividir en tres fases genéricas:  La fase de definición se centra sobre el qué. El que desarrolla el software intenta identificar que información ha de ser procesada, qué función y rendimiento se desea, qué comportamiento del sistema, qué interfases van a ser establecidas, qué restricciones de diseño existen, y que criterios de validación se necesitan para definir un sistema correcto.  La fase de desarrollo se centra en el cómo. Definir cómo han de diseñarse las estructuras de datos, cómo ha de implementarse la función como una arquitectura del software, cómo han de caracterizarse las interfases, cómo ha de traducirse el diseño de un lenguaje de programación (o lenguaje no procedimental) y cómo ha de realizarse la prueba.  La fase de mantenimiento se centra en el cambio que va asociado a la corrección de errores, a las adaptaciones requeridas a medida que evoluciona el entorno del software, y a cambios debidos a las mejoras producidas por los requisitos cambiantes del cliente. Durante esta fase se encuentran cuatro tipos de cambios:  Corrección. Mantenimiento correctivo para corregir los defectos.  Adaptación. El mantenimiento adaptativo para acomodarlo a los cambios de su entorno externo.  Mejora. El mantenimiento perfectivo lleva al software más allá de sus requisitos funcionales originales.  Prevención. Mantenimiento preventivo también llamado reingeniería del software, hace cambios en programas de computadoras a fin de que se puedan corregir, adaptar y mejorar más fácilmente.

Las fases y los pasos relacionados descriptos se complementan con un número de actividades en las cuales se incluyen:  Seguimiento y control del proyecto del software  Revisiones técnicas formales  Garantía de calidad del software  Gestión y configuración del software  Preparación de producción de documentos  Gestión de reutilización  Mediciones  Gestión de riesgos Las actividades se aplican a lo largo de todo el proyecto. 19 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

EL PROCESO DEL SOFTWARE Se establece:  Un marco común del proceso, definiendo un pequeño número de actividades del marco de trabajo.  Un conjunto de tareas que permiten que las actividades del marco de trabajo se adapten a las características del proyecto del software y a los requisitos del equipo de proyecto.  Las actividades de protección, tales como garantía de calidad del software, gestión de configuración del software y medición, abarcan el modelo de proceso. Estas son independientes de cualquier actividad del marco de trabajo. Para determinar el estado actual de madurez del proceso, el SEI (Software Engineering Institute) utiliza un cuestionario de evaluación y esquema de cinco grados (Ver Cuestionario en anexo xx): Nivel 1: Inicial.- Se definen pocos procesos, y el éxito depende del esfuerzo individual. Nivel 2: Repetible.- Para repetir éxitos anteriores en proyectos con aplicaciones similares se aplica la disciplina necesaria para el proceso. Nivel 3: Definido.- En este nivel se incluyen todas las características definidas en el nivel 2. Nivel 4: Gestionado.- Mediante la utilización de medidas detalladas, se comprenden y se controlan cuantitativamente tanto los productos como los procesos. Nivel 5: Optimización.- Mediante un resultado cuantitativo del proceso y de las ideas y tecnologías innovadoras se posibilita una mejora del proceso. El SEI ha asociado las ACP a cada uno de los niveles de madurez. Cada ACP se describe identificando las características siguientes:  Objetivos  Compromisos (requisitos para lograr los objetivos)  Capacidades (elementos que deben encontrarse)  Actividades (tareas especificas)  Métodos para supervisar la implementación  Métodos para verificar la implementación

MODELOS DE PROCESO DEL SOFTWARE Para resolver los problemas reales en los proyectos de desarrollo de software, un ingeniero del software o un equipo de ingenieros deben aplicar una estrategia de desarrollo que acompañe al proceso, métodos, capas de herramientas y las fases genéricas. Esta estrategia se llama modelo de proceso o paradigma de ingeniería del software. En el presente trabajo se expondrá a nivel detallado los componentes de las fases, etapas, tareas y documentación del ciclo de vida de un proyecto. Todo el desarrollo del software se puede caracterizar como un bucle de resolución de problemas en el que se encuentran las siguientes cuatro etapas teóricas:  Estado Actual: estado actual del problema.  Definición de problemas: identifica el problema específico a resolver.  Desarrollo técnico: resuelve el problema a través de la aplicación de alguna tecnología.  Integración de soluciones: ofrece resultados a los que solicitan la solución en primer lugar.

EL MODELO LINEAL SECUENCIAL Lo llamaremos “ciclo de vida básico” sugiere un enfoque sistemático, secuencial del desarrollo del software que comienza en un nivel de sistemas y progresa con el análisis, diseño (global y 20 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

detallado), construcción e implementación. En este trabajo no se incluye la fase de mantenimiento de un sistema en producción. El ciclo de vida básico acompaña a las actividades siguientes: Ingeniería y modelado de Sistemas/Información. Como el software siempre forma parte de un sistema más grande, el trabajo comienza estableciendo requisitos de todos los elementos del sistema y asignando al software algún subgrupo de estos requisitos. Análisis de los requisitos del software. El proceso de reunión de requisitos se intensifica y se centra especialmente en el software. Diseño (global y detallado). Es un proceso de muchos pasos que se centra en cuatro atributos distintos de un programa: El diseño básicamente se resuelve mediante el estudio y la generación de herramientas orientadas a los siguientes aspectos:  Estructura de datos  Arquitectura del software  Representaciones de interfaz  Detalle procedimental (algoritmo) La generación de las herramientas de trabajo (ej. DFD, DD, Diagramas de estructuras, Diagrama de Clases, Diagrama E-R, etc) traduce requisitos en una representación del software que se pueda evaluar por calidad antes de que comience la generación de código. El diseño se documenta. En esta fase, además se definen las estrategias de capacitación, pruebas (unitarias y globales) y de puesta en producción del sistema. Desarrollo. La orientación del diseño debe alcanzar documentación que permita traducir los requerimientos funcionales a programas. Implementación. Una vez que se ha generado un código, debe efectuarse las pruebas de los programas. El proceso de pruebas se centra en los procesos lógicos internos del software. Asimismo se incluye las actividades de capacitación e implementación, que se apoya en las estrategias diseñadas en la fase de diseño. Problemas en el modelo lineal ciclo de vida básico: 1. Los proyectos reales raras veces siguen el modelo secuencial que propone el modelo. 2. A menudo es difícil que el cliente exponga explícitamente todos los requisitos. 3. El cliente debe tener paciencia. Una versión de trabajo del (los) programa (s) no estará disponible hasta que el proyecto esté muy avanzado. 4. Los responsables del desarrollo del software siempre se retrasan respecto de los planes de trabajos concebidos.

EL MODELO DE CONSTRUCCIÓN DE PROTOTIPOS Un cliente a menudo define un conjunto de objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento, o salida. En estas y en otras muchas situaciones, un paradigma de construcción de prototipos puede ofrecer el mejor enfoque. El paradigma de construcción de prototipos comienza con la recolección de requisitos. El desarrollador y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos, y las áreas del esquema en donde es obligatoria más

21 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García definición. Entonces aparece un “diseño rápido”. El diseño rápido lleva a la construcción de un prototipo. El prototipo lo evalúa el cliente/usuario y lo utiliza para refinar los requisitos del software a desarrollar. La interacción ocurre cuando el prototipo satisface las necesidades del cliente, a la vez que permite que el desarrollador comprenda mejor lo que necesita hacer. Problemas del modelo de construcción de prototipos: 1. El cliente ve lo que parece ser una versión de trabajo del software, sin saber que con la prisa de hacer que funcione no se ha tenido en cuenta la calidad del software global o la facilidad de mantenimiento a largo plazo. 2. El desarrollador a menudo hace compromisos de implementación para hacer que el prototipo funcione rápidamente.

EL MODELO DRA El Desarrollo Rápido de Aplicaciones (DRA) es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto. Es una adaptación a alta velocidad del modelo lineal secuencial utilizando un enfoque de construcción basado en componentes. Comprende las siguientes fases:  Modelado de gestión: Responde: qué información conduce el proceso, qué información se genera, quién la genera, a dónde va y quién la procesa.  Modelado de datos: Se definen las características de cada uno de los objetos y las relaciones entre los objetos  Modelado de proceso: Las descripciones del proceso se crean para añadir, modificar, suprimir, o recuperar un objeto de datos.  Generación de aplicaciones: Trabaja para utilizar componentes ya existentes o a crear componentes reutilizables.  Pruebas y entrega: Se deben probar todos los componentes nuevos y las interfaces. Problemas del modelo DRA:  Para proyectos grandes, requiere recursos humanos suficientes para crear los equipos DRA.  Requiere clientes y desarrolladores comprometidos en las rápidas actividades necesarias.

MODELOS DE PROCESOS EVOLUTIVOS DE SOFTWARE Modelo incremental Combina elementos del modelo ciclo de vida básico con la filosofía interactiva de construcción de prototipos. Cada secuencia lineal produce un incremento del software. Cuando se utiliza un modelo incremental, el primer incremento es un producto esencial (núcleo). El plan afronta la modificación del producto central para cumplir las necesidades del cliente. Este proceso se repite hasta que se elabore el producto completo. A diferencia de la construcción de prototipos, se centra en la entrega de un producto operacional en cada incremento. Es útil cuando no está disponible el personal para una implementación completa en la fecha límite. Modelo en espiral Es un modelo de proceso evolutivo que acompaña la naturaleza interactiva de la construcción de prototipos con los aspectos del modelo lineal secuencial. El modelo en espiral se divide en actividades estructurales, también llamadas regiones de tareas:  Comunicación con el cliente 22 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García 

Planificación: definir recursos, tiempo y otras informaciones relacionadas con el proyecto.  Análisis de riesgos: evaluar riesgos técnicos y de gestión.  Ingeniería: construir una o más representaciones de la aplicación.  Construcción y adaptación: construir, probar, instalar y proporcionar soporte al usuario.  Evaluación del cliente: obtener la reacción del cliente. En todos los casos se aplican las actividades de protección. Modelo de ensamblaje de componentes El modelo de ensamblaje de componentes configura aplicaciones desde componentes preparados de software(“clases”). Es un modelo evolutivo e interactivo. Se identifican las clases candidatas. Esto se lleva a cabo examinando los datos que se van a manejar por parte de la aplicación y el algoritmo que se va a aplicar para conseguir el tratamiento. Las clases creadas se almacenan en una biblioteca de clases. Una vez identificadas las clases candidatas se examina si ya existen y en ese caso se vuelven a utilizar. Se compone así la primera interacción de la aplicación a construirse. Este modelo lleva a la reutilización del software. Modelo de desarrollo concurrente Define una serie de acontecimientos que dispararán transiciones de estado a estado para cada una de las actividades de la ingeniería del software. Todas las actividades existen concurrentemente, pero residen en estados diferentes.

MODELO DE MÉTODOS FORMALES El modelo de métodos formales acompaña a un conjunto de actividades que conducen a la especificación matemática del software. La ambigüedad, lo incompleto y la inconsistencia se descubren y corrigen mediante el análisis matemático. Inconvenientes:  Caro y lleva mucho tiempo.  Los desarrolladores poseen pocos antecedentes necesarios.  Difícil comunicación con el cliente con pocos conocimientos técnicos.

TÉCNICAS DE CUARTA GENERACIÓN El paradigma de las “técnicas de cuarta generación” (T4G) se orienta hacia la posibilidad de especificar el software usando formas de lenguaje especializado o notaciones gráficas que describan el problema que hay que resolver en términos que los entienda el cliente. Actualmente, incluye algunas de las siguientes herramientas: lenguajes no procedimentales de consulta de base de datos, generación de informes, manejo de datos, interacción y definición de pantallas, generación de códigos, capacidades gráficas de alto nivel y capacidades de hoja de cálculo.

TECNOLOGÍA DE PROCESOS Los modelos de procesos tratados se deben adaptar para utilizarse por el equipo de proyecto. Para conseguirlo, se han desarrollado herramientas de tecnología de procesos que permiten que una organización de software construya un modelo automatizado de la estructura común del proceso, conjuntos de tareas y actividades de protección.

PRODUCTO Y PROCESO Las personas obtienen tanta satisfacción del proceso creativo que del producto final. La dualidad de producto y proceso es un elemento importante para mantener ocupada a la gente creativa hasta que se finalice la transición de la programación a la ingeniería del software.

DIAGRAMA DE FASES Y ETAPAS

23 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

Habiendo efectuado un repaso de los diferentes modelos de diseño de aplicaciones existentes, debemos elegir uno a fin de desarrollar detalladamente las actividades que los equipos de desarrollo deben realizar. Teniendo en cuenta lo anteriormente dicho, creemos conveniente desarrollar el modelo ciclo de vida básico, también conocido como “Modelo Lineal Secuencial”. Este modelo nos permitirá alcanzar el objetivo pedagógico que perseguimos que es saber hacer siguiendo un modelo formal e intuitivo.

DIAGRAMA RESUMEN En esta primera aproximación del modelo, se presenta un esquema resumen con las fases generales y los hitos de continuación o detención (go no-go) del proyecto. Es importante resaltar que un proyecto de sistemas se inicia con la identificación de las necesidades, y culmina con la implantación y la puesta en producción del sistema junto con el balance o cierre correspondiente. Desde el momento en que el sistema se pasa a producción, comienza una nueva fase que no está incluída en el ciclo de vida del proyecto: la fase de Producción. Ésta, tiene vida propia y finalizará cuando el sistema deje de operar. Dentro del ciclo de vida del proyecto, se debe generar dos contratos: 1. Acuerdo de Servicio de Proyecto, suscripto entre el Owner del Proyecto y el Responsable Informático y que acompaña al proyecto durante todo su ciclo de vida 2. Contrato de Servicio de Producción entre el usuario del sistema y los proveedores (internos y externos) del servicio. Este contrato acompaña al sistema durante toda su vida de producción.

24 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

DIAGRAMA DE FASES A continuación, se presenta un diagrama completo con todas las fases de un proyecto, los hitos go, no-go, y de control y los acuerdos y contratos de servicio.

25 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

26 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

DIAGRAMA DE ETAPAS, TAREAS Y ENTREGABLES POR FASE Vamos describir el diagrama de las etapas, enunciaremos las tareas y entregables de cada una de las fases que compone la metodología que adoptamos. DESCRIPCIÓN DE NECESIDADES Y ESTUDIO PRELIMINAR

FASES D E S C R I P C I Ó N de

E S T U D I O

N E C E S I D A D E S

P R E L I M I N A R

ETAPAS

TAREAS

DESCRIPCIÓN NECESIDADES

- Identificar Necesidades - Relevamiento Global - Descripición de Objetivos y Alcance - Especificar Requerimiento

ESTUDIO DE FACTIBILIDAD

- Alineamiento Plan Maestro Sistemas - Alineamiento Plan Tecnológico - Alineamiento Plan Estratégico - Identificación de Alternativas - Análisis Factibilidad Técnica - Identificación Modalidad de Proyecto - Análisis Impacto del Proyecto - Análisis Costo Beneficio - Business Plan - Análisis DAFO - Identificación Métricas - Elaboración Inf. Ejecutivo Est. Factiblidad - Actualización Plan Maestro - Análisis de Presupuesto - Confección del Acuerdo de Servicio

HITO 0: APROBACIÓN PROYECTO

ENTREGABLES

- Descripción de la Necesidad

- Estudio Factibilidad Técnico/ Funcional - Estudio Factibilidad Económico - Métricas Claves - Informe Ejecutivo Estudio Factiibilidad - Plan Maestro Actualizado - Acuerdo de Servicio (Borrador)

COORDINADOR

Líder Funcional

Líder Funcional

- Carta de Decisión - Acuerdo de Servicio

El objetivo de las fases Descripción de las necesidades y el Estudio preliminar del Sistema es el análisis de un conjunto concreto de necesidades para proponer una solución a corto plazo, que tenga en cuenta restricciones económicas, técnicas, legales y operativas. La solución obtenida como resultado del estudio será la definición de uno o varios proyectos que afecten a uno o varios sistemas de información ya existentes o nuevos. Para ello, se identifican los requisitos que se ha de satisfacer y se estudia, si procede, la situación actual. 27 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

A partir del estado inicial, la situación actual y los requisitos planteados, se estudian las alternativas de solución. Dichas alternativas pueden incluir soluciones que impliquen desarrollos a medida, soluciones basadas en la adquisición de productos software del mercado o soluciones mixtas. Se describe cada una de las alternativas, indicando los requisitos que cubre. Una vez descritas cada una de las alternativas planteadas, se valora su impacto en la organización, la inversión a realizar en cada caso y los riesgos asociados. Esta información se analiza con el fin de evaluar las distintas alternativas y seleccionar la más adecuada, definiendo y estableciendo su planificación. Si en la organización se ha realizado con anterioridad un Plan de Sistemas de Información que afecte al sistema objeto de este estudio, se dispondrá de un conjunto de productos que proporcionarán información a tener en cuenta en todo el proceso. Las actividades que engloba este proceso se menciona a continuación: Descripción de Necesidades  Identificar Necesidades  Relevamiento Global  Descripción de Objetivos y Alcances  Especificar Requerimientos. Estudio Preliminar  Alineamiento al Plan Maestro de Sistemas  Alineamiento al Plan Tecnológico  Alineamiento al Plan Estrategico  Identificación de Alternativas  Análisis de Factibilidad Técnica  Identificación de la Modalidad del Proyecto  Análisis Impacto del Proyecto  Análisis de Costo Beneficio  Business Plan  Análisis DAFO (Debilidades y Fortalezas)  Identificación de Métricas  Elaboración del Informe Ejectivo del Estudio de Factibilidad  Actualización Plan Maestro  Análisis de Presupuesto  Confección del Acuerdo de Servicio.

28 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

DISEÑO GLOBAL Y PROCESO DE COMPRAS

FASES D I S E Ñ O

G L O B A L

ETAPAS

ESPECIFICACIÓN GENERAL

TAREAS - Descripción Requerimientos Funcionales - Análisis de Requerimientos - Impacto en Arquitectura Técnica - Realización de Especificación - Plan General de Trabajo - Definición de Equipo de Trabajo - Administración de Riesgo - Quality Management - Revisión Modalidad de Proyecto - Revisión de Business Plan

HITO 1: CONVALIDACIÓN ESPECIFICACIÓN P R O C E S O de

C O M P R A S

CONCURSO

ANALÍSIS TÉCNICO

ANÁLISIS ECONÓMICO

ENTREGABLES

COORDINADOR

- Especificación Funcional - Plan Maestro Actualizado - Arquitectura Técnica Actualizada - Especificación Técnica - Plan General de Trabajo - Equipo de Trabajo - Carta de Decisión Actualizada - Est Fact Económica Act.

Líder Funcional

- Especifiación Convalidada

- Requerimiento de Compras - Preparación Pliego - Convalidación Pliego - Publicación

- Requerimiento de Compras - Pliego - Circulares Aclaratorias - Ofertas (Técnica y Económica)

Compras

- Análisis Ofertas - Pruebas de Funcionamiento en Maqueta - Emisión Dictamen Técnico

- Preinforme Técnico - Preinforme Técnico de Pruebas - Dictamen Técnico

Líder Informático

- Análisis Económico

- Dictamen Económico

HITO 2: ADJUDICACIÓN

Compras

- Acta de Adjudicación - Documento de Compra

El objetivo de este proceso es la obtención de una especificación global del sistema de información que satisfaga las necesidades de información de los usuarios y sirva de base para el posterior diseño detallado del sistema. Se lleva a cabo la descripción inicial del sistema de información, a partir de los productos generados en el proceso Estudio Preliminar. Se delimita el alcance del sistema, se genera un catálogo de requisitos generales y se describe el sistema mediante unos modelos iniciales de alto nivel. También se identifican los usuarios que participan en el proceso de análisis, determinando sus perfiles, responsabilidades y dedicaciones necesarias. Así mismo se elabora el plan de trabajo a seguir. La definición de requisitos del nuevo sistema se realiza con el objetivo de elaborar el catálogo de requisitos detallado, que permita describir con precisión el sistema de información, y que además sirva de base para comprobar que es completa la especificación de los modelos obtenidos en las actividades Identificación de requerimientos 29 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

Para la obtención de requisitos se toman como punto de partida el catálogo de requisitos y los modelos elaborados en la actividad Definición del Sistema, completándolos mediante sesiones de trabajo con los usuarios. Estas sesiones de trabajo tienen como objetivo reunir la información necesaria para obtener la especificación detallada del nuevo sistema. Las técnicas que ayudan a la recopilación de esta información pueden variar en función de las características del proyecto y los tipos de usuario a entrevistar. Entre ellas podemos citar las reuniones, entrevistas, Joint Application Design (JAD), etc. Durante estas sesiones de trabajo se propone utilizar la especificación de los casos de uso como ayuda y guía en el establecimiento de requisitos. Esta técnica facilita la comunicación con los usuarios y en el análisis orientado a objetos constituye la base de la especificación. A continuación se identifican las facilidades que ha de proporcionar el sistema, y las restricciones a que está sometido en cuanto a rendimiento, frecuencia de tratamiento, seguridad y control de accesos, etc. Toda esta información se incorpora al catálogo de requisitos. Con la información recopilada, se estructura el sistema de información en subsistemas, para facilitar la especificación de los distintos modelos y la traza de requisitos. En paralelo, se generan los distintos modelos que sirven de base para el diseño. En el caso de análisis estructurado, se procede a la elaboración y descripción detallada del modelo de datos y de procesos, y en el caso de un análisis orientado a objetos, se elaboran el modelo de clases y el de interacción de objetos, mediante el análisis de los casos de uso. Se especifican, asimismo, todas las interfaces entre el sistema y el usuario, tales como formatos de pantallas, diálogos, formatos de informes y formularios de entrada. En la actividad impacto de la arquitectura técnica se efectúa el Análisis de Consistencia y Especificación de Requisitos, se realiza la verificación y validación de los modelos, con el fin de asegurar que son: - Completos, puesto que cada modelo obtenido contiene toda la información necesaria recogida en el catálogo de requisitos. - Consistentes, ya que cada modelo es coherente con el resto de los modelos. - Correctos, dado que cada modelo sigue unos criterios de calidad predeterminados en relación a la técnica utilizada, calidad de diagramas, elección de nombres, normas de calidad, etc.). La participación activa de los usuarios es una condición imprescindible para el análisis del sistema de información, ya que dicha participación constituye una garantía de que los requisitos identificados son comprendidos e incorporados al sistema y, por tanto, de que éste será aceptado. Para facilitar la colaboración de los usuarios, se pueden utilizar técnicas interactivas, como diseño de diálogos y prototipos, que permiten al usuario familiarizarse con el nuevo sistema y colaborar en la construcción y perfeccionamiento del mismo.

30 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

DISEÑO DETALLADO Y CONSTRUCCIÓN

FASES D I S E Ñ O

D E T A L L A D O

ETAPAS

TAREAS

COORDINADOR

DISEÑO DETALLADO

- Especificación Técnica de Detalle - Diseño Tecnología - Plan Detallado de Trabajo - Diseño del Modelo de Datos - Prototipo - Elaboración Plan de Pruebas Técnicas - Plan de Contingencia y Desastre - Plan de Backup - Documentación Operativa - Definición Proc. Gestión de Configuración

- Espec. técnica de Detalle - Plan Detallado de Trabajo - Plan de Pruebas Técnicas - Plan de Contingencia y de Desastre - Plan de Backup - Doc. Soporte Mesa de Ayuda - Doc. Soporte a Operaciones/ Soporte - Proc. Gestión de Configuración

Líder Informático

DEFINICIÓN ESTRATEGIAS

- Impacto Organizacional - Estrategia de Implantación - Elaboración Plan de Pruebas Funcionales - Estrategia de Confiabilización - Estrategia de Conversión de Datos - Estrategia de Carga de Datos - Plan Acción para el Cambio - Plan de Capacitación - Plan de Comunicación

- Impacto Organizacional - Estrategia de Implantación - Plan de Pruebas Funcionales - Estrategia de Confiabilización - Estrategia de Conversión de Datos - Estrategia de Carga de Datos - Plan de Acción para el Cambio - Plan de Capacitación - Plan de Comunicación

Líder Funcional

HITO 3: APROBACIÓN DISEÑO DETALLADO

C O N S T R U C C I Ó N

ENTREGABLES

Especificación Técnica de Detalle

PARAMETRIZACIÓN Y DESARROLLO

- Desarrollo de Programas - Adecuaciones de Programas - Parametrización - Elaboracion Manuales de Sistemas - Elaboracion Manuales de Usuario - Elaboración Manual de Procesos

- Programas, Módulos & Parametrización - Manual de Sistemas - Manual de Usuario - Manual de Procesos

Líder Informático

PRUEBAS

- Prueba Individual - Prueba de Cadena - Prueba de Integración - Prueba Global - Prueba de Perf., stress, volumen & seguridad - Pruebas de Compatibilidad

- Protocolos de Prueba - Aprobación de Pruebas

Líder Informático

PRUEBA PILOTO

- Preparación - Prueba Piloto - Homologación Prueba Piloto

- Protocolo de Prueba Piloto - Homologación Prueba Piloto

Líder Funcional

DEFINICIÓN PLAN DE IMPLANTACIÓN

- Revisión del Acuerdo de Servicio y Alcance - Plan de Implantación - Plan de Soporte - Elaboración Protocolo de Implantación - Definición Procedimiento de Producción - Actualización Gestión de Configuración

- Acuerdo de Servicio Revisado - Plan de Implantación - Plan de Soporte - Protocolo de Implantación - Procedimiento de Producción - Proc. Gestión de Configuración actualizado

Líder Funcional

HITO 4: DECISIÓN DE IMPLANTACIÓN

- Acuerdo de Implantación

31 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

Fase de Diseño Detallado. El objetivo de la Fase de Diseño Detallado es la definición de la arquitectura del sistema y del entorno tecnológico que le va a dar soporte, junto con la especificación detallada de los componentes del sistema de información. A partir de dicha información, se generan todas las especificaciones de construcción relativas al propio sistema, así como la descripción técnica del plan de pruebas, la definición de los requisitos de implantación y el diseño de los procedimientos de migración y carga inicial, éstos últimos cuando proceda. Las actividades de este proceso se agrupan en dos grandes bloques. 1.- En un primer bloque de actividades, que se llevan a cabo en paralelo, se obtiene el diseño de detalle del sistema de información. La realización de estas actividades exige una continua realimentación. En general, el orden real de ejecución de las mismas depende de las particularidades del sistema de información y, por lo tanto, de generación de sus productos. Se establece el particionamiento físico del sistema de información, así como su organización en subsistemas de diseño, la especificación del entorno tecnológico, y sus requisitos de operación, administración, seguridad y control de acceso. Se completan los catálogos de requisitos y normas, en función de la definición del entorno tecnológico, con aquellos aspectos relativos al diseño y construcción que sea necesario contemplar. Asimismo, se crea un catálogo de excepciones del sistema, en el que se registran las situaciones de funcionamiento secundario o anómalo que se estime oportuno considerar y, por lo tanto, diseñar y probar. Este catálogo de excepciones se utiliza como referencia en la especificación técnica de las pruebas del sistema. El sistema de información se estructura en subsistemas de diseño. Éstos a su vez se clasifican como de soporte o específicos, al responder a propósitos diferentes. Los subsistemas de soporte contienen los elementos o servicios comunes al sistema y a la instalación, y generalmente están originados por la interacción con la infraestructura técnica o la reutilización de otros sistemas, con un nivel de complejidad técnica mayor. También se especifica en detalle el entorno tecnológico del sistema de información, junto con su planificación de capacidades (capacity planning), y sus requisitos de operación, administración, seguridad y control de acceso. El diseño detallado del sistema de información, siguiendo un enfoque estructurado, comprende un conjunto de actividades que se llevan a cabo en paralelo a la Definición de la Arquitectura del Sistema. El alcance de cada una de estas actividades se resume a continuación:  Diseño de la Arquitectura de Soporte  Diseño de la Arquitectura de Módulos del Sistema  Diseño Físico de Datos En el caso de Diseño Orientado a Objetos, conviene señalar que el diseño de la persistencia de los objetos se lleva a cabo sobre bases de datos relacionales, y que el diseño detallado del sistema de información se realiza en paralelo con la actividad de Diseño de la Arquitectura de Soporte, y se corresponde con las siguientes actividades:  Diseño de Casos de Uso Reales.  Diseño de Clases En el caso de que sea necesario, se realiza la definición de un plan de migración y carga inicial de datos.

32 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

Una vez que se tiene el modelo de clases, se comienza el diseño físico en la actividad Diseño Físico de Datos. 2.- El segundo bloque de actividades complementa el diseño del sistema de información. En él se generan todas las especificaciones necesarias para la construcción del sistema de información:  Generación de Especificaciones de Construcción.  Diseño de la Migración y Carga Inicial de Datos  Especificación Técnica del Plan de Pruebas  Establecimiento de Requisitos de Implantación Fase de Construcción En este proceso se genera el código de los componentes del Sistema de Información, se desarrollan todos los procedimientos de operación y seguridad y se elaboran todos los manuales de usuario final y de explotación con el objetivo de asegurar el correcto funcionamiento del Sistema para su posterior implantación. Para conseguir dicho objetivo, en este proceso se realizan las pruebas unitarias, las pruebas de integración de los subsistemas y componentes y las pruebas del sistema, de acuerdo al plan de pruebas establecido. Asimismo, se define la formación de usuario final y, si procede, se construyen los procedimientos de migración y carga inicial de datos. El producto Especificaciones de Construcción del Sistema de Información, es la base para la construcción del sistema de información. En dicho producto se recoge la información relativa al entorno de construcción del sistema de información, la especificación detallada de los componentes y la descripción de la estructura física de datos, tanto bases de datos como sistemas de ficheros. Opcionalmente, incluye un plan de integración del sistema de información, en el que se especifica la secuencia y organización de la construcción de los distintos componentes. Se asegura la disponibilidad de la infraestructura necesaria para la generación del código de los componentes y procedimientos del sistema de información. Una vez configurado el entorno de construcción, se realiza la codificación y las pruebas de los distintos componentes que conforman el sistema de información, mediante las siguientes actividades genericas: Generación del Código de los Componentes y Procedimientos, que se hace según las especificaciones de construcción del sistema de información, y conforme al plan de integración del sistema de información. Ejecución de las Pruebas Unitarias, dónde se llevan a cabo las verificaciones definidas en el plan de pruebas para cada uno de los componentes Ejecución de las Pruebas de Integración, que incluye la ejecución de las verificaciones asociadas a los subsistemas y componentes, a partir de los componentes verificados individualmente, y la evaluación de los resultados. Una vez construido el sistema de información y realizadas las verificaciones correspondientes, se lleva a cabo la integración final del sistema de información en la actividad de Pruebas globales (GST), comprobando tanto las interfaces entre subsistemas y sistemas externos como los requisitos, de acuerdo a las verificaciones establecidas en el plan de pruebas para el nivel de pruebas del sistema. En la actividad Elaboración de los Manuales del sistema Usuario, se genera la documentación de usuario final o explotación, conforme a los requisitos definidos en el proceso Diseño del Sistema de Información.

33 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

La formación necesaria para que los usuarios finales sean capaces de utilizar el sistema de forma satisfactoria se especifica en la actividad Plan de Capacitación. Si se ha establecido la necesidad de realizar una migración de datos, la construcción y pruebas de los componentes y procedimientos relativos a dicha migración y a la carga inicial de datos se realiza en la actividad Estrategia de Conversión y Estrategia de Carga de Datos.

34 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

IMPLANTACIÓN Y CIERRE DEL PROYECTO

FASES I M P L A N T A C I O N

ETAPAS

TAREAS

ENTREGABLES

COORDINADOR

PREPARACIÓN IMPLANTACIÓN

- Ejecución de Confiabilización de Datos - Conversión de Datos - Aprobación de Conversión de Datos - Carga Inicial y Parametrización - Capacitación - Comunicación

- Aprobación Conversión Datos

PUESTA EN PRODUCCIÓN

- Realización Implantación - Aceptación Implantación

- Recepción Provisoria

- Contrato de Servicio de Producción - Documentación Puesta en Producción (Anexo el Proc. de Producción)

- Contrato de Servicio Producción - Doc. Soporte Mesa de Ayuda actualizado - Doc. Soporte a Operaciones/ Soporte actualizado

FORMALIZACIÓN PUESTA EN PRODUCCIÓN

HITO 5: SISTEMA EN PRODUCCIÓN

Líder Funcional

Líder Informático

Administrador Funcional

- Informe Sistema en Producción

COMIENZA FASE DE PRODUCCIÓN

B A L A N C E

P R O Y E C T de O

BALANCE DEL PROYECTO

- Balance del Proyecto

- Informe de Cierre del Proyecto

Líder Funcional Líder Informático

Este proceso tiene como objetivo principal la entrega y aceptación del sistema en su totalidad, y la realización de todas las actividades necesarias para el paso a producción del mismo. En primer lugar, se revisa la estrategia de implantación que ya se determinó en la Fase de Estudio Preliminar. Se estudia su alcance y, en función de sus características, se define un plan de implantación y se especifica el equipo que lo va a llevar a cabo. 35 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

Conviene señalar la participación del usuario de operación en las pruebas de implantación, del usuario final en las pruebas de aceptación, y del responsable de mantenimiento. Las actividades previas al inicio de la producción incluyen la preparación de la infraestructura necesaria para configurar el entorno, la instalación de los componentes, la activación de los procedimientos manuales y automáticos asociados y, cuando proceda, la migración o carga inicial de datos. Para ello se toman como punto de partida los productos software probados, obtenidos en la fase de Construcción del Sistema de Información y su documentación asociada. Se realizan las pruebas de implantación y de aceptación del sistema en su totalidad. Responden a los siguientes propósitos:  Las pruebas de implantación cubren un rango muy amplio, que va desde la comprobación de cualquier detalle de diseño interno hasta aspectos tales como las comunicaciones. Se debe comprobar que el sistema puede gestionar los volúmenes de información requeridos, se ajusta a los tiempos de respuesta deseados y que los procedimientos de respaldo, seguridad e interfaces con otros sistemas funcionan correctamente. Se debe verificar también el comportamiento del sistema bajo las condiciones más extremas. 

Las pruebas de aceptación se realizan por y para los usuarios. Tienen como objetivo validar formalmente que el sistema se ajusta a sus necesidades.

Asimismo, se llevan a cabo las tareas necesarias para la preparación del mantenimiento, siempre y cuando se haya decidido que éste va a efectuarse. En cualquier caso, es necesario que la persona que vaya a asumir el mantenimiento conozca el sistema, antes de su incorporación al entorno de producción. Además hay que determinar los servicios (y niveles para cada uno) que requiere el sistema que se va a implantar, y el acuerdo que se adquiere una vez que se inicie la producción. Hay que distinguir entre servicios de gestión de operaciones (servicios por lotes, seguridad, comunicaciones, etc.) y servicios al cliente (servicio de atención a usuario, mantenimiento, etc.) que se deben negociar en cuanto a recursos, horarios, costo, etc. Se fija el nivel con el que se prestará el servicio como indicador de la calidad del mismo. Conviene señalar que la implantación puede ser un proceso iterativo que se realiza de acuerdo al plan establecido para el comienzo de la producción del sistema en su entorno de operación. Para establecer este plan se tiene en cuenta:  El cumplimiento de los requisitos de implantación definidos en la fase de Descripción de las Necesidades.  La estrategia de transición del sistema antiguo al nuevo. Finalmente, se realizan las acciones necesarias para el inicio de la producción.

36 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

PRODUCCIÓN

FASES

P R O D U C C I Ó N

ETAPAS

TAREAS

ENTREGABLES

COORDINADOR

ADMINISTRACIÓN TÉCNICA

- Procesos Backup - Procesos Seguridad - Procesos Performance - Control de Procesos Rutinarios - Otros procesos

- Tablero de Mando

Soporte Técnico

ADMINISTRACIÓN FUNCIONAL

- Administración de Usuarios y Perfiles - Mantenimiento de Datos, Tablas y Parámetros - Capacitación Nuevos Usuarios

- Tablero de Mando

Administrador Funcional

- Atención a Usuarios - Soporte Funcional - Soporte Técnico - Soporte Aplicativo

- Tablero de Mando

Administrador Funcional

- Nuevos Requerimientos

- Nuevo Proyecto

Administrador Funcional

SOPORTE

EVOLUCIÓN

Es importante señalar, que en la fase de Producción las etapas no presentan una secuencialidad, ya que las tareas correspondientes a esta fase pueden realizarse en forma paralela independientemente de la etapa a la que pertenecen.

37 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

DESCRIPCIÓN DE LAS FASES

38 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

FASE: ESTUDIO PRELIMINAR

39 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

FASE: ESTUDIO FACTIBILIDAD FASE E S T U D I O

P R E L I M I N A R

ETAPAS

ESTUDIO DE FACTIBILIDAD

TAREAS - Alineamiento Plan Maestro Sistemas - Alineamiento Plan Tecnológico - Alineamiento Plan Estratégico - Identificación de Alternativas - Análisis Factibilidad Técnica - Identificación Modalidad de Proyecto - Análisis Impacto del Proyecto - Análisis Costo Beneficio - Business Plan - Análisis DAFO - Identificación Métricas - Elaboración Inf. Ejecutivo Est. Factiblidad - Actualización Plan Maestro - Análisis de Presupuesto - Confección del Acuerdo de Servicio

HITO 0: APROBACIÓN PROYECTO

1

ENTREGABLES

COORDINADOR

- Estudio Factibilidad Técnico/ Funcional - Estudio Factibilidad Económico - Métricas Claves - Informe Ejecutivo Estudio Factiibilidad - Plan Maestro Actualizado - Acuerdo de Servicio (Borrador)

Líder Funcional

- Carta de Decisión - Acuerdo de Servicio

ETAPA: ESTUDIO DE FACTIBILIDAD

El propósito de este proceso es analizar un conjunto concreto de necesidades, con la idea de proponer una solución a corto plazo. Los criterios con los que se hace esta propuesta no serán estratégicos sino tácticos y relacionados con aspectos económicos, técnicos, legales y operativos. Los resultados del Estudio de factibilidad del Sistema constituirán la base para tomar la decisión de seguir adelante o abandonar. Si se decide seguir adelante pueden surgir uno o varios proyectos que afecten a uno o varios sistemas de información. Dichos sistemas se desarrollarán según el resultado obtenido en el estudio de viabilidad y teniendo en cuenta la cartera de proyectos para la estrategia de implantación del sistema global. Se ha considerado que este proceso es obligatorio, aunque el nivel de profundidad con el que se lleve a cabo dependerá de cada caso. La conveniencia de la realización del estudio de la situación actual depende del valor añadido previsto para la especificación de requisitos y para el planteamiento de alternativas de solución. En las alternativas se considerarán soluciones "a medida", soluciones basadas en la adquisición de productos software del mercado o soluciones mixtas. Para valorar las alternativas planteadas y determinar una única solución, se estudiará el impacto en la organización de cada una de ellas, la inversión y los riesgos asociados. El resultado final de este proceso son los productos relacionados con la solución que se propone para cubrir la necesidad concreta que se planteó en el proceso, y que depende de: Si la solución conlleva desarrollo a medida o no: 

Contexto del sistema (con la definición de las interfaces en función de la solución).



Impacto en la organizació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. 40 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García



Solución propuesta:



Descripción de la solución.



Modelo de descomposición en subsistemas.



Matriz de 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 los procesos manuales.

Si la alternativa incluye desarrollo: 

Modelo abstracto de datos/Modelo de procesos.



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 el producto.



Estándares del producto.



Descripción de adaptación si es necesaria.

Si en la organización se ha realizado con anterioridad un Plan de Sistemas de Información que afecte al sistema objeto de este estudio, se dispondrá de un conjunto de productos que proporcionarán información a tener en cuenta en todo el proceso.

2

Alineamiento Plan Maestro de Sistemas

Análisis de coherencia del proyecto con el Plan Maestro de Sistemas INPUT - Descripción de la Necesidad (F1) - Plan Maestro de Sistemas

3

OUTPUT - Validación alineamiento

ACTORES - Líder funcional - Líder Informático - Experto tecnológico

RESPONSABLE - Líder informático

Alineamiento Plan Tecnológico

Análisis de coherencia del proyecto con el Plan Tecnológico INPUT - Descripción de la Necesidad (F1) - Plan Tecnológico

OUTPUT - Validación alineamiento

ACTORES - Experto tecnológico - Líder informático - Líder funcional

RESPONSABLE - Experto tecnológico

41 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

4

Alineamiento Plan Estratégico

Análisis de coherencia del proyecto con los lineamientos estratégicos de la Compañía, y análisis de impacto en los procesos de negocio y / o en los clientes INPUT - Descripción de la Necesidad (F1) - Lineamientos Estratégicos

5

OUTPUT - Validación alineamiento

-

ACTORES RESPONSABLE Líder funcional - Líder funcional Experto tecnológico Líder informático Experto en procesos

Identificación de Alternativas – Análisis Factibilidad Técnica – Identificación Modalidad del Proyecto

Se identifican y proponen las posibles alternativas técnicas, se analiza el impacto del proyecto sobre otros sistemas. Realización del análisis de factibilidad técnica. Evaluación técnica para identificar si el parque microinformático es el adecuado. Análisis de compatibilidad. Ver productos existentes en la empresa. Investigación de productos del mercado e identificación preliminar de modalidad del proyecto: producto offthe-shelf o desarrollo a medida. Propuesta de modalidad de adquisición (llave en mano, contratación de horas hombre, etc.) INPUT - Descripción de la Necesidad (F1) - Plan Maestro - Lineamientos Tecnológicos

6

OUTPUT - Estudio de Factibilidad técnico/funcional

-

ACTORES Líder funcional Líder Informático Experto tecnológico Experto seguridad informática

RESPONSABLE - Líder informático

Análisis de Impacto del Proyecto

Se identifican el impacto de cada alternativa en función de: - Procesos - Usuarios. INPUT - Descripción de la Necesidad (F1) - Estudio de Factibilidad técnico/funcional

7

OUTPUT - Estudio de Factibilidad técnico/funcional

ACTORES RESPONSABLE - Líder funcional - Líder funcional - Experto en procesos - Usuario

Análisis Costo Beneficio – Business Plan

Evaluación económica/financiera del proyecto (Business Plan, cálculo de VAN, TIR, etc.). Preparación del presupuesto. Se considerará como horizonte del análisis todo el ciclo de vida del producto y se incluirá inversiones, gastos iniciales y upgrades, releases, capacitaciones, mantenimiento, otros. Además se considerarán costos de terceros, como también las horas del personal propio que se imputarán al proyecto.

42 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

INPUT - Descripción de la Necesidad (F1) - Estudio de Factibilidad técnico/funcional

8

OUTPUT - Estudio de Factibilidad económico

ACTORES - Líder funcional - Experto económico/financier o - Experto informático

RESPONSABLE - Líder funcional

Análisis DAFO

Análisis DAFO. Identificación de Factores Claves de Éxito., riesgos, barreras/restricciones, aspectos legales (marco regulatorio). INPUT - Descripción de la Necesidad (F1) - Estudio de Factibilidad técnico/funcional - Estudio de Factibilidad económico

9

OUTPUT - Análisis DAFO - Factores Claves de Éxito. - Riesgos

ACTORES - Líder funcional - Experto económico/financier o - Experto informático

RESPONSABLE - Líder funcional

Identificación de Métricas

Identificación de métricas operativas, funcionales y financieras, y sus objetivos, con las que se podrá evaluar los resultados de haber realizado el proyecto. INPUT - Descripción de la Necesidad (F1) - Estudio de Factibilidad técnico/funcional - Estudio de Factibilidad económico

OUTPUT - Métricas clave para evaluación - Valores objetivo de las métricas

ACTORES - Líder funcional - Experto económico/financier o - Experto informático - Experto en calidad

RESPONSABLE - Líder funcional

10 Elaboración del Informe Ejecutivo de Estudio de Factibilidad En base a los Estudios de Factibilidad Técnico/Funcional y Económico se elabora un Resumen Ejecutivo para la presentación al Comité Director. INPUT - Estudio de Factibilidad Técnico/Funcional - Estudio de Factibilidad Económica

OUTPUT - Informe Ejecutivo de Estudio de Factibilidad

ACTORES - Líder Informático - Líder Funcional

RESPONSABLE - Líder funcional

11 Actualización del Plan Maestro Una vez aprobado el proyecto, se deberá actualizar el Plan Maestro de Sistemas incluyendo el nuevo proyecto, y sus impactos. Esta tarea se llevará a cabo después de la Aprobación del Proyecto (Hito 0) 43 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

INPUT - Plan Maestro de Sistemas

OUTPUT - Plan Maestro Actualizado

ACTORES - Líder Informático

RESPONSABLE - Líder Informático

12 Análisis de Presupuesto Analizar y definir el presupuesto a asignar para las etapas del proyecto. Identificar y designar el o los owners de presupuesto. INPUT - Estudio de Factibilidad Técnica/Funcional - Estudio de Factibilidad Económica

OUTPUT - Asignación Presupuestaria - Designación de owner/s de presupuesto

ACTORES - Comité Director - Comité Ejecutivo

RESPONSABLE - Comité Director

13 Confección de Acuerdo de Servicio Confección del Borrador del Acuerdo de Servicio entre el Owner del Proyecto y el Responsable Informático para el Proyecto de Sistemas. En proyectos de gran envergadura, el responsable funcional y el responsable informático llevarán adelante la negociación de este acuerdo. INPUT - Estudio de Factibilidad Técnica/Funcional

OUTPUT - Acuerdo de Servicio (Borrador)

-

ACTORES Owner del Proyecto Líder Informático Líder Funcional Experto en Calidad

RESPONSABLE - Líder Funcional

HITO 0: APROBACIÓN DEL PROYECTO El Comité Director analizará la información generada en la Fase Estudio Preliminar y tomará la DECISIÓN de aprobación del proyecto en forma conjunta. Obtención asignación de partida presupuestaria. Revisión y firma del Acuerdo de Servicio INPUT: OUTPUT:

ACTORES:

-

Informe Ejecutivo Estudio de Factibilidad Acuerdo de Servicio (Borrador) Carta de Decisión (Proyecto Aprobado) Carta de Decisión (Proyecto Rechazado) Acuerdo de Servicio (Firmado) Líder funcional Experto económico/financiero Responsable informático Responsable tecnológico Responsable procesos Owner del Proyecto Usuario

44 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

RESPONSABLE: - Comité Director Check-list   

  

2

Designación del Owner del Proyecto Identificación del Owner del Presupuesto Documentos:  Descripción de la Necesidad (F1)  Estudio de Factibilidad Técnico/Funcional  Estudio de Factibilidad Económica  Métricas Claves  Informe Ejecutivo de Estudio de Factibilidad  Acuerdo de Servicio Presupuesto (monto y asignación) Plazos Modalidad del Proyecto

“APROBACIÓN DEL PROYECTO” constituye el HITO 0 de Validación del Owner del Proyecto.

Notas: 2 El Comité Director delegará su responsabilidad de acuerdo a la importancia del proyecto.

45 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

FASE DESCRIPCIÓN DE NECESIDADES

46 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

0.- DESCRIPCIÓN ETAPAS D E S C R I P C I Ó N de

N E C E S I D A D E S

DESCRIPCIÓN NECESIDADES

TAREAS

- Identificar Necesidades - Relevamiento Global - Descripición de Objetivos y Alcance - Especificar Requerimiento

ENTREGABLES

COORDINADOR

- Descripción de la Necesidad

Líder Funcional

1.- Análisis del Sistema de Información El propósito de este proceso es conseguir la especificación detallada del sistema de información, a través de un catálogo de requisitos y una serie de modelos que cubran las necesidades de información de los usuarios para los que se desarrollará el sistema de información y que serán la entrada para el proceso de Diseño del Sistema de Información. En primer lugar se describe inicialmente el sistema de información, a partir de los productos generados en el proceso Estudio de Factibilidad del Sistema. Se delimita su alcance, se genera un catálogo de requisitos generales y se describe el sistema mediante unos modelos iniciales de alto nivel. Se recogen de forma detallada los requisitos funcionales que el sistema de información debe cubrir, catalogándolos, lo que permite hacer la traza a lo largo de los procesos de desarrollo. Además, se identifican los requisitos no funcionales del sistema, es decir, las facilidades que ha de proporcionar el sistema, y las restricciones a que estará sometido, en cuanto a rendimiento, frecuencia de tratamiento, seguridad, etc. Para facilitar el análisis del sistema se identifican los subsistemas de análisis, y se elaboran los modelos de Casos de Uso y de Clases, en desarrollos orientados a objetos, y de Datos y Procesos en desarrollos estructurados. Se ha incorporado una actividad específica para la definición de Interfaces de Usuario al tiempo que se van obteniendo y depurando los requisitos y los anteriores modelos. Se especificarán todas las interfaces entre el sistema y el usuario, como formatos de pantallas, diálogos, formatos de informes y formularios de entrada. Finalizados los modelos, se realiza un análisis de consistencia, mediante una verificación y validación, lo que puede forzar la modificación de algunos de los modelos obtenidos. Una vez realizado dicho análisis de consistencia se elabora el producto Especificación de Requisitos Software, que constituye un punto de referencia en el desarrollo del software y la línea base de referencia para las peticiones de cambio sobre los requisitos inicialmente especificados. En este proceso se inicia también la especificación del Plan de Pruebas, que se completará en el proceso Diseño del Sistema de Información.

47 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

Los productos resultantes del Análisis del Sistema de Información, dependen del tipo de desarrollo de que se trate y se detallan a continuación especificando los que son distintos, según los dos tipos de desarrollo mencionados: •

Descripción general del entorno tecnológico.

•

Glosario de términos.

•

Catálogo de normas.

•

Catálogo de requisitos.

•

Especificación de interfaz de usuario.

Además, en Análisis Estructurado.

•

•

Plan de migración y carga inicial de datos.

•

Contexto del sistema.

Matriz de procesos/localización geográfica. •

Descripción de interfaz con otros sistemas.

•

Modelo de procesos.

•

Modelo lógico de datos normalizado.

Además, en Análisis Orientado a Objetos. •

Descripción de subsistemas de análisis.

•

Descripción de interfaces entre subsistemas.

•

Modelo de clases de análisis.

•

Comportamiento de clases de análisis. / Diagramas híbridos

•

Análisis de la realización de los casos de uso.

En este proceso es muy importante la participación de los usuarios, a través de técnicas interactivas, como diseño de diálogos y prototipos, que permiten al usuario familiarizarse con el nuevo sistema y colaborar en la construcción y perfeccionamiento del mismo.

2.- ETAPA: DESCRIPCIÓN DE NECESIDADES INPUT - Necesidad

OUTPUT - Descripción de la Necesidad (F1)

ACTORES - Líder funcional - Owner del Proyecto - Usuario Final

RESPONSABLE - Líder funcional

2.1 Identificar Necesidades - Relevamiento Global - Descripción de Objetivos y Alcance – Especificar Requerimiento. Ante una necesidad detectada (mejora de un proceso, nuevo proceso, introducción de un nuevo servicio), y una motivación clara y definida se lleva adelante un relevamiento global. Definir el objetivo y alcance del proyecto y realizar la especificación del requerimiento funcional. Se realiza una descripción general de la necesidad planteada por el usuario, y se estudian las posibles restricciones de carácter económico, técnico, operativo y legal que puedan afectar al sistema. Antes de 48 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

iniciar el estudio de los requisitos del sistema se establecen los objetivos generales del Estudio de Viabilidad, teniendo en cuenta las restricciones identificadas anteriormente. Si el sistema objeto de estudio se encuentra en el ámbito de un Plan de Sistemas de Información vigente, se debe de tomar como referencia el catálogo de requisitos y la arquitectura de información resultante del mismo, como información adicional para la descripción general del sistema y determinación de los requisitos iniciales.

3.- ESTABLECER EL ALCANCE DEL SISTEMA Se analiza el alcance de la necesidad planteada y se identifican las restricciones relativas a la sincronización con otros proyectos, que puedan interferir en la planificación y futura puesta a punto del sistema objeto del estudio. Esta información se recoge en el catálogo de requisitos. Si el sistema pertenece al ámbito de un Plan de Sistemas de Información, se debe tener en cuenta la arquitectura de información propuesta para analizar el alcance del sistema e identificar los sistemas de información que quedan fuera del ámbito del estudio. Además, se estudia el plan de proyectos, para determinar las posibles dependencias con otros proyectos. Una vez establecido el alcance, se identifican las unidades organizativas afectadas por el sistema, así como su estructura y responsables de las mismas. Para determinar los responsables se tiene en cuenta a quiénes afecta directamente y quiénes pueden influir en el éxito o fracaso del mismo. En función del alcance del sistema y los objetivos del Estudio de Viabilidad del Sistema, se determinan las actividades y tareas a realizar. En particular, hay que decidir si se realiza o no el estudio de la situación actual y, en el caso de considerarlo necesario, con qué objetivo. Si el sistema pertenece al ámbito de un Plan de Sistemas de Información, los criterios que pueden orientar sobre la necesidad de llevar a cabo el estudio de la situación actual dependen de la arquitectura de información propuesta, en cuanto a la identificación de los sistemas de información actuales, implicados en el ámbito de este estudio, que se haya decidido conservar. Se identifican los usuarios participantes de las distintas unidades organizativas afectadas para la realización del Estudio de Viabilidad del Sistema, determinando previamente sus perfiles y responsabilidades. Debe comunicarse el plan de trabajo a los usuarios identificados como implicados en el Estudio de Viabilidad, solicitando su aceptación y esperado su confirmación.

4.- ESTUDIO DE LA SITUACIÓN ACTUAL La situación actual es el estado en el que se encuentran los sistemas de información existentes en el momento en el que se inicia su estudio. Teniendo en cuenta el objetivo del estudio de la situación actual, se realiza una valoración de la información existente acerca de los sistemas de información afectados. En función de dicha valoración, se especifica el nivel de detalle con que se debe llevar a cabo el estudio. Si es necesario, se constituye un equipo de trabajo específico para su realización y se identifican los usuarios participantes en el mismo.

49 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

Si se decide documentar la situación actual, normalmente es conveniente dividir el sistema actual en subsistemas. Si es posible se describirá cada uno de los subsistemas, valorando qué información puede ser relevante para la descripción. Como resultado de esta actividad se genera un diagnóstico, estimando la eficiencia de los sistemas de información existentes e identificando los posibles problemas y las mejoras.

5.- DEFINICIÓN DE REQUISITOS DEL SISTEMA Esta actividad incluye la determinación de los requisitos generales, mediante una serie de sesiones de trabajo con los usuarios participantes, que hay que planificar y realizar. Una vez finalizadas, se analiza la información obtenida definiendo los requisitos y sus prioridades, que se añaden al catálogo de requisitos que servirá para el estudio y valoración de las distintas alternativas de solución que se propongan.

6.- CONCEPTOS Y PRINCIPIOS DEL ANALISIS Tanto el desarrollador como el cliente tienen un papel activo en el análisis y especificación de los requisitos. 6.1 ANALISIS DE REQUISITOS Es una tarea que permite al ingeniero de sistemas: - Especificar la función y rendimiento del soft. - Indicar la interfaz del soft con otros elementos del sistema - Establecer las restricciones que debe cumplir el soft - Construir los modelos de dominios de datos, funcional y comportamiento - Proporciona al diseñador y al cliente los medios para valorar la calidad una vez que se ha construido el software. El análisis de requisitos se puede dividir en 5 áreas: 1) Reconocimiento del problema 2) Evaluación y síntesis - qué ¿? 3) Modelado del sistema 4) Especificación del software 5) Revisión El desarrollador puede no estar seguro de que un enfoque específico consiga apropiadamente el funcionamiento y rendimiento adecuados. Por esta y otras muchas razones, se puede llevar a cabo un enfoque alternativo del análisis de requisitos, denominado prototipato o creación de prototipos. 6.2 TECNICAS DE COMUNICACIÓN 6.2.1 Inicio del proceso Para empezar la comunicación entre cliente y desarrollador se lleva a cabo una reunión o entrevista preliminar. Se sugiere que el analista empiece preguntando cuestiones de contexto libre, es decir un conjunto de preguntas que llevarán a un entendimiento básico del problema. Pero el formato de preguntarespuesta de reunión tipo, no es un enfoque que haya tenido mucho éxito. Esta sesión de preguntas y respuestas debería emplearse solamente en el primer encuentro y sustituírse después por una modalidad que combine elementos de resolución de problema, negociación y especificación. 6.2.2 técnicas para facilitar las especificaciones de una aplicación.

50 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

El enfoque de Técnicas para Facilitar las Especificaciones de la Aplicación (TFEA), es partidario de la creación de un equipo conjunto de clientes y desarrolladores que trabajan juntos para identificar el problema, proponer soluciones, negociar diferentes enfoques y especificar un conjunto preliminar de requisitos de la solución. TFEA – DIRECTRICES BÁSICAS: - La reunión se celebra en un lugar neutral y acuden tanto clientes como los desarrolladores. - Se establecen normas de preparación y de participación. - Se sugiere una agenda lo suficientemente formal como para cubrir todos los puntos importantes pero lo suficientemente informal como para animar el libre flujo de ideas. - Un coordinador para coordinar la reunión. - Se usa un mecanismo de definición – gràficos, carteles, pizarra, hojas de trabajo – - Objetivo: identificar el problema, proponer elementos de solución. 6.2.3 Despliegue de la función de calidad El Despliegue de la Función Calidad (DFC) es una técnica de gestión de calidad que traduce las necesidades del cliente en requisitos técnico del software. DFC identifica 3 tipos de requisitos: - Requisitos normales: se declaran objetivos y metas para un producto o sistema durante reuniones con el cliente. Si estos requisitos están presentes el cliente estará satisfecho. - Requisitos esperados: son implícitos al producto o sistema y pueden ser tan fundamentales que el cliente no los declara explícitamente. Su ausencia será motivo de una insatisfacción significativa. - Requisitos innovadores: estas características van más allá de las expectativas del cliente y suelen ser muy satisfactorias. El producto entregado contiene ciertas capacidades no esperadas. El despliegue de función se utiliza para determinar el valor de cada función requerida para el sistema.

7.- PRINCIPIOS DEL ANALISIS Todos los métodos de análisis se relacionan por un conjunto de Principios operativos: 1) Debe representarse y entenderse el dominio de información de un problema. 2) Deben definirse las funciones que debe realizar el sotf. 3) Debe representarse el comportamiento del soft (como consecuencia de acontecimientos externos) 4) Deben dividirse los modelos que representan información, función y comportamiento. 5) El modelo del análisis debería ir desde la información esencial hasta el detalle de la implementación. Directrices para la ingeniería de requisitos(Davis): - Entender el problema antes de crear el modelo de análisis. - Desarrollar prototipos que permitan al usuario entender cómo será la interacción hombre-máquina. - Registrar el origen y la razón de cada requisito. - Usar múltiples planeamientos de requisitos. - Dar prioridad a los requisitos. - Trabajar para eliminar la ambigüedad. 7.1 El dominio de la información. El primer principio operativo de análisis requiere el examen del dominio de la información. Este dominio contiene 3 visiones diferentes: 1) el contenido de la información – datos y control 2) el flujo de la información – como cambian los datos y control 3) la estructura de la información – organización interna de datos y control – 7.1.2 Modelado Los modelos se crean para entender mejor la entidad que se va a construir y es fundamental para un buen trabajo de análisis: 51 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

-

-

Modelos funcionales: el soft. transforma la información y para hacerlo, debe realizar al menos tres funciones genéricas: entrad, procesamiento y salida. Este modelo empieza con un sencillo modelo a nivel de contexto (DFD Nivel 0). Modelos de comportamiento: la mayoría del software responde a los acontecimientos del mundo exterior (estímulo- respuesta). Esto forma parte de este modelo, que muestra los estados del soft y los acontecimientos que causan que cambie de estado.

7.1.3 Partición Es dividir los problemas que son demasiados grandes o complejos para entenderlos globalmente. La partición descompone a un problema en sus partes constitutivas. El enfoque de partición también puede aplicarse al dominio de la información y al de comportamiento. 7.1.4 Visiones esenciales y de implementación Visión esencial: de los requisitos del software presenta las funciones a conseguir y la información a procesar mínimos sin tener en cuenta los detalles de la implementación. Visión de implementación: de los requisitos del software introduce la manifestación en el mundo real de las funciones de procesamiento y las estructuras de la información. 7.2 CREACION DE PROTOTIPOS 7.2.1 Enfoque La creación de prototipos puede ser cerrada o abierta: - Cerrada: Prototipo desechable: sirve únicamente como una basta demostración de los requisitos. Después se desecha. - Abierta: Prototipo evolutivo: es empleado como primera parte de una actividad de análisis a la que seguirá el diseño y la construcción. Es la primera evolución del sistema terminado. 7.2.2 Métodos y herramientas para el desarrollo de prototipos. Para crear rápidamente prototipos existen: - Técnicas de cuarta generación: amplia gama de lenguajes de consultas e informes de bases de datos, generadores de programas. - Componentes de software reutilizables: ensamblar, más que construir, con componentes ya existentes. - Especificaciones formales y entornos para prototipos 7.3 ESPECIFICACION 7.3.1 Principios de la especificación: 1) Separar la funcionalidad de la implementación. 2) Desarrollar un modelo de comportamiento 3) Establecer el contexto en que opera el software. 4) Definir el entorno en que va a opera el sistema. 5) Crear el modelo intuitivo en vez de un diseño o modelo de implementación. 6) Establecer el contenido y la estructura de una especificación de manera que acepte cambios. 7.3.2 Representación: Los requisitos del soft pueden especificarse de varias maneras. Directrices a seguir: - El formato de la representación y el contenido debería estar relacionados con el problema. - La información contenida dentro de la especificación debería estar escalonada. - La numeración de párrafos y diagramas debería indicar el nivel de detalle que se muestra. - Los diagramas y otras formas de notación deberían restringirse en número y ser consistentes den su empleo. 52 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

-

Las representaciones deben permitir revisiones.

7.3.4 La especificación de los requisitos del software. Esquema como estructura para la especificación: - Introducción - Descripción de la información - descripción funcional - descripción del comportamiento - criterios de validación - bibliografía - apéndice En muchos casos una especificación de requisitos puede estar acompañada de un prototipo ejecutable o en papel o un manual del usuario. 7.4 REVISION DE LA ESPECIFICACION Es llevada a cabo tanto por el desarrollador como por el cliente. Inicialmente la revisión se lleva a cabo a nivel macroscópico. Se estudian las siguientes cuestiones: - Metas y objetivos declarados. - Descripto todas las interfaces importantes. - Definidos el flujo y la estructura de la información - Diagramas. - Funciones principales - Requisitos alternativos. - Riesgos tecnológicos. - Manual del usuario, etc. Directrices para una revisión detallada: - Conectores persuasivos. - Términos imprecisos - Listas incompletas. - Verbos de significados imprecisos. - Pronombres de significados ambiguos. - Frases que impliquen certidumbre. Etc. La especificación firmada se convierte en un contrato para el desarrollo del software.

53 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

FASE: DISEÑO GLOBAL

54 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

FASE: DISEÑO GLOBAL FASE D I S E Ñ O

G L O B A L

ETAPAS

ESPECIFICACIÓN GENERAL

TAREAS - Descripción Requerimientos Funcionales - Análisis de Requerimientos - Impacto en Arquitectura Técnica - Realización de Especificación - Plan General de Trabajo - Definición de Equipo de Trabajo - Administración de Riesgo - Quality Management - Revisión Modalidad de Proyecto - Revisión de Business Plan

HITO 1: CONVALIDACIÓN ESPECIFICACIÓN

ENTREGABLES

COORDINADOR

- Especificación Funcional - Plan Maestro Actualizado - Arquitectura Técnica Actualizada - Especificación Técnica - Plan General de Trabajo - Equipo de Trabajo - Carta de Decisión Actualizada - Est Fact Económica Act.

Líder Funcional

- Especifiación Convalidada

El propósito del Diseño del Sistema de Información es obtener la definición de la arquitectura del sistema y del entorno tecnológico que le va a dar soporte, junto con la especificación detallada de los componentes. A partir de dicha información, se generan todas las especificaciones de construcción relativas al propio sistema, así como la especificación técnica del plan de pruebas, la definición de los requisitos de implantación y el diseño de los procedimientos de migración y carga inicial, éstos últimos cuando proceda. El diseño de la arquitectura del sistema dependerá en gran medida de las características de la instalación, de modo que se ha de tener en cuenta una participación activa de los responsables de sistemas y explotación de las organizaciones para las que se desarrolla el sistema de información. Este proceso consta de un primer bloque de actividades, que se realizan en paralelo, y cuyo objetivo es obtener el diseño global del sistema de información que comprende la partición física del sistema de información, independiente de un entorno tecnológico concreto, la organización en subsistemas de diseño, la especificación del entorno tecnológico sobre el que se despliegan dichos subsistemas y la definición de los requisitos de operación, administración del sistema, seguridad y control de acceso. De este primer bloque de actividades se obtienen los siguientes productos: • •

Catálogo de requisitos (se completa).

Catálogo de excepciones. •

Catálogo de normas para el diseño y construcción.

•

Diseño de la arquitectura del sistema.

•

Entorno tecnológico del sistema.

•

Procedimientos de operación y administración del sistema.

•

Procedimientos de seguridad y control de acceso.

•

Diseño detallado de los subsistemas de soporte.

•

Modelo físico de datos optimizado.

•

Asignación de esquemas físicos de datos.

Además, en Diseño Estructurado. •

Diseño de la arquitectura modular. (Diagrama de Procesos) 55 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

•

Diseño de interfaz de usuario.

Además, en Diseño Orientado a Objetos. •

Diseño de la realización de casos de uso.

•

Modelo de clases de diseño.

•

Comportamiento de clases de diseño.

• Diseño de interfaz de usuario. Al igual que en el proceso de Análisis del Sistema de Información, antes de proceder a la especificación de los componentes, se realiza una verificación y validación, con objeto de analizar la consistencia entre los distintos modelos y formalizar la aceptación del diseño de la arquitectura del sistema por parte de los usuarios. Un segundo bloque de actividades complementa el diseño del sistema de información, en el que se generan todas las especificaciones necesarias para la construcción del sistema de información: •

Las especificaciones de construcción de los componentes del sistema (módulos o clases, según el caso) y de las estructuras de datos.

•

Los procedimientos de migración y sus componentes asociados.

•

La definición y revisión del plan de pruebas, y el diseño de las verificaciones de los niveles de prueba establecidos.

•

El catálogo de excepciones que permite establecer un conjunto de verificaciones relacionadas con el propio diseño o con la arquitectura del sistema.

•

La especificación de los requisitos de implantación.

ETAPA: ESPECIFICACIÓN GENERAL 1

Descripción de Requerimientos Funcionales

Elaboración del Documento de Especificaciones Funcionales (F1), donde se describen y/o especifican en forma detallada las necesidades de los usuarios. Este documento incluirá la definición de los procesos a implementar.

INPUT - Descripción de la Necesidad (F1) - Procesos de Negocio

OUTPUT - Especificación Funcional (F1)

-

ACTORES Líder funcional Líder informático Usuarios Experto en Procesos de Negocio

RESPONSABLE - Líder funcional

DEFINICIÓN DEL SISTEMA Esta actividad tiene como objetivo efectuar una descripción del sistema, delimitando su alcance, estableciendo las interfaces con otros sistemas e identificando a los usuarios representativos. Las tareas de esta actividad se pueden haber desarrollado ya en parte en el proceso de Estudio de Factibilidad, de modo que se parte de los productos obtenidos en dicho proceso para proceder a su adecuación como punto de partida para definir el sistema de información.

56 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

2

Análisis de Requerimientos – Impacto en Arquitectura Técnica Realización de la Especificación

Análisis detallado de la especificación funcional, considerando también aspectos de seguridad, clases de usuarios, perfiles, performance del sistema, volumetría, etc. Definición del Modelo de Información del Sistema. Análisis de impacto en la arquitectura técnica e interfaces con otros sistemas. Flujograma. Elaboración de la especificación técnica del producto. INPUT OUTPUT - Especificación - Plan Maestro Funcional (F1) Actualizado - Arquitectura Técnica - Arquitectura Técnica - Plan Maestro Actualizada - Especificación técnica (F2)

ACTORES RESPONSABLE Líder funcional - Líder informático Líder informático Experto tecnológico Experto informático Experto en seguridad informática

ESTABLECIMIENTO DE REQUISITOS En esta actividad se lleva a cabo la definición, análisis y validación de los requisitos a partir de la información facilitada por el usuario, completándose un catálogo de requisitos. El objetivo de esta actividad es obtener un catálogo detallado de los requisitos, a partir del cual se pueda comprobar que los productos generados en las actividades de modelización se ajustan a los requisitos de usuario. Esta actividad se descompone en un conjunto de tareas que, si bien tienen un orden, exige continuas realimentaciones y solapamientos, entre sí y con otras tareas realizadas en paralelo. No es necesaria la finalización de una tarea para el comienzo de la siguiente. Lo que se tiene en un momento determinado es un catálogo de requisitos especificado en función de la progresión del proceso de análisis. Se propone como técnica de obtención de requisitos la especificación de los casos de uso o diagramas híbridos. Dichas técnicas ofrece un diagrama simple y una guía de especificación en las sesiones de trabajo con el usuario. IDENTIFICACIÓN DE SUBSISTEMAS DE ANÁLISIS El objetivo de esta actividad es común tanto para análisis estructurado como para análisis orientado a objetos, y el esfuerzo está orientado a facilitar el análisis del sistema de información llevando a cabo la descomposición del sistema en subsistemas. Se realiza en paralelo con el resto de las actividades de generación de modelos del análisis. Por tanto, se asume la necesidad de una realimentación y ajuste continuo con respecto a la definición de los subsistemas, sus dependencias y sus interfaces.

3

Plan General de Trabajo

Confección del plan general de trabajo (cronograma), identificando tareas, hitos de entregables, recursos (externos e internos). INPUT - Especificación Técnica (F2) - Especificación Funcional (F1)

OUTPUT - Plan General de Trabajo

ACTORES - Líder informático - Líder funcional

57 de 181

RESPONSABLE - Líder informático

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

4

Definición de Equipo de Trabajo

Constitución del equipo de trabajo o equipo de implantación (funcionales, informáticos, expertos en tecnología, en procesos de negocio, responsables de soporte al cambio, etc.), determinando los sectores intervinientes, roles y responsabilidades. A partir de la estructura de la organización, identificar las personas que cumplirán los roles definidos para el proyecto. Asignar los responsables a cada tarea dentro del Plan General de Trabajo. Identificación del porcentaje de dedicación al proyecto INPUT - Descripción de la Necesidad (F1) - Especificación técnica (F2) - Plan General de Trabajo

5

OUTPUT ACTORES - Equipo de Trabajo - Líder informático - Plan General de - Líder funcional Trabajo (actualizado)

RESPONSABLE - Líder funcional

Administración del riesgo

Análisis de riesgos, identificación, cuantificación de fuentes de riesgos, síntomas de riesgos, lista de oportunidades (a seguir o a ignorar), planes de contingencia. INPUT - Especificación técnica (F2) - Plan General de Trabajo

OUTPUT - Análisis de Riesgo

-

ACTORES Líder funcional Líder informático Experto informático Experto en seguridad informática

RESPONSABLE - Líder funcional

En referencia a los riesgos del proyecto el líder funcional deberá poder identificar aquellos riesgos que puedan afectar la implementación del sistema. Entre otros se deberá identificar y proponer soluciones (si los riesgos se presentan) los siguientes aspectos.  Instalación del parque informático necesario para el desarrollo, prueba y puesta en marcha del sistema.  Aparición de nuevas necesidades cuando el desarrollo del sistema ya se encuentra iniciado.  Atrasos en el plan de trabajo.  Aparición de problemas en la logística del proyecto (ambientes de capacitación / pruebas, etc.)

6

Quality Management

Definición e identificación de indicadores de calidad asociados a cada tarea e hito del proyecto. Elaborar el Plan de Calidad. INPUT - Especificación técnica (F2) - Plan General de Trabajo - Especificación funcional (F1)

OUTPUT - Indicadores de Calidad - Plan Quality Management

-

ACTORES Líder funcional Líder informático Quality Assurance Experto en calidad

RESPONSABLE - Líder funcional

El plan de calidad tiene íntima relación con la metodología de desarrollo implementada en el proyecto, Particularmente los indicadores están asociados a la generación de documentación que todo proyecto de desarrollo de un sistema debe poseer como por ejemplo: 58 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

          

Documentos de especificación funcional (f1) Documento de especificación técnica (f2) Documentos de especificación de desarrollo (f3) Plan de trabajo general Diagramas de contexto Diagramas de flujo de datos Diccionario de datos Diagrama de clases / híbridos Documento de estrategia de capacitación Documento de estrategia de pruebas (integración y globales) Documento de estrategia de puesta en producción

HITO 1: CONVALIDACIÓN ESPECIFICACIÓN El Comité Ejecutivo analizará, revisará y convalidará la Especificación resultante en forma conjunta. INPUT:

OUTPUT: ACTORES: RESPONSABLE: -

Información Generada en la Fase Diseño Global Especificación técnica (F2) Especificación funcional (F1) Especificación funcional validada (F1 validado) Especificación técnica validada (F2 validado) Indicadores de Calidad Plan Quality Management Líder informático Líder funcional Experto tecnológico Usuario Comité Ejecutivo

Check-list  

 

Definición del Equipo de Trabajo Documentos:  Especificación funcional (F1)  Especificación técnica (F2)  Plan General de Trabajo Revisión de Business Plan Revisión de Modalidad de Trabajo

“CONVALIDACIÓN ESPECIFICACIÓN” constituye el HITO 1 de Validación del Owner del Proyecto.

59 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

FASE: DISEÑO DETALLADO

60 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

FASE: DISEÑO DETALLADO FASE D I S E Ñ O

D E T A L L A D O

ETAPAS

TAREAS

ENTREGABLES

COORDINADOR

DISEÑO DETALLADO

- Especificación Técnica de Detalle - Diseño Tecnología - Plan Detallado de Trabajo - Diseño del Modelo de Datos - Prototipo - Elaboración Plan de Pruebas Técnicas - Plan de Contingencia y Desastre - Plan de Backup - Documentación Operativa - Definición Proc. Gestión de Configuración

- Espec. técnica de Detalle - Plan Detallado de Trabajo - Plan de Pruebas Técnicas - Plan de Contingencia y de Desastre - Plan de Backup - Doc. Soporte Mesa de Ayuda - Doc. Soporte a Operaciones/ Soporte - Proc. Gestión de Configuración

Líder Informático

DEFINICIÓN ESTRATEGIAS

- Impacto Organizacional - Estrategia de Implantación - Elaboración Plan de Pruebas Funcionales - Estrategia de Confiabilización - Estrategia de Conversión de Datos - Estrategia de Carga de Datos - Plan Acción para el Cambio - Plan de Capacitación - Plan de Comunicación

- Impacto Organizacional - Estrategia de Implantación - Plan de Pruebas Funcionales - Estrategia de Confiabilización - Estrategia de Conversión de Datos - Estrategia de Carga de Datos - Plan de Acción para el Cambio - Plan de Capacitación - Plan de Comunicación

Líder Funcional

Especificación Técnica de Detalle

HITO 3: APROBACIÓN DISEÑO DETALLADO

ETAPA: DISEÑO DETALLADO 3 Especificación técnica de detalle – Diseño Tecnología - Plan Detallado de Trabajo– Diseño del Modelo de Datos Elaboración de la especificación técnica detallada del Proyecto, revisando y validando el detalle de la arquitectura tecnológica, incluyendo los aspectos técnicos de detalle. Elaboración del Plan de Trabajo de detalle. Identificación de hitos y tareas. Especificación detallada del Modelo de Datos. Determinación de las características del puesto de trabajo. INPUT - Especificación técnica (F2) - Especificación funcional (F1)

OUTPUT - Especificación técnica de Detalle (f3) - Plan Detallado de Trabajo

ACTORES Líder informático Líder funcional Experto tecnológico Experto informático Experto en seguridad informática - Proveedor -

RESPONSABLE - Líder informático

ELABORACIÓN DEL MODELO DE DATOS El objetivo de esta actividad es identificar las necesidades de información de cada uno de los procesos que conforman el sistema de información, con el fin de obtener un modelo de datos que contemple todas las entidades, relaciones, atributos y reglas de negocio necesarias para dar respuesta a dichas necesidades. El modelo de datos se elabora siguiendo un enfoque descendente (top-down). Notas: 3 El principal actor en la fase de Diseño Detallado es el proveedor (interno y externo), mientras que en la fase “Diseño Global” es la empresa.

61 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

A partir del modelo conceptual de datos, obtenido en la tarea Análisis de Requerimientos del Sistema, se incorporan a dicho modelo todas las entidades que vayan apareciendo, como resultado de las funcionalidades que se deban cubrir y de las necesidades de información del usuario. Es necesario tener en cuenta el catálogo de requisitos. Una vez construido el modelo conceptual y definidas sus entidades, se resuelven las relaciones complejas y se completa la información de entidades, relaciones, atributos y ocurrencias de las entidades, generando el modelo lógico de datos. Como última tarea en la definición del modelo, se asegura la normalización hasta la cuarta forma normal para obtener el modelo lógico de datos normalizado. Finalmente, si procede, se describen las necesidades de migración y carga inicial de los datos.

DISEÑO FÍSICO DE DATOS En esta actividad se define la estructura física de datos que utilizará el sistema, a partir del modelo lógico de datos normalizado o modelo de clases, de manera que teniendo presentes las características específicas del sistema de gestión de datos concreto a utilizar, los requisitos establecidos para el sistema de información, y las particularidades del entorno tecnológico, se consiga una mayor eficiencia en el tratamiento de los datos. También se analizan los caminos de acceso a los datos utilizados por cada módulo/clase del sistema en consultas y actualizaciones, con el fin de mejorar los tiempos de respuesta y optimizar los recursos de máquina. Las tareas de esta actividad se realizan de forma iterativa y en paralelo con las realizadas en las actividades Definición de la Arquitectura del Sistema, dónde se especifican los detalles de arquitectura e infraestructura y la planificación de capacidades, Diseño de la Arquitectura de Soporte dónde se determinan y diseñan los servicios comunes que pueden estar relacionados con la gestión de datos (acceso a bases de datos, ficheros, áreas temporales, sincronización de bases de datos, etc.), Diseño de Casos de Uso Reales y de Clases, para desarrollo orientado a objetos, y Diseño de la Arquitectura de Módulos del Sistema, para desarrollo estructurado, dónde se especifica la lógica de tratamiento y las interfaces utilizadas. En el caso de diseño orientado a objetos, esta actividad también es necesaria. La obtención del modelo físico de datos se realiza aplicando una serie de reglas de transformación a cada elemento del modelo de clases que se está generando en la actividad Diseño de Clases. Asimismo, en esta actividad hay que considerar los estándares y normas establecidos para el diseño aplicando, cuando proceda, los mecanismos genéricos de diseño identificados en la tarea Identificación de Mecanismos Genéricos de Diseño.

DISEÑO DE LA ARQUITECTURA DE MÓDULOS DEL SISTEMA El objetivo de esta actividad, que sólo se realiza en el caso de Diseño Estructurado, es definir los módulos del sistema de información, y la manera en que van a interactuar unos con otros, intentando que cada módulo trate total o parcialmente un proceso específico y tenga una interfaz sencilla. Para cada uno de los subsistemas específicos, identificados en la tarea Identificación de los Subsistemas de Diseño, se diseña la estructura modular de los procesos que lo integran, tomando como punto de partida los modelos obtenidos en la tarea Validación de los Modelos del proceso de Análisis del Sistema de Información y el catálogo de requisitos. Dicha estructura se irá completando con los módulos que vayan apareciendo como consecuencia del diseño de la interfaz de usuario, así como de la optimización del diseño físico de datos. Durante el diseño de los módulos, se pueden identificar características o comportamientos comunes relacionados con accesos a las bases de datos o ficheros, lógica de tratamiento, llamadas a otros 62 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

módulos, gestión de errores, etc. que determinen la necesidad de realizar su implementación como subsistemas de soporte. Además, se analizan los comportamientos de excepción asociados a los diferentes módulos y a las interfaces entre los mismos, intentando independizar en la medida de lo posible aquéllos que presenten un tratamiento común. Dichas excepciones se incorporan al catálogo de excepciones.

ELABORACIÓN DEL MODELO DE PROCESOS El objetivo de esta actividad es analizar las necesidades del usuario para establecer el conjunto de procesos que conforma el sistema de información. Para ello, se realiza una descomposición de dichos procesos siguiendo un enfoque descendente (top-down), en varios niveles de abstracción, donde cada nivel proporciona una visión más detallada del proceso definido en el nivel anterior. Con el fin de facilitar el desarrollo posterior, se debe llegar a un nivel de descomposición en el que los procesos obtenidos sean claros y sencillos, es decir, buscar un punto de equilibrio en el que dichos procesos tengan significado por sí mismos dentro del sistema global y a su vez la máxima independencia y simplicidad. Se recomienda el uso de Diagramas de Flujos de Datos, Diagramas Híbridos y Diagrama de Estructura.

DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA En esta actividad se define la arquitectura general del sistema de información, especificando las distintas particiones físicas del mismo, la descomposición lógica en subsistemas de diseño y la ubicación de cada subsistema en cada partición, así como la especificación detallada de la infraestructura tecnológica necesaria para dar soporte al sistema de información. El particionamiento físico del sistema de información se especifica identificando los nodos y las comunicaciones entre los mismos, con cierta independencia de la infraestructura tecnológica que da soporte a cada nodo. Con el fin de organizar y facilitar el diseño, se realiza una división del sistema de información en subsistemas de diseño, como partes lógicas coherentes y con interfaces claramente definidas. Se establece una distinción entre subsistemas específicos del sistema de información (en adelante, subsistemas específicos) y subsistemas de soporte, con la finalidad de independizar, en la medida de lo posible, las funcionalidades a cubrir por el sistema de información de la infraestructura que le da soporte. En la mayoría de los casos, los subsistemas específicos provienen directamente de las especificaciones de análisis y de los subsistemas de análisis, mientras que los subsistemas de soporte provienen de la necesidad de interacción del sistema de información con la infraestructura y con el resto de los sistemas, así como de la reutilización de módulos o subsistemas ya existentes en la instalación. Debido a que la definición de los subsistemas de soporte puede exigir la participación de distintos perfiles técnicos, se propone el diseño de ambos tipos de subsistemas en actividades distintas, aunque en paralelo. Una vez identificados y definidos los distintos subsistemas de diseño, se determina su ubicación óptima de acuerdo a la arquitectura propuesta. La asignación de dichos subsistemas a cada nodo permite disponer, en función de la carga de proceso y comunicación existente entre los nodos, de la información necesaria para realizar una estimación de las necesidades de infraestructura tecnológica que da soporte al sistema de información. Este factor es especialmente crítico en arquitecturas multinivel o cliente/servidor, donde las comunicaciones son determinantes en el rendimiento final del sistema.

63 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

Se propone crear un catálogo de excepciones en el que se especifiquen las situaciones anómalas o secundarias en el funcionamiento y ejecución del sistema de información, y que se irá completando a medida que se avance en el diseño detallado de los subsistemas En esta actividad también se establecen los requisitos, normas y estándares originados como consecuencia de la adopción de una determinada solución de arquitectura o infraestructura, que serán aplicables tanto en este proceso como en la Construcción del Sistema de Información. Se detallan a su vez, de acuerdo a las particularidades de la arquitectura del sistema propuesta, los requisitos de operación, seguridad y control, especificando los procedimientos necesarios para su cumplimiento. Como resultado de esta actividad, se actualizan los catálogos de requisitos y normas, y se generan los siguientes productos:  Diseño de la Arquitectura del Sistema, como producto que engloba el particionamiento físico del sistema de información y la descripción de subsistemas de diseño.  Entorno Tecnológico del Sistema, que a su vez comprende la especificación del entorno tecnológico, las restricciones técnicas y la planificación de capacidades.  Catálogo de Excepciones.  Procedimientos de Operación y Administración del Sistema.  Procedimientos de Seguridad y Control de Acceso.

GENERACIÓN DE ESPECIFICACIONES DE CONSTRUCCIÓN En esta actividad se generan las especificaciones para la construcción del sistema de información, a partir del diseño detallado. Estas especificaciones definen la construcción del sistema de información a partir de las unidades básicas de construcción (en adelante, componentes), entendiendo como tales unidades independientes y coherentes de construcción y ejecución, que se corresponden con un empaquetamiento físico de los elementos del diseño de detalle, como pueden ser módulos, clases o especificaciones de interfaz. La división del sistema de información en subsistemas de diseño proporciona, por continuidad, una primera división en subsistemas de construcción, definiendo para cada uno de ellos los componentes que lo integran. Si se considera necesario, un subsistema de diseño se podrá dividir a su vez en sucesivos niveles para mayor claridad de las especificaciones de construcción. Las dependencias entre subsistemas de diseño proporcionan información para establecer las dependencias entre los subsistemas de construcción y, por lo tanto, definir el orden o secuencia que se debe seguir en la construcción y en la realización de las pruebas. También se generan las especificaciones necesarias para la creación de las estructuras de datos en los gestores de bases de datos o sistemas de ficheros. El producto resultante de esta actividad es el conjunto de las especificaciones de construcción del sistema de información, que comprende:  Especificación del entorno de construcción.  Descripción de subsistemas de construcción y dependencias.  Descripción de componentes.  Plan de integración del sistema de información.  Especificación detallada de componentes.  Especificación de la estructura física de datos.

Prototipo Realización de prototipo 64 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

INPUT - Especificación Técnica de Detalle (Diseño detallado)

OUTPUT - Prototipo

ACTORES - Líder funcional - Líder informático - Proveedor

RESPONSABLE - Líder informático

DEFINICIÓN DE INTERFACES DE USUARIO En esta actividad se especifican las interfaces entre el sistema y el usuario: formatos de pantallas, diálogos, e informes, principalmente. El objetivo es realizar un análisis de los procesos del sistema de información en los que se requiere una interacción del usuario, con el fin de crear una interfaz que satisfaga todos los requisitos establecidos, teniendo en cuenta los diferentes perfiles a quiénes va dirigido. Al comienzo de este análisis es necesario seleccionar el entorno en el que es operativa la interfaz, considerando estándares internacionales y de la instalación, y establecer las directrices aplicables en los procesos de diseño y construcción. El propósito es construir una interfaz de usuario acorde a sus necesidades, flexible, coherente, eficiente y sencilla de utilizar, teniendo en cuenta la facilidad de cambio a otras plataformas, si fuera necesario. Se identifican los distintos grupos de usuarios de acuerdo con las funciones que realizan, conocimientos y habilidades que poseen, y características del entorno en el que trabajan. La identificación de los diferentes perfiles permite conocer mejor las necesidades y particularidades de cada uno de ellos. Asimismo, se determina la naturaleza de los procesos que se llevan a cabo (en lotes o en línea). Para cada proceso en línea se especifica qué tipo de información requiere el usuario para completar su ejecución realizando, para ello, una descomposición en diálogos que refleje la secuencia de la interfaz de pantalla tipo carácter o pantalla gráfica. Finalmente, se define el formato y contenido de cada una de las interfaces de pantalla especificando su comportamiento dinámico. Como resultado de esta actividad se genera la especificación de interfaz de usuario, como producto que engloba los siguientes elementos:  Principios generales de la interfaz.  Catálogo de perfiles de usuario.  Descomposición funcional en diálogos.  Catálogo de controles y elementos de diseño de interfaz de pantalla.  Formatos individuales de interfaz de pantalla.  Modelo de navegación de interfaz de pantalla.  Formatos de impresión.  Prototipo de interfaz interactiva.  Prototipo de interfaz de impresión.

DISEÑO DE LA ARQUITECTURA DE SOPORTE En esta actividad se lleva a cabo la especificación de la arquitectura de soporte, que comprende el diseño de los subsistemas de soporte identificados en la actividad de Definición de la Arquitectura del Sistema, y la determinación de los mecanismos genéricos de diseño. Estos últimos sirven de guía en la utilización de diferentes estilos de diseño, tanto en el ámbito global del sistema de información, como en el diseño de detalle. El diseño de los subsistemas de soporte, conceptualmente, es similar al diseño de los subsistemas específicos, aunque debe cumplir con unos objetivos claros de reutilización. De esta manera, se consigue simplificar y abstraer el diseño de los subsistemas específicos de la complejidad del entorno tecnológico, dotando al sistema de información de una mayor independencia de la infraestructura que le da soporte. 65 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

Con este fin, se aconseja la consulta de los datos de otros proyectos existentes, disponible en el Histórico de Proyectos. Si esto no fuera suficiente, se puede contar en esta actividad con la participación de perfiles técnicos, con una visión global de la instalación. Esta actividad se realiza en paralelo al diseño detallado, debido a que existe una constante realimentación, tanto en la especificación de los subsistemas con sus interfaces y dependencias, como en la aplicación de esqueletos o patrones en el diseño. Los productos resultantes de esta actividad son:  Diseño Detallado de los Subsistemas de Soporte.  Mecanismos Genéricos de Diseño y Construcción.

DISEÑO DE CASOS DE USO REALES Esta actividad, que se realiza solo en el caso de Diseño Orientado a Objetos, tiene como propósito especificar el comportamiento del sistema de información para un caso de uso, mediante objetos o subsistemas de diseño que interactúan, y determinar las operaciones de las clases e interfaces de los distintos subsistemas de diseño. Para ello, una vez identificadas las clases participantes dentro de un caso de uso, es necesario completar los escenarios que se recogen del análisis, incluyendo las clases de diseño que correspondan y teniendo en cuenta las restricciones del entorno tecnológico, esto es, detalles relacionados con la implementación del sistema. Es necesario analizar los comportamientos de excepción para dichos escenarios. Algunos de ellos pueden haber sido identificados en el proceso de análisis, aunque no se resuelven hasta este momento. Dichas excepciones se añadirán al catálogo de excepciones para facilitar las pruebas. Algunos de los escenarios detallados requerirán una nueva interfaz de usuario. Por este motivo es necesario diseñar el formato de cada una de las pantallas o impresos identificados. Es importante validar que los subsistemas definidos en la tarea Identificación de Subsistemas de Diseño tienen la mínima interfaz con otros subsistemas. Por este motivo, se elaboran los escenarios al nivel de subsistemas y, de esta forma, se delimitan las interfaces necesarias para cada uno de ellos, teniendo en cuenta toda la funcionalidad del sistema que recogen los casos de uso. Además, durante esta actividad pueden surgir requisitos de implementación, que se recogen en el catálogo de requisitos.

DISEÑO DE CLASES El propósito de esta actividad, que se realiza sólo en el caso de Diseño Orientado a Objetos, es transformar el modelo de clases lógico, que proviene del análisis, en un modelo de clases de diseño. Dicho modelo recoge la especificación detallada de cada una de las clases, es decir, sus atributos, operaciones, métodos, y el diseño preciso de las relaciones establecidas entre ellas, bien sean de agregación, asociación o jerarquía. Para llevar a cabo todos estos puntos, se tienen en cuenta las decisiones tomadas sobre el entorno tecnológico y el entorno de desarrollo elegido para la implementación. Se identifican las clases de diseño, que denominamos clases adicionales, en función del estudio de los escenarios de los casos de uso, que se está realizando en paralelo en la actividad Diseño de Casos de Uso Reales, y aplicando los mecanismos genéricos de diseño que se consideren convenientes por el tipo de especificaciones tecnológicas y de desarrollo. Entre ellas se encuentran clases abstractas, que integran características comunes con el objetivo de especializarlas en clases derivadas. Se diseñan las clases de interfaz de usuario, que provienen del 66 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

análisis. Como consecuencia del estudio de los escenarios secundarios que se está realizando, pueden aparecer nuevas clases de interfaz. También hay que considerar que, por el diseño de las asociaciones y agregaciones, pueden aparecer nuevas clases, o desaparecer incluyendo sus atributos y métodos en otras, si se considera conveniente por temas de optimización. La jerarquía entre las clases se va estableciendo a lo largo de esta actividad, a medida que se van identificando comportamientos comunes en las clases, aunque haya una tarea propia de diseño de la jerarquía. Otro de los objetivos del diseño de las clases es identificar para cada clase, los atributos, las operaciones que cubren las responsabilidades que se identificaron en el análisis, y la especificación de los métodos que implementan esas operaciones, analizando los escenarios del Diseño de Casos de Uso Reales. Se determina la visibilidad de los atributos y operaciones de cada clase, con respecto a las otras clases del modelo. Una vez que se ha elaborado el modelo de clases, se define la estructura física de los datos correspondiente a ese modelo, en la actividad Diseño Físico de Datos. Además, en los casos en que sea necesaria una migración de datos de otros sistemas o una carga inicial de información, se realizará su especificación a partir del modelo de clases y las estructuras de datos de los sistemas origen. Como resultado de todo lo anterior se actualiza el modelo de clases del análisis, una vez recogidas las decisiones de diseño.

VERIFICACIÓN Y ACEPTACIÓN DE LA ARQUITECTURA DEL SISTEMA El objetivo de esta actividad es garantizar la calidad de las especificaciones del diseño del sistema de información y la viabilidad del mismo, como paso previo a la generación de las especificaciones de construcción. Para cumplir dicho objetivo, se llevan a cabo las siguientes acciones:  Verificación de la calidad técnica de cada modelo o especificación  Aseguramiento de la coherencia entre los distintos modelos  Aceptación del diseño de la arquitectura por parte de Explotación y Sistemas. Esta actividad es compleja, por lo que es aconsejable utilizar herramientas de apoyo para la realización de sus tareas.

Elaboración del Plan de Pruebas Técnicas Definición de la estrategia y elaboración del Plan de Pruebas Técnicas en base al Especificación Técnica de Detalle. Ver estrategia de pruebas. INPUT - Especificación Técnica de Detalle (Diseño detallado)

OUTPUT - Plan de Pruebas Técnicas

ACTORES Líder informático Líder funcional Experto tecnológico Experto informático Experto en seguridad informática - Proveedor -

RESPONSABLE - Líder informático

67 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

En esta actividad se inicia la definición del plan de pruebas, el cual sirve como guía para la realización de las pruebas, y permite verificar que el sistema de información cumple las necesidades establecidas por el usuario, con las debidas garantías de calidad. El plan de pruebas es un producto formal que define los objetivos de la prueba de un sistema, establece y coordina una estrategia de trabajo, y provee del marco adecuado para elaborar una planificación paso a paso de las actividades de prueba. El plan se inicia en el proceso Análisis del Sistema de Información, definiendo el marco general, y estableciendo los requisitos de prueba de aceptación, relacionados directamente con la especificación de requisitos. Dicho plan se va completando y detallando a medida que se avanza en los restantes procesos del ciclo de vida del software, Diseño del Sistema de Información, Construcción del Sistema de Información e Implantación y Aceptación del Sistema. Se plantean los siguientes niveles de prueba:  Pruebas unitarias.  Pruebas de integración.  Pruebas del sistema.  Pruebas de implantación.  Pruebas de aceptación. En esta actividad también se avanza en la definición de las pruebas de aceptación del sistema. Con la información disponible, es posible establecer los criterios de aceptación de las pruebas incluidas en dicho nivel, al poseer la información sobre los requisitos que debe cumplir el sistema, recogidos en el catálogo de requisitos.

Plan de contingencia y de desastre – Plan de Backup Construcción del plan de contingencia y de desastre y del plan de backup. INPUT - Especificación Técnica de Detalle (Diseño detallado)

OUTPUT - Plan de Contingencia y de Desastre - Plan de Backup

ACTORES Líder informático Líder funcional Experto tecnológico Experto informático Experto en seguridad informática - Proveedor -

RESPONSABLE - Líder informático

Documentación Operativa Generación de la documentación que contenga los aspectos operativos y de seguridad necesarios para la puesta en producción y mantenimiento del sistema. Esta documentación se irá completando hasta la Puesta en Producción. INPUT - Especificación Técnica de Detalle (Diseño detallado)

OUTPUT - Documento de Soporte a Mesa de Ayuda - Documento de Soporte a Operaciones/Soport e Técnico

-

ACTORES Líder informático Líder funcional Experto tecnológico Experto informático Experto en seguridad informática

RESPONSABLE - Líder informático

68 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

- Proveedor

Definición del Procedimiento de Gestión de Configuración Se define un procedimiento de Gestión de Configuración mediante el cual se establecen los mecanismos para realizar modificaciones o actualizaciones a cualquier elemento producido durante el ciclo de vida del un proyecto y su posterior mantenimiento. El objetivo fundamental es el de establecer y mantener la integridad y control de los documentos y productos de software a través del ciclo de vida de un proyecto y durante el mantenimiento del mismo una vez puesto en producción. Implica definir aspectos técnicos y administrativos del manejo de los elementos que se establece que estarán bajo el procedimiento de Gestión de Configuración. INPUT - Arquitectura técnica - Especificación técnica - Plan General de Trabajo - Equipo de Trabajo

OUTPUT - Procedimiento de Gestión de Configuración

ACTORES - Líder Informático - Experto Informático

RESPONSABLE - Líder Informático

ETAPA: DEFINICIÓN DE ESTRATEGIAS Impacto Organizacional 4 Identificar con tiempo suficiente los impactos en la Organización que genera un cambio de Sistemas/Procesos a efectos de poder planear acciones de cambio. Se tomará como base el ítem “Impacto” del documento “Estudio de Factibilidad Técnico/Funcional” generado en la fase de Estudio Preliminar. INPUT - Especificación Técnica de Detalle (Diseño detallado) - Estudio de Factibilidad Técnico/Funcional

OUTPUT - Impacto Organizacional

ACTORES - Líder funcional - Usuarios - Responsable de Soporte al cambio

RESPONSABLE - Líder funcional

Estrategia de implantación Definir la estrategia de implantación del proyecto. Identificar el modo de implantación: big bang, roll-out (en etapas). Definir fases y releases. INPUT - Especificación técnica de detalle (Diseño detallado) - Impacto Organizacional

OUTPUT - Estrategia de implantación

ACTORES - Líder funcional - Líder informático

RESPONSABLE - Líder funcional

Notas: 4 La ubicación de esta tarea en la Etapa de Diseño Detallado, responde a una cuestión temporal.

69 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

Elaboración del Plan de Pruebas Funcionales Definición de la estrategia y elaboración del Plan de Pruebas Funcionales, Armado de Condiciones de 5 Prueba, Armado de Set de Datos, Set de Pruebas , Estrategia de Prueba. INPUT - Impacto Organizacional - Especificación técnica de detalle (Diseño detallado)

OUTPUT - Plan de Pruebas 6 Funcionales

ACTORES - Líder funcional - Usuarios - Líder informático

RESPONSABLE - Líder funcional

Especificación del Entorno de Pruebas El objetivo de esta tarea es la definición detallada y completa del entorno necesario para la realización de las pruebas del sistema: unitarias, de integración, de implantación y de aceptación. Se propone considerar los siguientes conceptos en la especificación del entorno:  Entorno tecnológico: hardware, software y comunicaciones.  Restricciones técnicas del entorno.  Requisitos de operación y seguridad del entorno de pruebas.  Herramientas de prueba relacionadas con la extracción de juegos de ensayo, análisis de resultados, utilidades de gestión del entorno, etc.  Planificación de capacidades previstas, o la información que estime oportuno el departamento técnico para efectuar dicha planificación.  Procedimientos de promoción de elementos entre entornos (desarrollo, pruebas, explotación, etc.).  Procedimientos de emergencia y de recuperación, así como de vuelta atrás.

Estrategia de Migración, Confiabilización, Conversión de Datos y Carga inicial de Datos Definir la estrategia de confiabilización. INPUT - Especificación técnica de detalle (Diseño detallado) - Estrategia de Implantación

OUTPUT - Estrategia de confiabilización - Estrategia de conversión de datos

-

ACTORES Líder funcional Líder informático Proveedor Experto informático

RESPONSABLE - Líder funcional

DISEÑO DE LA MIGRACIÓN Y CARGA INICIAL DE DATOS Esta actividad sólo se lleva a cabo cuando es necesaria una carga inicial de información, o una migración de datos de otros sistemas, cuyo alcance y estrategia a seguir se habrá establecido previamente. Para ello, se toma como referencia el plan de migración y carga inicial de datos, que recoge las estructuras físicas de datos del sistema o sistemas origen implicadas en la conversión, la prioridad en las cargas y secuencia a seguir, las necesidades previas de depuración de la información, así como los requisitos necesarios para garantizar la correcta implementación de los procedimientos de migración sin comprometer el funcionamiento de los sistemas actuales.

Notas: 5 De acuerdo a las Normas vigentes, los datos de Producción deberán tener la aprobación del Administrador Funcional 6 La descripción de la estrategia de pruebas funcionales está incluida en el documento general del plan de pruebas dentro del Anexo Carpeta de Proyectos.

70 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

A partir de dicho plan, y de acuerdo a la estructura física de los datos del nuevo sistema, obtenida en la actividad Diseño Físico de Datos, y a las características de la arquitectura y del entorno tecnológico propuesto en la actividad Definición de la Arquitectura del Sistema, se procede a definir y diseñar en detalle los procedimientos y procesos necesarios para realizar la migración. Se completa el plan de pruebas específico establecido en el plan de migración y carga inicial, detallando las pruebas a realizar, los criterios de aceptación o rechazo de la prueba y los responsables de la organización, realización y evaluación de resultados. Asimismo, se determinan las necesidades adicionales de infraestructura, tanto para la implementación de los procesos como para la realización de las pruebas. Como resultado de esta actividad, se actualiza el plan de migración y carga inicial de datos con la información siguiente:  Especificación del entorno de migración.  Definición de procedimientos de migración.  Diseño detallado de módulos.  Especificación técnica de las pruebas.  Planificación de la migración y carga inicial. Es importante considerar que una carga inicial de información no tiene el mismo alcance y complejidad que una migración de datos, de modo que las tareas de esta actividad se deben llevar a cabo en mayor o menor medida en función de las características de los datos a cargar.

Plan Acción para el Cambio 7 Estrategia de Desarrollo y organización (cambios de especialidades, competencias, estructuras, procesos de trabajo, etc.) INPUT - Impacto Organizacional - Estrategia de Implantación

OUTPUT - Plan de Acción para el Cambio

ACTORES - Líder funcional - Usuarios - Responsable de Capacitación

RESPONSABLE - Responsable Soporte al Cambio

Plan de Capacitación 8 Elaboración del Plan de Capacitación Lanzamiento de todas las tareas de preparación previas a la capacitación (logística, manuales, ambientes, comunicación de la capacitación, definición de la modalidad de capacitación, herramientas, etc.) INPUT - Impacto Organizacional - Estrategia de Implantación

OUTPUT - Plan de Capacitación

-

ACTORES Líder funcional Usuarios Líder informático Responsable de Capacitación

RESPONSABLE - Responsable de Capacitación

Notas: 7 La ubicación de esta tarea en la Etapa de Diseño Detallado, responde a una cuestión temporal. Sin embargo, la culminación de la misma, deberá haberse cumplido previo a la implantación. 8 La ubicación de esta tarea en la Etapa de Diseño Detallado, responde a una cuestión temporal. Sin embargo, la culminación de la misma, deberá haberse cumplido previo a la implantación.

71 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

Plan de Comunicación 9 Elaboración del Plan de Comunicación INPUT - Impacto Organizacional - Estrategia de Implantación

OUTPUT - Plan de Comunicación

ACTORES - Líder funcional - Usuarios - Responsable de Soporte al Cambio

RESPONSABLE - Responsable Soporte al Cambio

Notas: 9 La ubicación de esta tarea en la Etapa de Diseño Detallado, responde a una cuestión temporal. Sin embargo, la culminación de la misma, deberá haberse cumplido previo a la implantación.

72 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

HITO 3: APROBACIÓN DISEÑO DETALLADO El líder funcional analizará, revisará y convalidará la Especificación Técnica de Detalle. INPUT: OUTPUT: ACTORES:

RESPONSABLE: -

Todos los entregables de la fase Convalidación de entregables de la fase Líder informático Líder funcional Usuario Líder funcional

Check-list 

Documentos:  Especificación técnica de Detalle (Diseño detallado)  Plan Detallado de Trabajo  Plan de Pruebas Técnicas  Plan de Contingencia y de Desastre  Plan de Backup  Impacto Organizacional  Estrategia de Implantación  Estrategia de Confiabilización  Estrategia de Conversión de Datos  Estrategia de Carga de Datos  Plan de Acción para el Cambio  Plan de Capacitación  Plan de Comunicación

“APROBACIÓN DISEÑO DETALLADO” constituye el HITO 3 de validación del Owner del Proyecto.

73 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

FASE: CONSTRUCCIÓN

74 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

FASE: CONSTRUCCIÓN FASE

C O N S T R U C C I Ó N

ETAPAS

TAREAS

ENTREGABLES

COORDINADOR

PARAMETRIZACIÓN Y DESARROLLO

- Desarrollo de Programas - Adecuaciones de Programas - Parametrización - Elaboracion Manuales de Sistemas - Elaboracion Manuales de Usuario - Elaboración Manual de Procesos

- Programas, Módulos & Parametrización - Manual de Sistemas - Manual de Usuario - Manual de Procesos

Líder Informático

PRUEBAS

- Prueba Individual - Prueba de Cadena - Prueba de Integración - Prueba Global - Prueba de Perf., stress, volumen & seguridad - Pruebas de Compatibilidad

- Protocolos de Prueba - Aprobación de Pruebas

Líder Informático

PRUEBA PILOTO

- Preparación - Prueba Piloto - Homologación Prueba Piloto

- Protocolo de Prueba Piloto - Homologación Prueba Piloto

Líder Funcional

DEFINICIÓN PLAN DE IMPLANTACIÓN

- Revisión del Acuerdo de Servicio y Alcance - Plan de Implantación - Plan de Soporte - Elaboración Protocolo de Implantación - Definición Procedimiento de Producción - Actualización Gestión de Configuración

- Acuerdo de Servicio Revisado - Plan de Implantación - Plan de Soporte - Protocolo de Implantación - Procedimiento de Producción - Proc. Gestión de Configuración actualizado

Líder Funcional

- Acuerdo de Implantación

HITO 4: DECISIÓN DE IMPLANTACIÓN

La construcción del Sistema de Información tiene como objetivo final el desarrollo y prueba de los distintos componentes del sistema de información, a partir del conjunto de especificaciones lógicas y físicas del mismo, obtenido en el Proceso de Diseño global y detallado del Sistema de Información. Se desarrollan los procedimientos de operación y seguridad y se elaboran los manuales de usuario final y de explotación, estos últimos cuando proceda. Para conseguir dicho objetivo, se recoge la información relativa al producto del diseño Especificaciones de construcción, se prepara el entorno de construcción, se genera el código (programación) de cada uno de los componentes del sistema y se van realizando (a medida que se vaya finalizando la programación) las pruebas unitarias de cada uno de los componentes y las de integración entre subsistemas si las hubiere. Si fuera necesario realizar una migración de datos, es en este proceso donde se lleva a cabo la construcción de los componentes de migración, los procedimientos de migración y carga inicial de datos. Como resultado de dicho proceso se obtiene: •

Resultado de las pruebas unitarias.

•

Evaluación del resultado de las pruebas de integración.

•

Evaluación del resultado de las pruebas del sistema.

•

Producto software: 75 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García



Código fuente de los componentes.



Procedimientos de operación y administración del sistema.



Procedimientos de seguridad y control de acceso.



Manuales de usuario.



Especificación de la formación a usuarios finales.



Código fuente de los componentes de migración y carga inicial de datos.



Procedimientos de migración y carga inicial de datos.



Evaluación del resultado de las pruebas de migración y carga inicial de datos.

ETAPA: PARAMETRIZACIÓN Y DESARROLLO Desarrollo de Programas - Adecuación de Programas – Parametrización – Elaboración de Manuales de Sistemas Desarrollo y codificación de la funcionalidad del sistema. Actualización de Documentación de Sistemas. Elaboración Manuales de Sistemas Control y Seguimiento del Desarrollo INPUT - Especificación Técnica de Detalle (Diseño detallado)

OUTPUT ACTORES - Programas, Módulos - Líder informático & Parametrización - Proveedor - Manual de Sistemas

RESPONSABLE - Líder informático

PREPARACIÓN DEL ENTORNO DE GENERACIÓN Y CONSTRUCCIÓN El objetivo de esta actividad es asegurar la disponibilidad de todos los medios y facilidades para que se pueda llevar a cabo la construcción del sistema de información. Entre estos medios, cabe destacar la preparación de los puestos de trabajo, equipos físicos y lógicos, gestores de bases de datos, bibliotecas de programas, herramientas de generación de código, bases de datos o ficheros de prueba, entre otros. Las características del entorno de construcción y sus requisitos de operación y seguridad, así como las especificaciones de construcción de la estructura física de datos, se establecen en la actividad Generación de Especificaciones de Construcción, y constituyen el punto de partida para la realización de esta actividad.

GENERACIÓN DEL CÓDIGO DE LOS COMPONENTES Y PROCEDIMIENTOS El objetivo de esta actividad es la codificación de los componentes del sistema de información, a partir de las especificaciones de construcción obtenidas en el proceso Diseño del Sistema de Información, así como la construcción de los procedimientos de operación y seguridad establecidos para el mismo. En paralelo a esta actividad, se desarrollan las actividades relacionadas con las pruebas unitarias y de integración del sistema de información. Esto permite una construcción incremental, en el caso de que así se haya especificado en el plan de pruebas y en el plan de integración del sistema de información.

CONSTRUCCIÓN DE LOS COMPONENTES Y PROCEDIMIENTOS DE MIGRACIÓN Y CARGA INICIAL DE DATOS

76 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

El objetivo de esta actividad es la codificación y prueba de los componentes y procedimientos de migración y carga inicial de datos, a partir de las especificaciones recogidas en el plan de migración y carga inicial de datos obtenido en el proceso Diseño del Sistema de Información. Previamente a la generación del código, se prepara la infraestructura tecnológica necesaria para realizar la codificación y las pruebas de los distintos componentes y procedimientos asociados, de acuerdo a las características del entorno de migración especificado en el plan de migración y carga inicial de datos. Finalmente, se llevan a cabo las verificaciones establecidas en la especificación técnica del plan de pruebas propio de la migración.

Elaboración de Manuales de Usuario Elaboración Manuales de Usuario. INPUT - Especificación Técnica de Detalle (Diseño detallado)

OUTPUT - Manual de Usuario

ACTORES - Líder informático - Líder funcional - Responsable de Capacitación - Proveedor

RESPONSABLE - Líder funcional

Elaboración de los Manuales de Usuario El objetivo de esta tarea es elaborar la documentación de usuario, tanto usuario final como de explotación, de acuerdo a los requisitos establecidos en la tarea Especificación de Requisitos de Documentación de Usuario, y recogidos en el catálogo de requisitos. Los requisitos de documentación especifican aspectos relativos a los tipos de documentos a elaborar y estándares a seguir en la generación de los mismos, y para cada uno de ellos:  Formato y soporte en el que se desarrollarán  Estructura  Distribución y mantenimiento de la documentación y número de copias a editar.

Elaboración del Manual de Procesos Describir los nuevos circuitos de información de acuerdo a la forma de operación del nuevo sistema de información que implementará. El manual se basa en los procesos/sub-procesos definidos en la especificación funcional. INPUT - Especificación funcional (F1) - Especificación Técnica de Detalle (Diseño detallado)

OUTPUT - Manual de Procesos

ACTORES RESPONSABLE - Experto en procesos - Líder funcional - Líder funcional - Responsable de capacitación

ETAPA: PRUEBAS Para cada una de las funciones del sistema se realizará el protocolo de acuerdo al Plan de Pruebas (Técnicas o Funcionales) definido en la Fase de Diseño Detallado.

EJECUCIÓN DE LAS PRUEBAS INDIVIDUALES

77 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

En esta actividad se realizan las pruebas unitarias de cada uno de los componentes del sistema de información, una vez codificados, con el objeto de comprobar que su estructura es correcta y que se ajustan a la funcionalidad establecida. En el plan de pruebas se ha definido el entorno necesario para la realización de cada nivel de prueba, así como las verificaciones asociadas a las pruebas unitarias, la coordinación y secuencia a seguir en la ejecución de las mismas y los criterios de registro y aceptación de los resultados.

Prueba Individual Prueba Unitaria de Módulos y Programa. (Cabe aclarar que esta prueba podría realizarse en la etapa de desarrollo). Las pruebas unitarias no requieren de datos operativos dado que el objetivo que se desea alcanzar es comprobar el funcionamiento lógico del componente. De todos modos resulta deseable que los datos utilizados conlleven la coherencia de las reglas de negocio que el sistema debe tratar en producción. Asegurar el correcto funcionamiento de cada módulo en forma aislada utilizando dos enfoques: prueba de caja blanca y prueba de caja negra (ver glosario) INPUT - Plan de Pruebas Técnicas

OUTPUT - Protocolo de Prueba - Aprobación de Prueba

ACTORES - Líder informático

RESPONSABLE - Líder informático

Prueba de Cadena Asegurar el correcto funcionamiento de un conjunto de módulos componentes del sistema que se relacionan entre sí y que cumplen una funcionalidad única dentro del mismo. Asegurar la correcta integración entre módulos y sus interfaces. Generar un informe de los casos de prueba que en la prueba unitaria por motivos técnicos no pudieron ser generados a fin de que en las pruebas globales se ponga mayor atención a los resultados de estas. INPUT - Plan de Pruebas Técnicas

OUTPUT - Protocolo de Prueba - Aprobación de Prueba

ACTORES - Líder informático

RESPONSABLE - Líder informático

Prueba de Integración Probar la integridad técnica del sistema en su totalidad, incluyendo todas las interfaces que el sistema genera entre módulos propios y hacia otros sistemas sin que estas últimas sean necesariamente procesadas por otros sistemas (esto se realiza en la prueba global). INPUT - Plan de Pruebas Técnicas

OUTPUT - Protocolo de Prueba - Aprobación de Prueba

ACTORES - Líder informático

RESPONSABLE - Líder informático

EJECUCIÓN DE LAS PRUEBAS DE INTEGRACIÓN El objetivo de las pruebas de integración es verificar si los componentes o subsistemas interactúan correctamente a través de sus interfaces, tanto internas como externas, cubren la funcionalidad establecida, y se ajustan a los requisitos especificados en las verificaciones correspondientes. Particularmente los analistas que participan de esta prueba deben verificar el correcto impacto en la registración de los datos en la base de datos utilizada; por esta razón estos analistas funcionales deben poseer un conocimiento detallado del modelo de datos del sistema y el diseño de datos de las interfaces con sistemas externos. 78 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

La estrategia a seguir en las pruebas de integración se establece en el plan de pruebas, dónde se habrá tenido en cuenta el plan de integración del sistema de información, siempre y cuando se haya especificado en la tarea Definición de Componentes y Subsistemas de Construcción. Esta actividad se puede realizar en paralelo a las actividades Generación del Código de los Componentes y elaboración de los Procedimientos y Ejecución de las Pruebas Unitarias. Sin embargo, es necesario que los componentes objeto de las pruebas de integración se hayan verificado de manera unitaria.

Prueba Global Prueba funcional en ambiente de prueba con los siguientes objetivos: - Asegurar que las funcionalidades introducidas funcionan según los requerimientos especificados por los usuarios. - Probar la integridad funcional y técnica entre los sistemas impactados por la implantación del nuevo sistema (incluye interfaces entre sistemas). - Probar las Interfaces con otros sistemas. - Llevar adelante la Prueba de Aceptación del usuario - Asegurar que los beneficios acordados con el usuario son producidos por el sistema - Asegurar que cada Evento de Negocio funciona a lo largo de las aplicaciones. El líder informático es responsable de ejecutar la prueba. El líder funcional es responsable de redactar el informe de prueba y aprobar la misma. INPUT - Plan de Pruebas Funcionales

OUTPUT - Protocolo de Prueba - Aprobación de Prueba

ACTORES - Líder informático - Líder funcional - Usuarios

RESPONSABLE - Líder funcional

EJECUCIÓN DE LAS PRUEBAS GLOBALES DEL SISTEMA El objetivo de las pruebas del sistema es comprobar la integración del sistema de información globalmente, verificando el funcionamiento correcto de las interfaces entre los distintos subsistemas que lo componen y con el resto de sistemas de información con los que se comunica. En la realización de estas pruebas es importante comprobar la cobertura de los requisitos, dado que su incumplimiento puede comprometer la aceptación del sistema por el equipo de operación responsable de realizar las pruebas de implantación del sistema, que se llevarán a cabo en el proceso Implantación y Aceptación del Sistema.

Prueba de Performance, Volumen, Stress y Seguridad Pruebas de Performance, Volumen, Stress y Seguridad INPUT - Plan de Pruebas Técnicas

OUTPUT - Protocolo de Prueba - Aprobación de Prueba

-

ACTORES Líder informático Líder funcional Usuarios Experto informático Experto en seguridad informática

RESPONSABLE - Líder informático

Prueba de Compatibilidad Pruebas de compatibilidad con los sistemas actuales o próximos a implementarse. (Se participará a estas pruebas a los administradores funcionales de los sistemas involucrados) 79 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

INPUT - Plan de Pruebas Técnicas

OUTPUT - Protocolo de Prueba - Aprobación de Prueba

-

ACTORES Líder informático Líder funcional Experto informático Administrador funcional

RESPONSABLE - Líder informático

ETAPA: PRUEBAS PILOTO Preparación Preparar las pruebas piloto. Dado que se trata de una prueba en producción y con datos de producción, se llevarán adelante tareas previas a la puesta en Producción de un sistema, pero circunscriptas al contexto de la prueba piloto. 1. Armar el plan de Implantación de Prueba Piloto - Definición de Usuarios y Perfiles - Incorporar el sistema al circuito de solicitud de claves de acceso 2. Preparación de la implantación (referidas a los datos y actores involucrados en la prueba piloto) (Los inputs, outputs, actores y responsables de estas tareas son los descriptos en la Etapa “Preparación de la implantación” de la fase “Implantación”) - Ejecución de Confiabilización de Datos - Conversión de Datos - Aprobación de Conversión de Datos - Carga Inicial de los datos y Parametrización - Capacitación a los sectores técnicos y funcionales impactados - Comunicación a los sectores técnicos y funcionales impactados 3. Preparar el sitio: - Preparación de documentación. - Instalación de los productos/software. - Escribir los procedimientos. - Instructivos de instalación

Prueba Piloto Llevar adelante la prueba piloto propiamente dicha. INPUT - Plan de Pruebas funcionales - Plan de pruebas técnicas - Aprobación de Prueba Global - Aprobación de Prueba de Performance, Volumen, Stress y Seguridad - Aprobación de Prueba de Compatibilidad

OUTPUT - Protocolo de Prueba Piloto

ACTORES - Líder informático - Líder funcional - Administrador funcional - Usuario

RESPONSABLE - Líder funcional

Homologación Prueba Piloto Aprobación Prueba Piloto. 80 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

INPUT OUTPUT - Protocolo de Prueba - Homologación de Piloto Prueba Piloto

ACTORES - Líder informático - Líder funcional - Administrador funcional - Usuario

RESPONSABLE - Líder funcional

ETAPA: DEFINICIÓN PLAN DE IMPLANTACIÓN Revisión del Acuerdo de Servicio y Alcance De acuerdo a los resultados de las Pruebas, se evaluará y renegociará él alcance del sistema a implantar, determinándose los pendientes y sus plazos de entrega. Estas redefiniciones actualizarán el Acuerdo de Servicio del Proyecto, conformando un anexo. En proyectos de gran envergadura, la negociación del Acuerdo de Servicio será llevada a cabo por el Responsable Funcional y el Responsable Informático. INPUT - Acuerdo de Servicio - Protocolo/Aprobació n Prueba Global - Protocolo/Homologa ción Prueba Piloto

OUTPUT - Acuerdo de Servicio Revisado

ACTORES - Líder funcional - Líder informático

RESPONSABLE - Líder funcional / Líder informático

Plan de Implantación De acuerdo a la estrategia de Implantación ya definida y a los resultados de la Prueba Piloto definir el Plan de Implantación. Establecer sitios, recursos, cronogramas de implantación.

INPUT - Estrategia de Implantación - Acuerdo de Servicio Revisado

OUTPUT - Plan de Implantación -

ACTORES Líder funcional Líder informático Proveedor Administrador funcional

RESPONSABLE - Líder funcional

Plan de Soporte De acuerdo al Plan de Implantación, definir el esquema de Soporte a la Implantación. En función de las necesidades, el líder funcional y el líder informático convocarán a los actores correspondientes. INPUT OUTPUT - Plan de Implantación - Plan de Soporte

ACTORES - Líder funcional - Líder informático - Proveedor

RESPONSABLE - Líder funcional / Líder informático

Elaboración Protocolo de Implantación Elaboración del protocolo de la Implantación. (Luego de la Implantación, se llevará adelante una aceptación de la misma basándose en este protocolo) 81 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

Este protocolo deberá ser aprobado por el líder funcional del proyecto. INPUT OUTPUT - Plan de Implantación - Protocolo de Implantación

-

ACTORES Líder funcional Líder informático Proveedor Administrador funcional

RESPONSABLE - Líder funcional

Definición de Procedimiento de Producción Definir el procedimiento de producción/explotación. Comprende qué, cómo y cuándo se desarrollan las tareas de producción. INPUT - Plan de Backup - Plan de Contingencia y Desastre - Manual de Usuario - Manual de Sistemas

OUTPUT - Procedimiento de Producción

ACTORES - Líder informático - Líder funcional - Experto en seguridad informática - Experto informático

RESPONSABLE - Líder informático

Actualización del Procedimiento de Gestión de Configuración Actualizar el procedimiento de Gestión de Configuración definido en la fase de Diseño Detallado para establecer y mantener la integridad y control de los documentos y productos de software durante la implantación y el mantenimiento del mismo una vez puesto en producción. INPUT - Procedimiento de Gestión de Configuración

OUTPUT - Procedimiento de Gestión de Configuración actualizado

ACTORES - Líder Informático - Experto Informático

RESPONSABLE - Líder Informático

82 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

6.1.1.1

HITO 4: DECISIÓN DE IMPLANTACIÓN

El Líder Funcional analiza y revisa los informes de Prueba y Planes de Implantación y toma la DECISIÓN de Implantación. INPUT:

- Informes de Pruebas - Plan de Implantación - Producto homologado - Acuerdo de Servicio OUTPUT: - Acuerdo de Implantación ACTORES: - Líder informático - Líder funcional - Usuario RESPONSABLE: - Líder funcional

Check-list 

 

Documentos:  Manual de Sistemas  Manual de Usuario  Manual de Procesos  Protocolos de Prueba  Aprobación de Pruebas  Protocolo de Prueba Piloto  Homologación de Prueba Piloto  Plan de Implantación  Protocolo de Implantación  Procedimiento de Producción  Gestión de Configuración Revisión del Acuerdo de Servicio del Proyecto Definición del Equipo de Producción

“DECISIÓN DE IMPLANTACIÓN” constituye el HITO 4 de validación del Owner del Proyecto.

83 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

FASE DE IMPLANTACIÓN

84 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

FASE: IMPLANTACIÓN FASE I M P L A N T A C I O N

ETAPAS

TAREAS

ENTREGABLES

COORDINADOR

PREPARACIÓN IMPLANTACIÓN

- Ejecución de Confiabilización de Datos - Conversión de Datos - Aprobación de Conversión de Datos - Carga Inicial y Parametrización - Capacitación - Comunicación

- Aprobación Conversión Datos

PUESTA EN PRODUCCIÓN

- Realización Implantación - Aceptación Implantación

- Recepción Provisoria

- Contrato de Servicio de Producción - Documentación Puesta en Producción (Anexo el Proc. de Producción)

- Contrato de Servicio Producción - Doc. Soporte Mesa de Ayuda actualizado - Doc. Soporte a Operaciones/ Soporte actualizado

FORMALIZACIÓN PUESTA EN PRODUCCIÓN

Líder Funcional

Líder Informático

Administrador Funcional

- Informe Sistema en Producción

HITO 5: SISTEMA EN PRODUCCIÓN

Este proceso tiene como objetivo principal, la entrega y aceptación del sistema en su totalidad, que puede comprender varios sistemas de información desarrollados de manera independiente, según se haya establecido en el proceso de Estudio de Factibilidad del Sistema, y un segundo objetivo que es llevar a cabo las actividades oportunas para el paso a producción del sistema. Se establece el plan de implantación, una vez revisada la estrategia de implantación y se detalla el equipo que lo realizará. Para el inicio de este proceso se toman como punto de partida los componentes del sistema probados de forma unitaria e integrados en el proceso Construcción del Sistema de Información, así como la documentación asociada. El Sistema se someterá a las Pruebas de Implantación con la participación del usuario de operación cuya responsabilidad, entre otros aspectos, es comprobar el comportamiento del sistema bajo las condiciones más extremas. También se someterá a las Pruebas de Aceptación cuya ejecución es responsabilidad del usuario final. En este proceso se elabora el plan de mantenimiento del sistema de forma que el responsable del mantenimiento conozca el sistema antes de que éste pase a producción. También se establece el acuerdo de nivel de servicio requerido una vez que se inicie la producción. El acuerdo de nivel de servicio hace referencia a servicios de gestión de operaciones, de soporte a usuarios y al nivel con el que se prestarán dichos servicios. Como resultado de este proceso se obtienen los siguientes productos: •

Plan de implantación del sistema en su totalidad.

•

Equipo de implantación que realizará la implantación.

•

Plan de formación del equipo de implantación (esquema, materiales, recursos necesarios, planificación y especificación de la formación de usuarios finales).

•

Evaluación de las pruebas de implantación del sistema por parte del usuario de operación.

•

Evaluación de las pruebas de aceptación del sistema por parte del usuario final.

•

Plan de mantenimiento previo al paso a producción. 85 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

•

Acuerdo de nivel de servicio del sistema.

•

Sistema en producción.

ETAPA: PREPARACIÓN IMPLANTACIÓN Ejecución de Confiabilización de Datos Realizar la confiabilización de los Datos. Validar que los datos sean correctos de acuerdo al formato establecido. El Líder Funcional será responsable de convocar al Administrador Funcional y solicitar las autorizaciones que correspondan en caso de necesitar datos del sistema origen. INPUT - Estrategia de Confiabilización

OUTPUT - Datos Confiabilizados

-

ACTORES Líder funcional Líder informático Proveedor Usuario Administrador Funcional

RESPONSABLE - Líder funcional

Conversión de Datos Realizar la Conversión de los Datos del sistema origen al sistema actual. Esta conversión/migración se desarrolla con un proceso AUTOMÁTICO. El Líder Funcional será responsable de convocar al Administrador Funcional del sistema origen. INPUT OUTPUT - Estrategia de - Datos Convertidos Conversión de Datos

-

ACTORES Líder funcional Líder informático Proveedor Usuario Administrador Funcional

RESPONSABLE - Líder informático

Aprobación de la Conversión de Datos El Líder Funcional aprueba la conversión de datos realizada. El Líder Funcional será responsable de convocar al Administrador Funcional del sistema origen. INPUT OUTPUT ACTORES - Estrategia de - Aprobación de - Líder funcional Conversión de Datos Conversión de Datos - Líder informático - Datos Convertidos - Proveedor - Usuario - Administrador Funcional

RESPONSABLE - Líder funcional

Carga Inicial y Parametrización Realización de la Parametrización y Carga Inicial de los datos. Esta carga inicial se refiere a datos que no existen en otro sistema y podrá ser de carácter MANUAL o mediante un proceso AUTOMÁTICO. El líder funcional será responsable de verificar y aprobar la carga inicial. Esto no excluye la posibilidad de que informáticos ejecuten un proceso automático para la misma. 86 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

INPUT - Estrategia de Carga Inicial de datos - Datos iniciales

OUTPUT - Datos Cargados

-

ACTORES Líder funcional Líder informático Proveedor Usuario Administrador Funcional

RESPONSABLE - Líder funcional

Capacitación Capacitación de los usuarios finales, capacitadores y todos los actores involucrados en la operación del sistema. Garantizar que las tareas lanzadas en el plan de capacitación se hayan completado (logística, manuales, ambientes, comunicación de la capacitación, definición de la modalidad de capacitación, herramientas, etc.) Cabe señalar que la capacitación se podrá realizar a lo largo del ciclo de vida del proyecto de acuerdo al plan de capacitación. INPUT OUTPUT - Plan de - Personal capacitado Capacitación - Manual de Usuario - Manual de Procesos

-

ACTORES Usuario final Experto informático Proveedor Responsable de capacitación

RESPONSABLE - Responsable de Capacitación

DEFINICIÓN DE LA FORMACIÓN DE USUARIOS FINALES En esta actividad se establecen las necesidades de formación del usuario final, con el objetivo de conseguir la explotación eficaz del nuevo sistema. Para la definición de la formación hay que tener en cuenta las características funcionales y técnicas propias del sistema de información, así como los requisitos relacionados con la formación del usuario final, establecidos en la tarea Especificación de Requisitos de Implantación. El producto resultante de esta actividad es la especificación de la formación de usuarios finales, que consta de los siguientes elementos:  Esquema de formación  Materiales y entornos de formación. En el proceso Implantación y Aceptación del Sistema, se unifican las especificaciones de formación de cada sistema de información implicado en la implantación y se elabora un único plan de formación que esté alineado con el plan de implantación del sistema.

Comunicación Asegurar que el usuario final, soporte funcional, como así también todos los sectores involucrados, estén en conocimiento del alcance en cuanto a contenidos y fechas de las nuevas funcionalidades del proyecto a implantar INPUT OUTPUT - Plan de - Personal Comunicación comunicado - Plan de Implantación

ACTORES - Usuario final - Líder funcional - Administrador funcional - Responsable Soporte al Cambio

RESPONSABLE - Líder funcional

87 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

ETAPA: PUESTA EN PRODUCCIÓN La puesta en producción se llevará adelante de acuerdo al Plan de Implantación, ya sea en big bang o rollout (por etapas). En caso de tratarse de un roll-out, se realizará una puesta en producción en cada una de las etapas.

Realización Implantación Realización de la implantación con la colaboración del líder funcional y soportes (in situ, a distancia, soporte de las mesas de ayuda funcional, etc.) Esta tarea implica la implantación del sistema en forma total (en caso de big bang) o de una de sus etapas (roll-out). INPUT OUTPUT - Plan de Implantación - Sistema/etapa - Protocolo de implantado Implantación

ACTORES Experto informático Proveedor Soporte funcional Soporte técnico Soporte aplicativo Administrador funcional - Usuario - Líder informático -

RESPONSABLE - Líder Informático

Aceptación de la Implantación Aceptación del protocolo de implantación con su validación por parte del líder funcional y recepción provisoria del sistema/etapa. Esta tarea implica la aceptación y recepción provisoria del sistema en forma total (en caso de big bang) o de una de sus etapas (roll-out). INPUT - Sistema/etapa implantado

OUTPUT - Recepción Provisoria

-

ACTORES Líder funcional Líder informático Usuario final Administrador funcional

RESPONSABLE - Líder funcional

ETAPA: FORMALIZACIÓN PUESTA EN PRODUCCIÓN Contrato de Servicio de Producción Firma del Contrato de Servicio entre el Usuario y los proveedores (internos y externos) del servicio. INPUT OUTPUT - Especificación - Contrato de Servicio técnica/funcional (F1 de Producción / F2)

ACTORES - Usuario - Proveedores del 10 Servicio - Administrador funcional - Experto en Calidad

RESPONSABLE - Administrador funcional

Notas: 10 Normalmente los Proveedores del Servicio corresponden a: Soporte a Usuarios, Soporte Funcional, Soporte Técnico, Soporte Aplicativo, Soporte Seguridad.

88 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

Documentación Puesta en Producción 11 12

Completar la documentación para los soportes : - Soporte a Usuarios - Soporte Funcional - Soporte Técnico - Soporte Seguridad Esta documentación acompañará al Procedimiento de Producción definido en la fase anterior. INPUT

OUTPUT - Documento de Soporte a Mesa de Ayuda actualizado - Documento de Soporte a Operaciones/Soport e Técnico actualizado

ACTORES - Administrador Funcional - Líder Funcional - Líder informático - Experto Informático

RESPONSABLE - Líder Funcional - Líder Informático

Notas: 11 En este momento deberá estar finalizado el documento de procedimientos de producción, el cual se anexará a esta documentación 12 Los roles de soporte enunciados podrán corresponder a más de un sector, de acuerdo a la organización.

89 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

HITO 5: SISTEMA EN PRODUCCIÓN El Administrador Funcional y el Líder Funcional redactarán el informe del Sistema en Producción de manera conjunta. INPUT: OUTPUT: ACTORES:

RESPONSABLE: -

Check-list

Recepción provisoria del sistema/etapa Informe Sistema en Producción Líder informático Líder funcional Administrador funcional Usuario Líder funcional Administrador funcional

    

Capacitación Comunicación Confiabilización y Conversión de Datos Contrato de Servicio de Producción Documentos:  Recepción Provisoria  Documentación de Soporte  Procedimiento de Producción

“SISTEMA EN PRODUCCIÓN” constituye el HITO 5 de Validación del OWNER DEL PROYECTO.

90 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

FASE: PRODUCCIÓN FASE

P R O D U C C I Ó N

ETAPAS

TAREAS

ENTREGABLES

COORDINADOR

ADMINISTRACIÓN TÉCNICA

- Procesos Backup - Procesos Seguridad - Procesos Performance - Control de Procesos Rutinarios - Otros procesos

- Tablero de Mando

Soporte Técnico

ADMINISTRACIÓN FUNCIONAL

- Administración de Usuarios y Perfiles - Mantenimiento de Datos, Tablas y Parámetros - Capacitación Nuevos Usuarios

- Tablero de Mando

Administrador Funcional

- Atención a Usuarios - Soporte Funcional - Soporte Técnico - Soporte Aplicativo

- Tablero de Mando

Administrador Funcional

- Nuevos Requerimientos

- Nuevo Proyecto

Administrador Funcional

SOPORTE

EVOLUCIÓN

Es importante señalar, que en la fase de Producción las etapas no presentan una secuencialidad, ya que las tareas correspondientes a esta fase pueden realizarse en forma paralela independientemente de la etapa a la que pertenecen. ETAPA: ADMINISTRACIÓN TÉCNICA Procesos de Backup Realizar los procesos de backup de acuerdo al Plan de Backup. Notificar los resultados del backup a los actores correspondientes INPUT - Plan de Backup

OUTPUT - Backup - Notificación del backup

ACTORES - Soporte Técnico - Administrador funcional

RESPONSABLE - Soporte Técnico

Procesos de Seguridad Realizar los procesos de seguridad. Asegurar la integridad y coherencia de los datos Verificar y controlar los logs de auditoría. Asegurar la confidencialidad: identificación, autenticación y control de accesos Generar los informes correspondientes y actualizar el tablero de mando. INPUT - Procedimientos de Producción

OUTPUT 13 - Tablero de Mando

ACTORES - Soporte Seguridad

RESPONSABLE - Soporte Seguridad

Procesos de Performance Realizar los procesos de performance. Notas: 13 Los indicadores del tablero de mando se definirán en el contrato de servicio de producción

91 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

Relevar y asegurar performance del procesamiento, tiempos de CPU, número de procesos levantados, número de usuarios conectados, capacidad y tráfico de red. Tuning de BD, SO y Red. Generar los informes correspondientes y actualizar el tablero de mando. INPUT - Procedimientos de Producción

OUTPUT 14 - Tablero de Mando

ACTORES - Soporte Técnico - Soporte Aplicativo

RESPONSABLE - Soporte Técnico

Control de Procesos Rutinarios Realizar el control de procesos rutinarios (espacio en disco, control de interfaces, etc.) Controlar el correcto funcionamiento del sistema, conociendo los calendarios de procesamiento. Generar los informes correspondientes, mantener los indicadores y actualizar el tablero de mando. INPUT - Procedimientos de Producción

OUTPUT 15 - Tablero de Mando

ACTORES - Soporte Técnico

RESPONSABLE - Soporte Técnico

Otros Procesos Procesos extraordinarios. Upgrades de Hardware, Sistema Operativo, etc. Soporte en tareas para recuperación de información para Legales, Auditoría, otros sistemas, etc. INPUT - Solicitud extraordinaria

OUTPUT - Tarea realizada

ACTORES - Soporte Técnico - Administrador Funcional

RESPONSABLE - Soporte Técnico

ETAPA: ADMINISTRACIÓN FUNCIONAL Administración de Usuarios y Perfiles Administración de Usuarios y Perfiles en el sistema y la plataforma de acuerdo a la norma vigente. INPUT - Solicitud de ABM de usuarios y perfiles

OUTPUT - Solicitud realizada

ACTORES - Administrador Funcional - Soporte en seguridad

RESPONSABLE - Administrador Funcional

Mantenimiento de Datos, Tablas y Parámetros Mantener los datos, tablas y parámetros de los Sistemas en Producción Verificar por muestreo la validez de la información contenida en las copias de resguardo Restablecer, corregir datos Se solicitará a soporte aplicativo las herramientas necesarias para restablecer los datos. INPUT OUTPUT - Necesidad de - Corrección/actualiza corrección/actualizac ción realizada

ACTORES - Administrador Funcional

RESPONSABLE - Administrador Funcional

Notas: 14 Los indicadores del tablero de mando se definirán en el contrato de servicio de producción 15 Los indicadores del tablero de mando se definirán en el contrato de servicio de producción

92 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

ión de datos

- Soporte aplicativo

Capacitación Nuevos Usuarios Realizar la capacitación de los usuarios y todos los actores involucrados ante nuevos releases, nuevos perfiles, nuevas funcionalidades, nuevos usuarios, etc. Planificar y asegurar la logística. INPUT - Necesidad de capacitación

OUTPUT - Usuarios Capacitados

ACTORES - Responsable de capacitación - Usuarios - Administrador funcional - Soporte Funcional - Soporte Técnico - Soporte a Usuarios - Soporte Aplicativo

RESPONSABLE - Administrador Funcional

ETAPA: SOPORTE Atención a Usuarios Atender a los usuarios, recibir y registrar los llamados por consultas, reclamos y/o problemas. Diagnosticar e identificar criticidad y el origen del incidente, resolver y/o derivar los reclamos según corresponda (soporte funcional, soporte aplicativo u otro actor). Realizar seguimiento de los incidentes. Comunicar la solución al usuario. Mantener los indicadores de gestión de atención a usuarios actualizando el tablero de mando. INPUT - Consulta/Problema/ Reclamo/Incidente

OUTPUT 16 - Tablero de Mando - Reclamo atendido/solucionad o/derivado

ACTORES - Usuario - Soporte a Usuarios

RESPONSABLE - Soporte a Usuarios

Soporte Funcional Recibir consultas y asesorar acerca de la información que brinda el sistema y sus funcionalidades en general. Diagnosticar, identificando la criticidad y el origen del problema, y resolver o derivar la consulta.

-

INPUT OUTPUT 17 Incidente Funcional - Tablero de Mando Manual de Usuario - Incidente Manual de Sistemas atendido/resuelto/de Manual de Procesos rivado

-

ACTORES Usuario Soporte Funcional Soporte a Usuarios Administrador funcional

RESPONSABLE - Soporte Funcional

Soporte Técnico Recibir incidentes técnicos. Notas: 16 Los indicadores del tablero de mando se definirán en el contrato de servicio de producción 17 Los indicadores del tablero de mando se definirán en el contrato de servicio de producción

93 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

Diagnosticar, identificando criticidad y el origen del problema. Ejecutar las acciones correctivas o derivar a los actores correspondientes.

INPUT - Incidente Técnico

OUTPUT 18 - Tablero de Mando - Incidente técnico atendido/resuelto/de rivado

ACTORES - Soporte Técnico - Soporte a Usuarios - Soporte en seguridad

RESPONSABLE - Soporte Técnico

Soporte Aplicativo Recibir incidentes aplicativos y realizar el diagnóstico, identificando la criticidad y el origen del problema. Resolver y/o derivar el incidente a los actores correspondientes, priorizando la criticidad del problema. Corregir la aplicación eliminando la causa del incidente (corrección del bug). 19 Realizar los tests y preparar el pasaje a producción. Realizar la gestión de configuración. Actualizar documentación de Sistemas, de Usuario y de Procesos registrando las modificaciones de nuevas versiones, patchs, etc. INPUT - Incidente Aplicativo - Manuales de Sistemas, de Usuario y de Procesos

OUTPUT - Incidente aplicativo resuelto/derivado - Manual de Sistemas actualizado - Manual de Usuario actualizado - Manual de Procesos actualizado

ACTORES RESPONSABLE - Soporte Aplicativo - Soporte Aplicativo - Administrador Funcional. - Soporte funcional - Soporte técnico - Experto en Procesos

ETAPA: EVOLUCIÓN Nuevos Requerimientos Centralizar los requerimientos sobre nuevas funcionalidades y/o modificaciones al sistema. Generar la necesidad de evolución y el requerimiento para un nuevo sistema/release Esta evolución o nuevo sistema, o release seguirá el ciclo de un proyecto, de acuerdo a la Guía de Gestión de Proyectos. INPUT - Necesidad

OUTPUT - Nuevo Requerimiento

ACTORES - Administrador Funcional - Otros generadores de necesidad

RESPONSABLE - Administrador Funcional

Notas: 18 Los indicadores del tablero de mando se definirán en el contrato de servicio de producción 19 La aprobación del pasaje a producción y la puesta en producción se llevarán de acuerdo a las Normas vigentes.

94 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

FASE: BALANCE DEL PROYECTO FASE B A L A N C E

P R O Y E C T de O

ETAPAS

TAREAS

BALANCE DEL PROYECTO

- Balance del Proyecto

ENTREGABLES

COORDINADOR

- Informe de Cierre del Proyecto

Líder Funcional Líder Informático

ETAPA: BALANCE DEL PROYECTO Balance del Proyecto Verificar que los objetivos hayan sido alcanzados. Chequear presupuesto, tiempos e indicadores claves definidos en “Identificación de Métricas” de la fase “Estudio Preliminar”. Detectar oportunidades de mejora en la gestión del Proyecto. INPUT - Indicadores Clave - Presupuesto - Tablero de Mando

OUTPUT - Informe de Cierre

ACTORES - Líder funcional - Líder informático - Administrador funcional

RESPONSABLE - Líder funcional

95 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

CARPETA de PROYECTOS

96 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

CARPETA DE PROYECTOS En este capítulo se describen los entregables obligatorios originados en cada una de las fases descritas anteriormente.

FASE: DESCRIPCIÓN DE NECESIDADES DESCRIPCIÓN DE LA NECESIDAD (ver F1) NOMBRE Descripción de la Necesidad OBJETIVO Describir el objetivo y alcance de la necesidad de un nuevo sistema o una modificación indicando si reemplaza sistemas actuales (en cuyo caso identificarlos) CONTENIDO Ver Sección DESCRIPCION DE LA NECESIDAD ubicada en el cuerpo del Documento F1 RESPONSABLE Líder Funcional

97 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

DOCUMENTO F1 - Requerimientos funcionales e impactos NOMBRE REFERENCIAL: ..................................................................................................................... Proyecto: ........................................................ Subproyecto: ........................................................ Estado

Preliminar

Preparado por: Actualizado por: Aprobado por:

En análisis de impacto

En negociación c/usuario



Definitivo

Fecha de creación: Fecha de actualización: Fecha de aprobación:



DATOS GENERALES Requirente Responsable DRI

Gestión

en













Fecha requerida de implantación: Fecha estimada de respuesta del F1: Prioridad: 1 (alta), 10 (baja)

1

2

3

4

5

6

7

8

9

10

DESCRIPCIÓN DE LA NECESIDAD 1 Objetivo del proyecto/requerimiento 3 Breve descripción. 5 Identificación de procesos y subprocesos impactados

2.Alcance del proyecto/requerimiento 4. Beneficios esperados / motivación / justificación

ESPECIFICACIÓN FUNCIONAL

20

1. Funcionalidades Alcance de las funcionalidades Descripción detallada de las funcionalidades. Descripción de aspectos de seguridad de la funcionalidad Definición de usuarios y perfiles de la funcionalidad 2. Requerimientos a los sistemas impactados 3. Descripción de aspectos de volumetría y performance 4. Principales cambios a los procesos Definición de procesos/subprocesos a implementar/cambiar 5. Reportes 6. Puntos abiertos 7. Temas a desarrollar en una etapa posterior 8. Posibles indicadores

DOCUMENTOS DE ANÁLISIS DE IMPACTOS OTROS DOCUMENTOS RELACIONADOS – ANEXOS

Notas: 20 Debido a la importancia del entendimiento de los requerimientos funcionales por parte del líder informático y su equipo, se realizarán rondas de aclaraciones y actualización entre funcional e informático, que generarán modificaciones y/o aclaraciones a este documento. La revisión se realiza para asegurar que se ha identificado adecuadamente el marco del proyecto, se ha definido correctamente las funcionalidades, el rendimiento y las interfaces. Los procesos/sub-procesos definidos en la especificación funcional y resultantes de las rondas de validación entre líder funcional y líder informático serán los procesos/sub-procesos que implementará el sistema y que deberán ser volcados en el manual de procesos para el usuario final.

98 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

Descripción de los campos del formulario 





ENCABEZADO -

Id Requrimiento: código de identificación del requerimiento generado en forma secuencial y automáticamente en la base de Lotus Notes.

-

Nombre referencial: nombre Ej: CRM – Nota de crédito

-

Proyecto: nombre del proyecto Ej: CRM URSI

-

Subproyecto: nombre del subproyecto Ej: CRM - Fase 1

-

Estado: estado del requerimiento según el flujograma de gestión de la demanda (preliminar, en análisis de impacto, en negociación con el usuario, definitivo)

requerimiento

basado

en

la

función

asociada.

DATOS GENERALES -

Requirente: nombre del sector y persona que realiza el requerimiento (usuario final)

-

Responsable de gestión en DRI: nombre del sector y persona responsable de la gestión del requerimiento en la DRI

-

Fecha requerida de implantación: dd/mm/aa

-

Fecha estimada de respuesta del F1: dd/mm/aa

-

Prioridad: nivel de prioridad definido por el usuario para el estudio preliminar del requerimiento. Se elaborará una tabla de criterios para guiar a los usuarios.

DESCRIPCIÓN DE LA NECESIDAD -



del

Describir el objetivo y alcance de la necesidad de un nuevo sistema o una modificación. Identificar si se reemplaza a un sistema, si es una ampliación, una modificación o algo nuevo. Identificar procesos y subprocesos impactados, según la lista de procesos establecidos

ESPECIFICACIÓN FUNCIONAL (Los siguientes puntos se aplicarán según corresponda de acuerdo a las características del requerimiento y de los sistemas que impacta) 1. Funcionalidades: enumerar las funcionalidades requeridas - Alcance de la funcionalidad: describir los límites de la funcionalidad - Descripción detallada de la funcionalidad: es la especificación funcional propiamente dicha en la cual se describen las necesidades del usuario en forma detallada. (VER GUÍA) - Descripción de aspectos de seguridad de la funcionalidad: describir las restricciones de acceso o cualquier aspecto de seguridad que se considere relevante para la funcionalidad detallada. - Definición de usuarios y perfiles de la funcionalidad: definir los perfiles de acceso y usuarios. 2. Requerimientos a los sistemas impactados: describir los requerimientos a los sistemas impactados por este requerimiento/funcionalidad. 3. Descripción de aspectos de volumetría y performance: describir volúmenes de transacciones, de datos almacenados, etc. 4. Principales cambios a los procesos - Definición de procesos/subprocesos a implementar /cambiar: nombrar y describir, si fuera necesario, los cambios introducidos a los subprocesos debido a la implementación de la nueva funcionalidad requerida. 5. Reportes 99 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

6. Puntos abiertos 7. Temas a desarrollar en una etapa posterior 8. Posibles indicadores: definir indicadores, momento adecuado de la medición y definir valores estándares para ese indicador. 

DOCUMENTOS DE ANÁLISIS DE IMPACTO En esta sección se incluirán como anexos todos los documentos resultantes del análisis de los requerimientos. Nota: el resto del documento lo confeccionará el usuario con la colaboración del Analista funcional.



OTROS DOCUMENTOS RELACIONADOS – ANEXOS En esta sección se incluirán todos los documentos necesarios como soporte del documento F1. Por ejemplo estudio de factibilidad incluyendo el PLAZO DE AMORTIZACIÓN de la solución.

100 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

FASE: ESTUDIO DE FACTIBILIDAD ESTUDIO DE FACTIBILIDAD TÉCNICO/FUNCIONAL NOMBRE 21 Estudio de Factibilidad Técnico/Funcional OBJETIVO Estudio de la funcionalidad, el rendimiento y las restricciones que puedan afectar a la posibilidad de realización del sistema. Análisis y evaluación de distintas alternativas para el desarrollo del sistema. CONTENIDO Fecha:.. ../....../...... Proyecto:....................................................................................................................... Responsable:....................................................... Sector:............................................... Participantes:................................................................................................................. - Idea/objetivo: (incluir ficha de descripción de la necesidad) - Relevamiento - Presentación contexto (dónde) - Necesidades (relevamiento detallado) - Problemáticas detectadas - Situación actual (cómo se desarrolla hoy) - Factibilidad técnica / funcional 22 - Diagnóstico de la situación actual (PMO ) 23 - Alternativas. Escenarios de solución (FMO ) 24 - Descripción de tipos de solución (producto, desarrollo, evolución, no hace falta.) - Impacto - Plan Maestro de Sistemas. Arquitectura sistemas. Otros sistemas, visión TMN, mapeo TOM - Plan tecnológico - Parque informático - Procesos del cliente - Usuario - Organización - Ventajas y desventajas de la alternativa - Plazos estimados para llevar adelante la alternativa - Riesgos de no ejecución - Conclusión RESPONSABLE Líder Funcional + Líder Informático (Este documento contiene el resultado de tareas que, según la Guía de Proyectos, corresponden a distintos responsables. Será responsabilidad del líder funcional y el informático, conformar en conjunto, este documento con los distintos informes.)

Notas: 21 Dentro del ámbito de la Unidad de Negocios Red, el “Estudio de Factibilidad” se denomina “Estudio de Oportunidad”. 22 PMO: modelo objetivo presente 23 FMO: modelo objetivo futuro 24 Se deberá describir el sistema/producto con el soporte tecnológico (Hardware, Software, Base de Datos, Redes, Puestos de Trabajo, etc.)

101 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

ESTUDIO FACTIBILIDAD ECONÓMICA NOMBRE Estudio de Factibilidad Económica OBJETIVO Estudio de inversiones y gastos frente al beneficio final producido por el sistema. CONTENIDO Fecha:.. ../....../...... Proyecto:....................................................................................................................... Responsable:....................................................... Sector:............................................... Participantes:................................................................................................................. - Contexto - Alternativas. Escenarios posibles - Contexto - Inversiones y gastos del proyecto - Beneficios - Valor actual neto - Tasa interna de retorno - Período de recupero - Máxima necesidad de fondos y años en los que ocurre - Estado de resultados proyectado - Cash flow proyectado - Conclusión RESPONSABLE Líder funcional con colaboración del líder informático y de un experto económico.

102 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

MÉTRICAS CLAVES NOMBRE Métricas Claves OBJETIVO Identificar las métricas/indicadores claves para la evaluación del proyecto (aquellas asociadas a la motivación/justificación del proyecto para medir así los impactos esperados versus los reales). CONTENIDO Fecha:.. ../....../...... Proyecto:....................................................................................................................... Responsable:....................................................... Sector:............................................... Participantes:................................................................................................................. Seleccionar las métricas (indicadores) de acuerdo al proyecto: métricas operativas, funcionales y financieras. - Definición de cada métrica - Identificar el responsable de la medición - Definir el momento adecuado de la medición - Definir valores RESPONSABLE Líder funcional -

103 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

INFORME EJECUTIVO DE ESTUDIO DE FACTIBILIDAD NOMBRE Informe Ejecutivo de Estudio de Factibilidad OBJETIVO Describir sintéticamente las alternativas desarrolladas en los estudios de factibilidad técnico/funcional y económico para ser presentado al Comité. CONTENIDO Fecha:.. ../....../...... Proyecto:....................................................................................................................... Responsable:....................................................... Sector:............................................... Participantes:................................................................................................................. Objetivo Alternativas - Descripción técnica/funcional - Estudio económico - Plazos Estimados - Impacto - Conclusión RESPONSABLE Líder Funcional -

104 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

CARTA DE DECISIÓN NOMBRE Carta de Decisión OBJETIVO Informe de la decisión resultante del hito 0. CONTENIDO Fecha:.. ../....../...... Proyecto:....................................................................................................................... Responsable:....................................................... Sector:............................................... Participantes:................................................................................................................. Proyecto Aprobado? - Alternativa Elegida - Observaciones - Proyecto Rechazado? - Fundamentos - Modalidad del Proyecto - Presupuesto (todos los recursos + tiempo interno de compra) - Plazos (Gantt Macro) - Responsables (Compromiso de disponibilidad) RESPONSABLE Comité Director -

105 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

ACUERDO DE SERVICIO DE PROYECTO El “Acuerdo de Servicio de Proyecto” se describe en el Anexo de “Acuerdos y Contratos de Servicios”. DOCUMENTO MAILS DE APROBACIÓN DE HITOS APROBACIÓN DE HITOS Preparado por





Fecha de creación:

APROBACIÓN DE HITOS / CIERRE DE FASE Proyecto:



Fase:



Nombre del Hito:



Fecha estimada finalización

de

Fecha real de finalización Responsables de aprobación



Fecha de aprobación





SITUACIÓN DE ENTREGABLES Documentos entregados: Detalle de los documentos entregados: - Entregable 1 - Entregable 2 Documentos pendientes:

-

Entregable 3

Comentarios RECHAZO DEL HITO Rechazado por:



Motivo:



Fecha de rechazo

ANEXOS

6.1.1.2 -

Descripción de los campos del formulario Aclaración El mail irá dirigido al responsable de la gestión en la DRI. 106 de 181



Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

-

Preparado por: apellido y nombre de la persona que presenta el formulario para su aprobación. Este será el REMITENTE del mail

-

Proyecto: nombre del proyecto

-

Fase. Nombre de la fase a la que pertenece el hito. Estas corresponden al ciclo de vida del proyecto y se deberán cumplir de acuerdo a la naturaleza del proyecto y del sector. Ejemplos: Fase: Diseño global Hito 1: Convalidación de la especificación Fase: Diseño detallado Hito 3: Aprobación diseño detallado Fase: Construcción Hito 4: Decisión de implantación

-

Nombre del hito: número y nombre del hito según la descripción del campo anterior (fase)

-

Fecha estimada de finalización: fecha de finalización estimada de la fase a aprobar

-

Fecha real de finalización: fecha de finalización real de la fase a aprobar

-

Responsables de la aprobación: apellido y nombre de los responsables de la aprobación del hito

-

Documentos entregados: nombrar o adjuntar los documentos que quedan aprobados. En caso de nombrarlos, mencionar versión del documento que se aprueba

-

Documentos pendientes: nombrar los documentos que quedan pendientes

-

Comentarios: en caso de quedar algo pendiente, comentarlo claramente

107 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

FASE: DISEÑO GLOBAL 6.1.2

ESPECIFICACIÓN FUNCIONAL (ver F1)

NOMBRE Especificación Funcional ó Requerimiento Funcional de Bajo Nivel OBJETIVO Describir las funcionalidades y rendimiento deseado para el sistema y sus restricciones. Se describe también la información de control y datos que sirven de entrada/salida al sistema (especificación funcional). CONTENIDO Ver sección ESPECIFICACIÓN FUNCIONAL ubicada en el documento F1 RESPONSABLE Líder funcional Debido a la importancia del entendimiento de los requerimientos funcionales por parte del líder informático y su equipo, se realizarán rondas de aclaraciones y actualización entre funcional e informático, que generarán modificaciones y/o aclaraciones a este documento. La revisión se realiza para asegurar que se ha identificado adecuadamente el marco del proyecto, se ha definido correctamente las funcionalidades, el rendimiento y las interfaces. Los procesos/sub-procesos definidos en la especificación funcional y resultantes de las rondas de validación entre líder funcional y líder informático serán los procesos/sub-procesos que implementará el sistema y que deberán ser volcados en el manual de procesos para el usuario final.

108 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

ESPECIFICACIÓN TÉCNICA (ver F2) NOMBRE Especificación Técnica OBJETIVO Describir completamente la información, la funcionalidad detalladamente, con una indicación de los requisitos de rendimiento, de las restricciones de diseño y aspectos de volumetría, performance, dimensionamiento. CONTENIDO Ver sección DESCRIPCIÓN FUNCIONAL DE LA SOLUCIÓN ubicada en el documento F2 RESPONSABLE Líder informático

109 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

PLAN GENERAL DE TRABAJO (ver F2 – Fechas de implementación) NOMBRE Plan General de Trabajo OBJETIVO Definir macro tareas, plazos e hitos de control CONTENIDO Fecha:.. ../....../...... Proyecto:....................................................................................................................... Responsable:....................................................... Sector:............................................... Participantes:................................................................................................................. - Diagrama de Gantt identificando: - Macro Tareas - Plazos - Responsables - Hitos de control - Identificación de tareas dentro de las fases y etapas del proyecto - Proceso de Compra - Diseño Detallado - Construcción - Desarrollo - Pruebas - Prueba Piloto - Implantación - Identificación de tareas críticas - Identificación de tareas de Capacitación en el diagrama de Gantt RESPONSABLE Líder informático El plan de trabajo deberá ser convalidado por el líder funcional

110 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

EQUIPO DE TRABAJO NOMBRE Equipo de Trabajo OBJETIVO Identificar, dentro de la estructura de la organización, las personas que cumplen los distintos roles definidos para el proyecto CONTENIDO Fecha:.. ../....../...... Proyecto:....................................................................................................................... Responsable:....................................................... Sector:............................................... Participantes:................................................................................................................. - Para Cada Rol: - Rol - Responsables - Nombre - Sector - Porcentaje de Dedicación RESPONSABLE Líder funcional

111 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

DOCUMENTO F2 - Solución técnica a los requerimientos funcionales NOMBRE REFERENCIAL (F1): ................................................................. ID REQUERIMIENTO (F1): ................................................................. Proyecto: ............................. Subproyecto: ............................. Sistema afectado: ............................. Módulo afectado: ............................. Estado

En Diseño Global

En convalidación

Preparado por: .................... Actualizado por: .................... Aprobado por: ....................

Aprobado

Fecha de creación: Fecha de actualización: Fecha de aprobación:



Fecha requerida de implantación: Fecha estimada de comienzo: Tiempo estimado de duración: ALCANCE FUNCIONAL

-

-

DESCRIPCIÓN FUNCIONAL DE LA SOLUCIÓN Especificación técnica de los requerimientos funcionales Arquitectura técnica del sistema - Arquitectura lógica - Arquitectura física Modelo de Información Interfaces con otros sistemas Aspectos técnicos de seguridad Prototipo Modalidad de Proyecto

SUPUESTOS / PREMISAS / POSIBLES IMPACTOS

INTERFACES INVOLUCRADAS EN LA SOLUCIÓN - Interfaces con otros sistemas

IMPACTO EN LA ACTIVIDAD Y EN LA CANTIDAD DE INFORMACIÓN A ALMACENAR - Aspectos de volumetría, performance, dimensionamiento

FUNCIONALIDADES FUERA DE ALCANCE

DEFINICIONES PENDIENTES

FECHAS DE IMPLEMENTACIÓN

112 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

Descripción de los campos del formulario



-

ID Especificación técnica: código de identificación de la solución

-

Nombre referencial: nombre del requerimiento funcional que figura en el F1

-

ID Requerimiento: código de identificación del requerimiento que originó esta solución (F1)

-

Proyecto: nombre del proyecto impactado

-

Subproyecto: nombre del subproyecto

-

Estado: estado de la propuesta de solución al requerimiento del usuario según el flujograma de gestión de la demanda (en diseño global, en convalidación, aprobado)

-

Fecha requerida de implantación: dd/mm/aa. Es la fecha en que se requiere tener la solución implantada

-

Fecha estimada de comienzo: dd/mm/aa . Es la fecha que Sistemas estima que puede comenzar con el desarrollo

-

Tiempo estimado de duración: Tiempo total de desarrollo de la solución planteada

ALCANCE FUNCIONAL -



DESCRIPCIÓN FUNCIONAL DE LA SOLUCIÓN -



Describir aspectos de volumetría (transacciones, datos, etc.) , performance, dimensionamiento y cualquier otro aspecto que sea relevante para la solución.

FUNCIONALIDADES FUERA DE ALCANCE -



Describirlas

IMPACTO EN LA ACTIVIDAD Y EN LA CANTIDAD DE INFORMACIÓN A ALMACENAR -



Describir los supuestos o premisas bajo las cuales se desarrollará la solución, o bien los impactos que pueda tener el desarrollo

INTERFACES INVOLUCRADAS EN LA SOLUCIÓN -



Describir la solución del requerimiento detallado en el F1, a través de la especificación técnica, modelo de información, describiendo aspectos de seguridad y controles como así también la navegabilidad o secuencia de funciones.

SUPUESTOS / PREMISAS / POSIBLES IMPACTOS -



Breve descripción de los límites y alcance que tendrá la solución

Mencionar detalladamente las funcionalidades que quedan fuera del alcance de esta solución.

FECHAS DE IMPLEMENTACIÓN -

Describir el plan de trabajo con un cronograma asociado.

Ejemplo con cronograma modelo

113 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

114 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

FASE: DISEÑO DETALLADO 6.1.3

ESPECIFICACIÓN TÉCNICA DE DETALLE (ver document DISEÑO DETALLADO)

NOMBRE Especificación Técnica de Detalle OBJETIVO Describir la especificación técnica de detalle (estructura de datos detallada y representaciones algorítmicas del software). Se describe también el diseño de las interfaces. CONTENIDO Ver sección ESPECIFICACIÓN TÉCNICA DE DETALLE del documento DISEÑO DETALLADO RESPONSABLE Líder Informático

115 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

DOCUMENTO DISEÑO DETALLADO - Especificación técnica de detalle PROYECTO: ................................................................. SUBPROYECTO: ................................................................. Sistema/Módulo impactado: ......................................... Estado

Preliminar

En Consolidación

Preparado por: .................... Actualizado por: ....................

Definitivo Fecha de creación: Fecha de actualización: Fecha de aprobación:

Aprobado por: ....................

ESPECIFICACION TËCNICA DE DETALLE -

Gráfico de alto nivel del sistema (Soporte gráfico que describe el sistema en sí mismo) - Flujo de información entre aplicaciones, grupos funcionales e interfaces externas a nivel conceptual (flow de procesos) - Diagrama identificando los componentes generales del proceso.

-

Funcionalidades: - Diseño Macro de Funcionalidades: - Descripción de funcionalidades del sistema y funciones involucradas. - Flow del aplicativo: descripción de cómo, a nivel macro, la función será llevada a cabo por el sistema - Definición de entidades - Bases para identificar reportes, pantallas, procesos, módulos - Bases para identificar procesos manuales y computarizados. - Resolución de la funcionalidad: - Descripción gráfica - Descripción detallada

-

Interfaces - Descripción Funcional - Descripción Técnica

-

Módulos: - Resolución de los módulos: - Flow Chart estructurado / Arquitectura técnica - Input – Output del módulo - Descripción del Módulo - Pseudocódigo

-

Definición de archivos

-

Condiciones de pruebas potenciales

-

Códigos de Error - Descripción - Causa - Umbrales - Acciones

-

Controles de procesos

116 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

-

Descripción del Acceso a Base de Datos

-

Estructura de Datos - Diccionario de Datos - Elemento de Datos - Registro / Estructura - Archivos - Referencias Cruzadas - Base de Datos: - Diseño lógico - Diseño físico - Tablas - Indices - Foreign Keys

-

Reportes - Descripción Funcional - Layout - Ejemplo

-

Pantallas - Descripción Funcional - Layout - Ejemplo ANEXOS

117 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

PLAN DETALLADO DE TRABAJO NOMBRE Plan Detallado de Trabajo OBJETIVO Definir el detalle de las tareas, plazos e hitos de control CONTENIDO Fecha:.. ../....../...... Proyecto:....................................................................................................................... Responsable:....................................................... Sector:............................................... Participantes:................................................................................................................. - Diagrama de Gantt identificando: - Detalle de Tareas - Plazos - Responsables - Hitos de control - Identificación de tareas dentro de las fases y etapas del proyecto - Construcción - Desarrollo - Pruebas - Prueba Piloto - Implantación - Identificación de tareas de Capacitación en el diagrama de Gantt RESPONSABLE Líder informático El plan de trabajo deberá ser convalidado por el líder funcional

118 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

PLAN DE PRUEBAS TÉCNICAS - PLAN DE PRUEBAS FUNCIONALES Se realizarán los planes de prueba correspondientes a cada prueba: - Prueba Individual - Prueba de Cadena - Prueba de Integración - Prueba Global (Pruebas Funcionales) - Prueba de Performance, stress, volumen y seguridad - Prueba de Compatibilidad NOMBRE Plan de Pruebas Técnicas – Plan de Pruebas Funcionales OBJETIVO Describir un plan general para la integración del software y una descripción de las pruebas específicas. CONTENIDO Fecha:.. ../....../...... Proyecto:....................................................................................................................... Responsable:....................................................... Sector:............................................... Participantes:................................................................................................................. Plan de Pruebas: - Objetivo y Alcance - Contexto / Ambiente de prueba - Datos (generación) - Interfaces - Plataforma - Condiciones generales de prueba: - Datos de Entrada - Resultado Esperado - Responsable de la prueba - Documentación del input de la prueba - Descripción de la documentación que respaldará la prueba - Criterio de entrada - Criterio de salida (cota de calidad) - Criterio de aceptación - Circuito de resolución de incidentes de prueba - Métricas RESPONSABLE Líder informático Líder funcional para Prueba Global (Prueba Funcional) -

119 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

PLAN DE CONTINGENCIA Y DE DESASTRE NOMBRE Plan de Contingencia y de Desastre OBJETIVO Definir un plan que detalle las tareas y responsables para cada situación de contingencia que se pudiera presentar en el software y/o hardware. CONTENIDO Fecha:.. ../....../...... Proyecto:....................................................................................................................... Responsable:....................................................... Sector:............................................... Participantes:................................................................................................................. Momento en que se declara la contingencia Responsable/s de declarar la contingencia Tipos de contingencia (dependerá de la implementación de cada sistema) - Plan de Tareas / Responsable - Procedimiento de contingencia - Esquema de seguridad - Puesto de trabajo de contingencia - Escenarios posibles de contingencia - Identificación de interfaces críticas y propuestas de plan de contingencia - Descripción de pruebas de plan de contingencia. RESPONSABLE Líder informático -

120 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

PLAN DE BACKUP NOMBRE Plan de Backup OBJETIVO Definir el plan de backup para el sistema operativo, datos y aplicación (servidores y puestos de trabajo) CONTENIDO Fecha:.. ../....../...... Proyecto:....................................................................................................................... Responsable:....................................................... Sector:............................................... Participantes:................................................................................................................. Definir políticas de backup: - Sistema Operativo - Datos - Aplicación - Servidores - Puestos de Trabajo - Definir Instructivo y Menú de Backup - Designar Responsables RESPONSABLE Líder informático -

121 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

DOCUMENTO DE SOPORTE A MESA DE AYUDA NOMBRE Documento de Soporte a la Mesa de Ayuda OBJETIVO Describir la información que debe brindarse a la Mesa de Ayuda para que pueda conocer y satisfacer las inquietudes o inconvenientes que manifiesten los usuarios. CONTENIDO Fecha:.. ../....../...... Proyecto:....................................................................................................................... Responsable:....................................................... Sector:............................................... Participantes:................................................................................................................. - Horarios de Atención - Horario de utilización que tienen los usuarios del sistema. - Horario de Soporte al Aplicativo - Soporte del aplicativo - Lista de responsables por cada tema. - Alternativas de comunicación en sus distintos horarios. - Configuración - Esquema de configuración del equipo standard informático utilizado (Puesto de trabajo) - Esquema de conectividad y comunicaciones con equipo central o procesamiento distribuido - Equipo (host) - Nombre, mnemónico y direcciones IP Eth/X25 y X25 - Ubicación física del Equipo - Asistencia MASIT en Host - Usuario normalizado para todas las operaciones permitidas (Control de performance (Monitor), administración de procesos generados por los usuarios, etc.) - Instructivo de uso del mismo - Cortes programados - Referentes por Cortes programados - Casos en que quieran ser informados - Edificios y lugares que pudieran estar afectados - Análisis de puesta en marcha - Impacto de llamadas en la puesta en marcha - Cantidad de llamadas promedio ponderadas de consultas - Aplicación - Mensajes más comunes de error. - Soluciones a esos mensajes - Circuito de derivación de problemas. - Conocimiento por parte de las áreas involucradas el circuito. - Estadísticas - Que datos requerirán de la MASIT - Casos o seguimientos especiales. - Interlocutores - Responsables del sistema - Administradores. - Interlocutores de los sectores involucrados - Definición de las funcionalidades del sistema. - Breve descripción de la finalidad del sistema. - Detalle de usuarios del sistema - Nómina de los usuarios definidos - Descripción de la distribución geográfica de los usuarios RESPONSABLE Líder informático con la colaboración del líder funcional 122 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

123 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

DOCUMENTO DE SOPORTE A OPERACIONES/SOPORTE TÉCNICO NOMBRE Documento de Soporte a Operaciones/Soporte Técnico OBJETIVO Describir la información necesaria para que los sectores técnicos puedan administrar y dar soporte al hardware y software involucrado en el proyecto. CONTENIDO Fecha:.. ../....../...... Proyecto:....................................................................................................................... Responsable:....................................................... Sector:............................................... Participantes:................................................................................................................. -

-

Tipo de servicio requerido: Operación/ Instalación/ Administración de hardware Información sobre el hardware (servidores ya configurados o a configurar y estaciones de trabajo) Consumo eléctrico, disipación térmica y tamaño de los servers. Nro. de Serie, configuración, mac address de los servers. Ubicación física y responsables locales de los servers (de ser necesario). Orden de Compra Garantía o contrato de mantenimiento (copia del mismo) Estaciones de trabajo: indicar lista de usuarios con ID de usuario, Nombre y Apellido, interno, dirección, servidor de LAN al cual se conecta, tipo de PC que utiliza y Master, entorno operativo (Windows 95/98/NT). Información sobre el software (en el servidor y estaciones de trabajo) Aplicaciones en el servidor y en las estaciones de trabajo Licencias de software de base (sistema operativo, base de datos, etc.) en el servidor y estaciones de trabajo. Identificar la versión de software a instalar. Requerimientos mínimos del hardware para la instalación del software. Contrato de mantenimiento (copia del mismo). Manual de instalación

-

Backup Instructivo y menú de backup. Periodo de retención y reciclaje de las cintas. Información a resguardar (File System, directorios, etc.) Responsables del mismo (nombre, teléfono, radio, etc.)

-

Contingencia Especificación de los servers de contingencia. Responsable del lanzamiento de la contingencia. Plan de contingencia, procedimientos, etc.

-

Control de Interfaces Se deberá proveer toda la información necesaria para el control de las interfaces (origen/destino, periodicidad, manual/automática, etc.)

-

Carpeta Operativa. Se deberá proveer la misma, para ser utilizada en los casos en que el sector tenga que intervenir. (Instructivos, procedimientos, etc.)

-

-

RESPONSABLE Líder informático 124 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

125 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

PROCEDIMIENTO DE GESTIÓN DE CONFIGURACIÓN NOMBRE Procedimiento de Gestión de Configuración OBJETIVO Definir un procedimiento de Gestión de Configuración mediante el cual se establecen los mecanismos para realizar modificaciones o actualizaciones a cualquier elemento producido durante el ciclo de vida del un proyecto y su posterior mantenimiento. CONTENIDO Fecha:.. ../....../...... Proyecto:....................................................................................................................... Responsable:....................................................... Sector:............................................... Participantes:................................................................................................................. - Identificación y enumeración del tipo de elementos que se encuentran bajo el procedimiento de Gestión de Configuración: - Documentos (incluye cualquier documento generado en el ciclo de vida del proyecto). - Código fuente. - Tablas o archivos de parámetros. - Cualquier otro elemento que se pretenda tener control sobre los cambios que sobre el mismo se puedan hacer. - Definir a partir de que instante un elemento queda bajo el procedimiento de gestión de configuración. - Describir por cada tipo de elemento la información a conservar sobre versiones anteriores cada vez que se realice un cambio a un elemento que ha sido puesto bajo el procedimiento de gestión de configuración. - Descripción de los pasos a seguir para incluir un nuevo elemento bajo la gestión de configuración. - Descripción de los pasos requeridos para obtener e identificar un elemento en proceso de cambio. - Identificación de personas o grupos autorizados a realizar los cambios sobre cada tipo de elemento en cada una de las instancias del proyecto o durante la etapa de mantenimiento. - Descripción de los pasos para informar los cambios realizados a un elemento. - Definición de las herramientas automatizadas que se utilizarán en la gestión de configuración. RESPONSABLE Líder informático

126 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

IMPACTO ORGANIZACIONAL NOMBRE Impacto Organizacional OBJETIVO Conocer con tiempo suficiente los impactos en la Organización que genera un cambio de Sistemas/Procesos a efectos de poder planear acciones de cambio. CONTENIDO Fecha:.. ../....../...... Proyecto:....................................................................................................................... Responsable:....................................................... Sector:............................................... Participantes:................................................................................................................. Procesos a implantar/cambiar Sistemas a implantar/cambiar Población afectada - Cantidad - Localización - Tipo de contrato (D/C - F/C) - Especialidades / Puestos - Dimensionamiento del impacto respecto a las tareas / competencias / localizaciones necesarias previas al cambio RESPONSABLE Líder Funcional -

127 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

ESTRATEGIA DE IMPLANTACIÓN NOMBRE Estrategia de Implantación OBJETIVO Definir la estrategia de implantación de un proyecto CONTENIDO Fecha:.. ../....../...... Proyecto:....................................................................................................................... Responsable:....................................................... Sector:............................................... Participantes:................................................................................................................. Modo de Implantación: - Big Bang - Roll-out (en etapas) - Fases (descripción, alcance, contenido) - Releases - Cronograma General Por fases, Releases y Sitios RESPONSABLE Líder Funcional -

128 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

PLAN DE PRUEBAS FUNCIONALES Este documento se describe junto con el Plan de Pruebas Técnicas.

129 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

ESTRATEGIA DE CONFIABILIZACIÓN NOMBRE Estrategia de Confiabilización OBJETIVO Establecer un plan de confiabilización en caso que sea necesario. CONTENIDO Fecha:.. ../....../...... Proyecto:....................................................................................................................... Responsable:....................................................... Sector:............................................... Participantes:................................................................................................................. Confiabilización de Datos - Objetivo - Validaciones a aplicar sobre la fuente - Categorización y tipificación de errores - Identificación de la Distribución física de los datos (dónde) y plataforma para realizar la detección de errores. - Definición de Módulos de Detección, Ordenamiento y Comparación de Datos entre fuentes - Esquema de corrección de datos sobre la fuente a confiabilizar - Indicadores de permanencia de errores en la fuente - Plan de Confiabilización - Responsables RESPONSABLE Líder funcional -

130 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

ESTRATEGIA DE CONVERSIÓN DE DATOS NOMBRE Estrategia de Conversión de Datos OBJETIVO Establecer un plan de conversión de datos en caso que sea necesario. CONTENIDO Fecha:.. ../....../...... Proyecto:....................................................................................................................... Responsable:....................................................... Sector:............................................... Participantes:................................................................................................................. Conversión de Datos - Identificación de información a ser convertida - Identificación de fuente de obtención de nuevos datos - Requerimientos de conversión - Criterios de Conversión - Modalidad - Big bang - Por etapas - Dependencia y secuencialidad de procesos de conversión - Criterios de depuración previos a la conversión - Condiciones a probar para la conversión y lineamientos generales para la prueba de conversión. - Controles y criterios de aceptación de conversión - Condiciones claves y estándares de conversión ; determinar valores a asumir por defecto - Plan de Conversión - Documento de la Conversión - Responsables RESPONSABLE Líder funcional -

131 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

ESTRATEGIA DE CARGA DE DATOS NOMBRE Estrategia de Carga de Datos OBJETIVO Establecer un plan de Carga de Datos en caso que sea necesario. CONTENIDO Fecha:.. ../....../...... Proyecto:....................................................................................................................... Responsable:....................................................... Sector:............................................... Participantes:................................................................................................................. Identificación de la información a ser cargada Identificación de fuente de obtención de nuevos datos Determinar valores a asumir por defecto Definir el proceso de carga - Metodología - Modalidad Big Bang Por Etapas - Responsables - Criterios de aceptación - Circuito de corrección de errores - Plan de Carga RESPONSABLE Líder funcional -

132 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

PLAN DE ACCIÓN PARA EL CAMBIO NOMBRE Plan de Acción para el Cambio OBJETIVO Definir las acciones necesarias para abordar el impacto organizacional generado por la implementación del Proyecto. CONTENIDO Fecha:.. ../....../...... Proyecto:....................................................................................................................... Responsable:....................................................... Sector:............................................... Participantes:................................................................................................................. - Definición del Plan de Distribución Dotacional - Asignación de Responsables - Identificación de Recursos Necesarios - Definición de Plazos-Cronogramas (Gantt) - Definición de Hitos de Control RESPONSABLE Responsable Soporte al Cambio

133 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

PLAN DE CAPACITACIÓN NOMBRE Plan de Capacitación OBJETIVO Definir las acciones necesarias para capacitar a los actores involucrados CONTENIDO Fecha:.. ../....../...... Proyecto:....................................................................................................................... Responsable:....................................................... Sector:............................................... Participantes:................................................................................................................. Identificación del temario/contenido (procesos, funcionalidades del sistema, seguridad del sistema, etc.) - Herramientas - Logística - Salas - Materiales - Ambiente - Datos - Aplicación - Server y Puestos de Trabajo - Asistentes - Modalidad - Presencial - A distancia - Trainers/Formadores/Capacitadores (en caso de tratarse de una capacitación presencial) - Comunicación de la Capacitación - Plan de Capacitación RESPONSABLE Responsable Capacitación -

134 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

PLAN DE COMUNICACIÓN NOMBRE Plan de Comunicación OBJETIVO Definir las acciones necesarias para “comunicar”. CONTENIDO Fecha:.. ../....../...... Proyecto:....................................................................................................................... Responsable:....................................................... Sector:............................................... Participantes:................................................................................................................. Identificación de conceptos a comunicar (misión, alcance, objetivo y plazos) de la implementación del sistema. - Actores - Responsable de la Comunicación - Destinatarios Nombre Sector - Medio de Comunicación - Plan de Comunicación - Circuito de Comunicación (Feedback) RESPONSABLE Responsable Soporte al Cambio -

135 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

FASE: CONSTRUCCIÓN PROGRAMAS, MÓDULOS y PARAMETRIZACIÓN Si bien los programas, módulos y parametrizaciones no constituyen documentos en sí mismos, los mismos deberán documentarse, a saber: -

Los programas y módulos desarrollados en la etapa de construcción deberán estar documentados en el código. Se deberá generar un documento que describa cada uno de los parámetros del sistema, indicando nombre y valor. El mismo deberá ser actualizado ante modificaciones en los parámetros.

MANUAL DE SISTEMAS NOMBRE Manual de Sistemas OBJETIVO 25 Documentar la información técnica del Sistema CONTENIDO Fecha:.. ../....../...... Proyecto:....................................................................................................................... Responsable:....................................................... Sector:............................................... Participantes:................................................................................................................. Visión global del Sistema Plataforma de soporte y especificaciones técnicas Diagrama de módulos del Sistema y su interconexión Diagrama de relaciones con otros Sistemas Esquema de seguridad Tablas y parámetros del Sistema Diseño de base de datos Diseños de archivos Detalle de accesos a archivos de otras aplicaciones Descripción de programas batch y on-line Flow de encadenamiento de pantallas Flow de encadenamientos de programas batch para los distintos tipos de corridas Características de procesos especiales (cierres mensuales, anuales) Cross - reference (pantalla - pgm - módulos, pgms archivos, módulos reutilizables programas) RESPONSABLE Líder Informático -

Notas: 25 El Manual de Sistemas deberá incluir la Especificación Técnica de Detalle (Diseño detallado) actualizada.

136 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

MANUAL DE USUARIO NOMBRE Manual de Usuario OBJETIVO Documentar las funcionalidades del sistema apuntadas al uso del mismo CONTENIDO Fecha:.. ../....../...... Proyecto:....................................................................................................................... Responsable:....................................................... Sector:............................................... Participantes:................................................................................................................. Visión global del Sistema Módulos componentes del Sistema. Funciones on-line - Flow de encadenamiento de pantallas. - Pantallas con datos como ejemplo - Descripción del objetivo - Detalle de validaciones o controles generales - Función de los campos - Teclas de función con explicación de su funcionamiento - Mensajes de error con su respectiva explicación - Reportes - Diseño de reportes - Descripción del objetivo - Frecuencia y condiciones para su generación. - Descripción del contenido de los campos. - Descripción de los totales de control. - Interfaces con otros Sistemas - Descripción del objetivo - Frecuencia y condiciones para su generación - Reportes de control - Acciones a tomar en caso de diferencias o problemas en su generación - Breve descripción de los archivos del Sistema y archivos relacionados de otras aplicaciones - Descripción de tablas y parámetros del Sistema. - Mensajes de error del Sistema con detalle de acciones a tomar RESPONSABLE Líder Informático -

137 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

MANUAL DE PROCESOS NOMBRE Manual de Procesos OBJETIVO Describir el nuevo proceso/nueva forma de operación que implementará el proyecto CONTENIDO Fecha:.. ../....../...... Proyecto:....................................................................................................................... Responsable:....................................................... Sector:............................................... Participantes:................................................................................................................. 26

- Descripción del Proceso RESPONSABLE Líder funcional + dueño del proceso

Notas: 26 La base de este manual son los procesos/sub-procesos definidos en la especificación funcional

138 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

PROTOCOLO DE PRUEBA Se definirán protocolos para las distintas pruebas y sus respectivos informes: - Prueba Individual - Prueba de Cadena - Prueba de Integración - Prueba Global - Prueba de Performance, stress, volumen y seguridad - Prueba de Compatibilidad NOMBRE Protocolo de Prueba OBJETIVO Describir detalladamente los casos de prueba, los resultados esperados y obtenidos. CONTENIDO Fecha:.. ../....../...... Proyecto:....................................................................................................................... Responsable:....................................................... Sector:............................................... Participantes:................................................................................................................. - Objeto de la Prueba - Procedimientos de Prueba - Casos/ Condiciones detalladas de prueba (DTC): - Descripción del caso - Entorno - Datos de Entrada - Acciones - Resultado esperado - Resultado obtenido 27 - Observaciones Ver detalles y formatos en las planillas anexadas

RESPONSABLE Líder Informático (Prueba Individual, de Cadena, de Integración, de Performance, stress, volumen y seguridad) Líder funcional (Prueba Global)

Notas: 27 Se incluirán por ejemplo los pendientes de prueba.

139 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

APROBACIÓN DE PRUEBA Se realizarán los informes de aprobación de prueba correspondientes a cada prueba: - Prueba Individual - Prueba de Cadena - Prueba de Integración - Prueba Global - Prueba de Performance, stress, volumen y seguridad - Prueba de Compatibilidad NOMBRE Aprobación de Prueba OBJETIVO Documentar la aprobación de la prueba CONTENIDO Fecha:.. ../....../...... Proyecto:....................................................................................................................... Responsable:....................................................... Sector:............................................... Participantes:................................................................................................................. Objeto de la Prueba Resumen Ejecutivo del resultado de la prueba Criterio de Aceptación Prueba Aprobada 28 - Observaciones - Prueba Rechazada - Justificación - Recomendación RESPONSABLE Líder Informático (Prueba Individual, de Cadena, de Integración, de Performance, stress, volumen y seguridad) Líder funcional (Prueba Global) -

Notas: 28 Se incluirán por ejemplo los pendientes de prueba.

140 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

PROTOCOLO DE PRUEBA PILOTO NOMBRE Protocolo de Prueba Piloto OBJETIVO Describir detalladamente los casos de prueba a realizar en la Prueba Piloto, los resultados esperados y los resultados obtenidos en la misma. CONTENIDO Fecha:.. ../....../...... Proyecto:....................................................................................................................... Responsable:....................................................... Sector:............................................... Participantes:................................................................................................................. Objeto de la Prueba Piloto Sitio Procedimientos de Prueba Documentación Asociada Casos: - Descripción del caso - Entorno - Datos de Entrada - Acciones - Resultado esperado - Resultado obtenido 29 - Observaciones RESPONSABLE Líder funcional -

Notas: 29 Se incluirán por ejemplo los pendientes de prueba.

141 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

HOMOLOGACIÓN PRUEBA PILOTO NOMBRE Homologación de Prueba Piloto OBJETIVO Documentar la aprobación y homologación de la prueba piloto CONTENIDO Fecha:.. ../....../...... Proyecto:....................................................................................................................... Responsable:....................................................... Sector:............................................... Participantes:................................................................................................................. Objeto de la Prueba Resumen Ejecutivo del resultado de la prueba Criterio de Aceptación Prueba Aprobada 30 - Observaciones - Prueba Rechazada - Justificación - Recomendación RESPONSABLE Líder funcional -

Notas: 30 Se incluirán por ejemplo los pendientes de prueba.

142 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

PLAN DE IMPLANTACIÓN NOMBRE Plan de Implantación OBJETIVO Establecer el plan de implantación de un proyecto. CONTENIDO Fecha:.. ../....../...... Proyecto:....................................................................................................................... Responsable:....................................................... Sector:............................................... Participantes:................................................................................................................. Sitios para la implantación Recursos físicos y humanos necesarios Plan de trabajo - Cronograma - Responsables - Hitos RESPONSABLE Líder funcional -

143 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

PLAN DE SOPORTE NOMBRE Plan de Soporte OBJETIVO Establecer el plan de soporte a la implantación. CONTENIDO Fecha:.. ../....../...... Proyecto:....................................................................................................................... Responsable:....................................................... Sector:............................................... Participantes:................................................................................................................. Objetivo y alcance Circuito de atención, recepción, diagnóstico, derivación y resolución de incidentes Identificación de nivel de criticidad de incidentes Tipo de soporte por sitio de implantación - In situ - Funcional - Técnico - Centralizado - Funcional - Técnico - Disponibilidad y horario de atención de soporte por sitio RESPONSABLE Líder funcional / Líder informático -

144 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

PROTOCOLO DE IMPLANTACIÓN NOMBRE Protocolo de Implantación OBJETIVO Definir el protocolo de pruebas para la Implantación CONTENIDO Fecha:.. ../....../...... Proyecto:....................................................................................................................... Responsable:....................................................... Sector:............................................... Participantes:................................................................................................................. Sitio Procedimientos de Prueba Documentación Asociada Casos: - Descripción del caso - Entorno - Datos de Entrada - Acciones - Resultado esperado - Observaciones RESPONSABLE Líder funcional -

145 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

PROCEDIMIENTO DE PRODUCCIÓN NOMBRE Procedimiento de Producción OBJETIVO Definir qué, cómo y cuándo se desarrollan las tareas de producción CONTENIDO Fecha:.. ../....../...... Proyecto:....................................................................................................................... Responsable:....................................................... Sector:............................................... Participantes:................................................................................................................. - Procedimientos de Backup - Descripción - Responsable - Observaciones - Procedimientos de Seguridad - Descripción - Responsable - Observaciones - Procedimientos de Performance - Descripción - Responsable - Observaciones - Control de Procedimientos Rutinarios - Descripción - Responsable - Observaciones - Anexo: Documentación de Soporte - Documento de Soporte a Mesa de Ayuda - Documento de Soporte a Operación/Soporte Técnico RESPONSABLE Líder informático

146 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

ACUERDO DE IMPLANTACIÓN NOMBRE Acuerdo de Implantación OBJETIVO Documentar la decisión de implantar el proyecto CONTENIDO Fecha:.. ../....../...... Proyecto:....................................................................................................................... Responsable:....................................................... Sector:............................................... Participantes:................................................................................................................. - Fecha - Breve Descripción del Proyecto - Responsables - Firmas - Observaciones RESPONSABLE Líder funcional

147 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

FASE: IMPLANTACIÓN APROBACIÓN CONVERSIÓN DE DATOS NOMBRE Aprobación Conversión de Datos OBJETIVO Documentar la aprobación de la conversión de Datos CONTENIDO Fecha:.. ../....../...... Proyecto:....................................................................................................................... Responsable:....................................................... Sector:............................................... Participantes:................................................................................................................. - Criterio de Aceptación - Muestreo estadístico - Resumen de Volúmenes Convertidos - Volumen Previo - Volumen Final - Tiempos de conversión - Conversión Aprobada - Observaciones - Conversión Rechazada - Justificación - Recomendación RESPONSABLE Líder funcional

148 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

RECEPCIÓN PROVISORIA NOMBRE Recepción Provisoria OBJETIVO Documentar la Recepción Provisoria del Sistema (Aprobación), informando los resultados de la Prueba de Aceptación del Mismo. CONTENIDO Fecha:.. ../....../...... Proyecto:...........................................................…….................................................. Responsable:....................................................... Sector:............................................... Participantes:................................................................................................................. Descripción del sistema/etapa recibido Resumen Ejecutivo del resultado de la Prueba de Aceptación Criterio de Aceptación Prueba Aprobada 31 - Observaciones - Prueba Rechazada - Justificación - Recomendación - Documentación recibida (fuentes, manuales, etc.) - Firma responsables RESPONSABLE Líder funcional -

Notas: 31 Se incluirán por ejemplo los pendientes de prueba.

149 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

CONTRATO DE SERVICIO DE PRODUCCION Este documento se describe en el Anexo de “Acuerdo y Contrato de Servicio”. INFORME SISTEMA EN PRODUCCIÓN NOMBRE Informe Sistema en Producción OBJETIVO Documentar Puesta en Producción de un Sistema CONTENIDO Fecha:.. ../....../...... Proyecto:....................................................................................................................... Responsable:....................................................... Sector:............................................... Participantes:................................................................................................................. - Resumen Ejecutivo de Estado General del Sistema - Documentación Asociada - Contrato de Servicio de Producción - Pendientes (Hardware, Conectividad, Funcionalidades) - Descripción - Plazos de Entrega - Comentarios RESPONSABLE Líder funcional Administrador funcional

150 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

FASE: PRODUCCIÓN TABLERO DE MANDO NOMBRE Tablero de Mando OBJETIVO Presentar los indicadores para medir los procesos técnicos (seguridad, performance, procesos rutinarios) y el soporte (atención a usuarios, soporte funcional, soporte técnico, soporte aplicativo) CONTENIDO Fecha:.. ../....../...... Proyecto:....................................................................................................................... Responsable:....................................................... Sector:............................................... Participantes:................................................................................................................. - Procesos Técnicos - Procesos de Seguridad - Indicador 1 - Indicador n - Procesos de Performance - Indicador 1 - Indicador n - Procesos Rutinarios - Indicador 1 - Indicador n - Soporte - Atención de Usuarios - Indicador 1 - Indicador n - Soporte Funcional - Indicador 1 - Indicador n RESPONSABLE El Tablero de Mando será completado por el responsable de cada proceso. El contrato de servicio de producción define los indicadores del tablero de mando, la metodología de medición, responsable de medición.

151 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

FASE: BALANCE DEL PROYECTO INFORME DEL CIERRE DEL PROYECTO Se deberá confeccionar un documento con el informe de cierre del Proyecto, donde resuman: -

Inversiones totales reales y presupuestadas Tiempos reales vs. originalmente estimados. Valores de métricas claves (según lo identificado en el Estudio Preliminar): valores anteriores a puesta en producción, valores posteriores, estimados y reales. Comentarios sobre el desarrollo del proyecto.

152 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

ANEXO: MODELO DE PLAN DE PROYECTO En este capítulo se presenta un modelo de cronograma, que podrá ser utilizado como referencia para la construcción y seguimiento de los proyectos. Este plan incluye todas las fases con sus tareas, excluyendo la fase de producción, ya esta fase no está incluida en el ciclo de vida de proyecto. Cabe señalar que este modelo es un plan referencial y por lo tanto el inicio, la duración y la dependencia entre las tareas dependerán de cada proyecto en particular. A continuación, se presenta un cronograma resumido con las fases y etapas.

A continuación, se adjunta el archivo con el modelo completo (incluye todas las tareas descriptas en la Guía de Gestión de Proyectos de Sistemas):

153 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

154 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

ACUERDO y CONTRATO de SERVICIO

155 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

ACUERDO Y CONTRATO DE SERVICIO En este capítulo se describen los modelos del Acuerdo de Servicio de Proyecto y del Contrato de Servicio de Producción.

ACUERDO DE SERVICIO DE PROYECTO El Acuerdo de Servicio de Proyecto se suscribe entre el Owner del Proyecto y el Responsable Informático del Proyecto de Sistemas, y se firma en el Hito 0 de Aprobación del Proyecto. Este acuerdo tendrá vigencia hasta la Puesta en Producción de la totalidad del Proyecto y definirá las obligaciones del cliente y del proveedor durante el ciclo de vida del proyecto. Cabe señalar, que las condiciones y obligaciones correspondientes a la producción, operación y mantenimiento del sistema, se definen en el Contrato de Servicio de Producción. El Acuerdo de Servicio de Proyecto está basado en el Modelo Único de Contrato de Servicio.

MODELO

ACUERDO DE SERVICIO DE PROYECTO......………………………………... ENTRE ……..................................................... en

adelante

el

denominado

PROVEEDOR,

representado

por

....................................................................................………………………..

Y en

......................................................................... adelante

el

denominado

CLIENTE,

representado

....................................................................................………………………..

156 de 181

por

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

OBJETO Y CONSIDERACIONES INICIALES 1.1. El presente acuerdo tiene por objeto fijar los términos y condiciones del servicio de provisión de la solución informática ………………………... .......................................................................................................................................................................... ...................................................................................................................................... 1.2. El servicio comprende los siguientes puntos: ..................................................................…. .......................................................................................................................................................................... ...................................................................................................................................... 1.3. El presente acuerdo reemplaza integralmente a los siguientes documentos: .......................................................................................................................................................................... .......................................................................................................................................................................... .................................................................................................................... SERVICIOS A PRESTAR Describir los entregables, tareas y responsabilidades de acuerdo a la Guía de Gestión de Proyectos de Sistemas. 2.1. Servicios. Describir completamente los servicios a prestar (contenido, tipo, forma, etc.) (Enumerar los entregables a cargo del proveedor) 2.2. Obligaciones del PROVEEDOR. Describir todas las obligaciones que deberá cumplir el proveedor para la prestación del servicio objeto del presente contrato (modalidad de intervención, modo de requerimiento, etc.) (Enumerar las tareas y responsabilidades del proveedor para cumplir con lo enunciado en 2.1) 2.3. Obligaciones del CLIENTE. Describir todas las obligaciones que deberá cumplir el cliente (especificaciones, cooperación, asistencia, etc.) (Enumerar los entregables, tareas y responsabilidades del cliente para cumplir con lo enunciado en 2.1) 2.4. Procesos. Describir y/o referenciar el/los proceso/s asociado/s al servicio objeto de este contrato. 2.5. Elementos que intervienen para la prestación. En caso de necesitar identificar dichos elementos se deberá utilizar un formulario Anexo, indicando en cada caso tipos de equipos, cantidades, números de serie, ubicación precisa, etc. Asimismo, en caso de producirse modificaciones en los elementos deberá incluirse la modificación en el Anexo mencionado previamente. En este caso se detallarán altas, bajas y modificaciones de equipos. En ningún caso el PROVEEDOR podrá producir modificaciones sin recibir autorización formal por parte del CLIENTE. 2.6. Formas de Intervención. El CLIENTE definirá las actuaciones que deberá realizar el PROVEEDOR para intervenir (como por ejemplo, retrasos en el cumplimiento de plazos acordados). A los fines de estas actuaciones regirán los tiempos indicativos detallados en un Anexo a tal efecto. Asimismo, el proveedor deberá informar al cliente de manera fehaciente los avances y tiempos estimados de cada intervención. 2.7. Ámbito. Determinar los lugares para la prestación, que se detallarán en un Anexo. Deberá mantenerse actualizado con las modificaciones, de existir. 2.8. Pruebas de aceptación. El PROVEEDOR se compromete a informar por escrito la finalización de las tareas vinculadas a este servicio, a efectos de que el CLIENTE dé comienzo a las pruebas de aceptación respectivas. Si se le solicitara al PROVEEDOR participar de las mismas, se le informará de esta situación en tiempo y forma, debiendo el mismo confirmar de igual modo su disponibilidad. En este punto se describirán las condiciones de la Aceptación de la Implantación y la Generación del Documento de Recepción Provisoria del Proyecto (previo a la Puesta en Producción).

157 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

ROLES INTERVINIENTES En el anexo de descripción de roles, se detallarán los nombres y sectores de la organización que cumplen cada rol. En el caso en que un rol sea llevado a cabo por más de una persona o por más de un sector, se identificará claramente las responsabilidades de cada sector y persona o grupo de personas. 3.1. PROVEEDOR. Identificar con nombre, rol, dirección, teléfono y e-mail de las personas que intervendrán para brindar el servicio. Esta información deberá ser completada en una ficha. El PROVEEDOR presentará al CLIENTE en un Anexo al presente dicha ficha, que deberá ser actualizado por el PROVEEDOR toda vez que correspondiere. La modificación de la nómina de personal no altera la responsabilidad del PROVEEDOR en cuanto a confidencialidad y daños emergentes por acción u omisión. Asimismo, deberá el PROVEEDOR, informar con la debida anticipación los listados correspondientes al personal que se encuentre disponible para su convocatoria. 3.2. CLIENTE. Identificar el o los responsables de interactuar con el proveedor. Para ello se deberá completar con nombre, rol, dirección y teléfono la ficha que se encuentra en un Anexo. El CLIENTE presentará al PROVEEDOR la ficha indicada, que deberá ser actualizada por el CLIENTE toda vez que correspondiere.

OTROS SERVICIOS VINCULADOS 4.1. Describir otros servicios adicionales (esquema de seguimiento, etc.) que estén involucrados y que no formen parte del Servicio objeto del presente contrato. 4.2. Seguimiento de Proyecto. Se acordarán entre las partes la metodología de seguimiento de proyectos. Se definirán los indicadores de seguimiento: - Desvío de Presupuesto - Desvío de Plazos - Desvío de funciones entregados respecto a funcionalidades solicitadas - Incidentes - Otros 4.3. Se detallará en un Anexo los informes preestablecidos (frecuencia de prestación, etc.) con los tiempos previstos de solicitud. Cualquier otro informe deberá acordarse en el momento por ambas PARTES. 4.4. Ambas PARTES pueden proveer o solicitar nuevos servicios no comprendidos en el presente contrato, pero que se desprendan del objeto del mismo. En ese caso, el CLIENTE deberá realizar una descripción del servicio y deberá enviar tal descripción al PROVEEDOR quien notificará al CLIENTE, a los _____ días, si desea proceder a la negociación de la inclusión del nuevo servicio. Si ambas PARTES deciden continuar para la prestación del nuevo servicio, se propondrá una definición del servicio, precios y tiempos. 4.5 El presente contrato puede ser modificado o ajustado de común acuerdo de las partes.

PRECIOS Y PAGO. COSTOS Y PENALIDADES Los puntos 5.1 y 5.2 se aplican en el caso en que el presupuesto sea del Owner del Proyecto. 5.1. Entre las PARTES se establecerán los datos de prestación y contraprestación del servicio contratado, registrando al inicio del contrato, los insumos, gastos imprescindibles, viáticos, horas extras, guardias pasivas y todo aquel que fuera necesario detallar. Dichos precios se especificarán en un Anexo, diferenciando aquellos de única vez (no recurrentes) de los periódicos (recurrentes), indicando para estos últimos expresamente la periodicidad de cada cargo. 158 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

5.2. El CLIENTE efectuará las transferencias presupuestarias que surjan de las prestaciones solicitadas al PROVEEDOR, contra conformidad del CLIENTE del servicio entregado. En el caso de trabajos adicionales requeridos por el CLIENTE, el PROVEEDOR contestará formalmente la posibilidad de hacerlo en tiempo y forma y cotizará las tareas para que se efectúen las transferencias presupuestarias y de hs. extraordinarias en caso de necesidad. 5.3. Penalidades por incumplimiento. Se deberán establecer rangos y escalas de calidad de servicio, definiendo niveles de incumplimiento (del cliente y del proveedor) y asociarlo con las penalidades correspondientes. Deberán ser establecidas explícitamente tomando como base los indicadores de calidad de servicio que se definan en el ítem 6.2. del presente, contemplando los rangos y/o escalas que para los mismos AMBAS PARTES definan y acuerden. Se clasificarán en: 5.3.1. Penalidades para el CLIENTE 5.3.2. Penalidades para el PROVEEDOR. En ambos casos, las penalidades definidas y acordadas deberán guardar coherencia en un todo con las responsabilidades específicas detalladas según lo sugerido en el ítem 7. CALIDAD DEL SERVICIO 6.1. Satisfacción del cliente. El CLIENTE se reserva el derecho de realizar las encuestas de satisfacción a clientes (internos y/o externos) que estime necesarias. 6.2. Indicadores. Los indicadores de evaluación y seguimiento del presente contrato deberán detallarse en un Anexo. Se definirán los reportes de monitoreo, el tablero de mando y los indicadores que lo componen, junto con los responsables de medición, valores de referencia, umbrales. Se identificarán aquellos indicadores correspondientes a la performance de los aspectos técnicos del sistema y al soporte (a usuarios, funcional, técnico, aplicativo). A través de estos indicadores se medirán los servicios que el proveedor está prestando. RESPONSABILIDADES 7.1. El PROVEEDOR deberá disponer de los medios para prestar el servicio. El CLIENTE deberá brindar las condiciones para que el PROVEEDOR pueda dar el servicio de acuerdo al nivel de calidad acordado. 7.2. Las PARTES se obligan a cumplir estrictamente toda disposición reglamentaria y demás normas, procedimientos y políticas de la compañía dictadas o a dictarse por el sector competente y que resulte aplicable. 7.3. Ninguna de las PARTES será responsable por los retrasos o fallas de operación o performance derivadas de actos o hechos ajenos al control de cada parte. 7.4. La parte afectada por un evento de caso fortuito o fuerza mayor, deberá notificar rápida y fehacientemente a la otra acerca de todo retraso o falla que origine hasta que desaparezca el evento que lo causa. La parte afectada actuará de buena fe para solucionar la causa de retraso o falla, y ambas partes procederán con diligencia una vez que la causa del retraso o falla haya cesado o desaparecido. REGISTRACIÓN Y COMUNICACIÓN 8.1. Las PARTES se comprometen a divulgar en los sectores intervinientes ,incluyendo las áreas de Calidad corporativas así como las propias de los sectores que participan en el contrato, la firma del presente contrato, de conformidad con las disposiciones de la normativa vigente.

159 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

VIGENCIA 9.1. El presente contrato tendrá vigencia desde __________ y hasta __________ (de acuerdo al plan de proyecto). Finalizada, o antes de finalizada la vigencia del presente contrato, las PARTES en forma expresa podrán decidir la prórroga del Contrato o, en su caso, la celebración de otro. 9.2. Como excepción al plazo de vigencia fijado en el punto anterior, se pacta que: cesará la vigencia de este Contrato, si existiere una situación no prevista que altere significativamente la voluntad bilateral articulada en el presente, y ante ello, cualquiera de las PARTES optase por denunciar el Contrato comunicándolo fehacientemente a la otra, dentro de los ______ días de serle notificada aquella situación. 9.3. Si en algún hito go no-go del proyecto se acuerda no continuar con el mismo, de común acuerdo entre las partes cesará la vigencia del acuerdo. GARANTÍAS SOBRE LAS INTERVENCIONES 10.1. El PROVEEDOR garantizará todo defecto atribuible a su intervención por un período acordado por las PARTES medido en días corridos, contados a partir del momento en que el CLENTE verifique el normal funcionamiento del servicio intervenido, lo cual conlleva implícito la no reiteración de la intervención por un mismo motivo atribuible a fallas por la propia intervención del PROVEEDOR.

CONDUCTAS FRAUDULENTA 11.1. Las PARTES acuerdan trabajar estrechamente y en forma conjunta para combatir el uso fraudulento del servicio objeto del presente contrato, o consecuencia derivada de éste.

CESIÓN DEL CONTRATO 12.1. Las PARTES no podrán transferir ni ceder en todo o en parte, a título gratuito u oneroso, el presente contrato, salvo expresa autorización formal por parte de la otra PARTE.

INCUMPLIMIENTO. RESOLUCIÓN DEL CONTRATO. 13.1. Ante situaciones de: 13.1.1. Disolución del sector 13.1.2. Falta de pago 13.1.3. Incumplimiento de las cláusulas detalladas precedentemente se elevará al Organismo de Control, la petición de rescisión del presente contrato. 13.2. En el caso de incumplimiento de obligaciones estipuladas en este contrato (con respecto a los plazos e indicadores), el CLIENTE deberá intimar al PROVEEDOR a subsanar la situación en un plazo que de acuerdo a la circunstancia resulte razonable.

CONFIDENCIALIDAD 14.1. Toda la información que sea intercambiada en virtud del presente, será tratada en forma confidencial. 14.2. En tal sentido, las PARTES se comprometen a tratar en forma confidencial toda información técnica, comercial, referida a los sistemas, ingeniería, datos técnicos, registros comerciales, correspondencia, datos sobre costos, listas de clientes, etc., que resulte de la solicitud de cualquiera de las PARTES. 160 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

14.2. La información resultante deberá ser clasificada según la categorización de la empresa. 14.3. En caso que fuera necesario se firmará un Acuerdo de Confidencialidad de la información.

ORGANISMO DE CONTROL. 15.1. Se designa como Organismo de Control, a todos los efectos que diere lugar el presente contrato a ..........................................................................................................................….

COMPETENCIA 16.1. Las PARTES se comprometen a cumplir el presente contrato de buena fe. Sin embargo ante cualquier controversia o reclamo relativo a la interpretación, aplicación, revisión o consecuencias del mismo, que no pudieran resolverse mediante negociaciones amigables entre las PARTES, se elevará al Organismo de Control la petición de arbitraje correspondiente.

161 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

CONTRATO DE SERVICIO DE PRODUCCIÓN El Contrato de Servicio de Producción se suscribe entre el Usuario del sistema y los Proveedores (internos y externos) del servicio, y se firma previo al Hito 5: Sistema en Producción.

MODELO

CONTRATO DE SERVICIO DE PRODUCCIÓN DE SISTEMAS DE ......... ENTRE .................................................... en adelante el denominado PROVEEDOR, con domicilio en ......................................................................................................................

representado por ....................................................................................….

Y

..........................................................................................

en adelante el denominado CLIENTE, con domicilio en ......................................................................................................................

representado por ........................................................................................

OBJETO Y CONSIDERACIONES INICIALES 1.1. El presente acuerdo tiene por objeto fijar los términos y condiciones del servicio de .......................................................................................................................................................................... .......................................................................................................................................................................... .................................................................................................................... 1.2. El servicio comprende los siguientes puntos: ..................................................................…. .......................................................................................................................................................................... ...................................................................................................................................... 1.3. El presente acuerdo reemplaza integralmente a los siguientes documentos: .......................................................................................................................................................................... .......................................................................................................................................................................... ....................................................................................................................

162 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

SERVICIOS A PRESTAR Definir los servicios a prestar basándose en los entregables del Proyecto definidos en la Guía de Gestión (Documentación de Puesta en Producción, Procedimiento de Producción, Planes de backup, Planes de Contingencia, Pliego de Compra, etc.) La descripción del servicio, deberá contener mínimamente estos ítems: -

-

Identificación del nivel de criticidad de los incidentes Esquema de soporte, definiendo el circuito de atención, recepción, diagnóstico, derivación y resolución de incidentes. - Objetivo y Alcance - Tipo de soporte - In Situ, centralizado - Funcional, Técnico Disponibilidad de Servicio Tiempos de intervención Capacitación (en caso que corresponda): nuevas funcionalidades, nuevos usuarios, etc.

2.1. Servicios. Describir completamente los servicios a prestar (contenido, tipo, forma, etc.) 2.2. Obligaciones del PROVEEDOR. Describir todas las obligaciones que deberá cumplir el proveedor para la prestación del servicio objeto del presente acuerdo (modalidad de intervención, modo de requerimiento, etc.) 2.3. Obligaciones del CLIENTE. Describir todas las obligaciones que deberá cumplir el cliente (especificaciones, cooperación, asistencia, etc.) 2.4. Procesos. Describir y/o referenciar el/los proceso/s asociado/s al servicio objeto de este acuerdo. 2.5. Elementos que intervienen para la prestación. En caso de necesitar identificar dichos elementos se deberá utilizar un formulario Anexo, indicando en cada caso tipos de equipos, cantidades, números de serie, ubicación precisa, etc. Asimismo, en caso de producirse modificaciones en los elementos deberá incluirse la modificación en el Anexo mencionado previamente. En este caso se detallarán altas, bajas y modificaciones de equipos. En ningún caso el PROVEEDOR podrá producir modificaciones sin recibir autorización formal por parte del CLIENTE. 2.6. Formas de Intervención. El CLIENTE definirá las actuaciones que deberá realizar el PROVEEDOR para intervenir (como por ejemplo, para restitución de un servicio interrumpido). A los fines de estas actuaciones regirán los tiempos indicativos detallados en un Anexo a tal efecto. Asimismo, el proveedor deberá informar al cliente de manera fehaciente los avances y tiempos estimados de cada intervención. 2.7. Ámbito. Determinar los lugares para la prestación, que se detallarán en un Anexo. Deberá mantenerse actualizado con las modificaciones, de existir. 2.8. Pruebas de aceptación. El PROVEEDOR se compromete a informar por escrito la finalización de las tareas vinculadas a este servicio, a efectos de que el CLIENTE dé comienzo a las pruebas de aceptación respectivas. Si se le solicitara al PROVEEDOR participar de las mismas, se le informará de esta situación en tiempo y forma, debiendo el mismo confirmar de igual modo su disponibilidad.

ROLES INTERVINIENTES En el anexo de descripción de roles, se detallarán los nombres y sectores de la organización que cumplen cada rol. En el caso en que un rol sea llevado a cabo por más de una persona o por más de un sector, se identificará claramente las responsabilidades de cada sector y persona o grupo de personas. 3.1. PROVEEDOR. Identificar con nombre, rol, dirección, teléfono y e-mail de las personas que intervendrán para brindar el servicio. Esta información deberá ser completada en una ficha. 163 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

El PROVEEDOR presentará al CLIENTE en un Anexo al presente dicha ficha, que deberá ser actualizado por el PROVEEDOR toda vez que correspondiere. La modificación de la nómina de personal no altera la responsabilidad del PROVEEDOR en cuanto a confidencialidad y daños emergentes por acción u omisión. Asimismo, deberá el PROVEEDOR, informar con la debida anticipación los listados correspondientes al personal que se encuentre disponible para su convocatoria. 3.2. CLIENTE. Identificar el o los responsables de interactuar con el proveedor. Para ello se deberá completar con nombre, rol, dirección y teléfono la ficha que se encuentra en un Anexo. El CLIENTE presentará al PROVEEDOR la ficha indicada, que deberá ser actualizada por el CLIENTE toda vez que correspondiere.

OTROS SERVICIOS VINCULADOS 4.1. Describir otros servicios adicionales (capacitación, energía, horarios, etc.) que estén involucrados y que no formen parte del Servicio objeto del presente acuerdo. 4.2. Capacitación. El CLIENTE brindará capacitación ante requerimiento del PROVEEDOR, de acuerdo a temarios vigentes y según modalidad que se establezca para cada caso. El PROVEEDOR se compromete a presentar al CLIENTE el plan de capacitación anual o específico requerido. 4.3. El CLIENTE se reserva el derecho de requerir al PROVEEDOR los informes vinculados que estime conveniente respecto de sus actuaciones. Se detallará en un Anexo los informes preestablecidos, con los tiempos previstos de solicitud. Cualquier otro informe deberá acordarse en el momento por ambas PARTES. 4.4. Ambas PARTES pueden proveer o solicitar nuevos servicios no comprendidos en el presente acuerdo, pero que se desprendan del objeto del mismo. En ese caso, el CLIENTE deberá realizar una descripción del servicio y deberá enviar tal descripción al PROVEEDOR quien notificará al CLIENTE, a los _____ días, si desea proceder a la negociación de la inclusión del nuevo servicio. Si ambas PARTES deciden continuar para la prestación del nuevo servicio, se propondrá una definición del servicio, precios y tiempos. 4.5 El presente acuerdo puede ser modificado o ajustado de común acuerdo de las partes.

PRECIOS Y PAGO. COSTOS Y PENALIDADES 5.1. Entre las PARTES se establecerán los datos de prestación y contraprestación del servicio contratado, registrando al inicio del acuerdo, los insumos, gastos imprescindibles, viáticos, horas extras, guardias pasivas y todo aquel que fuera necesario detallar. Dichos precios se especificarán en un Anexo, diferenciando aquellos de única vez (no recurrentes) de los periódicos (recurrentes), indicando para estos últimos expresamente la periodicidad de cada cargo. 5.2. El CLIENTE efectuará las transferencias presupuestarias que surjan de las prestaciones solicitadas al PROVEEDOR, contra conformidad del CLIENTE del servicio entregado. En el caso de trabajos adicionales requeridos por el CLIENTE, el PROVEEDOR contestará formalmente la posibilidad de hacerlo en tiempo y forma y cotizará las tareas para que se efectúen las transferencias presupuestarias y de hs. extraordinarias en caso de necesidad. 5.3. Penalidades por incumplimiento. Se deberán establecer rangos y escalas de calidad de servicio, definiendo niveles de incumplimiento (del cliente y del proveedor) y asociarlo con las penalidades correspondientes.

164 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

Deberán ser establecidas explícitamente tomando como base los indicadores de calidad de servicio que se definan en el ítem 6.2. del presente, contemplando los rangos y/o escalas que para los mismos AMBAS PARTES definan y acuerden. Se clasificarán en: 5.3.1. Penalidades para el CLIENTE 5.3.2. Penalidades para el PROVEEDOR. En ambos casos, las penalidades definidas y acordadas deberán guardar coherencia en un todo con las responsabilidades específicas detalladas según lo sugerido en el ítem 7. CALIDAD DEL SERVICIO 6.1. Satisfacción del cliente. El CLIENTE se reserva el derecho de realizar las encuestas de satisfacción a clientes (internos y/o externos) que estime necesarias. 6.2. Indicadores. Los indicadores de evaluación y seguimiento del presente acuerdo deberán detallarse en un Anexo. Se definirán los reportes de monitoreo, el tablero de mando y los indicadores que lo componen, junto con los responsables de medición, valores de referencia, umbrales. Se identificarán aquellos indicadores correspondientes a la performance de los aspectos técnicos del sistema y al soporte (a usuarios, funcional, técnico, aplicativo). A través de estos indicadores se medirán los servicios que el proveedor está prestando. RESPONSABILIDADES 7.1. El PROVEEDOR deberá disponer de los medios para prestar el servicio. El CLIENTE deberá brindar las condiciones para que el PROVEEDOR pueda dar el servicio de acuerdo al nivel de calidad acordado. 7.2. Las PARTES se obligan a cumplir estrictamente toda disposición reglamentaria y demás normas, procedimientos y políticas de la compañía dictadas o a dictarse por el sector competente y que resulte aplicable. 7.3. Ninguna de las PARTES será responsable por los retrasos o fallas de operación o performance derivadas de actos o hechos ajenos al control de cada parte. 7.4. La parte afectada por un evento de caso fortuito o fuerza mayor, deberá notificar rápida y fehacientemente a la otra acerca de todo retraso o falla que origine hasta que desaparezca el evento que lo causa. La parte afectada actuará de buena fe para solucionar la causa de retraso o falla, y ambas partes procederán con diligencia una vez que la causa del retraso o falla haya cesado o desaparecido. 7.5. El PROVEEDOR tomará las precauciones necesarias para evitar daños en los espacios y áreas operativas, equipos y propiedades del CLIENTE. REGISTRACIÓN Y COMUNICACIÓN 8.1. Las PARTES se comprometen a divulgar en los sectores intervinientes ,incluyendo las áreas de Calidad corporativas así como las propias de los sectores que participan en el acuerdo, la firma del presente acuerdo, de conformidad con las disposiciones de la normativa vigente.

VIGENCIA 9.1. El presente acuerdo tendrá vigencia por un período de __________ a partir de la fecha de su suscripción. Finalizada, o hasta un mes antes de finalizada la vigencia del presente acuerdo, las PARTES en forma expresa podrán decidir la prórroga del Acuerdo o, en su caso, la celebración de otro.

165 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

9.2. Como excepción al plazo de vigencia fijado en el punto anterior, se pacta que: cesará la vigencia de este Acuerdo, si existiere una situación no prevista que altere significativamente la voluntad bilateral articulada en el presente, y ante ello, cualquiera de las PARTES optase por denunciar el Acuerdo comunicándolo fehacientemente a la otra, dentro de los ______ días de serle notificada aquella situación.

GARANTÍAS SOBRE LAS INTERVENCIONES 10.1. El PROVEEDOR garantizará todo defecto atribuible a su intervención por un período acordado por las PARTES medido en días corridos, contados a partir del momento en que el CLENTE verifique el normal funcionamiento del servicio intervenido, lo cual conlleva implícito la no reiteración de la intervención por un mismo motivo atribuible a fallas por la propia intervención del PROVEEDOR.

CONDUCTAS FRAUDULENTAS 11.1. Las PARTES acuerdan trabajar estrechamente y en forma conjunta para combatir el uso fraudulento del servicio objeto del presente acuerdo, o consecuencia derivada de éste.

CESIÓN DEL ACUERDO 12.1. Las PARTES no podrán transferir ni ceder en todo o en parte, a título gratuito u oneroso, el presente acuerdo, salvo expresa autorización formal por parte de la otra PARTE.

INCUMPLIMIENTO. RESOLUCIÓN DEL ACUERDO. 13.1. Ante situaciones de: 13.1.1. Disolución del sector 13.1.2. Falta de pago 13.1.3. Incumplimiento de las cláusulas detalladas precedentemente se elevará al Organismo de Control, la petición de rescisión del presente acuerdo. 13.2. En el caso de incumplimiento de obligaciones estipuladas en este acuerdo (con respecto a los plazos e indicadores), el CLIENTE deberá intimar al PROVEEDOR a subsanar la situación en un plazo que de acuerdo a la circunstancia resulte razonable.

CONFIDENCIALIDAD 14.1. Toda la información que sea intercambiada en virtud del presente, será tratada en forma confidencial. 14.2. En tal sentido, las PARTES se comprometen a tratar en forma confidencial toda información técnica, comercial, referida a los sistemas, ingeniería, datos técnicos, registros comerciales, correspondencia, datos sobre costos, listas de clientes, etc., que resulte de la solicitud de cualquiera de las PARTES. 14.2. La información resultante deberá ser clasificada según la categorización de la empresa. 14.3. En caso que fuera necesario se firmará un Acuerdo de Confidencialidad de la información.

ORGANISMO DE CONTROL. 166 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

15.1. Se designa como Organismo de Control, a todos los efectos que diere lugar el presente acuerdo a ..........................................................................................................................….

COMPETENCIA 16.1. Las PARTES se comprometen a cumplir el presente acuerdo de buena fe. Sin embargo ante cualquier controversia o reclamo relativo a la interpretación, aplicación, revisión o consecuencias del mismo, que no pudieran resolverse mediante negociaciones amigables entre las PARTES, se elevará al Organismo de Control la petición de arbitraje correspondiente.

167 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

MODELO ÚNICO DE CONTRATO DE SERVICIO A continuación se adjunta el documento del Modelo Único de Contrato de Servicio elaborado por el Grupo de Trabajo de SLA liderado por la Dirección de Reingeniería y Calidad.

168 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

Anexo XXX Cuestionarios

169 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

Cuestionario C1: Identificación de objetivos FINALIDAD: identificar las exigencias del Cliente y organizar / planificar las actividades. DESCRIPCIÓN: relevar esquemáticamente las informaciones relacionadas a una descripción formal de las exigencias del Cliente y a los resultados previstos. APLICACIÓN: se completa con el Dueño del Proceso en el fin de la fase Planeamiento. Cuestionario C1 Identificación de objetivos Fecha:

Nombre entrevistado:

del

Unidad organizativa:

Proceso:

Requisitos:



Resultados previstos:



Instrumentos:



7.1.1.1

DESCRIPCIÓN

Requisitos: El Dueño del Proceso debe expresar cuidadosamente sus requisitos y los resultados que espera obtener a través de la aplicación de la Metodología. Resultados previstos: Output que se proveerá (Reporte, documentos varios, etc.). Instrumentos: Los instrumentos (Cuestionarios, etc.) que se utilizarán en el trabajo.

170 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

Cuestionario C2: Nivel Objetivo / Supuesto del Proceso FINALIDAD: determinar el “perfil” del Nivel Objetivo / Supuesto del proceso examinado. DESCRIPCIÓN: el cuestionario retoma los atributos de los niveles de un proceso, los ordena lógicamente y los traduce en preguntas a proponer al entrevistado para evaluar el perfil del nivel objetivo / supuesto. Las preguntas se deben referir al tiempo final (instancia a la cual el dueño piensa alcanzar el objetivo) identificado con el Dueño. El tiempo final puede ser hoy si la evaluación debe medir la distancia entre “lo que piensa el Dueño del proceso” (en este caso el nivel es supuesto) y “lo que es efectivamente el proceso actual o real”. El tiempo final puede ser, en cambio, el momento que el Dueño define como objetivo para efectuar una acción de mejora, una reestructuración organizativa, una acción de reingeniería, etc. (está relacionado con el nivel objetivo). En este caso la Metodología debe medir la distancia entre la madurez del proceso actual y la misma del proceso objetivo. Las posibles respuestas a las preguntas del cuestionario C2 son: “SÍ”,”NO”, o “NA” (No Aplicable: si la pregunta no tiene sentido en el contexto analizado). Se reserva un espacio de “Notas” para eventuales consideraciones (a solicitar). El perfil objetivo identificado puede coincidir con uno de los niveles definidos o ser intermedio entre dos o más de estos. APLICACIÓN: se completa con el Dueño del Proceso en la fase Planeamiento si se requiere evaluar la distancia entre el Nivel actual y el objetivo / supuesto.

7.1.1.2

Nro.

DESCRIPCIÓN

Pregunta

Descripción

1

¿Piensa que Proceso (P) existe?

el

2

¿Piensa que el P fue ejecutado por lo menos una vez?

3

¿Piensa que el P tiene una secuencia operativa identificable?

4

¿Piensa que existe conocimiento acerca del P?

5

¿Piensa que existe una estabilización en el P?

6

¿Piensa que el P está documentado?

Atributo de Referencia

¿El P tiene un nombre (A01)? ¿Conoce los limites (cuando empieza y cuando termina)(A11)?

A01: Existente A11: Identificado

¿El P fue enteramente ejecutado por las personas involucradas? ¿En qué porcentaje y por quién? ¿En este momento está en fase de realización por primera vez?

A02: Teórico A03: Parcialmente realizado A12: Realizado de hecho .... A21: Definido

¿Las actividades que componen el P y su secuencia lógica-temporal son claras para las personas que trabajan en el proceso? ¿Las personas que operan en el proceso, tienen los conocimientos sobre el mismo consolidados (individualmente o por (sub)grupos), aunque no estén documentados, y sobre los instrumentos necesarios para su realización? ¿El modo de operar el P (método de trabajo) está estabilizado? ¿Existen casos atípicos periódicamente difundidos y explicados?

A13: Conocimiento parcial en evolución A27: Conocimiento consolidado ...

¿Existen algunos documentos (mapa / esquema representativo) que contienen una descripción (aunque sea resumida / esquemática) del P?

A14: Documentación existente pero parcial ....

171 de 181

A23: Estabilizado

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

Nro.

Pregunta

7

¿Esta representación del P piensa que está estructurada?

8

¿Existe una norma que establece reglas / lineamientos / regulaciones para el P?

9

¿Esta representación del P está reconocida como válida por el Management?

10

¿Piensa que existen algunos Procedimientos que describan el P?

11

¿Piensa que hay una revisión / actualización de estos Procedimientos?

12

¿Piensa que estos Procedimientos y el P están alineados?

13

¿Los Procedimientos del P están reconocidos y oficializado por el Management?

14

¿Piensa que todos los que trabajan en el P utilizan (conocen) los Procedimientos?

15

¿Piensa que conocimiento consensuado?

16

¿Piensa que toda la información necesaria para el trabajo del P está disponible para las personas involucradas en el P?

el está

Descripción

Atributo de Referencia

¿Este mapa / esquema contiene las actividades, su secuencia, los input / output?

A22: Representado gráficamente en forma esquemática

....

A26: Existe una norma ....

....

A28: Represtación univoca del P ...

¿Las modalidades operativas, los roles, las responsabilidades, y los instrumentos usados para realizar el P están descriptas?

A24: Actividades estructuradas en Procedimientos

¿Estos procedimientos son periódicamente actualizados también en función de las evoluciones del P? ¿Quién debería tener este rol?

A37: Hay revisión y actualización (mantenimiento) de los procedimientos

¿Estos Procedimientos reflejan el modo operativo actual (A25)?¿Están alineados al proceso (A35)?

A25 Coherencia entre los procedimientos A35: Coherencia entre los procedimientos y el P .... A36: Procedimientos reconocidos y oficializados por el Management

¿El Management de la organización saben que existen estos procedimientos?¿Estos procedimientos tienen un circuito de aprobación oficial?

¿La consulta de los procedimientos está disponible para todos los que trabajan en el P? ¿Estos procedimientos son un soporte para quien trabaja en el P? ¿Estos siguen los procedimientos en su trabajo? ¿Cómo se podría garantizar la difusión y la aplicación de los procedimientos? ¿Los conocimientos tecnológicos y los instrumentos (herramientas) de soporte son conocidos y aceptados por los Grupos de Trabajo del P? ...

172 de 181

A32: Conocimiento difundido

A33: Conocimiento consensuado ....

A34: Alineación (información compartida) entre las unidades organizacionales involucradas en el Proceso

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

Nro.

Pregunta

17

¿Piensa que Resultados repetibles?

los son

18

¿Piensa que se puede efectuar un seguimiento sobre las fases del P?

19

¿Hay algunos Indicadores internos de la performance del P?

20

¿Piensa que estos Indicadores son controlados constantemente?

21

¿Hay una gestión que persiga el mejoramiento basada en la performance observada en los indicadores?

Descripción

Atributo de Referencia

¿Realizando nuevamente el P con los mismos input y en las mismas condiciones de trabajo se consiguen los mismos output? ¿En el mismo tiempo? ¿También intercambiando las personas involucradas? ¿Los output son lógicamente dependientes de las actividades realizadas / no realizadas en el P? ¿Conozco siempre el output que obtengo del proceso según las actividades que se realizan o no? ¿En un momento cualquiera piensa que se puede identificar en cual de sus fases se encuentra el proceso?¿Existe una figura que verifica esto?

A31: Sistemático (repetitivo).

¿Cuales son y cual es su fin?

A41: Hay indicadores internos

¿La recolección de los datos de prestación en el P es metódica? ¿Existe un responsable en la Organización de la recolección / elaboración de los datos? ¿Quién es? ¿La recolección de los datos es parte de los procedimientos y del día a día? ¿Que utilización se hace de los datos recolectados? ¿Se los comunican al Management? ¿Se emprenden normalmente algunas actividades correctivas como consecuencia de datos fuera de lo normal? ¿Cómo se administra el feedback de los datos analizados?

A43: Medido A42: Los indicadores están integrados como procedimiento normal

A38: Se puede efectuar un seguimiento sobre las fases del P

A44: Gestionado estratégicamente.

Cuestionarios por la evaluación de los Operativos Cuestionario C3: Nivel Actual del Proceso FINALIDAD: identificar el “perfil” del nivel actual del Proceso examinado. DESCRIPCIÓN: el cuestionario retoma los atributos de los niveles de un proceso, los ordena lógicamente y los traduce en preguntas a proponer al entrevistado para evaluar el perfil del nivel actual. Las posibles respuestas son: “SÍ”, “Parcialmente / Si, no univoco”, ”NO”, o “NA” (No Aplicable: si la pregunta no tiene sentido en el contexto analizado). Se reserva un espacio para eventuales consideraciones. El perfil identificado puede coincidir con uno de los niveles definidos o ser intermedio entre dos o más de estos. APLICACIÓN: se compila con los personales operativos del Proceso en la fase Relevamiento. 7.1.1.3

Nro.

DESCRIPCIÓN

Pregunta

Descripción

Atributo de Referencia 173 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

Nro.

Pregunta

Descripción

1

¿El Proceso existe?

(P)

2

¿El P fue ejecutado al menos una vez?

3

¿El P tiene una secuencia operativa identificable?

4

¿Existe conocimiento acerca del P?

5

¿Existe una estabilización en el P?

6

¿El P documentado?

7

¿Esta representación del P está estructurada?

8

¿Existe una norma que establece reglas / lineamientos / regulaciones para el P?

9

¿Esta representación del P está reconocida como válida por el Management?

10

¿Existen algunos Procedimientos que describan el P?

11

¿Hay una revisión / actualización de estos Procedimientos?

12

¿Estos Procedimientos y el P

está

Atributo de Referencia

¿El P tiene un nombre (A01)? ¿Conoce los limites (cuando empieza y cuando termina)(A11)?

A01: Existente A11: Identificado

¿El P fue enteramente ejecutado por las personas involucradas? ¿En que porcentaje y por quien? ¿En este momento está en fase de realización por primera vez?

A02: Teórico A03: Parcialmente realizado A12: Realizado de hecho .... A21: Definido

¿Las actividades que componen el P y su secuencia lógica-temporal son claras para las personas que trabajan en el proceso? ¿Las personas que operan en el proceso, tienen los conocimientos sobre el mismo consolidados (individualmente o por (sub)grupos), aunque no estén documentados, y sobre los instrumentos necesarios para su realización? ¿El modo de operar el P (método de trabajo) está estabilizado? ¿Existen casos atípicos periódicamente difundidos y explicados?

A13: Conocimiento parcial en evolución A27: Conocimiento consolidado ...

¿Existen algunos documentos (mapa / esquema representativo) que contienen una descripción (aunque sea resumida / esquemática) del P? ¿Este mapa / esquema contiene las actividades, su secuencia, los input / output?

A14: Documentación existente pero parcial ....

....

A26: Existe una norma ....

....

A28: Represtación unívoca del P ...

¿Las modalidades operativas, los roles, las responsabilidades, y los instrumentos usados para realizar el P están descriptas?

A24: Actividades estructuradas en Procedimientos

¿Estos procedimientos son periódicamente actualizados también en función de las evoluciones del P? ¿Quién debería tener este rol? ¿Estos Procedimientos reflejan el modo operativo actual (A25)?¿Están alineados al proceso (A35)?

A37: Hay revisión y actualización (mantenimiento) de los procedimientos A25 Coherencia entre los procedimientos A35: Coherencia entre

174 de 181

A23: Estabilizado

A22: Representado gráficamente en forma esquemática

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

Nro.

Pregunta

Descripción

Atributo de Referencia

¿El Management de la organización saben que existen estos procedimientos?¿Estos procedimientos tienen un circuito de aprobación oficial?

los procedimientos y el P .... A36: Procedimientos reconocidos y oficializados por el Management

están alineados? 13

¿Los Procedimientos del P están reconocidos y oficializado por el Management?

14

¿Todos los que trabajan en el P utilizan (conocen) los Procedimientos?

15

¿El conocimiento está consensuado?

16

¿Toda la información necesaria para el trabajo del P está disponible para las personas involucradas en el P?

17

¿Los Resultados son repetibles?

18

¿Se puede efectuar un seguimiento sobre las fases del P?

19

¿Hay algunos Indicadores internos de la performance del P?

20

¿Estos Indicadores son controlados constantemente?

¿La consulta de los procedimientos está disponible para todos los que trabajan en el P? ¿Estos procedimientos son un soporte para quien trabaja en el P? ¿Estos siguen los procedimientos en su trabajo? ¿Cómo se podría garantizar la difusión y la aplicación de los procedimientos? ¿Los conocimientos tecnológicos y los instrumentos (herramientas) de soporte son conocidos y aceptados por los Grupos de Trabajo del P? ...

¿Realizando nuevamente el P con los mismos input y en las mismas condiciones de trabajo se consiguen los mismos output? ¿En el mismo tiempo? ¿También intercambiando las personas involucradas? ¿Los output son lógicamente dependientes de las actividades realizadas / no realizadas en el P? ¿Conozco siempre el output que obtengo del proceso según las actividades que se realizan o no? ¿En un momento cualquiera piensa que se puede identificar en cual de sus fases se encuentra el proceso?¿Existe una figura que verifica esto?

A32: Conocimiento difundido

A33: Conocimiento consensuado ....

A34: Alineación (información compartida) entre las unidades organizacionales involucradas en el Proceso A31: Sistemático (repetitivo).

A38: Se puede efectuar un seguimiento sobre las fases del P

¿Cuales son y cual es su fin?

A41: Hay indicadores internos

¿La recolección de los datos de prestación en el P es metódica? ¿Existe un responsable en la Organización de la recolección / elaboración de los datos? ¿Quién es? ¿La recolección de los datos es parte de los procedimientos y del día a día?

A43: Medido A42: Los indicadores están integrados como procedimiento normal

175 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

Nro.

Pregunta

Descripción

Atributo de Referencia

21

¿Hay una gestión que persiga el mejoramiento basada en la performance observada en los indicadores?

¿Que utilización se hace de los datos recolectados? ¿Se los comunican al Management? ¿Se emprenden normalmente algunas actividades correctivas como consecuencia de datos fuera de lo normal? ¿Cómo se administra el feedback de los datos analizados?

A44: Gestionado estratégicamente.

176 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

Cuestionario C4 – Nivel X: Descripción del Proceso

32

FINALIDAD: describir el Proceso en términos de fases y de características para individualizar las funcionalidades del nivel objetivo definido por el Dueño. DESCRIPCIÓN: hay un cuestionario C4 por cada nivel objetivo. El cuestionario tiene la finalidad de identificar las características del Proceso actual y, eventualmente, de evaluar el grado de las mismas a través de la visión del personal operativo entrevistado. La descripción de cada pregunta se presenta en gris en la tabla. APLICACIÓN: se completa con el personal operativo del Proceso (a excepción del “C4-4 Parte II” que se completa con los Dueños, porque se refiere a la Gestión Estratégica) en la Fase: Relevamiento. Cuestionario C4 - Nivel 4 PARTE II (Dueños)

33

34

FINALIDAD: puntualizar detalles en la Gestión del Proceso (en particular acerca de “indicadores”) si existen mas Dueños involucrados en el análisis (por ejemplo cuando se analizan dos procesos relacionados para identificar problemas en las interfases). DESCRIPCIÓN: identifica el grado de “dominio (control) sobre del proceso a través de indicadores”. La descripción de cada pregunta se presenta en gris en la tabla. APLICACIÓN: se completa con los

Notas: 32

Ver Anexo: Cuestionarios Ver párrafo siguiente. 34 Ver Anexo: Cuestionarios 33

177 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

GLOSARIO

178 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

GLOSARIO ABM

Altas, Bajas y Modificaciones. Son funcionalidades que ofrece un sistema para ingresar, eliminar y actualizar registros.

Actor

Persona que interviene y participa en la elaboración de las distintas actividades definidas dentro de una tarea o fase

BD

Base de Datos

BE (Eventos de Negocios)

Condición de Prueba de más alto nivel. Definirán un área funcional

Big Bang

Modalidad de puesta en producción que se realiza para todos los clientes, líneas, etc. en forma conjunta

Bug

Error en algún módulo del sistema

Business Plan

Plan que considera inversiones, gastos iniciales, upgrades, capacitación, mantenimiento de la aplicación, etc.

Condiciones de Detalle de Prueba (DTC)

Derivan de los requerimientos funcionales y del usuario. Están compuestas por la condición que se va a probar y los resultados esperados de alto nivel asociados.

Condiciones Representan agrupaciones lógicas de condiciones de detalle de prueba. Sumarizadas de Pueden describir funcionalidades (ej: suspensión – conexión) o categorías (ej: Prueba (STC) Clientes, Productos, etc). Coordinador

Persona encargada de coordinar y llevar adelante todas las tareas dentro de una etapa

CPU

Procesador de la computadora (Central Processing Unit)

DAFO

Análisis de Debilidades, Amenazas, Fortalezas, Oportunidades que se realiza para un proyecto (en inglés SWOT: strong, weak, oportunity, threat)

DB

Data base

Datos para la Prueba

Reutilización de los Datos provenientes de la Fase de Prueba Previa y creación de Datos adicionales para asegurar que se hayan cubierto todas las Condiciones de Detalle de Prueba.

Despliegue

Implantación, generalización, roll out

DTC Derivan de los requerimientos funcionales y del usuario. Están compuestas por (Condiciones de la condición que se va a probar y los resultados esperados de alta nivel Detalle de asociados. Prueba) Entregables

Son los documentos que se obtienen como resultado de la ejecución de las tareas.

Eventos de Negocios (BE)

Condición de Prueba de más alto nivel. Definirán un área funcional 179 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

FCE

Factores Claves de Éxito.

Generalización

Implantación, despliegue, roll out

GST (Global System Test)

Implica verificar que el conjunto de los desarrollos cubran los requerimientos de negocio predefinidos.

Hito

Punto de control que aparece al final de cada fase. Existen dos clases: – Hito GO / NO GO: son aquellos donde se determinan la continuidad o no del proyecto. – Hito de validación: son aquellos que permiten validar y controlar la realización de las tareas y de los entregables de una fase.

Implantación

Generalización, despliegue, roll out

In house

Paquete cerrado, desarrollos propios

Legacy

Sistemas ya existentes en la Cía

Llave en mano

Modalidad de contratación en la cual se implementan funcionalidades a un precio fijo donde se establece la fecha de inicio y fecha de fin de la implementación sin importar la cantidad de horas hombre utilizadas...

MBs

Mega Bits

NOC / SOC

Network Operation Center / Service Operation Center provee monitoreo de la Red 24x7 asegurando que los eventuales inconvenientes sean rápidamente identificados y resueltos

Proyecto

Proyecto de sistemas es todo aquel que comienza con la identificación de una necesidad y culmina con la implantación de la solución informática.

Prueba Caja Blanca

Definir casos de prueba de modo tal que cada línea de código sea ejecutada y cada condición de bifurcación o decisión del código sea alcanzada con todos los casos posibles. Asegurar que cada punto de decisión sea pasado con su valor mínimo, máximo y algún valor intermedio. Asegurar que todas las condiciones de error que el módulo debe detectar sean correctamente ejecutadas.

Prueba Caja Negra

Definir casos de prueba teniendo en cuenta la función que cada módulo cumple estableciendo datos de entrada al módulo y sus correspondientes resultados esperados.

QA (Quality Assurance)

Aseguramiento de la calidad. Evaluar periódicamente la realización total del proyecto para asegurar que se cumplen los estándares de calidad establecidos para el proyecto.

Responsable

Persona encargada de llevar adelante las tareas a su cargo

Rol

Actividad que puede ser desarrollada por una persona o un grupo de personas

Roll Out

Implantación, generalización, despliegue

Sitio Web

Es solo un conjunto de archivos relacionados entre sí, que puede estar guardado en cualquier soporte magnético (disco rígido, cd, etc.). Para que este 180 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

conjunto de archivos sea visible desde la Web será necesario almacenarlo en un «web server». Dado que Internet es una red gigante de servidores conectados entre sí, es necesario que cada website tenga una identidad propia (un nombre) para poder ser ubicado. El nombre de un espacio dentro de un servidor, en el lenguaje de Internet, es un conjunto de números que conforman una dirección IP única. Esta dirección permite identificar unívocamente a ese espacio que, en el caso del web hosting, contiene un website determinado. SLA

(Service Level Agreement) Compromiso de nivel de servicio

SO

Sistema Operativo

STC Representan agrupaciones lógicas de condiciones de detalle de prueba. (Condiciones Pueden describir funcionalidades (ej: suspensión – conexión) o categorías (ej: Sumarizadas de Clientes, Productos, etc). Prueba) TIR

Tasa Interna de Retorno. Indicador económico que ayuda, junto con el VAN, a determinar la rentabilidad de un proyecto

VAN

Valor Anual Neto. Indicador económico que permite, junto con el TIR determinar la rentabilidad de un proyecto.

Volumetría

(de un sistema) Se refiere a los volúmenes de información, transacciones y tráfico en general que es capaz de manejar un sistema en situaciones normales y picos.

Web Hosting

El servicio de web hosting brinda la posibilidad de «publicar» un sitio en la Web, es decir que hace posible que un sitio se pueda visualizar navegando la web.

Web Server

Es decir un servidor conectado a Internet y que tiene como función servir páginas web.

Web Site

Sitio Web

181 de 181