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

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. Pressman. Como producto puede residir en un teléfono celular inteligente o una computadora central donde produce. de acuerdo a las necesidades / motivaciones de las empresas que consume este “arte” (el software). 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. adquiere. 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. Lic. brindando una introducción completa al tema de la ingeniería de software. transforma. El formato y estilo de esta primera edición está orientada tanto a los aspectos teóricos.Sistemas de Información Gestión de Proyectos Informáticos Prof. el hardware era de propósito general y el software se diseñaba a medida. 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. Pretende servir a estudiantes y profesionales. ya que se incluye fichas y documentos que se utilizan en los proyectos de desarrollo de software. modifica muestra y transmite información tan compleja como un bit o una presentación multimedia. la comunicación de información (Redes) y creación y control de otros programas (Entornos y herramientas de programación). 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. ya que es esto lo que las empresas requieren y necesitan del software. incluyendo su administración y soporte. 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. 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. 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 por ello que quienes estamos en el área de la enseñanza. LA EVOLUCIÓN DEL SOFTWARE Roger S. es decir cumplir con las necesidades de los usuarios y que permita ser construido y mantenido con el mínimo costo y esfuerzo posible. En el comienzo de la era informática el desarrollo de software se realizaba prácticamente sin planificación y con un esfuerzo enorme. debemos orientar y ayudar a quienes quieren ser expertos en esta profesión fascinante a contextualizar el concepto de “arte”. dice en su obra que el Software es a la vez un producto y el vehículo de entrega de un producto. Como vehículo para hacer entrega del producto actúa como la base de control de una PC (Sistema Operativo).. como a los prácticos. 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. Esta publicación pretende que los alumnos comprendan. 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

Las etapas comprendidas en cada fase.etapas .Aprobación de Conversión de Datos .Carga Inicial y Parametrización . Niveles de Desagregación Esta guía propone 3 niveles de desagregación.sus tareas.los outputs (o entregables) . pueden ejecutarse en forma paralela. .Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. se desarrollan en forma secuencial.el coordinador (la figura responsable de coordinar todas las tareas dentro de esta etapa) ETAPAS TAREAS .los inputs.Conversión de Datos . donde la entidad FASE es la que reviste mayor peso como entidad. .su descripción. .Comunicación ENTREGABLES COORDINADOR PREPARACIÓN IMPLANTACIÓN .Aprobación Conversión Datos Líder Funcional Cada tarea se define a través de: .entregables (los principales entregables de las tareas de una misma etapa) .el responsable (figura responsable de ejecutar esta tarea) 8 de 181 . FASE ETAPA TAREA Cada fase se define a través de: .Ejecución de Confiabilización de Datos .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: .Capacitación .los actores (lista de participantes de la tarea) y . mientras que las tareas de una misma. 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.

. INPUT OUTPUT ......... determinan en sí mismas el cierre de la fase.El responsable (figura responsable del hito) ...........Sector:..............Sistemas de Información Gestión de Proyectos Informáticos Prof... interrupción y/o postergación de un proyecto ......... Este documento incluirá la definición de los procesos a implementar.....Líder informática ...3........ 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..........Procesos de Negocio ACTORES ...........Objetivo ............ se conforma una instancia de validación...Usuarios RESPONSABLE ......Líder funcional Cada entregable se define a través de: ...........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..Contenido ..... donde se describen y/o especifican en forma detallada las necesidades de los usuarios......... Lic......... se desarrollan tareas de revisión.Nombre .Check list A su vez. análisis............. los hitos se pueden clasificar en: ....Los inputs. ORGANIZACIÓN DEL PROYECTO 9 de 181 .....Los outputs (o entregables) . por su relevancia.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:.............. cada hito se define a través de: ....... Por lo tanto.............. Estas tareas... aprobación y/o convalidación de los principales entregables de las mismas..............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....Descripción de la .............................Los actores (lista de participantes) ...Hitos de Go. Participantes:........ Luego del cierre de la fase y considerando el resultado global de la misma..Especificación Necesidad Funcional ....No Go: Aquellos hitos donde se decide la continuación.... .........Tarea de cierre de la fase .......Líder funcional ....1.. Roberto García 4..... Responsable:..

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. el equipo del proyecto debe organizarse de manera que maximice las habilidades y capacidades de cada persona. el número de personas que compondrá el equipo. se nombran coordinadores de tareas a corto plazo. Comunicación entre subgrupos e individuos es horizontal. É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. No tiene un jefe permanente.Sistemas de Información Gestión de Proyectos Informáticos Prof. 10 de 181 . 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. Usuarios finales Para ser eficaz. Lic. Gestores superiores 2. Vertical a lo largo de la jerarquía de control. La comunicación entre el jefe y los miembros es vertical. Clientes 5. La comunicación entre los miembros es horizontal. 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. Descentralizado controlado (DC). Los participantes El proceso del software lo componen participantes que pueden clasificarse en una de cinco categorías: 1. Gestores (técnicos) del proyecto 3. sus niveles de preparación y la dificultad general del problema. Tiene un jefe definido que coordina tareas y jefes secundarios con responsabilidades sobre sub tareas. problema y proceso. Profesionales 4. 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. Se sugieren tres organigramas de equipo genéricos: Descentralizado democrático DD).

Incluyen reuniones de revisión de estado e inspecciones de diseño y de código. se definen de manera tal que.  Red interpersonal: discusiones informales con personas que no están en el proyecto pero que pueden tener experiencia. 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). 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. su envergadura y cantidad de entidades involucradas.  Informal. de acuerdo al tipo de proyecto. definición de requisistos etc. 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. enfoque impersonal: incluyen documentos. ROLES DEL INGENIERO DEL SOFTWARE En esta sección se definen los roles que intervienen en un Equipo de Proyecto. la incertidumbre.. una persona podrá adoptar más de un rol o por el contrario un rol podrá estar compuesto por más de una persona. etc. entregas memorandos técnicos. producción o quality assurance (Aseguramiento de calidad). Paradigma abierto: estructura el equipo de manera que consiga algunos de los controles asociados con el paradigma cerrado. Cabe destacar. que independientemente de los roles específicos. Los mismos no se encuentran asociados a un sector o persona específica de la organización. 11 de 181 . en cambio. Lic. procedimientos interpersonales: actividades de garantía de calidad.  Formal. procedimientos interpersonales: incluyen reunioes de grupo para divulgación de información. Cabe señalar. de acuerdo a la envergadura del mismo. la interoperatividad (comunicación soft nuevo con el anterior). cada integrante del equipo del proyecto deberá garantizar el cumplimiento de las normas de la empresa. sino que. correos electronicos.Sistemas de Información Gestión de Proyectos Informáticos Prof. ORGANIZACIÓN DEL EQUIPO DEL PROYECTO Los ingenieros del software están habilitados para cumplir cualquier rol en los equipos de implantación. 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. EQUIPO DE PROYECTO El siguiente diagrama describe una propuesta genérica de la constitución del Equipo del Proyecto. que el Comité Director definirá la organización particular para cada proyecto.  Comunicación electrónica: videoconferencia. Paradigma aleatorio: estructura al equipo libremente y depende de la iniciativa individual de los miembros del equipo. Las técnicas de coordinación se categorizan de la siguiente manera:  Formal. resolución de problemas.

Sistemas de Información Gestión de Proyectos Informáticos Prof. Responsable Informático y los Usuarios Finales. Designar integrantes del Comité Ejecutivo. COMITÉ EJECUTIVO Integrado por los roles Owner del Proyecto. El Comité Director podrá delegar sus responsabilidades de acuerdo a la envergadura del proyecto. Roberto García COM ITÉ DIRECTOR RESPONSABLE FUNCIONAL OWNER DEL PROYECTO COM ITÉ EJECUTIVO RESPONSABLE INFORM ÁTICO Q U A L I T Y LÍDER FUNCIONAL LÍDER INFORM ÁTICO EXPERTO EN PROCESOS DE NEGOCIO RESPONSABLE CAPACITACIÓN EXPERTO ECONÓM ICO/ FINA NCIERO EXPERTO EN REDES 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) A S S U R A N C E U S U A R I O S F I N A L E S EQUIPO DE IM PLANTACIÓN SOPORTE USUARIOS ADM INISTRA DOR FUNCIONAL SOPORTE APLICATIVO SOPORTE FUNCIONAL SOPORTE TÉCNICO EQUIPO DE PRODUCCIÓN SOPORTE SEGURIDAD RESPONSABILIDADES COMITÉ DIRECTOR Integrado por los responsables ejecutivos de las áreas funcionales. 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. informáticas y de calidad. Responsable Funcional. Lic. Sus principales responsabilidades son: 12 de 181 .

Experto tecnológico. software de base y de aplicación. administración y el control del Proyecto informático. seguridad y controles. redes. EQUIPO DE PRODUCCIÓN Integrado por los roles Administrador Funcional. Poner en marcha los nuevos procedimientos definidos bajo la responsabilidad del Líder Funcional. Participar de la definición de esquemas de acceso. objetivos. Coordinar esfuerzos de todos los servicios involucrados en el Proyecto. esquemas de implantación y planes de trabajo al inicio del Proyecto. Sus principales responsabilidades son: Brindar soporte funcional. Asegurar que el Proyecto sea consistente con las pautas y alcances fijados. 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. es el responsable de “velar” en términos generales por el cumplimiento de la metodología. los elementos informáticos (hardware. Experto en Calidad. alcances. Soporte en Seguridad y Soporte Aplicativo. Soporte Usuarios. Experto en Redes. Interactuar con el Comité Director y el equipo de implantación. Informar el avance del proyecto al Comité Ejecutivo. Definir responsabilidades de las entidades sobre el equipo de implantación en función de la naturaleza de cada Proyecto. Experto informático. y elevar necesidades respecto a los recursos no funcionales necesarios para el éxito del Proyecto. Soporte Técnico. 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. Sus principales responsabilidades son: Generar y ejecutar el diseño global y detallado. los planes de trabajo y estrategias de implantación. Experto en Seguridad Informática. Al ser el principal beneficiario del proyecto. los análisis técnicos y funcionales. Garantizar el compromiso de las áreas involucradas y la disponibilidad oportuna del personal clave requerido. capacitación técnica). Acordar expectativas. Determinar orientación a adoptar para llevar a cabo el Proyecto. Roberto García - Participar de la planificación. Experto Económico/Financiero.Sistemas de Información Gestión de Proyectos Informáticos Prof. Administrador Funcional y el Proveedor (Interno o Externo). Implementar bajo la coordinación del Líder Informático. Validar tareas de prueba piloto e implantación. Responsable de Soporte al Cambio. Lic. Validar documentos y/o productos a obtener en cada fase. Experto en Procesos de Negocio. Líder Informático. EQUIPO DE IMPLANTACIÓN Integrado por los roles Líder Funcional. Soporte Funcional. Establecer los recursos funcionales requeridos para el Proyecto. 13 de 181 . Responsable de Capacitación.

Evaluar. Definir aspectos informáticos del Proyecto. 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. Definir los lineamientos del Plan de Capacitación junto con el Responsable Funcional. Asegurar la capacitación de los usuarios finales Participar y aprobar de las pruebas del producto. los impactos organizacionales que genera un cambio de Sistemas/Procesos. Participar de la definición del esquema de planificación. Definir los servicios informáticos a contratar. Fijar objetivos de explotación y seguimiento. Validar diseños funcionales y detallados. evaluando impactos en la Organización.establecer recursos informáticos requeridos para el Proyecto. Elaborar el Business Plan del Proyecto junto al Responsable Funcional. etc. soluciones propuestas.elevar necesidades de recursos no informáticos para el éxito del Proyecto. administración y control del Proyecto: . implantación. Informar al Comité Ejecutivo periódicamente sobre el avance del desarrollo. competencias y localizaciones necesarias previas al cambio.planes de trabajo informático y estimación de costos del Proyecto. Validar el Business Plan del Proyecto. Coordinar la prueba piloto desde el punto de vista funcional. la población afectada y el dimensionamiento respecto de las tareas. siendo el nexo con los restantes roles del área informática. Identificar.Sistemas de Información Gestión de Proyectos Informáticos Prof. 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. Participar en el aseguramiento de la logística necesaria para soportar el Sistema. organizacional. Participar en la evaluación técnico/económico de las alternativas de las soluciones propuestas. en la fase de Prueba. Lic. LÍDER FUNCIONAL Sus principales responsabilidades son: Preparar las especificaciones funcionales y los requerimientos del Usuario para los Sistemas en desarrollo. desvíos. . participar de la logística (elegir sitios pilotos y su preparación) Coordinar los soportes funcionales locales y la asistencia funcional. en conjunto con el Usuario Final. .). 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. . seguridad y controles. Administrar y documentar los requerimientos de acceso. etc. si las aplicaciones y entorno satisfacen los requerimientos funcionales. Interactuar principalmente con el Responsable Funcional y Líder informático. garantizando la coherencia global respecto del resto de los Sistemas de información existentes y proyectados de la compañía. factores críticos identificados. Definir y revisar el Acuerdo de Servicio de Proyecto en conjunto con el Responsable Informático.definir las premisas/supuestos del proyecto. Roberto García - Garantizar la coherencia global del Sistema desde el punto de vista funcional (definiendo procedimientos funcionales. - - 14 de 181 . Supervisar al equipo de implantación en sus aspectos funcionales.

materiales. etc. prueba. Ejecutar el Plan de Capacitación a Capacitadores. 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. 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.Plan de Distribución Dotacional . Organizar el Proyecto y preparar los planes de trabajo. Usuarios Finales y Administradores Funcionales. Definir la arquitectura informática y el desarrollo del Sistema. Evaluar periódicamente la realización total del proyecto. intermediando entre estos y el Líder Funcional. Definir desarrollo de adecuaciones necesarias para soportar las especificaciones funcionales recibidas y las de integración con otros Sistemas existentes y/o planificados. capacitación y operación del Sistema. Monitorear el avance y calidad de las tareas e informar y corregir los desvíos. 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.) Elaborar los requerimientos para el ambiente de capacitación. Lic. 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. Nexo con los proveedores involucrados. Colaborar con los líderes del proyecto para detectar y anticipar posibles desvíos y problemas. 15 de 181 . Usuarios Finales y Administradores Funcionales.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. Roberto García LÍDER INFORMÁTICO Sus principales responsabilidades son: Garantizar que el Proyecto. . desarrollo. Definir los ambientes de desarrollo. Asegurar la logística necesaria para impartir la capacitación (manuales. salas. Asegurar capacitación informática del equipo de implantación. Interactuar principalmente con el Responsable Informático y el Líder Funcional. etc. Garantizar el cumplimiento de los aspectos informáticos del proyecto (requerimientos.) Definir las especificaciones detalladas del nuevo Sistema o producto. Asegurar la logística informática necesaria para soportar el Sistema y sus sucesivas versiones. puestos de trabajo.Sistemas de Información Gestión de Proyectos Informáticos Prof.

Participar de los estudios de mercado. Participar en las pruebas del sistema en general con especial participación en las pruebas de performance. Verificar el parque informático para determinar si la tecnología actual de la empresa está preparada para dicho proyecto. del análisis de productos y de la identificación de alternativas. Sus principales responsabilidades son: Colaborar en el análisis costo/beneficio de un proyecto. Sus principales responsabilidades son: Asegurar que el sistema a implantar respete los lineamientos del Plan Tecnológico de la Compañía. - 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. etc. 16 de 181 . Roberto García EXPERTO TECNOLÓGICO Este rol estará llevado a cabo por un grupo de expertos de distintas especialidades. Aprobar o no desde el punto de vista de la seguridad del sistema la puesta en producción del mismo. Lic. Realizar las recomendaciones necesarias de seguridad ya fijadas y específicas para el proyecto en particular en su comienzo. para verificar efectivamente que se hayan realizado las recomendaciones esperadas.) y controlar que sean cumplidas en la instalación. transmisiones. EXPERTO INFORMÁTICO Este rol estará llevado a cabo por un grupo de expertos de distintas especialidades. Estudiar y definir el capacity planning Definir normas técnicas para la operación del sistema (backups. 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. Ejecutar el pasaje a producción Evaluar tiempos y costos de terceros y propios relacionados con el proyecto. verificación de equipos. Verificar el cumplimiento de los requerimientos y normas de seguridad en el análisis de las ofertas. Colaborar en las pruebas en maqueta. Definición del Plan de Trabajo Detallado EXPERTO EN SEGURIDAD INFORMÁTICA Sus principales responsabilidades son: Participar del estudio de factibilidad técnico. volumen y stress. 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. Garantizar la coherencia tecnológica de las ofertas presentadas por los proveedores respecto de la tecnología actual y proyectada. concluyendo en las recomendaciones técnicas pertinentes. evaluando los impactos en los sistemas y en otros proyectos en curso Participar en la elaboración de los manuales de procesos. con el objetivo que sean incorporadas al pliego de compra. Realizar las pruebas de compatibilidad. Participar de las distintas pruebas.Sistemas de Información Gestión de Proyectos Informáticos Prof.

resolver y/o derivar Identificar nuevos requerimientos y derivarlos al Administrador Funcional SOPORTE TÉCNICO Normalmente. 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. 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. EXPERTO EN REDES Este rol estará llevado a cabo por un grupo de expertos de distintas especialidades. los mecanismos de backup para routers y vínculos.Sistemas de Información Gestión de Proyectos Informáticos Prof. y los sistemas de estadísticas para monitoreo del estado de salud de la red. sus principales responsabilidades son: Asesorar acerca de la información que brinda el Sistema y sus funciones en general. Sus principales responsabilidades son: 17 de 181 . Definir los protocolos de comunicación. 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. Lic. los anchos de banda requeridos. este rol estará soportado por un grupo de especialistas de distintas disciplinas y sectores. en equipos y vínculos de comunicació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. Sus principales responsabilidades son: Evaluar el impacto que produce incorporar un nuevo flujo de datos. las rutas básicas y alternativas. resolver y/o derivar SOPORTE FUNCIONAL Sus principales responsabilidades son: Recibir las consultas y reclamos sobre el funcionamiento de un sistema Diagnosticar el problema.

Bases de Datos . 18 de 181 .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.La Composición del Grupo de Trabajo. Sus principales responsabilidades son: Asegurar la integridad y coherencia de los datos Asegurar la confidencialidad: identificación. esquema. responsabilidades .Próximos Pasos .Conectividad .Software de base .Estado .Puntos de atención .Hardware . Roberto García - Recibir las consultas e incidentes técnicos Diagnosticar el problema.Decisiones a tomar . 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.Acciones. autenticación y control de accesos.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. indicando responsables y fechas . resolver y/o derivar Verificar y velar por el mantenimiento operativo: .Cronograma consensuado .Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. se pueden identificar las siguientes pautas para la 1 administración y control del Proyecto.Modalidad del informe de seguimiento que mínimamente deberá contener: .Periodicidad de reuniones de seguimiento . Cada proyecto definirá: .

 La fase de mantenimiento se centra en el cambio que va asociado a la corrección de errores. Estos abarcan tareas que incluyen el análisis de requerimientos. Definir cómo han de diseñarse las estructuras de datos. qué comportamiento del sistema. qué función y rendimiento se desea. El mantenimiento perfectivo lleva al software más allá de sus requisitos funcionales originales. hace cambios en programas de computadoras a fin de que se puedan corregir. Los cimientos que son la base de la ingeniería del software están orientados hacia la calidad. qué interfases van a ser establecidas. 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é. etapas y tareas que se requieren para construir software de alta calidad. métodos y herramientas La ingeniería del software es una tecnología multicapa. Roberto García INTODUCCIÓN A LA METODOLOGÍA Definimos un proceso de software como un marco de trabajo de las fases. Durante esta fase se encuentran cuatro tipos de cambios:  Corrección. Mantenimiento preventivo también llamado reingeniería del software. El que desarrolla el software intenta identificar que información ha de ser procesada. diseño global. se establece un sistema de soporte para el desarrollo del software llamado ingeniería del software asistida por computadora (Computer-aided software engineering CASE). 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. El mantenimiento adaptativo para acomodarlo a los cambios de su entorno externo. Cuando se integran herramientas para que la información creada por una herramienta la pueda utilizar otra. Mantenimiento correctivo para corregir los defectos. a las adaptaciones requeridas a medida que evoluciona el entorno del software. Lic. INGENIERÍA DEL SOFTWARE Proceso. 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. Los métodos de la ingeniería del software indican como construir técnicamente el software. diseño detallado. puesta en producción y mantenimiento. El fundamento de la ingeniería del software es la capa proceso.  La fase de desarrollo se centra en el cómo.  Mejora.  Prevención.Sistemas de Información Gestión de Proyectos Informáticos Prof. y a cambios debidos a las mejoras producidas por los requisitos cambiantes del cliente. cómo han de caracterizarse las interfases. 19 de 181 . adaptar y mejorar más fácilmente. qué restricciones de diseño existen.  Adaptación. 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. y que criterios de validación se necesitan para definir un sistema correcto. Las herramientas de la ingeniería del software proporcionan un soporte automático o semiautomático para el proceso y para los métodos. cómo ha de implementarse la función como una arquitectura del software. pruebas. construcción.

 Definición de problemas: identifica el problema específico a resolver. Esta estrategia se llama modelo de proceso o paradigma de ingeniería del software. el SEI (Software Engineering Institute) utiliza un cuestionario de evaluación y esquema de cinco grados (Ver Cuestionario en anexo xx): Nivel 1: Inicial.. abarcan el modelo de proceso. gestión de configuración del software y medición. definiendo un pequeño número de actividades del marco de trabajo. Roberto García EL PROCESO DEL SOFTWARE Se establece:  Un marco común del proceso. Para determinar el estado actual de madurez del proceso.Mediante la utilización de medidas detalladas. etapas.Para repetir éxitos anteriores en proyectos con aplicaciones similares se aplica la disciplina necesaria para el proceso. un ingeniero del software o un equipo de ingenieros deben aplicar una estrategia de desarrollo que acompañe al proceso.Sistemas de Información Gestión de Proyectos Informáticos Prof.En este nivel se incluyen todas las características definidas en el nivel 2.Se definen pocos procesos. 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. secuencial del desarrollo del software que comienza en un nivel de sistemas y progresa con el análisis. EL MODELO LINEAL SECUENCIAL Lo llamaremos “ciclo de vida básico” sugiere un enfoque sistemático. Estas son independientes de cualquier actividad del marco de trabajo. se comprenden y se controlan cuantitativamente tanto los productos como los procesos. tareas y documentación del ciclo de vida de un proyecto. En el presente trabajo se expondrá a nivel detallado los componentes de las fases.. Nivel 2: Repetible. El SEI ha asociado las ACP a cada uno de los niveles de madurez.  Integración de soluciones: ofrece resultados a los que solicitan la solución en primer lugar..Mediante un resultado cuantitativo del proceso y de las ideas y tecnologías innovadoras se posibilita una mejora del proceso. Nivel 3: Definido. capas de herramientas y las fases genéricas. Nivel 4: Gestionado. 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. Lic. métodos.  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.. diseño (global y 20 de 181 . tales como garantía de calidad del software.. y el éxito depende del esfuerzo individual. Nivel 5: Optimización.  Desarrollo técnico: resuelve el problema a través de la aplicación de alguna tecnología.

La orientación del diseño debe alcanzar documentación que permita traducir los requerimientos funcionales a programas. El desarrollador y el cliente encuentran y definen los objetivos globales para el software. Los proyectos reales raras veces siguen el modelo secuencial que propone el modelo. identifican los requisitos conocidos. Los responsables del desarrollo del software siempre se retrasan respecto de los planes de trabajos concebidos. Una versión de trabajo del (los) programa (s) no estará disponible hasta que el proyecto esté muy avanzado. debe efectuarse las pruebas de los programas. El proceso de pruebas se centra en los procesos lógicos internos del software. pruebas (unitarias y globales) y de puesta en producción del sistema. Diagramas de estructuras. Análisis de los requisitos del software. En estas y en otras muchas situaciones. Implementación. El paradigma de construcción de prototipos comienza con la recolección de requisitos. procesamiento. Diseño (global y detallado). 2. Roberto García detallado). 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. Una vez que se ha generado un código. Asimismo se incluye las actividades de capacitación e implementación. pero no identifica los requisitos detallados de entrada. Lic. 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. 3. o salida. El proceso de reunión de requisitos se intensifica y se centra especialmente en el software. y las áreas del esquema en donde es obligatoria más 21 de 181 . El cliente debe tener paciencia. En este trabajo no se incluye la fase de mantenimiento de un sistema en producción. Desarrollo. A menudo es difícil que el cliente exponga explícitamente todos los requisitos. En esta fase.Sistemas de Información Gestión de Proyectos Informáticos Prof. el trabajo comienza estableciendo requisitos de todos los elementos del sistema y asignando al software algún subgrupo de estos requisitos. EL MODELO DE CONSTRUCCIÓN DE PROTOTIPOS Un cliente a menudo define un conjunto de objetivos generales para el software. construcción e implementación. además se definen las estrategias de capacitación. que se apoya en las estrategias diseñadas en la fase de diseño. DFD. Diagrama de Clases. El ciclo de vida básico acompaña a las actividades siguientes: Ingeniería y modelado de Sistemas/Información. un paradigma de construcción de prototipos puede ofrecer el mejor enfoque. Como el software siempre forma parte de un sistema más grande. Diagrama E-R. El diseño se documenta. Problemas en el modelo lineal ciclo de vida básico: 1. 4. DD.

El desarrollador a menudo hace compromisos de implementación para hacer que el prototipo funcione rápidamente.  Generación de aplicaciones: Trabaja para utilizar componentes ya existentes o a crear componentes reutilizables. Cada secuencia lineal produce un incremento del software. el primer incremento es un producto esencial (núcleo).  Requiere clientes y desarrolladores comprometidos en las rápidas actividades necesarias. Roberto García definición. El modelo en espiral se divide en actividades estructurales. 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. Es una adaptación a alta velocidad del modelo lineal secuencial utilizando un enfoque de construcción basado en componentes. 2. a la vez que permite que el desarrollador comprenda mejor lo que necesita hacer. Comprende las siguientes fases:  Modelado de gestión: Responde: qué información conduce el proceso. 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. Problemas del modelo de construcción de prototipos: 1. El cliente ve lo que parece ser una versión de trabajo del software. 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. A diferencia de la construcción de prototipos. a dónde va y quién la procesa. Cuando se utiliza un modelo incremental. La interacción ocurre cuando el prototipo satisface las necesidades del cliente. Es útil cuando no está disponible el personal para una implementación completa en la fecha límite. quién la genera. 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. El diseño rápido lleva a la construcción de un prototipo. suprimir. o recuperar un objeto de datos. Entonces aparece un “diseño rápido”. Lic.  Pruebas y entrega: Se deben probar todos los componentes nuevos y las interfaces. Problemas del modelo DRA:  Para proyectos grandes. se centra en la entrega de un producto operacional en cada incremento. modificar. El prototipo lo evalúa el cliente/usuario y lo utiliza para refinar los requisitos del software a desarrollar. Este proceso se repite hasta que se elabore el producto completo. qué información se genera. también llamadas regiones de tareas:  Comunicación con el cliente 22 de 181 . requiere recursos humanos suficientes para crear los equipos DRA.  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. El plan afronta la modificación del producto central para cumplir las necesidades del cliente.Sistemas de Información Gestión de Proyectos Informáticos Prof.

incluye algunas de las siguientes herramientas: lenguajes no procedimentales de consulta de base de datos. La ambigüedad. capacidades gráficas de alto nivel y capacidades de hoja de cálculo. Una vez identificadas las clases candidatas se examina si ya existen y en ese caso se vuelven a utilizar. Para conseguirlo.  Ingeniería: construir una o más representaciones de la aplicación. pero residen en estados diferentes. Actualmente. 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. generación de informes. Todas las actividades existen concurrentemente.  Análisis de riesgos: evaluar riesgos técnicos y de gestión. Lic. DIAGRAMA DE FASES Y ETAPAS 23 de 181 . Es un modelo evolutivo e interactivo. conjuntos de tareas y actividades de protección. Modelo de ensamblaje de componentes El modelo de ensamblaje de componentes configura aplicaciones desde componentes preparados de software(“clases”). PRODUCTO Y PROCESO Las personas obtienen tanta satisfacción del proceso creativo que del producto final. 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. En todos los casos se aplican las actividades de protección. Las clases creadas se almacenan en una biblioteca de clases.  Evaluación del cliente: obtener la reacción del cliente. lo incompleto y la inconsistencia se descubren y corrigen mediante el análisis matemático. generación de códigos. TECNOLOGÍA DE PROCESOS Los modelos de procesos tratados se deben adaptar para utilizarse por el equipo de proyecto. Inconvenientes:  Caro y lleva mucho tiempo.Sistemas de Información Gestión de Proyectos Informáticos Prof. 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.  Los desarrolladores poseen pocos antecedentes necesarios. 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 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. manejo de datos. Este modelo lleva a la reutilización del software. Se identifican las clases candidatas. tiempo y otras informaciones relacionadas con el proyecto.  Construcción y adaptación: construir.  Difícil comunicación con el cliente con pocos conocimientos técnicos. 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. probar. Se compone así la primera interacción de la aplicación a construirse. interacción y definición de pantallas. Roberto García  Planificación: definir recursos. instalar y proporcionar soporte al usuario.

Teniendo en cuenta lo anteriormente dicho. se presenta un esquema resumen con las fases generales y los hitos de continuación o detención (go no-go) del proyecto. Roberto García Habiendo efectuado un repaso de los diferentes modelos de diseño de aplicaciones existentes. Dentro del ciclo de vida del proyecto. también conocido como “Modelo Lineal Secuencial”. debemos elegir uno a fin de desarrollar detalladamente las actividades que los equipos de desarrollo deben realizar. DIAGRAMA RESUMEN En esta primera aproximación del modelo. Es importante resaltar que un proyecto de sistemas se inicia con la identificación de las necesidades. Lic. tiene vida propia y finalizará cuando el sistema deje de operar. Desde el momento en que el sistema se pasa a producción. Este contrato acompaña al sistema durante toda su vida de producción. Contrato de Servicio de Producción entre el usuario del sistema y los proveedores (internos y externos) del servicio. suscripto entre el Owner del Proyecto y el Responsable Informático y que acompaña al proyecto durante todo su ciclo de vida 2. Ésta. Acuerdo de Servicio de Proyecto. se debe generar dos contratos: 1. creemos conveniente desarrollar el modelo ciclo de vida básico. 24 de 181 . Este modelo nos permitirá alcanzar el objetivo pedagógico que perseguimos que es saber hacer siguiendo un modelo formal e intuitivo. comienza una nueva fase que no está incluída en el ciclo de vida del proyecto: la fase de Producción. y culmina con la implantación y la puesta en producción del sistema junto con el balance o cierre correspondiente.Sistemas de Información Gestión de Proyectos Informáticos Prof.

Roberto García DIAGRAMA DE FASES A continuación. no-go.Sistemas de Información Gestión de Proyectos Informáticos Prof. 25 de 181 . se presenta un diagrama completo con todas las fases de un proyecto. los hitos go. Lic. y de control y los acuerdos y contratos de servicio.

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

Carta de Decisión .Identificar Necesidades .Business Plan .Informe Ejecutivo Estudio Factiibilidad . Roberto García DIAGRAMA DE ETAPAS. TAREAS Y ENTREGABLES POR FASE Vamos describir el diagrama de las etapas.Confección del Acuerdo de Servicio .Análisis de Presupuesto .Alineamiento Plan Tecnológico . legales y operativas. Factiblidad . 27 de 181 . la situación actual.Elaboración Inf.Relevamiento Global . Ejecutivo Est. 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.Alineamiento Plan Maestro Sistemas .Estudio Factibilidad Económico .Análisis DAFO . si procede.Plan Maestro Actualizado .Estudio Factibilidad Técnico/ Funcional .Análisis Factibilidad Técnica .Acuerdo de Servicio (Borrador) Líder Funcional HITO 0: APROBACIÓN PROYECTO . se identifican los requisitos que se ha de satisfacer y se estudia.Descripición de Objetivos y Alcance .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. Lic. DESCRIPCIÓN DE NECESIDADES Y ESTUDIO PRELIMINAR FASES D E S C R I P C I Ó N de N E C E S I D A D E S ETAPAS TAREAS ENTREGABLES COORDINADOR DESCRIPCIÓN NECESIDADES .Alineamiento Plan Estratégico . que tenga en cuenta restricciones económicas.Identificación de Alternativas . enunciaremos las tareas y entregables de cada una de las fases que compone la metodología que adoptamos.Análisis Costo Beneficio .Análisis Impacto del Proyecto .Identificación Métricas . técnicas.Descripción de la Necesidad Líder Funcional E S T U D I O P R E L I M I N A R ESTUDIO DE FACTIBILIDAD .Sistemas de Información Gestión de Proyectos Informáticos Prof.Métricas Claves .Especificar Requerimiento .Actualización Plan Maestro .Identificación Modalidad de Proyecto .

soluciones basadas en la adquisición de productos software del mercado o soluciones mixtas. se estudian las alternativas de solución. se valora su impacto en la organización. Dichas alternativas pueden incluir soluciones que impliquen desarrollos a medida. se dispondrá de un conjunto de productos que proporcionarán información a tener en cuenta en todo el proceso. la inversión a realizar en cada caso y los riesgos asociados. la situación actual y los requisitos planteados. Lic. Una vez descritas cada una de las alternativas planteadas. Se describe cada una de las alternativas. 28 de 181 . indicando los requisitos que cubre. 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. 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. 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. Roberto García A partir del estado inicial. 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.Sistemas de Información Gestión de Proyectos Informáticos Prof.

Líder Funcional HITO 1: CONVALIDACIÓN ESPECIFICACIÓN P R O C E S O de C O M P R A S . Se delimita el alcance del sistema.Sistemas de Información Gestión de Proyectos Informáticos Prof.Especificación Técnica . a partir de los productos generados en el proceso Estudio Preliminar. También se identifican los usuarios que participan en el proceso de análisis.Análisis Económico .Análisis Ofertas .Quality Management . Lic.Convalidación Pliego .Requerimiento de Compras .Acta de Adjudicación . La definición de requisitos del nuevo sistema se realiza con el objetivo de elaborar el catálogo de requisitos detallado. se genera un catálogo de requisitos generales y se describe el sistema mediante unos modelos iniciales de alto nivel.Revisión Modalidad de Proyecto . Así mismo se elabora el plan de trabajo a seguir.Descripción Requerimientos Funcionales .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.Realización de Especificación .Ofertas (Técnica y Económica) Compras ANALÍSIS TÉCNICO .Emisión Dictamen Técnico . 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 .Plan General de Trabajo .Pruebas de Funcionamiento en Maqueta . Se lleva a cabo la descripción inicial del sistema de información.Carta de Decisión Actualizada .Definición de Equipo de Trabajo .Revisión de Business Plan ENTREGABLES COORDINADOR ESPECIFICACIÓN GENERAL . Roberto García DISEÑO GLOBAL Y PROCESO DE COMPRAS FASES D I S E Ñ O G L O B A L ETAPAS TAREAS .Impacto en Arquitectura Técnica .Dictamen Económico Compras HITO 2: ADJUDICACIÓN . que permita describir con precisión el sistema de información.Administración de Riesgo .Circulares Aclaratorias .Equipo de Trabajo .Arquitectura Técnica Actualizada .Especifiación Convalidada CONCURSO .Plan Maestro Actualizado . responsabilidades y dedicaciones necesarias.Est Fact Económica Act.Requerimiento de Compras .Plan General de Trabajo .Dictamen Técnico Líder Informático ANÁLISIS ECONÓMICO .Pliego .Preparación Pliego .Análisis de Requerimientos .Preinforme Técnico .Especificación Funcional .Publicación .Preinforme Técnico de Pruebas . determinando sus perfiles.

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

Gestión de Configuración .Proc.Acuerdo de Implantación 31 de 181 .Definición Proc. stress.Diseño Tecnología .Actualización Gestión de Configuración Especificación Técnica de Detalle PARAMETRIZACIÓN Y DESARROLLO .Manual de Sistemas .Prueba de Integración .Plan de Soporte .Estrategia de Implantación .Plan de Capacitación .Estrategia de Conversión de Datos .Preparación .Especificación Técnica de Detalle .Estrategia de Carga de Datos .Prueba de Cadena .Elaboración Manual de Procesos .Doc.Protocolos de Prueba . Módulos & Parametrización .Parametrización .Prueba de Perf. 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 .Elaboracion Manuales de Usuario .Impacto Organizacional ..Documentación Operativa .Plan de Comunicación ENTREGABLES . Lic.Protocolo de Implantación .Elaboracion Manuales de Sistemas . volumen & seguridad .Elaboración Protocolo de Implantación .Estrategia de Carga de Datos .Manual de Usuario .Diseño del Modelo de Datos . Soporte Mesa de Ayuda .Impacto Organizacional . Gestión de Configuración actualizado Líder Funcional DEFINICIÓN PLAN DE IMPLANTACIÓN Líder Funcional HITO 4: DECISIÓN DE IMPLANTACIÓN .Plan de Pruebas Técnicas .Plan de Acción para el Cambio .Acuerdo de Servicio Revisado .Plan de Contingencia y Desastre .Plan Detallado de Trabajo .Plan de Backup .Procedimiento de Producción .Plan de Backup .Homologación Prueba Piloto .Plan de Comunicación COORDINADOR DISEÑO DETALLADO Líder Informático DEFINICIÓN ESTRATEGIAS Líder Funcional HITO 3: APROBACIÓN DISEÑO DETALLADO .Estrategia de Implantación . Soporte a Operaciones/ Soporte .Manual de Procesos Líder Informático C O N S T R U C C I Ó N PRUEBAS .Desarrollo de Programas .Prueba Global .Prueba Piloto .Plan de Soporte .Plan de Implantación .Plan Detallado de Trabajo .Doc.Elaboración Plan de Pruebas Funcionales .Protocolo de Prueba Piloto . Gestión de Configuración .Plan de Implantación .Homologación Prueba Piloto .Programas.Prototipo .Prueba Individual .Estrategia de Confiabilización .Definición Procedimiento de Producción .Estrategia de Conversión de Datos .Elaboración Plan de Pruebas Técnicas .Plan de Capacitación .Sistemas de Información Gestión de Proyectos Informáticos Prof.Adecuaciones de Programas . técnica de Detalle .Plan de Pruebas Funcionales .Pruebas de Compatibilidad .Aprobación de Pruebas Líder Informático PRUEBA PILOTO .Espec.Estrategia de Confiabilización .Plan de Contingencia y de Desastre .Proc.Plan Acción para el Cambio .Revisión del Acuerdo de Servicio y Alcance .

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

si procede. se define la formación de usuario final y.El segundo bloque de actividades complementa el diseño del sistema de información. 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. 33 de 181 . la especificación detallada de los componentes y la descripción de la estructura física de datos. y conforme al plan de integración del sistema de información. que incluye la ejecución de las verificaciones asociadas a los subsistemas y componentes. de acuerdo al plan de pruebas establecido. de acuerdo a las verificaciones establecidas en el plan de pruebas para el nivel de pruebas del sistema. tanto bases de datos como sistemas de ficheros. En la actividad Elaboración de los Manuales del sistema Usuario. se comienza el diseño físico en la actividad Diseño Físico de Datos. 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. comprobando tanto las interfaces entre subsistemas y sistemas externos como los requisitos. y la evaluación de los resultados. en este proceso se realizan las pruebas unitarias. Opcionalmente. Lic. se lleva a cabo la integración final del sistema de información en la actividad de Pruebas globales (GST). El producto Especificaciones de Construcción del Sistema de Información. incluye un plan de integración del sistema de información. Roberto García Una vez que se tiene el modelo de clases.Sistemas de Información Gestión de Proyectos Informáticos Prof. que se hace según las especificaciones de 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. las pruebas de integración de los subsistemas y componentes y las pruebas del sistema.  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. Para conseguir dicho objetivo. se genera la documentación de usuario final o explotación. en el que se especifica la secuencia y organización de la construcción de los distintos componentes. se construyen los procedimientos de migración y carga inicial de datos. 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.. a partir de los componentes verificados individualmente. es la base para la construcción 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. conforme a los requisitos definidos en el proceso Diseño 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. Una vez construido el sistema de información y realizadas las verificaciones correspondientes. Asimismo. 2. Ejecución de las Pruebas Unitarias.

Lic. Si se ha establecido la necesidad de realizar una migración de datos. 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. 34 de 181 . 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.Sistemas de Información Gestión de Proyectos Informáticos Prof.

Roberto García IMPLANTACIÓN Y CIERRE DEL PROYECTO FASES I M P L A N T A C I O N ETAPAS TAREAS .Carga Inicial y Parametrización .Realización Implantación .Comunicación .Capacitación . 35 de 181 . de Producción) .Conversión de Datos . Soporte a Operaciones/ Soporte actualizado Administrador Funcional HITO 5: SISTEMA EN PRODUCCIÓN COMIENZA FASE DE PRODUCCIÓN .Aprobación Conversión Datos Líder Funcional PUESTA EN PRODUCCIÓN .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.Aprobación de Conversión de Datos .Sistemas de Información Gestión de Proyectos Informáticos Prof.Balance del Proyecto . Lic. Se estudia su alcance y.Contrato de Servicio de Producción . en función de sus características.Recepción Provisoria Líder Informático FORMALIZACIÓN PUESTA EN PRODUCCIÓN .Ejecución de Confiabilización de Datos .Doc.Aceptación Implantación ENTREGABLES COORDINADOR PREPARACIÓN IMPLANTACIÓN . En primer lugar. y la realización de todas las actividades necesarias para el paso a producción del mismo.Documentación Puesta en Producción (Anexo el Proc.Informe Sistema en Producción P R O Y E C T de O B A L A N C E BALANCE DEL PROYECTO . se revisa la estrategia de implantación que ya se determinó en la Fase de Estudio Preliminar. se define un plan de implantación y se especifica el equipo que lo va a llevar a cabo.Contrato de Servicio Producción .Doc. Soporte Mesa de Ayuda actualizado .

etc. Se debe verificar también el comportamiento del sistema bajo las condiciones más extremas. horarios. y del responsable de mantenimiento.) y servicios al cliente (servicio de atención a usuario. 36 de 181 . Finalmente. seguridad. En cualquier caso. Responden a los siguientes propósitos:  Las pruebas de implantación cubren un rango muy amplio. comunicaciones. cuando proceda. la instalación de los componentes. mantenimiento. 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. Las actividades previas al inicio de la producción incluyen la preparación de la infraestructura necesaria para configurar el entorno. 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.  Las pruebas de aceptación se realizan por y para los usuarios. se llevan a cabo las tareas necesarias para la preparación del mantenimiento. se realizan las acciones necesarias para el inicio de la producción. y el acuerdo que se adquiere una vez que se inicie la producción. es necesario que la persona que vaya a asumir el mantenimiento conozca el sistema. seguridad e interfaces con otros sistemas funcionan correctamente. se ajusta a los tiempos de respuesta deseados y que los procedimientos de respaldo. Hay que distinguir entre servicios de gestión de operaciones (servicios por lotes. Lic. Para ello se toman como punto de partida los productos software probados. 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. Asimismo. Además hay que determinar los servicios (y niveles para cada uno) que requiere el sistema que se va a implantar.) que se deben negociar en cuanto a recursos. Roberto García Conviene señalar la participación del usuario de operación en las pruebas de implantación. la migración o carga inicial de datos. etc. 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. siempre y cuando se haya decidido que éste va a efectuarse.Sistemas de Información Gestión de Proyectos Informáticos Prof. Tienen como objetivo validar formalmente que el sistema se ajusta a sus necesidades. la activación de los procedimientos manuales y automáticos asociados y. Se fija el nivel con el que se prestará el servicio como indicador de la calidad del mismo. etc.  La estrategia de transición del sistema antiguo al nuevo. del usuario final en las pruebas de aceptación. costo. antes de su incorporación al entorno de producción.

Roberto García PRODUCCIÓN FASES ETAPAS ADMINISTRACIÓN TÉCNICA TAREAS . que en la fase de Producción las etapas no presentan una secuencialidad. Lic.Capacitación Nuevos Usuarios .Tablero de Mando Soporte Técnico P R O D U C C I Ó N ADMINISTRACIÓN FUNCIONAL . ya que las tareas correspondientes a esta fase pueden realizarse en forma paralela independientemente de la etapa a la que pertenecen.Nuevo Proyecto Administrador Funcional Es importante señalar.Soporte Técnico .Nuevos Requerimientos .Procesos Seguridad . 37 de 181 .Soporte Aplicativo ENTREGABLES COORDINADOR .Otros procesos . Tablas y Parámetros .Mantenimiento de Datos.Sistemas de Información Gestión de Proyectos Informáticos Prof.Tablero de Mando Administrador Funcional SOPORTE .Control de Procesos Rutinarios .Procesos Performance .Procesos Backup .Atención a Usuarios .Tablero de Mando Administrador Funcional EVOLUCIÓN .Soporte Funcional .Administración de Usuarios y Perfiles .

Sistemas de Información Gestión de Proyectos Informáticos Prof. Roberto García DESCRIPCIÓN DE LAS FASES 38 de 181 . Lic.

Roberto García FASE: ESTUDIO PRELIMINAR 39 de 181 .Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic.

Identificación Modalidad de Proyecto .Alineamiento Plan Tecnológico .Alineamiento Plan Estratégico .Análisis Factibilidad Técnica . En las alternativas se considerarán soluciones "a medida". la inversión y los riesgos asociados. Se ha considerado que este proceso es obligatorio. 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.Análisis DAFO .Identificación Métricas . aunque el nivel de profundidad con el que se lleve a cabo dependerá de cada caso. se estudiará el impacto en la organización de cada una de ellas.Informe Ejecutivo Estudio Factiibilidad . legales y operativos.Identificación de Alternativas . 40 de 181 . 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 TAREAS .Plan Maestro Actualizado . Valoración de riesgos de la solución. Lic.Métricas Claves .Elaboración Inf. 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.Alineamiento Plan Maestro Sistemas .Análisis de Presupuesto . 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).Carta de Decisión . Coste/beneficio de la solución.Business Plan .Confección del Acuerdo de Servicio ENTREGABLES COORDINADOR ESTUDIO DE FACTIBILIDAD .Acuerdo de Servicio (Borrador) Líder Funcional HITO 0: APROBACIÓN PROYECTO .Actualización Plan Maestro . Para valorar las alternativas planteadas y determinar una única solución. Factiblidad .Análisis Costo Beneficio . Los criterios con los que se hace esta propuesta no serán estratégicos sino tácticos y relacionados con aspectos económicos.Análisis Impacto del Proyecto . soluciones basadas en la adquisición de productos software del mercado o soluciones mixtas. Ejecutivo Est. Impacto en la organización.Estudio Factibilidad Técnico/ Funcional . Enfoque del plan de trabajo de la solución. Planificación de la solución. técnicos.Acuerdo de Servicio 1 ETAPA: ESTUDIO DE FACTIBILIDAD El propósito de este proceso es analizar un conjunto concreto de necesidades. 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.Sistemas de Información Gestión de Proyectos Informáticos Prof.Estudio Factibilidad Económico . Si se decide seguir adelante pueden surgir uno o varios proyectos que afecten a uno o varios sistemas de información. con la idea de proponer una solución a corto plazo. Los resultados del Estudio de factibilidad del Sistema constituirán la base para tomar la decisión de seguir adelante o abandonar.

Experto tecnológico RESPONSABLE . Estándares del producto.Plan Maestro de Sistemas 3 Alineamiento Plan Tecnológico OUTPUT .Líder funcional .Descripción de la Necesidad (F1) . Entorno tecnológico y comunicaciones. Modelo de negocio/Modelo de dominio. Costes ocasionados por el producto. Si la alternativa incluye un producto software estándar de mercado:      Descripción del producto.Líder informático . 2 Alineamiento Plan Maestro de Sistemas OUTPUT .Líder funcional RESPONSABLE .Descripción de la Necesidad (F1) . Modelo de descomposición en subsistemas.Validación alineamiento ACTORES .Líder Informático . Matriz de procesos/localización geográfica. Estrategia de implantación global del sistema.Líder informático Análisis de coherencia del proyecto con el Plan Maestro de Sistemas INPUT . 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.Experto tecnológico . Lic. se dispondrá de un conjunto de productos que proporcionarán información a tener en cuenta en todo el proceso. Si la alternativa incluye desarrollo:   Modelo abstracto de datos/Modelo de procesos.Validación alineamiento ACTORES . Descripción de los procesos manuales. Matriz datos/localización geográfica.Experto tecnológico Análisis de coherencia del proyecto con el Plan Tecnológico INPUT .Sistemas de Información Gestión de Proyectos Informáticos Prof. Evolución del producto. Roberto García         Solución propuesta: Descripción de la solución. Descripción de adaptación si es necesaria.Plan Tecnológico 41 de 181 .

Estudio de Factibilidad técnico/funcional ACTORES Líder funcional Líder Informático Experto tecnológico Experto seguridad informática RESPONSABLE .Estudio de Factibilidad técnico/funcional ACTORES RESPONSABLE . INPUT .Líder funcional Experto tecnológico Líder informático Experto en procesos - 5 Identificación de Alternativas – Análisis Factibilidad Técnica – Identificación Modalidad del Proyecto Se identifican y proponen las posibles alternativas técnicas. 42 de 181 . Ver productos existentes en la empresa. Lic. Preparación del presupuesto.Usuario 7 Análisis Costo Beneficio – Business Plan Evaluación económica/financiera del proyecto (Business Plan. capacitaciones. Investigación de productos del mercado e identificación preliminar de modalidad del proyecto: producto offthe-shelf o desarrollo a medida.Líder informático - 6 Análisis de Impacto del Proyecto Se identifican el impacto de cada alternativa en función de: .Descripción de la Necesidad (F1) . Se considerará como horizonte del análisis todo el ciclo de vida del producto y se incluirá inversiones. Evaluación técnica para identificar si el parque microinformático es el adecuado.).Sistemas de Información Gestión de Proyectos Informáticos Prof.Estudio de Factibilidad técnico/funcional OUTPUT .Descripción de la Necesidad (F1) . gastos iniciales y upgrades.Usuarios. etc.Validación alineamiento ACTORES RESPONSABLE Líder funcional .Descripción de la Necesidad (F1) . Realización del análisis de factibilidad técnica.Líder funcional . releases. y análisis de impacto en los procesos de negocio y / o en los clientes INPUT .Procesos . otros. como también las horas del personal propio que se imputarán al proyecto. Propuesta de modalidad de adquisición (llave en mano.Líder funcional .) INPUT . se analiza el impacto del proyecto sobre otros sistemas. cálculo de VAN. Además se considerarán costos de terceros. TIR.Plan Maestro . mantenimiento. etc.Lineamientos Tecnológicos OUTPUT . contratación de horas hombre. Análisis de compatibilidad. Roberto García 4 Alineamiento Plan Estratégico Análisis de coherencia del proyecto con los lineamientos estratégicos de la Compañía.Lineamientos Estratégicos OUTPUT .Experto en procesos .

Estudio de Factibilidad técnico/funcional .Experto económico/financier o .Factores Claves de Éxito.Estudio de Factibilidad económico OUTPUT .Líder funcional 9 Identificación de Métricas Identificación de métricas operativas.Riesgos ACTORES .Líder funcional .Análisis DAFO . funcionales y financieras.Descripción de la Necesidad (F1) .Experto informático .Líder funcional .Estudio de Factibilidad técnico/funcional .Estudio de Factibilidad técnico/funcional OUTPUT .Sistemas de Información Gestión de Proyectos Informáticos Prof. riesgos. barreras/restricciones. Esta tarea se llevará a cabo después de la Aprobación del Proyecto (Hito 0) 43 de 181 ..Líder funcional 11 Actualización del Plan Maestro Una vez aprobado el proyecto. y sus objetivos. INPUT .Informe Ejecutivo de Estudio de Factibilidad ACTORES .Líder Funcional RESPONSABLE .Descripción de la Necesidad (F1) .Experto informático RESPONSABLE .Estudio de Factibilidad económico ACTORES .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.Descripción de la Necesidad (F1) . Identificación de Factores Claves de Éxito.Experto económico/financier o .Estudio de Factibilidad económico OUTPUT .Experto económico/financier o .Líder Informático . INPUT . aspectos legales (marco regulatorio).Líder funcional .Valores objetivo de las métricas ACTORES . y sus impactos.Experto informático RESPONSABLE . .Experto en calidad RESPONSABLE .Líder funcional 8 Análisis DAFO Análisis DAFO.Métricas clave para evaluación .Estudio de Factibilidad Técnico/Funcional . se deberá actualizar el Plan Maestro de Sistemas incluyendo el nuevo proyecto. Lic. INPUT . Roberto García INPUT .Estudio de Factibilidad Económica OUTPUT . con las que se podrá evaluar los resultados de haber realizado el proyecto.

Estudio de Factibilidad Técnica/Funcional OUTPUT .Comité Director .Plan Maestro Actualizado ACTORES .Comité Ejecutivo RESPONSABLE .Líder Informático RESPONSABLE .Sistemas de Información Gestión de Proyectos Informáticos Prof.Plan Maestro de Sistemas OUTPUT .Estudio de Factibilidad Técnica/Funcional .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. INPUT .Designación de owner/s de presupuesto ACTORES . Revisión y firma del Acuerdo de Servicio INPUT: OUTPUT: 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 ACTORES: 44 de 181 .Acuerdo de Servicio (Borrador) ACTORES Owner del Proyecto Líder Informático Líder Funcional Experto en Calidad RESPONSABLE . el responsable funcional y el responsable informático llevarán adelante la negociación de este acuerdo. INPUT . Identificar y designar el o los owners de presupuesto.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. Roberto García INPUT . En proyectos de gran envergadura. Obtención asignación de partida presupuestaria.Estudio de Factibilidad Económica OUTPUT .Asignación Presupuestaria .Líder Informático 12 Análisis de Presupuesto Analizar y definir el presupuesto a asignar para las etapas del proyecto. Lic.

Roberto García RESPONSABLE: . Lic. 45 de 181 .Sistemas de Información Gestión de Proyectos Informáticos Prof. Notas: 2 El Comité Director delegará su responsabilidad de acuerdo a la importancia del proyecto.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.

Sistemas de Información Gestión de Proyectos Informáticos Prof. Roberto García FASE DESCRIPCIÓN DE NECESIDADES 46 de 181 . Lic.

Especificar Requerimiento . Para facilitar el análisis del sistema se identifican los subsistemas de análisis.Descripción de la Necesidad Líder Funcional 1. y se elaboran los modelos de Casos de Uso y de Clases. En este proceso se inicia también la especificación del Plan de Pruebas. mediante una verificación y validación. como formatos de pantallas.. diálogos. lo que puede forzar la modificación de algunos de los modelos obtenidos. 47 de 181 .Descripición de Objetivos y Alcance .Sistemas de Información Gestión de Proyectos Informáticos Prof. 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. 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. etc. seguridad. formatos de informes y formularios de entrada. es decir. Se especificarán todas las interfaces entre el sistema y el usuario. las facilidades que ha de proporcionar el sistema. Una vez realizado dicho análisis de consistencia se elabora el producto Especificación de Requisitos Software. frecuencia de tratamiento.. que se completará en el proceso Diseño del Sistema de Información. y de Datos y Procesos en desarrollos estructurados. se genera un catálogo de requisitos generales y se describe el sistema mediante unos modelos iniciales de alto nivel. Además. se realiza un análisis de consistencia. Se recogen de forma detallada los requisitos funcionales que el sistema de información debe cubrir. y las restricciones a que estará sometido. lo que permite hacer la traza a lo largo de los procesos de desarrollo.Análisis del Sistema de Información El propósito de este proceso es conseguir la especificación detallada del sistema de información. se identifican los requisitos no funcionales del sistema. En primer lugar se describe inicialmente el sistema de información.Identificar Necesidades . Roberto García 0. catalogándolos. Lic.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 TAREAS ENTREGABLES COORDINADOR DESCRIPCIÓN NECESIDADES . a partir de los productos generados en el proceso Estudio de Factibilidad del Sistema. en cuanto a rendimiento.Relevamiento Global . 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. en desarrollos orientados a objetos. Se delimita su alcance. Finalizados los modelos.

Lic.Sistemas de Información Gestión de Proyectos Informáticos Prof. / Diagramas híbridos Análisis de la realización de los casos de uso. • • • • • Descripción de subsistemas de análisis.1 Identificar Necesidades . Modelo de clases de análisis. y una motivación clara y definida se lleva adelante un relevamiento global. Además. Antes de 48 de 181 . en Análisis Estructurado. Descripción de interfaces entre subsistemas. en Análisis Orientado a Objetos. En este proceso es muy importante la participación de los usuarios. • • • Plan de migración y carga inicial de datos. Matriz de procesos/localización geográfica. introducción de un nuevo servicio). Ante una necesidad detectada (mejora de un proceso. dependen del tipo de desarrollo de que se trate y se detallan a continuación especificando los que son distintos. Roberto García Los productos resultantes del Análisis del Sistema de Información. Comportamiento de clases de análisis. que permiten al usuario familiarizarse con el nuevo sistema y colaborar en la construcción y perfeccionamiento del mismo. como diseño de diálogos y prototipos.Owner del Proyecto .ETAPA: DESCRIPCIÓN DE NECESIDADES INPUT . Glosario de términos. técnico.Líder funcional .Usuario Final RESPONSABLE . 2. • • • Descripción de interfaz con otros sistemas. Contexto del sistema. operativo y legal que puedan afectar al sistema. Modelo lógico de datos normalizado. Además. y se estudian las posibles restricciones de carácter económico. nuevo proceso. Catálogo de requisitos..Relevamiento Global . Modelo de procesos.Descripción de Objetivos y Alcance – Especificar Requerimiento. según los dos tipos de desarrollo mencionados: • • • • • Descripción general del entorno tecnológico. Se realiza una descripción general de la necesidad planteada por el usuario. Catálogo de normas.Líder funcional 2. a través de técnicas interactivas. Definir el objetivo y alcance del proyecto y realizar la especificación del requerimiento funcional.Necesidad OUTPUT . Especificación de interfaz de usuario.Descripción de la Necesidad (F1) ACTORES .

se debe de tomar como referencia el catálogo de requisitos y la arquitectura de información resultante del mismo.. Si el sistema pertenece al ámbito de un Plan de Sistemas de Información. en el caso de considerarlo necesario. 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. hay que decidir si se realiza o no el estudio de la situación actual y. se estudia el plan de proyectos. implicados en el ámbito de este estudio. Teniendo en cuenta el objetivo del estudio de la situación actual. que se haya decidido conservar. se realiza una valoración de la información existente acerca de los sistemas de información afectados. Lic. En particular. Si el sistema objeto de estudio se encuentra en el ámbito de un Plan de Sistemas de Información vigente. 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. Se identifican los usuarios participantes de las distintas unidades organizativas afectadas para la realización del Estudio de Viabilidad del Sistema. 4.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. así como su estructura y responsables de las mismas. Además. teniendo en cuenta las restricciones identificadas anteriormente. 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. Esta información se recoge en el catálogo de requisitos. 49 de 181 . determinando previamente sus perfiles y responsabilidades. para determinar las posibles dependencias con otros proyectos. en cuanto a la identificación de los sistemas de información actuales. En función de dicha valoración. se constituye un equipo de trabajo específico para su realización y se identifican los usuarios participantes en el mismo.. que puedan interferir en la planificación y futura puesta a punto del sistema objeto del estudio. En función del alcance del sistema y los objetivos del Estudio de Viabilidad del Sistema. se identifican las unidades organizativas afectadas por el sistema.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. Una vez establecido el alcance. se determinan las actividades y tareas a realizar. como información adicional para la descripción general del sistema y determinación de los requisitos iniciales. con qué objetivo. 3. solicitando su aceptación y esperado su confirmación. Roberto García iniciar el estudio de los requisitos del sistema se establecen los objetivos generales del Estudio de Viabilidad. se especifica el nivel de detalle con que se debe llevar a cabo el estudio. Debe comunicarse el plan de trabajo a los usuarios identificados como implicados en el Estudio de Viabilidad. Si es necesario.Sistemas de Información Gestión de Proyectos Informáticos Prof.

Una vez finalizadas. Se sugiere que el analista empiece preguntando cuestiones de contexto libre. que hay que planificar y realizar. Como resultado de esta actividad se genera un diagnóstico. funcional y comportamiento .2.1 ANALISIS DE REQUISITOS Es una tarea que permite al ingeniero de sistemas: .Establecer las restricciones que debe cumplir el soft .. negociación y especificación..2 TECNICAS DE COMUNICACIÓN 6. no es un enfoque que haya tenido mucho éxito. El análisis de requisitos se puede dividir en 5 áreas: 1) Reconocimiento del problema 2) Evaluación y síntesis .Construir los modelos de dominios de datos. mediante una serie de sesiones de trabajo con los usuarios participantes.Proporciona al diseñador y al cliente los medios para valorar la calidad una vez que se ha construido el software. se puede llevar a cabo un enfoque alternativo del análisis de requisitos.Sistemas de Información Gestión de Proyectos Informáticos Prof.Especificar la función y rendimiento del soft. . estimando la eficiencia de los sistemas de información existentes e identificando los posibles problemas y las mejoras. es decir un conjunto de preguntas que llevarán a un entendimiento básico del problema. 6. 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.Indicar la interfaz del soft con otros elementos del sistema . se analiza la información obtenida definiendo los requisitos y sus prioridades. 5.2. 50 de 181 .2 técnicas para facilitar las especificaciones de una aplicación. 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. Lic. normalmente es conveniente dividir el sistema actual en subsistemas. Roberto García Si se decide documentar la situación actual. valorando qué información puede ser relevante para la descripción.1 Inicio del proceso Para empezar la comunicación entre cliente y desarrollador se lleva a cabo una reunión o entrevista preliminar. 6. Pero el formato de preguntarespuesta de reunión tipo.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. Si es posible se describirá cada uno de los subsistemas.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.DEFINICIÓN DE REQUISITOS DEL SISTEMA Esta actividad incluye la determinación de los requisitos generales. denominado prototipato o creación de prototipos. 6. Por esta y otras muchas razones.

Sistemas de Información Gestión de Proyectos Informáticos Prof. . Directrices para la ingeniería de requisitos(Davis): .1 El dominio de la información.Requisitos esperados: son implícitos al producto o sistema y pueden ser tan fundamentales que el cliente no los declara explícitamente. . función y comportamiento.Dar prioridad a los requisitos. 2) Deben definirse las funciones que debe realizar el sotf. . El primer principio operativo de análisis requiere el examen del dominio de la información.Entender el problema antes de crear el modelo de análisis. . 6. hojas de trabajo – .La reunión se celebra en un lugar neutral y acuden tanto clientes como los desarrolladores. 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.Registrar el origen y la razón de cada requisito. proponer soluciones.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 . pizarra.Desarrollar prototipos que permitan al usuario entender cómo será la interacción hombre-máquina.Se establecen normas de preparación y de participación.Un coordinador para coordinar la reunión.Objetivo: identificar el problema. . negociar diferentes enfoques y especificar un conjunto preliminar de requisitos de la solució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.Requisitos normales: se declaran objetivos y metas para un producto o sistema durante reuniones con el cliente. es partidario de la creación de un equipo conjunto de clientes y desarrolladores que trabajan juntos para identificar el problema.Requisitos innovadores: estas características van más allá de las expectativas del cliente y suelen ser muy satisfactorias. Su ausencia será motivo de una insatisfacción significativa. El producto entregado contiene ciertas capacidades no esperadas.1. Si estos requisitos están presentes el cliente estará satisfecho. .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. TFEA – DIRECTRICES BÁSICAS: .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: . Roberto García El enfoque de Técnicas para Facilitar las Especificaciones de la Aplicación (TFEA). 5) El modelo del análisis debería ir desde la información esencial hasta el detalle de la implementación. 7.Trabajar para eliminar la ambigüedad.Se usa un mecanismo de definición – gràficos.2. . . 3) Debe representarse el comportamiento del soft (como consecuencia de acontecimientos externos) 4) Deben dividirse los modelos que representan información. proponer elementos de solución. . Lic.Usar múltiples planeamientos de requisitos. carteles. El despliegue de función se utiliza para determinar el valor de cada función requerida para el sistema.

7.Técnicas de cuarta generación: amplia gama de lenguajes de consultas e informes de bases de datos.respuesta).La información contenida dentro de la especificación debería estar escalonada. transforma la información y para hacerlo.Cerrada: Prototipo desechable: sirve únicamente como una basta demostración de los requisitos.3 ESPECIFICACION 7.Componentes de software reutilizables: ensamblar.Especificaciones formales y entornos para prototipos 7. . . más que construir. 6) Establecer el contenido y la estructura de una especificación de manera que acepte cambios. La partición descompone a un problema en sus partes constitutivas.2. generadores de programas. Este modelo empieza con un sencillo modelo a nivel de contexto (DFD Nivel 0). 4) Definir el entorno en que va a opera el sistema. Es la primera evolución del sistema terminado.Los diagramas y otras formas de notación deberían restringirse en número y ser consistentes den su empleo. . . El enfoque de partición también puede aplicarse al dominio de la información y al de comportamiento. Directrices a seguir: .El formato de la representación y el contenido debería estar relacionados con el problema. 7. 2) Desarrollar un modelo de comportamiento 3) Establecer el contexto en que opera el software. .Sistemas de Información Gestión de Proyectos Informáticos Prof.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.1. con componentes ya existentes. 7.2 Representación: Los requisitos del soft pueden especificarse de varias maneras. Después se desecha. 7. Roberto García - - Modelos funcionales: el soft.3 Partición Es dividir los problemas que son demasiados grandes o complejos para entenderlos globalmente.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. Para crear rápidamente prototipos existen: . 5) Crear el modelo intuitivo en vez de un diseño o modelo de implementación. procesamiento y salida.1 Enfoque La creación de prototipos puede ser cerrada o abierta: .1 Principios de la especificación: 1) Separar la funcionalidad de la implementación. Modelos de comportamiento: la mayoría del software responde a los acontecimientos del mundo exterior (estímulo.La numeración de párrafos y diagramas debería indicar el nivel de detalle que se muestra.2 Métodos y herramientas para el desarrollo de prototipos.2 CREACION DE PROTOTIPOS 7. 7.2. que muestra los estados del soft y los acontecimientos que causan que cambie de estado.3. debe realizar al menos tres funciones genéricas: entrad.1. Lic. Esto forma parte de este modelo. .3. 52 de 181 . 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.

Definidos el flujo y la estructura de la información .Términos imprecisos . . .4 REVISION DE LA ESPECIFICACION Es llevada a cabo tanto por el desarrollador como por el cliente. 7. .Verbos de significados imprecisos. etc.Metas y objetivos declarados. .3. La especificación firmada se convierte en un contrato para el desarrollo del software. .criterios de validación . Esquema como estructura para la especificación: .Pronombres de significados ambiguos.Descripción de la información .Funciones principales . Roberto García - Las representaciones deben permitir revisiones.bibliografía .Descripto todas las interfaces importantes.Sistemas de Información Gestión de Proyectos Informáticos Prof. . Inicialmente la revisión se lleva a cabo a nivel macroscópico.Manual del usuario. Directrices para una revisión detallada: .Introducción .Riesgos tecnológicos. 53 de 181 .descripción del comportamiento .4 La especificación de los requisitos del software. .Requisitos alternativos.Diagramas.Listas incompletas. Se estudian las siguientes cuestiones: .Frases que impliquen certidumbre. .Conectores persuasivos. Lic. Etc.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.descripción funcional . 7. .

Lic.Sistemas de Información Gestión de Proyectos Informáticos Prof. Roberto García FASE: DISEÑO GLOBAL 54 de 181 .

Diseño detallado de los subsistemas de soporte. Líder Funcional HITO 1: CONVALIDACIÓN ESPECIFICACIÓN .Sistemas de Información Gestión de Proyectos Informáticos Prof. Procedimientos de seguridad y control de acceso.Revisión de Business Plan ENTREGABLES COORDINADOR ESPECIFICACIÓN GENERAL .Administración de Riesgo . seguridad y control de acceso. que se realizan en paralelo. 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. De este primer bloque de actividades se obtienen los siguientes productos: • • Catálogo de requisitos (se completa). Además. Modelo físico de datos optimizado. éstos últimos cuando proceda. El diseño de la arquitectura del sistema dependerá en gran medida de las características de la instalación. • Diseño de la arquitectura modular. Procedimientos de operación y administración del sistema.Carta de Decisión Actualizada .Arquitectura Técnica Actualizada .Impacto en Arquitectura Técnica . Roberto García FASE: DISEÑO GLOBAL FASE D I S E Ñ O G L O B A L ETAPAS TAREAS . administración del sistema.Plan General de Trabajo . así como la especificación técnica del plan de pruebas.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. • • • • • • • • Catálogo de normas para el diseño y construcción. independiente de un entorno tecnológico concreto. en Diseño Estructurado. Asignación de esquemas físicos de datos. (Diagrama de Procesos) 55 de 181 .Análisis de Requerimientos .Revisión Modalidad de Proyecto .Especificación Funcional . Diseño de la arquitectura del sistema.Especificación Técnica . 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.Equipo de Trabajo .Est Fact Económica Act. Lic. Catálogo de excepciones. la especificación del entorno tecnológico sobre el que se despliegan dichos subsistemas y la definición de los requisitos de operación. la definición de los requisitos de implantación y el diseño de los procedimientos de migración y carga inicial.Plan General de Trabajo . junto con la especificación detallada de los componentes.Plan Maestro Actualizado .Quality Management .Definición de Equipo de Trabajo . Entorno tecnológico del sistema. se generan todas las especificaciones de construcción relativas al propio sistema.Realización de Especificación . la organización en subsistemas de diseño. A partir de dicha información. Este proceso consta de un primer bloque de actividades.Descripción Requerimientos Funcionales .

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.Sistemas de Información Gestión de Proyectos Informáticos Prof. antes de proceder a la especificación de los componentes.Descripción de la Necesidad (F1) . Este documento incluirá la definición de los procesos a implementar. 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. Al igual que en el proceso de Análisis del Sistema de Información. Comportamiento de clases de diseño. El catálogo de excepciones que permite establecer un conjunto de verificaciones relacionadas con el propio diseño o con la arquitectura del sistema. y el diseño de las verificaciones de los niveles de prueba establecidos. estableciendo las interfaces con otros sistemas e identificando a los usuarios representativos. Modelo de clases de diseño. Además. • • • Diseño de la realización de casos de uso. 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. se realiza una verificación y validación. La especificación de los requisitos de implantación. delimitando su alcance. Roberto García • Diseño de interfaz de usuario. INPUT .Procesos de Negocio OUTPUT . 56 de 181 . en Diseño Orientado a Objetos. 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. Los procedimientos de migración y sus componentes asociados. según el caso) y de las estructuras de datos. Las tareas de esta actividad se pueden haber desarrollado ya en parte en el proceso de Estudio de Factibilidad. La definición y revisión del plan de pruebas.Especificación Funcional (F1) - ACTORES Líder funcional Líder informático Usuarios Experto en Procesos de Negocio RESPONSABLE . • Diseño de interfaz de usuario. Un segundo bloque de actividades complementa el diseño del sistema de información.Líder funcional DEFINICIÓN DEL SISTEMA Esta actividad tiene como objetivo efectuar una descripción del sistema. Lic.

identificando tareas. 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. 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.Arquitectura Técnica . volumetría. etc. hitos de entregables.Líder funcional RESPONSABLE .Líder informático . 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. se asume la necesidad de una realimentación y ajuste continuo con respecto a la definición de los subsistemas. completándose un catálogo de requisitos.Plan Maestro Funcional (F1) Actualizado . sus dependencias y sus interfaces.Líder informático 57 de 181 . Análisis de impacto en la arquitectura técnica e interfaces con otros sistemas.Especificación Funcional (F1) OUTPUT . 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.Especificación . Definición del Modelo de Información del Sistema. Elaboración de la especificación técnica del producto. Flujograma. performance del sistema. El objetivo de esta actividad es obtener un catálogo detallado de los requisitos. perfiles. INPUT OUTPUT . Se propone como técnica de obtención de requisitos la especificación de los casos de uso o diagramas híbridos.Plan Maestro Actualizada . Dichas técnicas ofrece un diagrama simple y una guía de especificación en las sesiones de trabajo con el usuario. No es necesaria la finalización de una tarea para el comienzo de la siguiente. INPUT .Plan General de Trabajo ACTORES . Lic.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. a partir del cual se pueda comprobar que los productos generados en las actividades de modelización se ajustan a los requisitos de usuario. análisis y validación de los requisitos a partir de la información facilitada por el usuario. Esta actividad se descompone en un conjunto de tareas que. 3 Plan General de Trabajo Confección del plan general de trabajo (cronograma). clases de usuarios. Por tanto.Especificación Técnica (F2) . considerando también aspectos de seguridad.Arquitectura Técnica . recursos (externos e internos).Especificación técnica (F2) ACTORES RESPONSABLE Líder funcional . entre sí y con otras tareas realizadas en paralelo.Sistemas de Información Gestión de Proyectos Informáticos Prof. si bien tienen un orden. exige continuas realimentaciones y solapamientos.

Líder funcional 5 Administración del riesgo Análisis de riesgos.Especificación funcional (F1) OUTPUT .Plan General de Trabajo .Especificación técnica (F2) . planes de contingencia. cuantificación de fuentes de riesgos. INPUT . Elaborar el Plan de Calidad. Lic. determinando los sectores intervinientes.Especificación técnica (F2) . Roberto García 4 Definición de Equipo de Trabajo Constitución del equipo de trabajo o equipo de implantación (funcionales.Plan Quality Management ACTORES Líder funcional Líder informático Quality Assurance Experto en calidad RESPONSABLE . Identificación del porcentaje de dedicación al proyecto INPUT .Análisis de Riesgo ACTORES Líder funcional Líder informático Experto informático Experto en seguridad informática RESPONSABLE .Líder funcional - El plan de calidad tiene íntima relación con la metodología de desarrollo implementada en el proyecto. prueba y puesta en marcha del sistema.) 6 Quality Management Definición e identificación de indicadores de calidad asociados a cada tarea e hito del proyecto. identificar las personas que cumplirán los roles definidos para el proyecto. en procesos de negocio.Especificación técnica (F2) . informáticos.Plan General de Trabajo OUTPUT .Líder funcional Trabajo (actualizado) RESPONSABLE .Plan General de Trabajo OUTPUT ACTORES . Asignar los responsables a cada tarea dentro del Plan General de Trabajo. síntomas de riesgos. etc.Plan General de . identificación. 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. A partir de la estructura de la organización. lista de oportunidades (a seguir o a ignorar). INPUT .Descripción de la Necesidad (F1) .Indicadores de Calidad . Entre otros se deberá identificar y proponer soluciones (si los riesgos se presentan) los siguientes aspectos. roles y responsabilidades.Líder informático . expertos en tecnología. etc.  Atrasos en el plan de trabajo.  Aparición de problemas en la logística del proyecto (ambientes de capacitación / pruebas.  Aparición de nuevas necesidades cuando el desarrollo del sistema ya se encuentra iniciado.).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.Equipo de Trabajo .  Instalación del parque informático necesario para el desarrollo. responsables de soporte al cambio.

Sistemas de Información Gestión de Proyectos Informáticos Prof. 59 de 181 . 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. Lic.

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
- 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 - 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

ENTREGABLES

COORDINADOR

DISEÑO DETALLADO

- 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 - 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 Informático

DEFINICIÓN ESTRATEGIAS

Líder Funcional

HITO 3: APROBACIÓN DISEÑO DETALLADO

Especificación Técnica de Detalle

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

 Procedimientos de Seguridad y Control de Acceso. y se generan los siguientes productos:  Diseño de la Arquitectura del Sistema. que a su vez comprende la especificación del entorno tecnológico.  Entorno Tecnológico del Sistema. clases o especificaciones de interfaz.  Especificación detallada de componentes. definiendo para cada uno de ellos los componentes que lo integran. una primera división en subsistemas de construcción. Se detallan a su vez. El producto resultante de esta actividad es el conjunto de las especificaciones de construcción del sistema de información. que serán aplicables tanto en este proceso como en la Construcción del Sistema de Información. 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. 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.  Descripción de subsistemas de construcción y dependencias.  Descripción de componentes. Como resultado de esta actividad. Si se considera necesario. a partir del diseño detallado. Prototipo Realización de prototipo 64 de 181 . La división del sistema de información en subsistemas de diseño proporciona. como pueden ser módulos. componentes).  Plan de integración del sistema de información. normas y estándares originados como consecuencia de la adopción de una determinada solución de arquitectura o infraestructura. Estas especificaciones definen la construcción del sistema de información a partir de las unidades básicas de construcción (en adelante. se actualizan los catálogos de requisitos y normas. GENERACIÓN DE ESPECIFICACIONES DE CONSTRUCCIÓN En esta actividad se generan las especificaciones para la construcción del sistema de información. entendiendo como tales unidades independientes y coherentes de construcción y ejecución. de acuerdo a las particularidades de la arquitectura del sistema propuesta. las restricciones técnicas y la planificación de capacidades. especificando los procedimientos necesarios para su cumplimiento. 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. que comprende:  Especificación del entorno de construcción. seguridad y control.  Catálogo de Excepciones. por continuidad.Sistemas de Información Gestión de Proyectos Informáticos Prof. definir el orden o secuencia que se debe seguir en la construcción y en la realización de las pruebas. Las dependencias entre subsistemas de diseño proporcionan información para establecer las dependencias entre los subsistemas de construcción y. un subsistema de diseño se podrá dividir a su vez en sucesivos niveles para mayor claridad de las especificaciones de construcción. Lic. por lo tanto. los requisitos de operación.  Especificación de la estructura física de datos. como producto que engloba el particionamiento físico del sistema de información y la descripción de subsistemas de diseño.  Procedimientos de Operación y Administración del Sistema. que se corresponden con un empaquetamiento físico de los elementos del diseño de detalle.

se determina la naturaleza de los procesos que se llevan a cabo (en lotes o en línea). y establecer las directrices aplicables en los procesos de diseño y construcción. que comprende el diseño de los subsistemas de soporte identificados en la actividad de Definición de la Arquitectura del Sistema. La identificación de los diferentes perfiles permite conocer mejor las necesidades y particularidades de cada uno de ellos. conocimientos y habilidades que poseen. dotando al sistema de información de una mayor independencia de la infraestructura que le da soporte. como en el diseño de detalle. flexible.  Catálogo de controles y elementos de diseño de interfaz de pantalla.  Catálogo de perfiles de usuario. Como resultado de esta actividad se genera la especificación de interfaz de usuario. Al comienzo de este análisis es necesario seleccionar el entorno en el que es operativa la interfaz. si fuera necesario. y características del entorno en el que trabajan. coherente. se define el formato y contenido de cada una de las interfaces de pantalla especificando su comportamiento dinámico. eficiente y sencilla de utilizar.  Formatos individuales de interfaz de pantalla. se consigue simplificar y abstraer el diseño de los subsistemas específicos de la complejidad del entorno tecnológico.  Prototipo de interfaz interactiva. Se identifican los distintos grupos de usuarios de acuerdo con las funciones que realizan. Para cada proceso en línea se especifica qué tipo de información requiere el usuario para completar su ejecución realizando. aunque debe cumplir con unos objetivos claros de reutilización.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.Especificación Técnica de Detalle (Diseño detallado) OUTPUT . y la determinación de los mecanismos genéricos de diseño. e informes.Líder funcional .Sistemas de Información Gestión de Proyectos Informáticos Prof. como producto que engloba los siguientes elementos:  Principios generales de la interfaz. Asimismo.Prototipo ACTORES . para ello. diálogos. una descomposición en diálogos que refleje la secuencia de la interfaz de pantalla tipo carácter o pantalla gráfica. conceptualmente. Estos últimos sirven de guía en la utilización de diferentes estilos de diseño. con el fin de crear una interfaz que satisfaga todos los requisitos establecidos.  Modelo de navegación de interfaz de pantalla. teniendo en cuenta la facilidad de cambio a otras plataformas.Líder informático . El propósito es construir una interfaz de usuario acorde a sus necesidades. DISEÑO DE LA ARQUITECTURA DE SOPORTE En esta actividad se lleva a cabo la especificación de la arquitectura de soporte. es similar al diseño de los subsistemas específicos. Lic. De esta manera. 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. El diseño de los subsistemas de soporte. 65 de 181 . considerando estándares internacionales y de la instalación.  Prototipo de interfaz de impresión. principalmente.  Formatos de impresión.Proveedor RESPONSABLE . tanto en el ámbito global del sistema de información. Roberto García INPUT . Finalmente. teniendo en cuenta los diferentes perfiles a quiénes va dirigido.  Descomposición funcional en diálogos.

Algunos de los escenarios detallados requerirán una nueva interfaz de usuario.  Mecanismos Genéricos de Diseño y Construcción. tiene como propósito especificar el comportamiento del sistema de información para un caso de uso. Para llevar a cabo todos estos puntos. 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. es transformar el modelo de clases lógico. que se realiza sólo en el caso de Diseño Orientado a Objetos. Lic. Para ello. sus atributos. asociación o jerarquía. incluyendo las clases de diseño que correspondan y teniendo en cuenta las restricciones del entorno tecnológico. bien sean de agregación. en función del estudio de los escenarios de los casos de uso. y el diseño preciso de las relaciones establecidas entre ellas. es decir. disponible en el Histórico de Proyectos. durante esta actividad pueden surgir requisitos de implementación. Entre ellas se encuentran clases abstractas. operaciones. se elaboran los escenarios al nivel de subsistemas y. se aconseja la consulta de los datos de otros proyectos existentes. y determinar las operaciones de las clases e interfaces de los distintos subsistemas de diseño. Es necesario analizar los comportamientos de excepción para dichos escenarios. aunque no se resuelven hasta este momento. métodos. Por este motivo. Se identifican las clases de diseño. esto es. como en la aplicación de esqueletos o patrones en el diseño. de esta forma. Se diseñan las clases de interfaz de usuario. que denominamos clases adicionales. que se está realizando en paralelo en la actividad Diseño de Casos de Uso Reales. Esta actividad se realiza en paralelo al diseño detallado.Sistemas de Información Gestión de Proyectos Informáticos Prof. que proviene del análisis. teniendo en cuenta toda la funcionalidad del sistema que recogen los casos de uso. Dichas excepciones se añadirán al catálogo de excepciones para facilitar las pruebas. una vez identificadas las clases participantes dentro de un caso de uso. DISEÑO DE CLASES El propósito de esta actividad. que integran características comunes con el objetivo de especializarlas en clases derivadas. que provienen del 66 de 181 . se tienen en cuenta las decisiones tomadas sobre el entorno tecnológico y el entorno de desarrollo elegido para la implementación. con una visión global de la instalación. se puede contar en esta actividad con la participación de perfiles técnicos. debido a que existe una constante realimentación. detalles relacionados con la implementación del sistema. que se realiza solo en el caso de Diseño Orientado a Objetos. Si esto no fuera suficiente. Dicho modelo recoge la especificación detallada de cada una de las clases. Los productos resultantes de esta actividad son:  Diseño Detallado de los Subsistemas de Soporte. en un modelo de clases de diseño. Algunos de ellos pueden haber sido identificados en el proceso de análisis. Además. Por este motivo es necesario diseñar el formato de cada una de las pantallas o impresos identificados. mediante objetos o subsistemas de diseño que interactúan. Roberto García Con este fin. es necesario completar los escenarios que se recogen del análisis. DISEÑO DE CASOS DE USO REALES Esta actividad. tanto en la especificación de los subsistemas con sus interfaces y dependencias. y aplicando los mecanismos genéricos de diseño que se consideren convenientes por el tipo de especificaciones tecnológicas y de desarrollo. que se recogen en el catálogo de requisitos. se delimitan las interfaces necesarias para cada uno de ellos.

a medida que se van identificando comportamientos comunes en las clases. Se determina la visibilidad de los atributos y operaciones de cada clase. los atributos. Ver estrategia de pruebas. Otro de los objetivos del diseño de las clases es identificar para cada clase. La jerarquía entre las clases se va estableciendo a lo largo de esta actividad.Líder informático 67 de 181 . las operaciones que cubren las responsabilidades que se identificaron en el análisis. Roberto García análisis. aunque haya una tarea propia de diseño de la jerarquía. Como consecuencia del estudio de los escenarios secundarios que se está realizando. 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. por el diseño de las asociaciones y agregaciones. se define la estructura física de los datos correspondiente a ese modelo. y la especificación de los métodos que implementan esas operaciones. en los casos en que sea necesaria una migración de datos de otros sistemas o una carga inicial de información. Como resultado de todo lo anterior se actualiza el modelo de clases del análisis.Especificación Técnica de Detalle (Diseño detallado) OUTPUT . pueden aparecer nuevas clases de interfaz. una vez recogidas las decisiones de diseño.Sistemas de Información Gestión de Proyectos Informáticos Prof.Plan de Pruebas Técnicas ACTORES Líder informático Líder funcional Experto tecnológico Experto informático Experto en seguridad informática . Una vez que se ha elaborado el modelo de clases. o desaparecer incluyendo sus atributos y métodos en otras. Además. con respecto a las otras clases del modelo. 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. Esta actividad es compleja. Lic. por lo que es aconsejable utilizar herramientas de apoyo para la realización de sus tareas. 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. INPUT . También hay que considerar que. en la actividad Diseño Físico de Datos. pueden aparecer nuevas clases. analizando los escenarios del Diseño de Casos de Uso Reales.Proveedor RESPONSABLE . como paso previo a la generación de las especificaciones de construcción. se realizará su especificación a partir del modelo de clases y las estructuras de datos de los sistemas origen. Para cumplir dicho objetivo. si se considera conveniente por temas de optimización.

El plan de pruebas es un producto formal que define los objetivos de la prueba de un sistema. relacionados directamente con la especificación de requisitos. con las debidas garantías de calidad. Lic. Esta documentación se irá completando hasta la Puesta en Producción. y permite verificar que el sistema de información cumple las necesidades establecidas por el usuario. En esta actividad también se avanza en la definición de las pruebas de aceptación del sistema. Construcción del Sistema de Información e Implantación y Aceptación del Sistema.Proveedor RESPONSABLE .Sistemas de Información Gestión de Proyectos Informáticos Prof.Especificación Técnica de Detalle (Diseño detallado) OUTPUT . Se plantean los siguientes niveles de prueba:  Pruebas unitarias. INPUT . al poseer la información sobre los requisitos que debe cumplir el sistema. Diseño del Sistema de Información.  Pruebas de integración.  Pruebas de implantación.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.Líder informático - 68 de 181 . Roberto García En esta actividad se inicia la definición del plan de pruebas.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 . el cual sirve como guía para la realización de las pruebas. definiendo el marco general.  Pruebas del sistema. El plan se inicia en el proceso Análisis del Sistema de Información. Con la información disponible.Plan de Backup ACTORES Líder informático Líder funcional Experto tecnológico Experto informático Experto en seguridad informática . Dicho plan se va completando y detallando a medida que se avanza en los restantes procesos del ciclo de vida del software.  Pruebas de aceptación. recogidos en el catálogo de requisitos. es posible establecer los criterios de aceptación de las pruebas incluidas en dicho nivel.Especificación Técnica de Detalle (Diseño detallado) OUTPUT . establece y coordina una estrategia de trabajo. INPUT . y provee del marco adecuado para elaborar una planificación paso a paso de las actividades de prueba.Documento de Soporte a Mesa de Ayuda . Plan de contingencia y de desastre – Plan de Backup Construcción del plan de contingencia y de desastre y del plan de backup.Plan de Contingencia y de Desastre . y estableciendo los requisitos de prueba de aceptación.

Líder funcional .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. 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. roll-out (en etapas).Impacto Organizacional ACTORES . responde a una cuestión temporal.Impacto Organizacional OUTPUT .Especificación Técnica de Detalle (Diseño detallado) .Responsable de Soporte al cambio RESPONSABLE . INPUT .Procedimiento de Gestión de Configuración ACTORES . INPUT .Plan General de Trabajo .Especificación técnica .Líder funcional Notas: 4 La ubicación de esta tarea en la Etapa de Diseño Detallado.Sistemas de Información Gestión de Proyectos Informáticos Prof.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.Líder Informático .Estudio de Factibilidad Técnico/Funcional OUTPUT .Usuarios . Identificar el modo de implantación: big bang. Definir fases y releases. Roberto García .Arquitectura técnica . 69 de 181 .Equipo de Trabajo OUTPUT .Especificación técnica de detalle (Diseño detallado) .Líder funcional . INPUT .Estrategia de implantación ACTORES . Lic.Experto Informático RESPONSABLE .Líder informático RESPONSABLE . Se tomará como base el ítem “Impacto” del documento “Estudio de Factibilidad Técnico/Funcional” generado en la fase de Estudio Preliminar. 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.Líder funcional Estrategia de implantación Definir la estrategia de implantación del proyecto.

Confiabilización. etc. pruebas.  Restricciones técnicas del entorno. explotación.Plan de Pruebas 6 Funcionales ACTORES .Líder informático RESPONSABLE .Especificación técnica de detalle (Diseño detallado) . se toma como referencia el plan de migración y carga inicial de datos. las necesidades previas de depuración de la información.  Procedimientos de emergencia y de recuperación. 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. etc. Estrategia de Migración.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. software y comunicaciones. o la información que estime oportuno el departamento técnico para efectuar dicha planificación.Estrategia de confiabilización . que recoge las estructuras físicas de datos del sistema o sistemas origen implicadas en la conversión.Líder funcional .  Herramientas de prueba relacionadas con la extracción de juegos de ensayo.). de implantación y de aceptació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. INPUT . de integración. INPUT .  Planificación de capacidades previstas. Roberto García Elaboración del Plan de Pruebas Funcionales Definición de la estrategia y elaboración del Plan de Pruebas Funcionales.  Procedimientos de promoción de elementos entre entornos (desarrollo.Estrategia de Implantación OUTPUT . o una migración de datos de otros sistemas. Notas: 5 De acuerdo a las Normas vigentes. Armado de Condiciones de 5 Prueba. Set de Pruebas .Estrategia de conversión de datos ACTORES Líder funcional Líder informático Proveedor Experto informático RESPONSABLE .Usuarios . Para ello. Se propone considerar los siguientes conceptos en la especificación del entorno:  Entorno tecnológico: hardware.Especificación técnica de detalle (Diseño detallado) OUTPUT . Conversión de Datos y Carga inicial de Datos Definir la estrategia de confiabilización.Sistemas de Información Gestión de Proyectos Informáticos Prof.  Requisitos de operación y seguridad del entorno de pruebas. Lic.Impacto Organizacional . análisis de resultados. 70 de 181 . así como de vuelta atrás. cuyo alcance y estrategia a seguir se habrá establecido previamente. utilidades de gestión del entorno. Estrategia de Prueba. Armado de Set de Datos.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. la prioridad en las cargas y secuencia a seguir.

Usuarios .  Planificación de la migración y carga inicial.Líder funcional . estructuras. deberá haberse cumplido previo a la implantación. ambientes. y a las características de la arquitectura y del entorno tecnológico propuesto en la actividad Definición de la Arquitectura del Sistema. comunicación de la capacitación.Impacto Organizacional .Estrategia de Implantación OUTPUT . la culminación de la misma. procesos de trabajo. detallando las pruebas a realizar.Plan de Acción para el Cambio ACTORES . Es importante considerar que una carga inicial de información no tiene el mismo alcance y complejidad que una migración de datos. Sin embargo.) INPUT . Se completa el plan de pruebas específico establecido en el plan de migración y carga inicial. Roberto García A partir de dicho plan. tanto para la implementación de los procesos como para la realización de las pruebas. se actualiza el plan de migración y carga inicial de datos con la información siguiente:  Especificación del entorno de migración.Estrategia de Implantación OUTPUT . definición de la modalidad de capacitación. se determinan las necesidades adicionales de infraestructura. Sin embargo.  Definición de procedimientos de migración. 71 de 181 .Impacto Organizacional . competencias.Responsable de Capacitación RESPONSABLE .) INPUT . responde a una cuestión temporal. Como resultado de esta actividad. etc.Responsable de Capacitación - Notas: 7 La ubicación de esta tarea en la Etapa de Diseño Detallado. Lic. Asimismo. obtenida en la actividad Diseño Físico de Datos. deberá haberse cumplido previo a la implantación. etc. 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. realización y evaluación de resultados. Plan Acción para el Cambio 7 Estrategia de Desarrollo y organización (cambios de especialidades.  Diseño detallado de módulos. manuales.Sistemas de Información Gestión de Proyectos Informáticos Prof.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. la culminación de la misma. los criterios de aceptación o rechazo de la prueba y los responsables de la organización. 8 La ubicación de esta tarea en la Etapa de Diseño Detallado. se procede a definir y diseñar en detalle los procedimientos y procesos necesarios para realizar la migración. herramientas. responde a una cuestión temporal.Plan de Capacitación ACTORES Líder funcional Usuarios Líder informático Responsable de Capacitación RESPONSABLE . y de acuerdo a la estructura física de los datos del nuevo sistema.  Especificación técnica de las pruebas.

Roberto García Plan de Comunicación 9 Elaboración del Plan de Comunicación INPUT . Sin embargo. Lic.Impacto Organizacional . la culminación de la misma.Plan de Comunicación ACTORES . deberá haberse cumplido previo a la implantación. 72 de 181 .Responsable Soporte al Cambio Notas: 9 La ubicación de esta tarea en la Etapa de Diseño Detallado.Líder funcional .Estrategia de Implantación OUTPUT .Responsable de Soporte al Cambio RESPONSABLE . responde a una cuestión temporal.Usuarios .Sistemas de Información Gestión de Proyectos Informáticos Prof.

revisará y convalidará la Especificación Técnica de Detalle. 73 de 181 . 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. Roberto García HITO 3: APROBACIÓN DISEÑO DETALLADO El líder funcional analizará. Lic.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.

Evaluación del resultado de las pruebas del sistema.Homologación Prueba Piloto . se prepara el entorno de construcción. Lic.Plan de Soporte .Prueba Piloto . Como resultado de dicho proceso se obtiene: • • • • Resultado de las pruebas unitarias.Prueba de Integración .Definición Procedimiento de Producción . Si fuera necesario realizar una migración de datos.Pruebas de Compatibilidad . a partir del conjunto de especificaciones lógicas y físicas del mismo. Evaluación del resultado de las pruebas de integración. los procedimientos de migración y carga inicial de datos.Protocolos de Prueba .Desarrollo de Programas .Programas. Producto software: 75 de 181 .Elaboracion Manuales de Usuario .Plan de Implantación .Proc. es en este proceso donde se lleva a cabo la construcción de los componentes de migración.Acuerdo 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. se recoge la información relativa al producto del diseño Especificaciones de construcción. stress.Elaboracion Manuales de Sistemas .Elaboración Manual de Procesos . Módulos & Parametrización . volumen & seguridad .Prueba Individual .Prueba de Cadena .Manual de Sistemas .Manual de Usuario .Manual de Procesos COORDINADOR PARAMETRIZACIÓN Y DESARROLLO Líder Informático C O N S T R U C C I Ó N PRUEBAS . Gestión de Configuración actualizado Líder Funcional DEFINICIÓN PLAN DE IMPLANTACIÓN Líder Funcional HITO 4: DECISIÓN DE IMPLANTACIÓN .Prueba de Perf.Homologación Prueba Piloto .. Para conseguir dicho objetivo.Sistemas de Información Gestión de Proyectos Informáticos Prof.Adecuaciones de Programas .Protocolo de Implantación .Acuerdo de Servicio Revisado .Plan de Soporte .Preparació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. obtenido en el Proceso de Diseño global y detallado del Sistema de Información.Aprobación de Pruebas Líder Informático PRUEBA PILOTO .Plan de Implantación .Prueba Global .Parametrización . Roberto García FASE: CONSTRUCCIÓN FASE ETAPAS TAREAS . estos últimos cuando proceda.Elaboración Protocolo de Implantación .Revisión del Acuerdo de Servicio y Alcance . Se desarrollan los procedimientos de operación y seguridad y se elaboran los manuales de usuario final y de explotación.Actualización Gestión de Configuración ENTREGABLES .Procedimiento de Producción .Protocolo de Prueba Piloto .

ETAPA: PARAMETRIZACIÓN Y DESARROLLO Desarrollo de Programas . Evaluación del resultado de las pruebas de migración y carga inicial de datos. se desarrollan las actividades relacionadas con las pruebas unitarias y de integración del sistema de información. así como las especificaciones de construcción de la estructura física de datos.Sistemas de Información Gestión de Proyectos Informáticos Prof. entre otros. herramientas de generación de código. Manuales de usuario. CONSTRUCCIÓN DE LOS COMPONENTES Y PROCEDIMIENTOS DE MIGRACIÓN Y CARGA INICIAL DE DATOS 76 de 181 . Las características del entorno de construcción y sus requisitos de operación y seguridad. En paralelo a esta actividad.Proveedor .Especificación Técnica de Detalle (Diseño detallado) OUTPUT ACTORES . se establecen en la actividad Generación de Especificaciones de Construcción. cabe destacar la preparación de los puestos de trabajo.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. bases de datos o ficheros de prueba. a partir de las especificaciones de construcción obtenidas en el proceso Diseño del Sistema de Información. Procedimientos de operación y administración del sistema. Módulos . 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.Adecuación de Programas – Parametrización – Elaboración de Manuales de Sistemas Desarrollo y codificación de la funcionalidad del sistema. Elaboración Manuales de Sistemas Control y Seguimiento del Desarrollo INPUT . y constituyen el punto de partida para la realización de esta actividad. Lic. gestores de bases de datos. Especificación de la formación a usuarios finales. Procedimientos de seguridad y control de acceso. Procedimientos de migración y carga inicial de datos. Esto permite una construcción incremental. Roberto García         Código fuente de los componentes.Programas. así como la construcción de los procedimientos de operación y seguridad establecidos para el mismo.Manual de Sistemas RESPONSABLE . 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. equipos físicos y lógicos. Actualización de Documentación de Sistemas. Código fuente de los componentes de migración y carga inicial de datos. bibliotecas de programas. Entre estos medios.Líder informático & Parametrización .

de acuerdo a los requisitos establecidos en la tarea Especificación de Requisitos de Documentación de Usuario.Especificación funcional (F1) .Líder funcional .Líder funcional .Manual de Procesos ACTORES RESPONSABLE . Previamente a la generación del código. 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. Lic. El manual se basa en los procesos/sub-procesos definidos en la especificación funcional. 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. Elaboración de Manuales de Usuario Elaboración Manuales de Usuario.Experto en procesos .Responsable de Capacitación . se prepara la infraestructura tecnológica necesaria para realizar la codificación y las pruebas de los distintos componentes y procedimientos asociados.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.Especificación Técnica de Detalle (Diseño detallado) OUTPUT . tanto usuario final como de explotación.Sistemas de Información Gestión de Proyectos Informáticos Prof.Líder funcional . 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. Finalmente. 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.Manual de Usuario ACTORES . INPUT . 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á. INPUT .Líder funcional Elaboración de los Manuales de Usuario El objetivo de esta tarea es elaborar la documentación de usuario.Líder informático . y recogidos en el catálogo de requisitos. EJECUCIÓN DE LAS PRUEBAS INDIVIDUALES 77 de 181 .Especificación Técnica de Detalle (Diseño detallado) OUTPUT . de acuerdo a las características del entorno de migración especificado en el plan de migración y carga inicial de datos. se llevan a cabo las verificaciones establecidas en la especificación técnica del plan de pruebas propio de la migración.Proveedor RESPONSABLE .

INPUT . Lic.Aprobación de Prueba ACTORES .Plan de Pruebas Técnicas OUTPUT . una vez codificados. 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). Las pruebas unitarias no requieren de datos operativos dado que el objetivo que se desea alcanzar es comprobar el funcionamiento lógico del componente.Plan de Pruebas Técnicas OUTPUT . con el objeto de comprobar que su estructura es correcta y que se ajustan a la funcionalidad establecida.Plan de Pruebas Técnicas OUTPUT .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. cubren la funcionalidad establecida.Protocolo de Prueba .Sistemas de Información Gestión de Proyectos Informáticos Prof.Líder informático RESPONSABLE . 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.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. (Cabe aclarar que esta prueba podría realizarse en la etapa de desarrollo). 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.Protocolo de Prueba . Asegurar la correcta integración entre módulos y sus interfaces.Líder informático RESPONSABLE .Aprobación de Prueba ACTORES .Aprobación de Prueba ACTORES . Prueba Individual Prueba Unitaria de Módulos y Programa. 78 de 181 . y se ajustan a los requisitos especificados en las verificaciones correspondientes. INPUT . 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. Roberto García En esta actividad se realizan las pruebas unitarias de cada uno de los componentes del sistema de información. 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.Líder informático Prueba de Integración Probar la integridad técnica del sistema en su totalidad.Protocolo de Prueba . tanto internas como externas. 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 .Líder informático RESPONSABLE . En el plan de pruebas se ha definido el entorno necesario para la realización de cada nivel de prueba. 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. así como las verificaciones asociadas a las pruebas unitarias.

Volumen. Prueba de Performance.Líder informático - Prueba de Compatibilidad Pruebas de compatibilidad con los sistemas actuales o próximos a implementarse.Líder funcional . Prueba Global Prueba funcional en ambiente de prueba con los siguientes objetivos: . Roberto García La estrategia a seguir en las pruebas de integración se establece en el plan de pruebas. . El líder informático es responsable de ejecutar la prueba.Protocolo de Prueba . que se llevarán a cabo en el proceso Implantación y Aceptación del Sistema. (Se participará a estas pruebas a los administradores funcionales de los sistemas involucrados) 79 de 181 . .Asegurar que los beneficios acordados con el usuario son producidos por el sistema .Sistemas de Información Gestión de Proyectos Informáticos Prof.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. El líder funcional es responsable de redactar el informe de prueba y aprobar la misma. Sin embargo. INPUT . 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.Plan de Pruebas Funcionales OUTPUT . 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. Lic.Usuarios RESPONSABLE .Asegurar que cada Evento de Negocio funciona a lo largo de las aplicaciones.Probar las Interfaces con otros sistemas.Líder informático .Plan de Pruebas Técnicas OUTPUT .Protocolo de Prueba . Volumen. dónde se habrá tenido en cuenta el plan de integración del sistema de información.Llevar adelante la Prueba de Aceptación del usuario . En la realización de estas pruebas es importante comprobar la cobertura de los requisitos.Asegurar que las funcionalidades introducidas funcionan según los requerimientos especificados por los usuarios.Aprobación de Prueba ACTORES . es necesario que los componentes objeto de las pruebas de integración se hayan verificado de manera unitaria.Probar la integridad funcional y técnica entre los sistemas impactados por la implantación del nuevo sistema (incluye interfaces entre sistemas). Stress y Seguridad INPUT .Aprobación de Prueba ACTORES Líder informático Líder funcional Usuarios Experto informático Experto en seguridad informática RESPONSABLE . . siempre y cuando se haya especificado en la tarea Definición de Componentes y Subsistemas de Construcción. 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. Stress y Seguridad Pruebas de Performance.

pero circunscriptas al contexto de la prueba piloto.Usuario RESPONSABLE .Ejecución de Confiabilización de Datos . 80 de 181 .Plan de Pruebas Técnicas OUTPUT . Lic. Dado que se trata de una prueba en producción y con datos de producción.Aprobación de Prueba - ACTORES Líder informático Líder funcional Experto informático Administrador funcional RESPONSABLE .Plan de pruebas técnicas .Líder funcional Homologación Prueba Piloto Aprobación Prueba Piloto.Protocolo de Prueba Piloto ACTORES . actores y responsables de estas tareas son los descriptos en la Etapa “Preparación de la implantación” de la fase “Implantación”) . Preparación de la implantación (referidas a los datos y actores involucrados en la prueba piloto) (Los inputs.Aprobación de Conversión de Datos . Roberto García INPUT .Protocolo de Prueba .Aprobación de Prueba de Performance.Definición de Usuarios y Perfiles . Preparar el sitio: .Líder informático ETAPA: PRUEBAS PILOTO Preparación Preparar las pruebas piloto.Comunicación a los sectores técnicos y funcionales impactados 3. se llevarán adelante tareas previas a la puesta en Producción de un sistema.Incorporar el sistema al circuito de solicitud de claves de acceso 2.Escribir los procedimientos. Armar el plan de Implantación de Prueba Piloto . outputs.Líder funcional . . Stress y Seguridad .Aprobación de Prueba Global . Volumen. .Capacitación a los sectores técnicos y funcionales impactados . 1.Preparación de documentación.Aprobación de Prueba de Compatibilidad OUTPUT .Plan de Pruebas funcionales .Líder informático .Conversión de Datos .Carga Inicial de los datos y Parametrización .Instructivos de instalación Prueba Piloto Llevar adelante la prueba piloto propiamente dicha.Instalación de los productos/software. .Sistemas de Información Gestión de Proyectos Informáticos Prof. INPUT .Administrador funcional .

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.Homologación de Piloto Prueba Piloto ACTORES .Líder informático . En proyectos de gran envergadura. conformando un anexo. En función de las necesidades.Protocolo/Aprobació n Prueba Global .Administrador funcional . INPUT .Acuerdo de Servicio Revisado OUTPUT . recursos.Líder funcional .Sistemas de Información Gestión de Proyectos Informáticos Prof.Proveedor RESPONSABLE . Establecer sitios.Plan de Soporte ACTORES .Acuerdo de Servicio Revisado ACTORES . cronogramas de implantación.Líder funcional . definir el esquema de Soporte a la Implantación.Líder funcional / Líder informático Elaboración Protocolo de Implantación Elaboración del protocolo de la Implantación.Líder informático .Líder funcional Plan de Soporte De acuerdo al Plan de Implantación.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. Lic.Protocolo/Homologa ción Prueba Piloto OUTPUT .Plan de Implantación - ACTORES Líder funcional Líder informático Proveedor Administrador funcional RESPONSABLE .Líder funcional . Roberto García INPUT OUTPUT .Protocolo de Prueba . se evaluará y renegociará él alcance del sistema a implantar.Estrategia de Implantación .Acuerdo de Servicio . se llevará adelante una aceptación de la misma basándose en este protocolo) 81 de 181 .Plan de Implantación . el líder funcional y el líder informático convocarán a los actores correspondientes. (Luego de la Implantación. INPUT .Usuario RESPONSABLE . Estas redefiniciones actualizarán el Acuerdo de Servicio del Proyecto. la negociación del Acuerdo de Servicio será llevada a cabo por el Responsable Funcional y el Responsable Informático. determinándose los pendientes y sus plazos de entrega. INPUT OUTPUT .

Plan de Implantación .Sistemas de Información Gestión de Proyectos Informáticos Prof. Roberto García Este protocolo deberá ser aprobado por el líder funcional del proyecto.Plan de Backup .Protocolo de Implantación ACTORES Líder funcional Líder informático Proveedor Administrador funcional RESPONSABLE .Líder Informático 82 de 181 .Procedimiento de Gestión de Configuración actualizado ACTORES . cómo y cuándo se desarrollan las tareas de producción. INPUT .Procedimiento de Producción ACTORES .Plan de Contingencia y Desastre .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.Líder funcional .Procedimiento de Gestión de Configuración OUTPUT . INPUT OUTPUT .Manual de Sistemas OUTPUT .Líder informático . Comprende qué.Líder funcional - Definición de Procedimiento de Producción Definir el procedimiento de producción/explotación.Experto Informático RESPONSABLE .Manual de Usuario . Lic.Líder Informático . INPUT .Experto informático RESPONSABLE .Experto en seguridad informática .

83 de 181 .Sistemas de Información Gestión de Proyectos Informáticos Prof.Producto homologado .Líder funcional . Roberto García 6.Acuerdo de Implantación ACTORES: .Líder informático .1.Informes de Pruebas .Usuario RESPONSABLE: .1. Lic.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.Acuerdo de Servicio OUTPUT: .Plan de Implantación . INPUT: .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.

Lic. Roberto García FASE DE IMPLANTACIÓN 84 de 181 .Sistemas de Información Gestión de Proyectos Informáticos Prof.

Ejecución de Confiabilización de Datos . una vez revisada la estrategia de implantación y se detalla el equipo que lo realizará. Roberto García FASE: IMPLANTACIÓN FASE I M P L A N T A C I O N ETAPAS TAREAS . El Sistema se someterá a las Pruebas de Implantación con la participación del usuario de operación cuya responsabilidad. entre otros aspectos. planificación y especificación de la formación de usuarios finales).Contrato de Servicio de Producción . Soporte a Operaciones/ Soporte actualizado Administrador Funcional HITO 5: SISTEMA EN PRODUCCIÓN . que puede comprender varios sistemas de información desarrollados de manera independiente.Doc.Sistemas de Información Gestión de Proyectos Informáticos Prof.Documentación Puesta en Producción (Anexo el Proc.Aprobación de Conversión de Datos . recursos necesarios. Equipo de implantación que realizará la implantación.Comunicación .Conversión de Datos . El acuerdo de nivel de servicio hace referencia a servicios de gestión de operaciones. 85 de 181 .Informe Sistema en Producción Este proceso tiene como objetivo principal. materiales. 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.Contrato de Servicio Producción .Aprobación Conversión Datos Líder Funcional PUESTA EN PRODUCCIÓN . la entrega y aceptación del sistema en su totalidad. Plan de formación del equipo de implantación (esquema.Realización Implantación . es comprobar el comportamiento del sistema bajo las condiciones más extremas. Se establece el plan de implantación.Recepción Provisoria Líder Informático FORMALIZACIÓN PUESTA EN PRODUCCIÓN .Capacitación . de soporte a usuarios y al nivel con el que se prestarán dichos servicios. así como la documentación asociada. Evaluación de las pruebas de implantación del sistema por parte del usuario de operación. de Producción) . También se someterá a las Pruebas de Aceptación cuya ejecución es responsabilidad del usuario final. según se haya establecido en el proceso de Estudio de Factibilidad del Sistema. Como resultado de este proceso se obtienen los siguientes productos: • • • • • • Plan de implantación del sistema en su totalidad. Soporte Mesa de Ayuda actualizado .Carga Inicial y Parametrización . Plan de mantenimiento previo al paso a producción.Aceptación Implantación ENTREGABLES COORDINADOR PREPARACIÓN IMPLANTACIÓN . 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. y un segundo objetivo que es llevar a cabo las actividades oportunas para el paso a producción del sistema. Lic.Doc. Evaluación de las pruebas de aceptación del sistema por parte del usuario final.

Validar que los datos sean correctos de acuerdo al formato establecido. Roberto García • • Acuerdo de nivel de servicio del sistema.Estrategia de Confiabilización OUTPUT . Esta conversión/migración se desarrolla con un proceso AUTOMÁTICO.Líder informático - Aprobación de la Conversión de Datos El Líder Funcional aprueba la conversión de datos realizada. INPUT . El líder funcional será responsable de verificar y aprobar la carga inicial. INPUT OUTPUT ACTORES . El Líder Funcional será responsable de convocar al Administrador Funcional del sistema origen.Datos Convertidos Conversión de Datos ACTORES Líder funcional Líder informático Proveedor Usuario Administrador Funcional RESPONSABLE . 86 de 181 . 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. INPUT OUTPUT . Esto no excluye la posibilidad de que informáticos ejecuten un proceso automático para la misma.Líder informático . ETAPA: PREPARACIÓN IMPLANTACIÓN Ejecución de Confiabilización de Datos Realizar la confiabilización de los Datos.Estrategia de .Aprobación de .Estrategia de . El Líder Funcional será responsable de convocar al Administrador Funcional del sistema origen. 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. Sistema en producción.Administrador Funcional RESPONSABLE .Sistemas de Información Gestión de Proyectos Informáticos Prof.Proveedor .Líder funcional - Conversión de Datos Realizar la Conversión de los Datos del sistema origen al sistema actual.Líder funcional Conversión de Datos Conversión de Datos .Usuario .Datos Confiabilizados ACTORES Líder funcional Líder informático Proveedor Usuario Administrador Funcional RESPONSABLE . Lic.Líder funcional Carga Inicial y Parametrización Realización de la Parametrización y Carga Inicial de los datos.Datos Convertidos .

Líder funcional 87 de 181 .Personal Comunicación comunicado . Garantizar que las tareas lanzadas en el plan de capacitación se hayan completado (logística. estén en conocimiento del alcance en cuanto a contenidos y fechas de las nuevas funcionalidades del proyecto a implantar INPUT OUTPUT . manuales. 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.Datos iniciales OUTPUT . herramientas. con el objetivo de conseguir la explotación eficaz del nuevo sistema.Sistemas de Información Gestión de Proyectos Informáticos Prof.Estrategia de Carga Inicial de datos . Lic. que consta de los siguientes elementos:  Esquema de formación  Materiales y entornos de formación.Administrador funcional . comunicación de la capacitación. INPUT OUTPUT . Comunicación Asegurar que el usuario final. capacitadores y todos los actores involucrados en la operación del sistema. como así también todos los sectores involucrados. En el proceso Implantación y Aceptación del Sistema.Usuario final .) 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.Plan de Implantación ACTORES .Manual de Procesos ACTORES Usuario final Experto informático Proveedor Responsable de capacitación RESPONSABLE . 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. etc. definición de la modalidad de capacitación.Datos Cargados - ACTORES Líder funcional Líder informático Proveedor Usuario Administrador Funcional 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.Plan de . soporte funcional. 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. Roberto García INPUT . así como los requisitos relacionados con la formación del usuario final.Líder funcional Capacitación Capacitación de los usuarios finales.Plan de .Responsable Soporte al Cambio RESPONSABLE . ambientes.Líder funcional .Personal capacitado Capacitación .Manual de Usuario .

Administrador funcional . INPUT OUTPUT .Experto en Calidad RESPONSABLE . se realizará una puesta en producción en cada una de las etapas. Soporte Aplicativo. etc. INPUT OUTPUT . Roberto García ETAPA: PUESTA EN PRODUCCIÓN La puesta en producción se llevará adelante de acuerdo al Plan de Implantación.Recepción Provisoria ACTORES Líder funcional Líder informático Usuario final Administrador funcional RESPONSABLE . En caso de tratarse de un roll-out. Realización Implantación Realización de la implantación con la colaboración del líder funcional y soportes (in situ.Protocolo de implantado Implantación ACTORES Experto informático Proveedor Soporte funcional Soporte técnico Soporte aplicativo Administrador funcional .Usuario .Proveedores del 10 Servicio .Líder informático RESPONSABLE .Sistema/etapa implantado OUTPUT .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). Lic. Soporte Funcional. Soporte Técnico.Plan de Implantación .Contrato de Servicio técnica/funcional (F1 de Producción / F2) ACTORES .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. soporte de las mesas de ayuda funcional.Administrador funcional Notas: 10 Normalmente los Proveedores del Servicio corresponden a: Soporte a Usuarios. a distancia.Especificación .Sistemas de Información Gestión de Proyectos Informáticos Prof.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 . 88 de 181 . Soporte Seguridad. ya sea en big bang o rollout (por etapas).Usuario .) Esta tarea implica la implantación del sistema en forma total (en caso de big bang) o de una de sus etapas (roll-out).

Líder Informático 12 Notas: 11 En este momento deberá estar finalizado el documento de procedimientos de producción.Líder informático . el cual se anexará a esta documentación 12 Los roles de soporte enunciados podrán corresponder a más de un sector.Líder Funcional .Experto Informático RESPONSABLE .Administrador Funcional .Soporte Funcional . INPUT OUTPUT .Soporte Seguridad Esta documentación acompañará al Procedimiento de Producción definido en la fase anterior. de acuerdo a la organización.Líder Funcional .Soporte Técnico .Documento de Soporte a Operaciones/Soport e Técnico actualizado ACTORES .Sistemas de Información Gestión de Proyectos Informáticos Prof. Roberto García Documentación Puesta en Producción 11 Completar la documentación para los soportes : .Documento de Soporte a Mesa de Ayuda actualizado . Lic. 89 de 181 .Soporte a Usuarios .

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. 90 de 181 . Lic. INPUT: OUTPUT: ACTORES: RESPONSABLE: 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 Check-list      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.Sistemas de Información Gestión de Proyectos Informáticos Prof.

autenticación y control de accesos Generar los informes correspondientes y actualizar el tablero de mando.Mantenimiento de Datos.Nuevos Requerimientos . Notas: 13 Los indicadores del tablero de mando se definirán en el contrato de servicio de producción 91 de 181 .Plan de Backup OUTPUT .Nuevo Proyecto Administrador Funcional Es importante señalar.Tablero de Mando Administrador Funcional SOPORTE .Soporte Funcional .Soporte Aplicativo ENTREGABLES COORDINADOR Soporte Técnico .Administrador funcional RESPONSABLE .Backup . ya que las tareas correspondientes a esta fase pueden realizarse en forma paralela independientemente de la etapa a la que pertenecen. Asegurar la confidencialidad: identificación.Atención a Usuarios . Roberto García FASE: PRODUCCIÓN FASE ETAPAS ADMINISTRACIÓN TÉCNICA TAREAS . Lic.Soporte Técnico .Procesos Performance .Soporte Técnico Procesos de Seguridad Realizar los procesos de seguridad.Soporte Seguridad Procesos de Performance Realizar los procesos de performance.Control de Procesos Rutinarios . que en la fase de Producción las etapas no presentan una secuencialidad.Tablero de Mando P R O D U C C I Ó N ADMINISTRACIÓN FUNCIONAL .Capacitación Nuevos Usuarios .Sistemas de Información Gestión de Proyectos Informáticos Prof. Tablas y Parámetros .Procesos Backup .Procesos Seguridad . Notificar los resultados del backup a los actores correspondientes INPUT .Administración de Usuarios y Perfiles . INPUT . ETAPA: ADMINISTRACIÓN TÉCNICA Procesos de Backup Realizar los procesos de backup de acuerdo al Plan de Backup.Notificación del backup ACTORES .Otros procesos .Procedimientos de Producción OUTPUT 13 .Soporte Seguridad RESPONSABLE . Asegurar la integridad y coherencia de los datos Verificar y controlar los logs de auditoría.Tablero de Mando ACTORES .Soporte Técnico .Tablero de Mando Administrador Funcional EVOLUCIÓN .

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. corregir datos Se solicitará a soporte aplicativo las herramientas necesarias para restablecer los datos. capacidad y tráfico de red.Soporte Técnico .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 . Sistema Operativo. INPUT . INPUT .Administrador Funcional RESPONSABLE . Soporte en tareas para recuperación de información para Legales. Tuning de BD.Corrección/actualiza corrección/actualizac ción realizada ACTORES . Generar los informes correspondientes. número de procesos levantados.) Controlar el correcto funcionamiento del sistema.Procedimientos de Producción OUTPUT 15 . etc. tiempos de CPU. INPUT OUTPUT .Soporte Técnico RESPONSABLE . control de interfaces. Generar los informes correspondientes y actualizar el tablero de mando.Administrador Funcional . Tablas y Parámetros Mantener los datos.Solicitud de ABM de usuarios y perfiles OUTPUT . Upgrades de Hardware.Administrador Funcional Mantenimiento de Datos. SO y Red.Tarea realizada ACTORES .Soporte Aplicativo RESPONSABLE .Soporte en seguridad RESPONSABLE . número de usuarios conectados.Necesidad de .Administrador Funcional RESPONSABLE . mantener los indicadores y actualizar el tablero de mando.Soporte Técnico Otros Procesos Procesos extraordinarios.Tablero de Mando ACTORES . INPUT . Auditoría.Soporte Técnico .Soporte Técnico Control de Procesos Rutinarios Realizar el control de procesos rutinarios (espacio en disco. 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. conociendo los calendarios de procesamiento. INPUT . otros sistemas.Solicitud extraordinaria OUTPUT .Procedimientos de Producción OUTPUT 14 .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. etc.Solicitud realizada ACTORES . Roberto García Relevar y asegurar performance del procesamiento. etc.Tablero de Mando ACTORES .

INPUT OUTPUT 17 Incidente Funcional .Soporte aplicativo Capacitación Nuevos Usuarios Realizar la capacitación de los usuarios y todos los actores involucrados ante nuevos releases. recibir y registrar los llamados por consultas. identificando la criticidad y el origen del problema. Diagnosticar. Roberto García ión de datos . INPUT . Realizar seguimiento de los incidentes. etc.Responsable de capacitación .Reclamo atendido/solucionad o/derivado ACTORES . 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 .Incidente Manual de Sistemas atendido/resuelto/de Manual de Procesos rivado ACTORES Usuario Soporte Funcional Soporte a Usuarios Administrador funcional RESPONSABLE .Soporte Técnico .Usuario .Administrador Funcional ETAPA: SOPORTE Atención a Usuarios Atender a los usuarios. INPUT .Soporte a Usuarios RESPONSABLE .Administrador funcional . Planificar y asegurar la logística.Soporte Funcional - - Soporte Técnico Recibir incidentes técnicos. nuevas funcionalidades. soporte aplicativo u otro actor). nuevos perfiles.Sistemas de Información Gestión de Proyectos Informáticos Prof.Tablero de Mando . Diagnosticar e identificar criticidad y el origen del incidente. resolver y/o derivar los reclamos según corresponda (soporte funcional.Soporte a Usuarios . Mantener los indicadores de gestión de atención a usuarios actualizando el tablero de mando. nuevos usuarios. Comunicar la solución al usuario.Soporte a Usuarios Soporte Funcional Recibir consultas y asesorar acerca de la información que brinda el sistema y sus funcionalidades en general.Tablero de Mando Manual de Usuario .Necesidad de capacitación OUTPUT . y resolver o derivar la consulta.Usuarios . Lic.Soporte Funcional .Usuarios Capacitados ACTORES .Soporte Aplicativo RESPONSABLE .Consulta/Problema/ Reclamo/Incidente OUTPUT 16 . reclamos y/o problemas.

Incidente Técnico OUTPUT 18 .Nuevo Requerimiento ACTORES . INPUT .Soporte técnico .Manual de Usuario actualizado . identificando criticidad y el origen del problema.Sistemas de Información Gestión de Proyectos Informáticos Prof.Soporte en seguridad RESPONSABLE .Soporte a Usuarios .Incidente aplicativo resuelto/derivado . . Ejecutar las acciones correctivas o derivar a los actores correspondientes.Tablero de Mando . Corregir la aplicación eliminando la causa del incidente (corrección del bug).Administrador Funcional .Administrador Funcional. priorizando la criticidad del problema. Lic.Incidente técnico atendido/resuelto/de rivado ACTORES .Manuales de Sistemas. Actualizar documentación de Sistemas.Soporte funcional . INPUT .Soporte Aplicativo .Soporte Técnico Soporte Aplicativo Recibir incidentes aplicativos y realizar el diagnóstico. 19 Realizar los tests y preparar el pasaje a producción.Experto en Procesos ETAPA: EVOLUCIÓN Nuevos Requerimientos Centralizar los requerimientos sobre nuevas funcionalidades y/o modificaciones al sistema. patchs. de Usuario y de Procesos OUTPUT .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 .Otros generadores de necesidad RESPONSABLE . Resolver y/o derivar el incidente a los actores correspondientes.Manual de Sistemas actualizado .Soporte Aplicativo . o release seguirá el ciclo de un proyecto. Realizar la gestión de configuración. de acuerdo a la Guía de Gestión de Proyectos. identificando la criticidad y el origen del problema. etc.Incidente Aplicativo . de Usuario y de Procesos registrando las modificaciones de nuevas versiones. INPUT .Manual de Procesos actualizado ACTORES RESPONSABLE . Generar la necesidad de evolución y el requerimiento para un nuevo sistema/release Esta evolución o nuevo sistema.Necesidad OUTPUT . Roberto García Diagnosticar.Soporte Técnico .

Líder funcional 95 de 181 . tiempos e indicadores claves definidos en “Identificación de Métricas” de la fase “Estudio Preliminar”.Informe de Cierre ACTORES .Sistemas de Información Gestión de Proyectos Informáticos Prof.Indicadores Clave . Roberto García FASE: BALANCE DEL PROYECTO FASE P R O Y E C T de O B A L A N C E ETAPAS TAREAS ENTREGABLES COORDINADOR BALANCE DEL PROYECTO .Líder informático .Tablero de Mando OUTPUT . Lic. INPUT .Líder funcional .Presupuesto .Administrador funcional RESPONSABLE .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. Detectar oportunidades de mejora en la gestión del Proyecto.Balance del Proyecto .

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

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. 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 . Roberto García CARPETA DE PROYECTOS En este capítulo se describen los entregables obligatorios originados en cada una de las fases descritas anteriormente.

........ Roberto García DOCUMENTO F1 ................... Principales cambios a los procesos Definición de procesos/subprocesos a implementar/cambiar 5........... Proyecto: .......... 98 de 181 ........ Estado Preliminar En análisis de impacto En negociación c/usuario Fecha de creación: Fecha de actualización: Fecha de aprobación: Definitivo <dd/mm/aa> <dd/mm/aa> <dd/mm/aa> Preparado por: Actualizado por: Aprobado por: <Nombre y Apellido> <Nombre y Apellido> <Nombre y Apellido> DATOS GENERALES Requirente Responsable DRI Gestión en <Gerencia> <Gerencia> <Nombre y Apellido> <Nombre y Apellido> <Interno> <Interno> Fecha requerida de implantación: <dd/mm/aa> Fecha estimada de respuesta del F1: <dd/mm/aa> 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........... Requerimientos a los sistemas impactados 3. Descripción de aspectos de seguridad de la funcionalidad Definición de usuarios y perfiles de la funcionalidad 2................Requerimientos funcionales e impactos NOMBRE REFERENCIAL: . Beneficios esperados / motivación / justificación ESPECIFICACIÓN FUNCIONAL 1..Sistemas de Información Gestión de Proyectos Informáticos Prof....... 5 Identificación de procesos y subprocesos impactados 2.... Posibles indicadores 20 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.................... Temas a desarrollar en una etapa posterior 8............. Funcionalidades Alcance de las funcionalidades Descripción detallada de las funcionalidades.................... 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...... Descripción de aspectos de volumetría y performance 4..... La revisión se realiza para asegurar que se ha identificado adecuadamente el marco del proyecto....... Lic.. Subproyecto: .... Puntos abiertos 7. que generarán modificaciones y/o aclaraciones a este documento................. Reportes 6......Alcance del proyecto/requerimiento 4......... se realizarán rondas de aclaraciones y actualización entre funcional e informático............... el rendimiento y las interfaces........ se ha definido correctamente las funcionalidades......

2. Lic. Se elaborará una tabla de criterios para guiar a los usuarios. Reportes 99 de 181 . 3. 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. si es una ampliación. en negociación con el usuario. 4. de datos almacenados.Sistemas de Información Gestión de Proyectos Informáticos Prof.Alcance de la funcionalidad: describir los límites de la funcionalidad . Principales cambios a los procesos .  DESCRIPCIÓN DE LA NECESIDAD Describir el objetivo y alcance de la necesidad de un nuevo sistema o una modificación. si fuera necesario. 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. en análisis de impacto.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. Descripción de aspectos de volumetría y performance: describir volúmenes de transacciones. etc. Proyecto: nombre del proyecto Ej: CRM URSI Subproyecto: nombre del subproyecto Ej: CRM .Definición de procesos/subprocesos a implementar /cambiar: nombrar y describir. los cambios introducidos a los subprocesos debido a la implementación de la nueva funcionalidad requerida.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. una modificación o algo nuevo.Fase 1 Estado: estado del requerimiento según el flujograma de gestión de la demanda (preliminar. . definitivo)  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. Requerimientos a los sistemas impactados: describir los requerimientos a los sistemas impactados por este requerimiento/funcionalidad. Funcionalidades: enumerar las funcionalidades requeridas . (VER GUÍA) . Identificar procesos y subprocesos impactados. Nombre referencial: nombre Ej: CRM – Nota de crédito del requerimiento basado en la función asociada. Identificar si se reemplaza a un sistema. 5.Definición de usuarios y perfiles de la funcionalidad: definir los perfiles de acceso y usuarios.

 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 . Puntos abiertos 7. momento adecuado de la medición y definir valores estándares para ese indicador.Sistemas de Información Gestión de Proyectos Informáticos Prof. Nota: el resto del documento lo confeccionará el usuario con la colaboración del Analista funcional. Roberto García 6. Lic. Temas a desarrollar en una etapa posterior 8. Posibles indicadores: definir indicadores.  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.

...... este documento con los distintos informes...........Situación actual (cómo se desarrolla hoy) .. Software.... conformar en conjunto..Organización ....... según la Guía de Proyectos........ el rendimiento y las restricciones que puedan afectar a la posibilidad de realización del sistema.) Notas: 21 Dentro del ámbito de la Unidad de Negocios Red...........................Relevamiento ...............................Problemáticas detectadas ....... mapeo TOM ..Usuario ..... Otros sistemas....Plan tecnológico ....... Será responsabilidad del líder funcional y el informático. corresponden a distintos responsables.Impacto ............. Redes.. el “Estudio de Factibilidad” se denomina “Estudio de Oportunidad”....Sistemas de Información Gestión de Proyectos Informáticos Prof.............. 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.Necesidades (relevamiento detallado) .../.................Ventajas y desventajas de la alternativa ...Riesgos de no ejecución ... desarrollo.. no hace falta. ... Puestos de Trabajo. Sector:............... 22 PMO: modelo objetivo presente 23 FMO: modelo objetivo futuro 24 Se deberá describir el sistema/producto con el soporte tecnológico (Hardware.. Responsable:... Participantes:...../. Base de Datos.Procesos del cliente ...Plan Maestro de Sistemas.........Alternativas..... CONTENIDO Fecha:. Escenarios de solución (FMO ) 24 .... Análisis y evaluación de distintas alternativas para el desarrollo del sistema.... visión TMN..........Parque informático .............Presentación contexto (dónde) ....Diagnóstico de la situación actual (PMO ) 23 ..........Idea/objetivo: (incluir ficha de descripción de la necesidad) .........Descripción de tipos de solución (producto..............) 101 de 181 ... .....Conclusión RESPONSABLE Líder Funcional + Líder Informático (Este documento contiene el resultado de tareas que..................................... Arquitectura sistemas............ Proyecto:..............) . evolución....Factibilidad técnica / funcional 22 ..... Lic...... etc....Plazos estimados para llevar adelante la alternativa ...

......................... Participantes:......... Escenarios posibles .........Contexto ........................Máxima necesidad de fondos y años en los que ocurre ... 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.........................Conclusión RESPONSABLE Líder funcional con colaboración del líder informático y de un experto económico.. Proyecto:.....Cash flow proyectado ......................../........................Inversiones y gastos del proyecto .......... ....... Responsable:..............Beneficios .... ....Alternativas.......... 102 de 181 .........Estado de resultados proyectado ................ Lic......................................Tasa interna de retorno ............... CONTENIDO Fecha:./...........Valor actual neto .................Contexto ............Período de recupero .....................Sistemas de Información Gestión de Proyectos Informáticos Prof.............. Sector:...............

................................Definición de cada métrica .............. Proyecto:.... Seleccionar las métricas (indicadores) de acuerdo al proyecto: métricas operativas.........../............Definir el momento adecuado de la medición . ..........................Sistemas de Información Gestión de Proyectos Informáticos Prof........................ Sector:.................... 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:...................Definir valores RESPONSABLE Líder funcional - 103 de 181 .............. ...........Identificar el responsable de la medición ........ Lic..................................................................... Responsable:........./........ funcionales y financieras............. Participantes:...........................................

............................../........................ Participantes:..........................Descripción técnica/funcional ......... CONTENIDO Fecha:................................... Lic...... Objetivo Alternativas . Sector:................ Proyecto:............Plazos Estimados .......................................................Sistemas de Información Gestión de Proyectos Informáticos Prof.............................................. 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é........ Responsable:................./................. ...................Impacto ...........Conclusión RESPONSABLE Líder Funcional - 104 de 181 .........................Estudio económico ..

.... Lic......... Participantes:.. Proyecto Aprobado? .......Sistemas de Información Gestión de Proyectos Informáticos Prof....................................Fundamentos ..Plazos (Gantt Macro) ...... Responsable:.....Proyecto Rechazado? ........................................................................Observaciones ....................................................... ........... Roberto García CARTA DE DECISIÓN NOMBRE Carta de Decisión OBJETIVO Informe de la decisión resultante del hito 0..........................Modalidad del Proyecto . Sector:...............Alternativa Elegida .........Responsables (Compromiso de disponibilidad) RESPONSABLE Comité Director - 105 de 181 ..............Presupuesto (todos los recursos + tiempo interno de compra) .........../.............. CONTENIDO Fecha:....................../......... Proyecto:................................

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 <Apellido y nombre de la persona que presenta el formulario para su aprobación> <Gerencia> Fecha de creación: <dd/mm/aa>

APROBACIÓN DE HITOS / CIERRE DE FASE Proyecto: Fase: Nombre del Hito: Fecha estimada finalización Fecha real de finalización Responsables de aprobación Fecha de aprobación <Nombre de los responsables> <dd/mm/aa> SITUACIÓN DE ENTREGABLES Documentos entregados: Detalle de los documentos entregados: - Entregable 1 - Entregable 2 Documentos pendientes: Comentarios RECHAZO DEL HITO Rechazado por: Motivo: <Nombre de la persona que rechaza el hito> <Motivo del rechazo> <Comentarios sobre las razones del mismo> Fecha de rechazo <dd/mm/aa> ANEXOS <Gerencia> Entregable 3 <Gerencia> de <Identificación del Proyecto> <Nombre de la fase según el ciclo de vida del proyecto> <Número y nombre del hito>

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

......................Diseño Detallado ................................Macro Tareas ...........Identificación de tareas críticas .............Hitos de control .... .Responsables .......................... Roberto García PLAN GENERAL DE TRABAJO (ver F2 – Fechas de implementación) NOMBRE Plan General de Trabajo OBJETIVO Definir macro tareas....... Sector:.............. Responsable:.........Implantación ..Identificación de tareas dentro de las fases y etapas del proyecto ........................Proceso de Compra .Diagrama de Gantt identificando: ............ Participantes:.....Pruebas .../..................................Sistemas de Información Gestión de Proyectos Informáticos Prof.........Plazos ..............Prueba Piloto .............Construcción ... Proyecto:............../....................Desarrollo ................... .................. plazos e hitos de control CONTENIDO Fecha:.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 ............................. Lic.........

.......... las personas que cumplen los distintos roles definidos para el proyecto CONTENIDO Fecha:...............Sistemas de Información Gestión de Proyectos Informáticos Prof.....................Porcentaje de Dedicación RESPONSABLE Líder funcional 111 de 181 ..... Lic..... Proyecto:.................../.. ..............Rol .....Para Cada Rol: ........................................Sector .......... Roberto García EQUIPO DE TRABAJO NOMBRE Equipo de Trabajo OBJETIVO Identificar................... Participantes:.../............. Sector:....................................................................................... Responsable:........Responsables ............................... dentro de la estructura de la organización..................Nombre .......................... ..........

................Sistemas de Información Gestión de Proyectos Informáticos Prof... Actualizado por: ................... Subproyecto: ... Estado En Diseño Global En convalidación Aprobado <dd/mm/aa> <dd/mm/aa> <dd/mm/aa> Preparado por: ........................................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 ......... Aprobado por: ..............................Arquitectura lógica ... Sistema afectado: ........... dimensionamiento FUNCIONALIDADES FUERA DE ALCANCE DEFINICIONES PENDIENTES FECHAS DE IMPLEMENTACIÓN 112 de 181 ................. Proyecto: ............... Fecha requerida de implantación: <dd/mm/aa> Fecha estimada de comienzo: <dd/mm/aa> Tiempo estimado de duración: Fecha de creación: Fecha de actualización: Fecha de aprobación: ALCANCE FUNCIONAL - - DESCRIPCIÓN FUNCIONAL DE LA SOLUCIÓN Especificación técnica de los requerimientos funcionales Arquitectura técnica del sistema ..................... Lic..............Solución técnica a los requerimientos funcionales NOMBRE REFERENCIAL (F1): ...... performance.........Aspectos de volumetría......................Interfaces con otros sistemas IMPACTO EN LA ACTIVIDAD Y EN LA CANTIDAD DE INFORMACIÓN A ALMACENAR .. Módulo afectado: ....................................................... ID REQUERIMIENTO (F1): ... Roberto García DOCUMENTO F2 ..................

etc. en convalidación. Ejemplo con cronograma modelo 113 de 181 . performance. Lic.  FECHAS DE IMPLEMENTACIÓN Describir el plan de trabajo con un cronograma asociado. dimensionamiento y cualquier otro aspecto que sea relevante para la solución. modelo de información. datos.  SUPUESTOS / PREMISAS / POSIBLES IMPACTOS Describir los supuestos o premisas bajo las cuales se desarrollará la solución. 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 Breve descripción de los límites y alcance que tendrá la solución  DESCRIPCIÓN FUNCIONAL DE LA SOLUCIÓN Describir la solución del requerimiento detallado en el F1. aprobado) Fecha requerida de implantación: dd/mm/aa.  FUNCIONALIDADES FUERA DE ALCANCE Mencionar detalladamente las funcionalidades que quedan fuera del alcance de esta solución. o bien los impactos que pueda tener el desarrollo  INTERFACES INVOLUCRADAS EN LA SOLUCIÓN Describirlas  IMPACTO EN LA ACTIVIDAD Y EN LA CANTIDAD DE INFORMACIÓN A ALMACENAR Describir aspectos de volumetría (transacciones. a través de la especificación técnica.Sistemas de Información Gestión de Proyectos Informáticos Prof.) . describiendo aspectos de seguridad y controles como así también la navegabilidad o secuencia de funciones. 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.

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

Se describe también el diseño de las interfaces. Roberto García FASE: DISEÑO DETALLADO 6. CONTENIDO Ver sección ESPECIFICACIÓN TÉCNICA DE DETALLE del documento DISEÑO DETALLADO RESPONSABLE Líder Informático 115 de 181 . Lic.Sistemas de Información Gestión de Proyectos Informáticos Prof.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).

... a nivel macro... - - - - - 116 de 181 ..Flujo de información entre aplicaciones............Diseño Macro de Funcionalidades: ..Flow Chart estructurado / Arquitectura técnica ...... la función será llevada a cabo por el sistema .......................Input – Output del módulo ...... procesos... Actualizado por: .....................Causa .Acciones Controles de procesos Preparado por: ....... Funcionalidades: . SUBPROYECTO: ....Bases para identificar procesos manuales y computarizados...Resolución de los módulos: .....Resolución de la funcionalidad: .. Aprobado por: .Definición de entidades . Estado Preliminar En Consolidación Definitivo Fecha de creación: <dd/mm/aa> Fecha de actualización: <dd/mm/aa> Fecha de aprobación: <dd/mm/aa> ESPECIFICACION TËCNICA DE DETALLE Gráfico de alto nivel del sistema (Soporte gráfico que describe el sistema en sí mismo) .. ...Descripción de funcionalidades del sistema y funciones involucradas......................Descripción Funcional ..Diagrama identificando los componentes generales del proceso..Bases para identificar reportes............Pseudocódigo Definición de archivos Condiciones de pruebas potenciales Códigos de Error .. pantallas.......Especificación técnica de detalle PROYECTO: . Lic...................Descripción del Módulo .... ....Descripción gráfica ....... Sistema/Módulo impactado: ...Descripción ..............................Descripción Técnica Módulos: ... Roberto García DOCUMENTO DISEÑO DETALLADO ... módulos .......Descripción detallada Interfaces .......... grupos funcionales e interfaces externas a nivel conceptual (flow de procesos) ......Sistemas de Información Gestión de Proyectos Informáticos Prof.Flow del aplicativo: descripción de cómo....Umbrales ......

Diseño físico .Descripción Funcional .Archivos .Diccionario de Datos .Tablas . Roberto García - Descripción del Acceso a Base de Datos Estructura de Datos .Registro / Estructura .Ejemplo ANEXOS - - 117 de 181 .Sistemas de Información Gestión de Proyectos Informáticos Prof.Base de Datos: .Ejemplo Pantallas .Diseño lógico .Layout . Lic.Referencias Cruzadas .Descripción Funcional .Indices .Foreign Keys Reportes .Layout .Elemento de Datos .

.................................................Implantación .............Sistemas de Información Gestión de Proyectos Informáticos Prof... Responsable:.......Hitos de control ............/.... Sector:.... Proyecto:..Identificación de tareas dentro de las fases y etapas del proyecto ................Desarrollo .....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 .............. Lic......Pruebas ..................... plazos e hitos de control CONTENIDO Fecha:..................... ..... Participantes:..........Construcción .Responsables . Roberto García PLAN DETALLADO DE TRABAJO NOMBRE Plan Detallado de Trabajo OBJETIVO Definir el detalle de las tareas.....................Plazos ............................................./........................Detalle de Tareas .... ..............................................Prueba Piloto .......................Diagrama de Gantt identificando: .........

Prueba Global (Pruebas Funcionales) ..Criterio de entrada ....................Circuito de resolución de incidentes de prueba ........................ CONTENIDO Fecha:.... volumen y seguridad .................Criterio de salida (cota de calidad) ... Proyecto:...................... .....................Descripción de la documentación que respaldará la prueba ...............Resultado Esperado .........Objetivo y Alcance ............. Responsable:.........................Prueba de Cadena ........ Lic........................../....... Plan de Pruebas: ..Responsable de la prueba .....Contexto / Ambiente de prueba ..Interfaces ...... Sector:.......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................... Roberto García PLAN DE PRUEBAS TÉCNICAS ...Datos de Entrada .......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........ Participantes:..Plataforma ......... stress..........Documentación del input de la prueba ........Prueba de Performance....Datos (generación) .Criterio de aceptación ............./...............Condiciones generales de prueba: ..............Prueba Individual ......Prueba de Integración .PLAN DE PRUEBAS FUNCIONALES Se realizarán los planes de prueba correspondientes a cada prueba: .....

......................................Sistemas de Información Gestión de Proyectos Informáticos Prof.................... Responsable:............ Proyecto:.... 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.............. ....Puesto de trabajo de contingencia ..... CONTENIDO Fecha:....................................................Plan de Tareas / Responsable .......................................................Procedimiento de contingencia .Escenarios posibles de contingencia ... Lic.. Momento en que se declara la contingencia Responsable/s de declarar la contingencia Tipos de contingencia (dependerá de la implementación de cada sistema) .............................. Participantes:...................................................Esquema de seguridad .Identificación de interfaces críticas y propuestas de plan de contingencia ................../..... Sector:..........Descripción de pruebas de plan de contingencia........ RESPONSABLE Líder informático - 120 de 181 ......................./......

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

.... Participantes:......Casos en que quieran ser informados ........... CONTENIDO Fecha:.Conocimiento por parte de las áreas involucradas el circuito. .........Instructivo de uso del mismo .......Administradores..Nómina de los usuarios definidos ...Asistencia MASIT en Host ...Edificios y lugares que pudieran estar afectados ...Cortes programados ......... mnemónico y direcciones IP Eth/X25 y X25 ....Definición de las funcionalidades del sistema..... .Que datos requerirán de la MASIT ......Nombre.Interlocutores .Circuito de derivación de problemas.................... 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..... administración de procesos generados por los usuarios....Interlocutores de los sectores involucrados .Soporte del aplicativo ..Horario de Soporte al Aplicativo .....Referentes por Cortes programados . ...Cantidad de llamadas promedio ponderadas de consultas ............ Sector:......Sistemas de Información Gestión de Proyectos Informáticos Prof.....Breve descripción de la finalidad del sistema....Esquema de conectividad y comunicaciones con equipo central o procesamiento distribuido ......... ............... .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 ..) .............Responsables del sistema ....... Responsable:.................Detalle de usuarios del sistema ......Alternativas de comunicación en sus distintos horarios...Impacto de llamadas en la puesta en marcha ./.Equipo (host) ............Análisis de puesta en marcha .......Esquema de configuración del equipo standard informático utilizado (Puesto de trabajo) . .......Soluciones a esos mensajes .... .......... .....Lista de responsables por cada tema............Configuración ... Lic.. ...../............Mensajes más comunes de error........Usuario normalizado para todas las operaciones permitidas (Control de performance (Monitor)...........Horario de utilización que tienen los usuarios del sistema..................Ubicación física del Equipo .Estadísticas .............Casos o seguimientos especiales........ ........Horarios de Atención .....Aplicación .. ....... etc... Proyecto:........... ............

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

... Proyecto:. 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......... CONTENIDO Fecha:........ . procedimientos.................................... Sector:. directorios..... etc............. Se deberá proveer la misma.... Nombre y Apellido............ disipación térmica y tamaño de los servers......................... entorno operativo (Windows 95/98/NT). dirección....... etc... Periodo de retención y reciclaje de las cintas................... Orden de Compra Garantía o contrato de mantenimiento (copia del mismo) Estaciones de trabajo: indicar lista de usuarios con ID de usuario...... Control de Interfaces Se deberá proveer toda la información necesaria para el control de las interfaces (origen/destino.... 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........ Ubicación física y responsables locales de los servers (de ser necesario)......... manual/automática... Identificar la versión de software a instalar...... procedimientos.... Manual de instalación Backup Instructivo y menú de backup. tipo de PC que utiliza y Master....) Contingencia Especificación de los servers de contingencia.... etc..........Sistemas de Información Gestión de Proyectos Informáticos Prof. servidor de LAN al cual se conecta.. etc.. Responsable:. Contrato de mantenimiento (copia del mismo)......... para ser utilizada en los casos en que el sector tenga que intervenir. base de datos.............. de Serie........... teléfono............................ 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. configuración. radio...... periodicidad........ interno. Información a resguardar (File System.. (Instructivos..... Participantes:.. Nro..) - - RESPONSABLE Líder informático 124 de 181 .. Responsable del lanzamiento de la contingencia..../............ etc....... Requerimientos mínimos del hardware para la instalación del software......./.............. mac address de los servers.) en el servidor y estaciones de trabajo......... Lic...........) Carpeta Operativa..) Responsables del mismo (nombre.... Plan de contingencia............... etc.......

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

.......................Descripción de los pasos para informar los cambios realizados a un elemento. Sector:......./..........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... 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........................ ............. .. .... ....Sistemas de Información Gestión de Proyectos Informáticos Prof.............................. Proyecto:....Documentos (incluye cualquier documento generado en el ciclo de vida del proyecto).............Código fuente..Descripción de los pasos requeridos para obtener e identificar un elemento en proceso de cambio......Definir a partir de que instante un elemento queda 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...Identificación y enumeración del tipo de elementos que se encuentran bajo el procedimiento de Gestión de Configuración: . ......................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.............. Lic......... CONTENIDO Fecha:. ................... Responsable:...........Definición de las herramientas automatizadas que se utilizarán en la gestión de configuración...... .....Tablas o archivos de parámetros................... ..... ........... RESPONSABLE Líder informático 126 de 181 ............Cualquier otro elemento que se pretenda tener control sobre los cambios que sobre el mismo se puedan hacer................ ................/........... ................................... Participantes:............

...........................................Dimensionamiento del impacto respecto a las tareas / competencias / localizaciones necesarias previas al cambio RESPONSABLE Líder Funcional - 127 de 181 ..Tipo de contrato (D/C ................. Participantes:......................... ... Procesos a implantar/cambiar Sistemas a implantar/cambiar Población afectada . Lic..................................../............Localización ........................ 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..................................................................Sistemas de Información Gestión de Proyectos Informáticos Prof............/.................... Sector:.....................F/C) ......... Proyecto:.......Cantidad .. CONTENIDO Fecha:......Especialidades / Puestos ........................................ Responsable:..............

........................... contenido) .../... ...........Big Bang .............................. Lic..................... Sector:... Responsable:........... Proyecto:................... Participantes:.............................../...........Fases (descripción.......Sistemas de Información Gestión de Proyectos Informáticos Prof...............................................Releases ....Roll-out (en etapas) ..Cronograma General Por fases................. Roberto García ESTRATEGIA DE IMPLANTACIÓN NOMBRE Estrategia de Implantación OBJETIVO Definir la estrategia de implantación de un proyecto CONTENIDO Fecha:................................ Releases y Sitios RESPONSABLE Líder Funcional - 128 de 181 ................ Modo de Implantación: ............................................ alcance......................

129 de 181 . Roberto García PLAN DE PRUEBAS FUNCIONALES Este documento se describe junto con el Plan de Pruebas Técnicas.Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic.

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

.Condiciones claves y estándares de conversión ...........Controles y criterios de aceptación de conversión .Big bang ..................Sistemas de Información Gestión de Proyectos Informáticos Prof.../....Documento de la Conversión ..........................Criterios de depuración previos a la conversión ....... ..................../.......... Participantes:.............Dependencia y secuencialidad de procesos de conversión .............................................Por etapas ......... 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...Modalidad ...Requerimientos de conversión .. Conversión de Datos ...............Identificación de información a ser convertida ..................................Condiciones a probar para la conversión y lineamientos generales para la prueba de conversión............ determinar valores a asumir por defecto ..........Criterios de Conversión ......Plan de Conversión .......................................Identificación de fuente de obtención de nuevos datos ..... .................. Lic....................... Sector:.....Responsables RESPONSABLE Líder funcional - 131 de 181 ... Proyecto:. Responsable:................... CONTENIDO Fecha:.....

.....Plan de Carga RESPONSABLE Líder funcional - 132 de 181 ..................Sistemas de Información Gestión de Proyectos Informáticos Prof............... ................................. 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:..........................Modalidad Big Bang Por Etapas .................................................. Lic.......Circuito de corrección de errores ......Metodología .................................. 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 ......./.....................................Criterios de aceptación ............./...................... Sector:..... Responsable:.................... Participantes:..... Proyecto:............Responsables ..........

............................................................. CONTENIDO Fecha:..Definición del Plan de Distribución Dotacional .Identificación de Recursos Necesarios ............................................................................. Proyecto:...Definición de Plazos-Cronogramas (Gantt) .................................................................... . 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.. Responsable:........ Participantes:...........................................Definición de Hitos de Control RESPONSABLE Responsable Soporte al Cambio 133 de 181 . Lic..........Sistemas de Información Gestión de Proyectos Informáticos Prof../............................... Sector:... .....Asignación de Responsables ................./........................

. Proyecto:...... Responsable:....... funcionalidades del sistema./................Ambiente ...................................................Server y Puestos de Trabajo .Sistemas de Información Gestión de Proyectos Informáticos Prof.............. Participantes:...............Asistentes .........Logística ..... 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:...........) . Sector:........Materiales ..............................Datos .......................Comunicación de la Capacitación .... ......Presencial ........................................... seguridad del sistema./....................Aplicación . Identificación del temario/contenido (procesos............................. Lic......A distancia ..................Trainers/Formadores/Capacitadores (en caso de tratarse de una capacitación presencial) ...Plan de Capacitación RESPONSABLE Responsable Capacitación - 134 de 181 .....Salas . etc.Modalidad ...................Herramientas ................

............................................. Identificación de conceptos a comunicar (misión... Responsable:..............Actores ......... objetivo y plazos) de la implementación del sistema....................... Proyecto:........ Participantes:.....................Destinatarios Nombre Sector .... Lic.... ... ............ Sector:... Roberto García PLAN DE COMUNICACIÓN NOMBRE Plan de Comunicación OBJETIVO Definir las acciones necesarias para “comunicar”......................Medio de Comunicación ................................../...........Responsable de la Comunicación .................................. CONTENIDO Fecha:.........../....................Sistemas de Información Gestión de Proyectos Informáticos Prof........................Plan de Comunicación ....................................................Circuito de Comunicación (Feedback) RESPONSABLE Responsable Soporte al Cambio - 135 de 181 .... alcance..

.......... 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....módulos.. Responsable:........ anuales) Cross ................................................... 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......................... Proyecto:..............reference (pantalla ....... indicando nombre y valor............... pgms archivos........................../............. Se deberá generar un documento que describa cada uno de los parámetros del sistema.. MANUAL DE SISTEMAS NOMBRE Manual de Sistemas OBJETIVO 25 Documentar la información técnica del Sistema CONTENIDO Fecha:............... Participantes:.... los mismos deberán documentarse............................... Lic.. Roberto García FASE: CONSTRUCCIÓN PROGRAMAS...... ..pgm . El mismo deberá ser actualizado ante modificaciones en los parámetros............... 136 de 181 .............................. módulos y parametrizaciones no constituyen documentos en sí mismos.. MÓDULOS y PARAMETRIZACIÓN Si bien los programas../......... a saber: Los programas y módulos desarrollados en la etapa de construcción deberán estar documentados en el código........................................................Sistemas de Información Gestión de Proyectos Informáticos Prof............. Sector:...

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

. 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:./.................................................../..... Sector:................................ Lic...................... Responsable:........Sistemas de Información Gestión de Proyectos Informáticos Prof...............................................Descripción del Proceso RESPONSABLE Líder funcional + dueño del proceso 26 Notas: 26 La base de este manual son los procesos/sub-procesos definidos en la especificación funcional 138 de 181 ................................................................ ......................................... Participantes:............ .................................................... Proyecto:..................

Casos/ Condiciones detalladas de prueba (DTC): ............... volumen y seguridad) Líder funcional (Prueba Global) Notas: 27 Se incluirán por ejemplo los pendientes de prueba....... ....... de Integración....Datos de Entrada ....... stress.............................Entorno ...........................Prueba de Performance................ Roberto García PROTOCOLO DE PRUEBA Se definirán protocolos para las distintas pruebas y sus respectivos informes: ......Resultado esperado .Resultado obtenido 27 ................ Lic.......Objeto de la Prueba ...Prueba de Integración ...Prueba Individual ...Prueba de Cadena ..... de Performance....Observaciones Ver detalles y formatos en las planillas anexadas RESPONSABLE Líder Informático (Prueba Individual... 139 de 181 ........................................... CONTENIDO Fecha:..... Responsable:.. Participantes:................Acciones ........Procedimientos de Prueba ........................../. volumen y seguridad ...........Sistemas de Información Gestión de Proyectos Informáticos Prof....... los resultados esperados y obtenidos............Prueba de Compatibilidad NOMBRE Protocolo de Prueba OBJETIVO Describir detalladamente los casos de prueba.... ........ Proyecto:....................../..Prueba Global ..... Sector:...... stress......... de Cadena..................Descripción del caso ...........

......./..Prueba Rechazada .......Prueba de Performance...................Observaciones ...Prueba Global ........................ volumen y seguridad ......Recomendación RESPONSABLE Líder Informático (Prueba Individual........................... 140 de 181 .....Prueba de Compatibilidad NOMBRE Aprobación de Prueba OBJETIVO Documentar la aprobación de la prueba CONTENIDO Fecha:.......... Lic.............. de Integración.......................... Proyecto:................................................................ stress.. Sector:................ Objeto de la Prueba Resumen Ejecutivo del resultado de la prueba Criterio de Aceptación Prueba Aprobada 28 .. ...........Prueba de Integración .. stress.Prueba de Cadena ...... Responsable:....Prueba Individual ............... Participantes:........Justificación ............./............... volumen y seguridad) Líder funcional (Prueba Global) - Notas: 28 Se incluirán por ejemplo los pendientes de prueba...............Sistemas de Información Gestión de Proyectos Informáticos Prof.................... de Cadena. de Performance........... Roberto García APROBACIÓN DE PRUEBA Se realizarán los informes de aprobación de prueba correspondientes a cada prueba: ...............

......................... Participantes:........ los resultados esperados y los resultados obtenidos en la misma............. Objeto de la Prueba Piloto Sitio Procedimientos de Prueba Documentación Asociada Casos: .............Descripción del caso ... Lic....... CONTENIDO Fecha:...........Sistemas de Información Gestión de Proyectos Informáticos Prof.......... 141 de 181 .....Observaciones RESPONSABLE Líder funcional - Notas: 29 Se incluirán por ejemplo los pendientes de prueba. ........ Responsable:............/............Datos de Entrada ............................................. Sector:..........Entorno ......................................................................................./.Resultado esperado ........ 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... Proyecto:....................Acciones ...............................Resultado obtenido 29 ..............................

............Justificación ........ Lic................................................................. 142 de 181 .... ............................ Participantes:.....................Prueba Rechazada ..............................Sistemas de Información Gestión de Proyectos Informáticos Prof.../....... Proyecto:.............. Objeto de la Prueba Resumen Ejecutivo del resultado de la prueba Criterio de Aceptación Prueba Aprobada 30 .............../... Responsable:....Recomendación RESPONSABLE Líder funcional - Notas: 30 Se incluirán por ejemplo los pendientes de prueba.............. Sector:.................................................. 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:...........................................Observaciones .....................................

.................................................................Responsables ......................... Proyecto:............... .....................................................................Hitos RESPONSABLE Líder funcional - 143 de 181 ......../........... Participantes:............/.... CONTENIDO Fecha:.............. Sitios para la implantación Recursos físicos y humanos necesarios Plan de trabajo ...........................................Sistemas de Información Gestión de Proyectos Informáticos Prof...... Roberto García PLAN DE IMPLANTACIÓN NOMBRE Plan de Implantación OBJETIVO Establecer el plan de implantación de un proyecto......................... Lic........................Cronograma ........... Sector:.................. Responsable:.......

......... Objetivo y alcance Circuito de atención.......... Participantes:... Proyecto:.................. Responsable:......Técnico .......... diagnóstico..Funcional ............... CONTENIDO Fecha:..Disponibilidad y horario de atención de soporte por sitio RESPONSABLE Líder funcional / Líder informático - 144 de 181 ..... ............... Lic.................Centralizado ......................Sistemas de Información Gestión de Proyectos Informáticos Prof....Funcional ......................./..../............................................................................ Roberto García PLAN DE SOPORTE NOMBRE Plan de Soporte OBJETIVO Establecer el plan de soporte a la implantación. recepción...................................................Técnico ....... Sector:.................. 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 ............

.......... Proyecto:.......Entorno ......................................................Observaciones RESPONSABLE Líder funcional - 145 de 181 .........../..........Resultado esperado .................. Participantes:...........Acciones ..........................Datos de Entrada ......./....... Sector:.................................................... Roberto García PROTOCOLO DE IMPLANTACIÓN NOMBRE Protocolo de Implantación OBJETIVO Definir el protocolo de pruebas para la Implantación CONTENIDO Fecha:..................... Lic.....Descripción del caso .................. Sitio Procedimientos de Prueba Documentación Asociada Casos: .................................... Responsable:........................Sistemas de Información Gestión de Proyectos Informáticos Prof.................................... ......

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

...................Responsables ... Participantes:./.....................................................Sistemas de Información Gestión de Proyectos Informáticos Prof.......................... Sector:........................... ................................................... Lic......................................... Proyecto:...................................................................../... Responsable:.............Fecha ...... Roberto García ACUERDO DE IMPLANTACIÓN NOMBRE Acuerdo de Implantación OBJETIVO Documentar la decisión de implantar el proyecto CONTENIDO Fecha:.......Firmas ...... ....................Observaciones RESPONSABLE Líder funcional 147 de 181 ..........Breve Descripción del Proyecto ...

... Lic....../...........................Tiempos de conversión ..................................................... Sector:.... 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:..... Responsable:.Muestreo estadístico ...Criterio de Aceptación .............../.............Recomendación RESPONSABLE Líder funcional 148 de 181 ...Conversión Aprobada ................Resumen de Volúmenes Convertidos .......Sistemas de Información Gestión de Proyectos Informáticos Prof.........................Conversión Rechazada ...................Justificación ................ ................................................................... Participantes:....Volumen Previo ........................Volumen Final .................. ... Proyecto:.Observaciones ...............................

................../........Justificación ........................... 149 de 181 ........Observaciones ................................... etc........ Proyecto:... Sector:....................... ....................Documentación recibida (fuentes.......) .. Roberto García RECEPCIÓN PROVISORIA NOMBRE Recepción Provisoria OBJETIVO Documentar la Recepción Provisoria del Sistema (Aprobación)..Recomendación ..........................................……. manuales..... Descripción del sistema/etapa recibido Resumen Ejecutivo del resultado de la Prueba de Aceptación Criterio de Aceptación Prueba Aprobada 31 .Prueba Rechazada .........................Firma responsables RESPONSABLE Líder funcional - Notas: 31 Se incluirán por ejemplo los pendientes de prueba............................................/................ Responsable:. Lic.........Sistemas de Información Gestión de Proyectos Informáticos Prof............. Participantes:... informando los resultados de la Prueba de Aceptación del Mismo.............. CONTENIDO Fecha:....................

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

........... soporte técnico...Indicador 1 ........./.Procesos de Performance ............................ 151 de 181 ..Indicador n ... Sector:............Indicador 1 ..........Soporte Funcional ........................... soporte aplicativo) CONTENIDO Fecha:...........Procesos de Seguridad ... ......................Procesos Técnicos .........................Sistemas de Información Gestión de Proyectos Informáticos Prof............. Participantes:.............Indicador n ........Indicador 1 ..Indicador 1 ....... performance.Indicador n RESPONSABLE El Tablero de Mando será completado por el responsable de cada proceso.......................Procesos Rutinarios ............... responsable de medición.. El contrato de servicio de producción define los indicadores del tablero de mando.......................... la metodología de medición. 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............/............Indicador n .......... ..........Indicador 1 ....Atención de Usuarios ...... Responsable:.... Proyecto:................. soporte funcional............Indicador n .. procesos rutinarios) y el soporte (atención a usuarios.Soporte ...

Valores de métricas claves (según lo identificado en el Estudio Preliminar): valores anteriores a puesta en producción. 152 de 181 . 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. estimados y reales. valores posteriores.Sistemas de Información Gestión de Proyectos Informáticos Prof. Comentarios sobre el desarrollo del proyecto. originalmente estimados.

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

Roberto García ACUERDO y CONTRATO de SERVICIO 155 de 181 .Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic.

..... MODELO ACUERDO DE SERVICIO DE PROYECTO........................………………………………........................................................ 156 de 181 .........………………………... El Acuerdo de Servicio de Proyecto está basado en el Modelo Único de Contrato de Servicio.............. en adelante el denominado PROVEEDOR.Sistemas de Información Gestión de Proyectos Informáticos Prof............................................……………………….. se definen en el Contrato de Servicio de Producción....................... y se firma en el Hito 0 de Aprobación del Proyecto................ ENTRE <Responsable Informático>……............. 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..................... que las condiciones y obligaciones correspondientes a la producción.......... operación y mantenimiento del sistema........... Cabe señalar............ Y en <Owner del Proyecto>.. 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............ adelante el denominado CLIENTE.. representado por ............. Lic........ representado por ...................

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

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. Seguimiento de Proyecto. Cualquier otro informe deberá acordarse en el momento por ambas PARTES. etc.1. precios y tiempos. Se acordarán entre las partes la metodología de seguimiento de proyectos. Ambas PARTES pueden proveer o solicitar nuevos servicios no comprendidos en el presente contrato. etc. guardias pasivas y todo aquel que fuera necesario detallar. Describir otros servicios adicionales (esquema de seguimiento. Asimismo. En ese caso. PRECIOS Y PAGO. Se detallará en un Anexo los informes preestablecidos (frecuencia de prestación. se identificará claramente las responsabilidades de cada sector y persona o grupo de personas. diferenciando aquellos de única vez (no recurrentes) de los periódicos (recurrentes). viáticos.Desvío de Plazos .2.) con los tiempos previstos de solicitud. Identificar con nombre. El CLIENTE presentará al PROVEEDOR la ficha indicada. se detallarán los nombres y sectores de la organización que cumplen cada rol. Dichos precios se especificarán en un Anexo.2 se aplican en el caso en que el presupuesto sea del Owner del Proyecto. Lic. informar con la debida anticipación los listados correspondientes al personal que se encuentre disponible para su convocatoria. teléfono y e-mail de las personas que intervendrán para brindar el servicio. Entre las PARTES se establecerán los datos de prestación y contraprestación del servicio contratado. 3. Identificar el o los responsables de interactuar con el proveedor. gastos imprescindibles. que deberá ser actualizada por el CLIENTE toda vez que correspondiere. rol. 5. 4. dirección y teléfono la ficha que se encuentra en un Anexo. se propondrá una definición del servicio. PROVEEDOR. Esta información deberá ser completada en una ficha. a los _____ días.1 y 5.3.Otros 4. que deberá ser actualizado por el PROVEEDOR toda vez que correspondiere. 3. 158 de 181 . Si ambas PARTES deciden continuar para la prestación del nuevo servicio. dirección. el CLIENTE deberá realizar una descripción del servicio y deberá enviar tal descripción al PROVEEDOR quien notificará al CLIENTE.1. Para ello se deberá completar con nombre.Sistemas de Información Gestión de Proyectos Informáticos Prof. El PROVEEDOR presentará al CLIENTE en un Anexo al presente dicha ficha. si desea proceder a la negociación de la inclusión del nuevo servicio.Desvío de Presupuesto . OTROS SERVICIOS VINCULADOS 4. los insumos. horas extras. Roberto García ROLES INTERVINIENTES En el anexo de descripción de roles. CLIENTE. pero que se desprendan del objeto del mismo. 4.2.1. rol. registrando al inicio del contrato. COSTOS Y PENALIDADES Los puntos 5.Desvío de funciones entregados respecto a funcionalidades solicitadas . En el caso en que un rol sea llevado a cabo por más de una persona o por más de un sector. deberá el PROVEEDOR.) que estén involucrados y que no formen parte del Servicio objeto del presente contrato.4. 4.Incidentes .5 El presente contrato puede ser modificado o ajustado de común acuerdo de las partes. Se definirán los indicadores de seguimiento: . indicando para estos últimos expresamente la periodicidad de cada cargo.

6. Se clasificarán en: 5. el tablero de mando y los indicadores que lo componen. Deberán ser establecidas explícitamente tomando como base los indicadores de calidad de servicio que se definan en el ítem 6. definiendo niveles de incumplimiento (del cliente y del proveedor) y asociarlo con las penalidades correspondientes. 7. El CLIENTE se reserva el derecho de realizar las encuestas de satisfacción a clientes (internos y/o externos) que estime necesarias. Lic. Se definirán los reportes de monitoreo. Se identificarán aquellos indicadores correspondientes a la performance de los aspectos técnicos del sistema y al soporte (a usuarios. 5.3. técnico.1. REGISTRACIÓN Y COMUNICACIÓN 8. 7. La parte afectada por un evento de caso fortuito o fuerza mayor. El PROVEEDOR deberá disponer de los medios para prestar el servicio. funcional. RESPONSABILIDADES 7. 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. Las PARTES se obligan a cumplir estrictamente toda disposición reglamentaria y demás normas. Se deberán establecer rangos y escalas de calidad de servicio.2.Sistemas de Información Gestión de Proyectos Informáticos Prof.2.2. 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. 159 de 181 . Satisfacción del cliente. A través de estos indicadores se medirán los servicios que el proveedor está prestando. contra conformidad del CLIENTE del servicio entregado. Penalidades para el PROVEEDOR. CALIDAD DEL SERVICIO 6.3. y ambas partes procederán con diligencia una vez que la causa del retraso o falla haya cesado o desaparecido.3. Penalidades por incumplimiento. El CLIENTE deberá brindar las condiciones para que el PROVEEDOR pueda dar el servicio de acuerdo al nivel de calidad acordado.2. aplicativo). de conformidad con las disposiciones de la normativa vigente. Penalidades para el CLIENTE 5.1. En ambos casos. la firma del presente contrato. procedimientos y políticas de la compañía dictadas o a dictarse por el sector competente y que resulte aplicable. umbrales.1. Indicadores. 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. Las PARTES se comprometen a divulgar en los sectores intervinientes . junto con los responsables de medición.incluyendo las áreas de Calidad corporativas así como las propias de los sectores que participan en el contrato.1. del presente.4.2.3. 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. Los indicadores de evaluación y seguimiento del presente contrato deberán detallarse en un Anexo. El CLIENTE efectuará las transferencias presupuestarias que surjan de las prestaciones solicitadas al PROVEEDOR. contemplando los rangos y/o escalas que para los mismos AMBAS PARTES definan y acuerden. Roberto García 5. extraordinarias en caso de necesidad. En el caso de trabajos adicionales requeridos por el CLIENTE. 7. valores de referencia.

3.1. 14. registros comerciales. CESIÓN DEL CONTRATO 12. Roberto García VIGENCIA 9. El presente contrato tendrá vigencia desde __________ y hasta __________ (de acuerdo al plan de proyecto).3.1. Falta de pago 13. la petición de rescisión del presente contrato. comercial.1. Toda la información que sea intercambiada en virtud del presente. etc. cualquiera de las PARTES optase por denunciar el Contrato comunicándolo fehacientemente a la otra. el CLIENTE deberá intimar al PROVEEDOR a subsanar la situación en un plazo que de acuerdo a la circunstancia resulte razonable. Finalizada. listas de clientes. 9. la celebración de otro. datos sobre costos. ingeniería. será tratada en forma confidencial. que resulte de la solicitud de cualquiera de las PARTES.1.Sistemas de Información Gestión de Proyectos Informáticos Prof.1.2. Como excepción al plazo de vigencia fijado en el punto anterior. Las PARTES no podrán transferir ni ceder en todo o en parte. de común acuerdo entre las partes cesará la vigencia del acuerdo.2. dentro de los ______ días de serle notificada aquella situación. 160 de 181 . RESOLUCIÓN DEL CONTRATO. 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. Incumplimiento de las cláusulas detalladas precedentemente se elevará al Organismo de Control.. Si en algún hito go no-go del proyecto se acuerda no continuar con el mismo. se pacta que: cesará la vigencia de este Contrato. a título gratuito u oneroso. en su caso. CONFIDENCIALIDAD 14. salvo expresa autorización formal por parte de la otra PARTE. 13. INCUMPLIMIENTO.1. o consecuencia derivada de éste. las PARTES en forma expresa podrán decidir la prórroga del Contrato o. datos técnicos.1. si existiere una situación no prevista que altere significativamente la voluntad bilateral articulada en el presente. 9. 13. El PROVEEDOR garantizará todo defecto atribuible a su intervención por un período acordado por las PARTES medido en días corridos. las PARTES se comprometen a tratar en forma confidencial toda información técnica. Lic. Las PARTES acuerdan trabajar estrechamente y en forma conjunta para combatir el uso fraudulento del servicio objeto del presente contrato.2. referida a los sistemas. y ante ello.1.1. En tal sentido.2. el presente contrato. GARANTÍAS SOBRE LAS INTERVENCIONES 10.1. En el caso de incumplimiento de obligaciones estipuladas en este contrato (con respecto a los plazos e indicadores). Disolución del sector 13. Ante situaciones de: 13. o antes de finalizada la vigencia del presente contrato. correspondencia. contados a partir del momento en que el CLENTE verifique el normal funcionamiento del servicio intervenido. CONDUCTAS FRAUDULENTA 11.

..... que no pudieran resolverse mediante negociaciones amigables entre las PARTES...... Las PARTES se comprometen a cumplir el presente contrato de buena fe. La información resultante deberá ser clasificada según la categorización de la empresa............. Sin embargo ante cualquier controversia o reclamo relativo a la interpretación........1. 15.. se elevará al Organismo de Control la petición de arbitraje correspondiente... revisión o consecuencias del mismo...... Lic............ a todos los efectos que diere lugar el presente contrato a .............1. aplicación.....….......... 14......2.......... COMPETENCIA 16.....3... Se designa como Organismo de Control.. ORGANISMO DE CONTROL....... 161 de 181 .............Sistemas de Información Gestión de Proyectos Informáticos Prof.. En caso que fuera necesario se firmará un Acuerdo de Confidencialidad de la información....... Roberto García 14...

.................................................................. representado por ......................................................................................................................................................................................................................... El presente acuerdo reemplaza integralmente a los siguientes documentos: ...................... 162 de 181 ......... El presente acuerdo tiene por objeto fijar los términos y condiciones del servicio de ............................................... OBJETO Y CONSIDERACIONES INICIALES 1.......................................................................... .........….................................................. MODELO CONTRATO DE SERVICIO DE PRODUCCIÓN DE SISTEMAS DE ......................................….....................................................<proveedor interno – externo>........................1...................................................................................................................................................................................................................................................................... El servicio comprende los siguientes puntos: ..................................................... 1................ Y <el usuario>............................................................................................................................................................................. 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........................................ ....................................... ............ 1.................................... ............................................. ENTRE ................................................................Sistemas de Información Gestión de Proyectos Informáticos Prof.................................................................................................................. en adelante el denominado PROVEEDOR................................................................................ Lic.. con domicilio en ......... ............. representado por ...........................................3..........................................................2............................................................................. ........ en adelante el denominado CLIENTE........ y se firma previo al Hito 5: Sistema en Producción............. con domicilio en ..................................................................................

6. Pruebas de aceptación. Deberá mantenerse actualizado con las modificaciones. tipo. Asimismo. definiendo el circuito de atención. forma. etc. para restitución de un servicio interrumpido). 2.) La descripción del servicio. se detallarán los nombres y sectores de la organización que cumplen cada rol. Describir todas las obligaciones que deberá cumplir el proveedor para la prestación del servicio objeto del presente acuerdo (modalidad de intervención. Ámbito. derivación y resolución de incidentes. Lic. Obligaciones del PROVEEDOR. Procesos. que se detallarán en un Anexo.Sistemas de Información Gestión de Proyectos Informáticos Prof.2. debiendo el mismo confirmar de igual modo su disponibilidad. Pliego de Compra. Esta información deberá ser completada en una ficha. 163 de 181 . recepción.Funcional. se identificará claramente las responsabilidades de cada sector y persona o grupo de personas. El PROVEEDOR se compromete a informar por escrito la finalización de las tareas vinculadas a este servicio. asistencia. cantidades. Describir y/o referenciar el/los proceso/s asociado/s al servicio objeto de este acuerdo. en caso de producirse modificaciones en los elementos deberá incluirse la modificación en el Anexo mencionado previamente.In Situ.3. Procedimiento de Producción. etc. - 2. modo de requerimiento. bajas y modificaciones de equipos. 2. . Planes de backup.4.8. etc. etc. deberá contener mínimamente estos ítems: Identificación del nivel de criticidad de los incidentes Esquema de soporte. de existir. centralizado . En ningún caso el PROVEEDOR podrá producir modificaciones sin recibir autorización formal por parte del CLIENTE. 3. Elementos que intervienen para la prestación. En este caso se detallarán altas.) 2. Identificar con nombre.1. Si se le solicitara al PROVEEDOR participar de las mismas. Planes de Contingencia. A los fines de estas actuaciones regirán los tiempos indicativos detallados en un Anexo a tal efecto.5.Objetivo y Alcance . nuevos usuarios. Técnico Disponibilidad de Servicio Tiempos de intervención Capacitación (en caso que corresponda): nuevas funcionalidades. diagnóstico. Determinar los lugares para la prestación. Formas de Intervención. Servicios. se le informará de esta situación en tiempo y forma. Describir completamente los servicios a prestar (contenido. El CLIENTE definirá las actuaciones que deberá realizar el PROVEEDOR para intervenir (como por ejemplo. Asimismo. 2. teléfono y e-mail de las personas que intervendrán para brindar el servicio.) 2. En el caso en que un rol sea llevado a cabo por más de una persona o por más de un sector.7. rol.) 2. Describir todas las obligaciones que deberá cumplir el cliente (especificaciones. indicando en cada caso tipos de equipos. PROVEEDOR. ubicación precisa.1. 2. 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. En caso de necesitar identificar dichos elementos se deberá utilizar un formulario Anexo. dirección. el proveedor deberá informar al cliente de manera fehaciente los avances y tiempos estimados de cada intervención. cooperación. a efectos de que el CLIENTE dé comienzo a las pruebas de aceptación respectivas. ROLES INTERVINIENTES En el anexo de descripción de roles. Obligaciones del CLIENTE.Tipo de soporte . números de serie. etc. etc.

Penalidades por incumplimiento. contra conformidad del CLIENTE del servicio entregado. 164 de 181 . gastos imprescindibles. guardias pasivas y todo aquel que fuera necesario detallar. viáticos.3. 3. etc. CLIENTE. 4. Entre las PARTES se establecerán los datos de prestación y contraprestación del servicio contratado.2. 5. Asimismo. Capacitación. energía. el CLIENTE deberá realizar una descripción del servicio y deberá enviar tal descripción al PROVEEDOR quien notificará al CLIENTE. En ese caso. PRECIOS Y PAGO. Si ambas PARTES deciden continuar para la prestación del nuevo servicio.5 El presente acuerdo puede ser modificado o ajustado de común acuerdo de las partes. Dichos precios se especificarán en un Anexo. Describir otros servicios adicionales (capacitación. de acuerdo a temarios vigentes y según modalidad que se establezca para cada caso. Para ello se deberá completar con nombre. diferenciando aquellos de única vez (no recurrentes) de los periódicos (recurrentes).2. 5. los insumos. que deberá ser actualizado por el PROVEEDOR toda vez que correspondiere. En el caso de trabajos adicionales requeridos por el CLIENTE. si desea proceder a la negociación de la inclusión del nuevo servicio. indicando para estos últimos expresamente la periodicidad de cada cargo. Identificar el o los responsables de interactuar con el proveedor. registrando al inicio del acuerdo.2. COSTOS Y PENALIDADES 5. que deberá ser actualizada por el CLIENTE toda vez que correspondiere.4. con los tiempos previstos de solicitud. definiendo niveles de incumplimiento (del cliente y del proveedor) y asociarlo con las penalidades correspondientes. El PROVEEDOR se compromete a presentar al CLIENTE el plan de capacitación anual o específico requerido. Se detallará en un Anexo los informes preestablecidos. horas extras.Sistemas de Información Gestión de Proyectos Informáticos Prof. Se deberán establecer rangos y escalas de calidad de servicio. 4. Cualquier otro informe deberá acordarse en el momento por ambas PARTES. El CLIENTE presentará al PROVEEDOR la ficha indicada.1. El CLIENTE efectuará las transferencias presupuestarias que surjan de las prestaciones solicitadas al PROVEEDOR. horarios. 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. a los _____ días. informar con la debida anticipación los listados correspondientes al personal que se encuentre disponible para su convocatoria. Roberto García El PROVEEDOR presentará al CLIENTE en un Anexo al presente dicha ficha. se propondrá una definición del servicio. Lic. 4. Ambas PARTES pueden proveer o solicitar nuevos servicios no comprendidos en el presente acuerdo. OTROS SERVICIOS VINCULADOS 4.3. deberá el PROVEEDOR. 4. precios y tiempos.) que estén involucrados y que no formen parte del Servicio objeto del presente acuerdo. El CLIENTE se reserva el derecho de requerir al PROVEEDOR los informes vinculados que estime conveniente respecto de sus actuaciones. extraordinarias en caso de necesidad. pero que se desprendan del objeto del mismo.1. dirección y teléfono la ficha que se encuentra en un Anexo. rol. El CLIENTE brindará capacitación ante requerimiento del PROVEEDOR. 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.

5. Penalidades para el PROVEEDOR. y ambas partes procederán con diligencia una vez que la causa del retraso o falla haya cesado o desaparecido.2. El PROVEEDOR deberá disponer de los medios para prestar el servicio. 165 de 181 .1. del presente. 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. equipos y propiedades del CLIENTE. REGISTRACIÓN Y COMUNICACIÓN 8. aplicativo). umbrales. Las PARTES se obligan a cumplir estrictamente toda disposición reglamentaria y demás normas. 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.incluyendo las áreas de Calidad corporativas así como las propias de los sectores que participan en el acuerdo. las PARTES en forma expresa podrán decidir la prórroga del Acuerdo o. Indicadores.1.4. contemplando los rangos y/o escalas que para los mismos AMBAS PARTES definan y acuerden. Los indicadores de evaluación y seguimiento del presente acuerdo deberán detallarse en un Anexo. junto con los responsables de medición.1.1. 7. la celebración de otro. técnico. o hasta un mes antes de finalizada la vigencia del presente acuerdo. Satisfacción del cliente. Penalidades para el CLIENTE 5. 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. Se clasificarán en: 5. A través de estos indicadores se medirán los servicios que el proveedor está prestando. El CLIENTE deberá brindar las condiciones para que el PROVEEDOR pueda dar el servicio de acuerdo al nivel de calidad acordado.2. 7. En ambos casos. Lic. La parte afectada por un evento de caso fortuito o fuerza mayor. Se definirán los reportes de monitoreo.3. 6. 7.Sistemas de Información Gestión de Proyectos Informáticos Prof. Finalizada. procedimientos y políticas de la compañía dictadas o a dictarse por el sector competente y que resulte aplicable.1. RESPONSABILIDADES 7. 7. el tablero de mando y los indicadores que lo componen. CALIDAD DEL SERVICIO 6. la firma del presente acuerdo. valores de referencia.2. La parte afectada actuará de buena fe para solucionar la causa de retraso o falla.3. El CLIENTE se reserva el derecho de realizar las encuestas de satisfacción a clientes (internos y/o externos) que estime necesarias. de conformidad con las disposiciones de la normativa vigente. El PROVEEDOR tomará las precauciones necesarias para evitar daños en los espacios y áreas operativas.3. funcional. El presente acuerdo tendrá vigencia por un período de __________ a partir de la fecha de su suscripción.2. VIGENCIA 9. Se identificarán aquellos indicadores correspondientes a la performance de los aspectos técnicos del sistema y al soporte (a usuarios. Las PARTES se comprometen a divulgar en los sectores intervinientes . en su caso. 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.

correspondencia.1.Sistemas de Información Gestión de Proyectos Informáticos Prof. ingeniería. Roberto García 9. 14. cualquiera de las PARTES optase por denunciar el Acuerdo comunicándolo fehacientemente a la otra.1. 13.1. CESIÓN DEL ACUERDO 12.1. Incumplimiento de las cláusulas detalladas precedentemente se elevará al Organismo de Control.. RESOLUCIÓN DEL ACUERDO. INCUMPLIMIENTO. datos técnicos. la petición de rescisión del presente acuerdo. se pacta que: cesará la vigencia de este Acuerdo. 14. En caso que fuera necesario se firmará un Acuerdo de Confidencialidad de la información.3. referida a los sistemas. Las PARTES no podrán transferir ni ceder en todo o en parte. el CLIENTE deberá intimar al PROVEEDOR a subsanar la situación en un plazo que de acuerdo a la circunstancia resulte razonable.1.2. 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. El PROVEEDOR garantizará todo defecto atribuible a su intervención por un período acordado por las PARTES medido en días corridos. En el caso de incumplimiento de obligaciones estipuladas en este acuerdo (con respecto a los plazos e indicadores).1. si existiere una situación no prevista que altere significativamente la voluntad bilateral articulada en el presente. En tal sentido.1. dentro de los ______ días de serle notificada aquella situación. o consecuencia derivada de éste. Falta de pago 13. CONDUCTAS FRAUDULENTAS 11. Ante situaciones de: 13.2. comercial. Como excepción al plazo de vigencia fijado en el punto anterior. GARANTÍAS SOBRE LAS INTERVENCIONES 10.1. La información resultante deberá ser clasificada según la categorización de la empresa. contados a partir del momento en que el CLENTE verifique el normal funcionamiento del servicio intervenido. las PARTES se comprometen a tratar en forma confidencial toda información técnica. Las PARTES acuerdan trabajar estrechamente y en forma conjunta para combatir el uso fraudulento del servicio objeto del presente acuerdo. CONFIDENCIALIDAD 14. registros comerciales. el presente acuerdo.2. etc. ORGANISMO DE CONTROL. listas de clientes.2. Toda la información que sea intercambiada en virtud del presente. 13. datos sobre costos. a título gratuito u oneroso. 14. Disolución del sector 13. será tratada en forma confidencial. salvo expresa autorización formal por parte de la otra PARTE.2. 166 de 181 .3.1. y ante ello. que resulte de la solicitud de cualquiera de las PARTES. Lic.

..Sistemas de Información Gestión de Proyectos Informáticos Prof...... revisión o consecuencias del mismo......... aplicación.............................. Se designa como Organismo de Control. se elevará al Organismo de Control la petición de arbitraje correspondiente........................... 167 de 181 ...….........1............... a todos los efectos que diere lugar el presente acuerdo a ..1.... que no pudieran resolverse mediante negociaciones amigables entre las PARTES.......... Sin embargo ante cualquier controversia o reclamo relativo a la interpretación... Roberto García 15.. COMPETENCIA 16......... Lic.... Las PARTES se comprometen a cumplir el presente acuerdo de buena fe.

Lic.Sistemas de Información Gestión de Proyectos Informáticos Prof. 168 de 181 . 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.

Lic. Roberto García Anexo XXX Cuestionarios 169 de 181 .Sistemas de Información Gestión de Proyectos Informáticos Prof.

Roberto García Cuestionario C1: Identificación de objetivos FINALIDAD: identificar las exigencias del Cliente y organizar / planificar las actividades.1.1.Sistemas de Información Gestión de Proyectos Informáticos Prof. APLICACIÓN: se completa con el Dueño del Proceso en el fin de la fase Planeamiento. Lic.) que se utilizarán en el trabajo. Cuestionario C1 Identificación de objetivos Fecha: Nombre entrevistado: Proceso: del Unidad organizativa: Requisitos: Resultados previstos: Instrumentos:    7.). etc. etc.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. Instrumentos: Los instrumentos (Cuestionarios. documentos varios. DESCRIPCIÓN: relevar esquemáticamente las informaciones relacionadas a una descripción formal de las exigencias del Cliente y a los resultados previstos. 170 de 181 .

. A21: Definido 4 A13: Conocimiento parcial en evolución A27: Conocimiento consolidado . una acción de reingeniería. o “NA” (No Aplicable: si la pregunta no tiene sentido en el contexto analizado). etc. 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... Lic. una reestructuración organizativa. tienen los conocimientos sobre el mismo consolidados (individualmente o por (sub)grupos). (está relacionado con el nivel objetivo). aunque no estén documentados.2 DESCRIPCIÓN Nro. . El tiempo final puede ser.. 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? ¿Existen algunos documentos (mapa / esquema representativo) que contienen una descripción (aunque sea resumida / esquemática) del P? 171 de 181 Atributo de Referencia A01: Existente A11: Identificado 2 ¿Piensa que el P fue ejecutado por lo menos una vez? 3 ¿Piensa que el P tiene una secuencia operativa identificable? ¿Piensa que existe conocimiento acerca del P? A02: Teórico A03: Parcialmente realizado A12: Realizado de hecho . en cambio. En este caso la Metodología debe medir la distancia entre la madurez del proceso actual y la misma del proceso objetivo. Roberto García Cuestionario C2: Nivel Objetivo / Supuesto del Proceso FINALIDAD: determinar el “perfil” del Nivel Objetivo / Supuesto del proceso examinado.Sistemas de Información Gestión de Proyectos Informáticos Prof. DESCRIPCIÓN: el cuestionario retoma los atributos de los niveles de un proceso.1. los ordena lógicamente y los traduce en preguntas a proponer al entrevistado para evaluar el perfil del nivel objetivo / supuesto. 5 ¿Piensa que existe una estabilización en el P? A23: Estabilizado 6 ¿Piensa que el P está documentado? A14: Documentación existente pero parcial . 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”. 7.. 1 Pregunta ¿Piensa que Proceso (P) existe? el Descripción ¿El P tiene un nombre (A01)? ¿Conoce los limites (cuando empieza y cuando termina)(A11)? ¿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? ¿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. Se reserva un espacio de “Notas” para eventuales consideraciones (a solicitar)..”NO”. Las posibles respuestas a las preguntas del cuestionario C2 son: “SÍ”. Las preguntas se deben referir al tiempo final (instancia a la cual el dueño piensa alcanzar el objetivo) identificado con el Dueño..1.. El perfil objetivo identificado puede coincidir con uno de los niveles definidos o ser intermedio entre dos o más de estos. el momento que el Dueño define como objetivo para efectuar una acción de mejora.

su secuencia.. 9 ....Sistemas de Información Gestión de Proyectos Informáticos Prof. Roberto García Nro.. las responsabilidades.. A28: Represtación univoca del P ...... Lic. 10 ¿Las modalidades operativas...... los input / output? Atributo de Referencia A22: Representado gráficamente en forma esquemática A26: Existe una norma . 7 Pregunta ¿Esta representación del P piensa que está estructurada? ¿Existe una norma que establece reglas / lineamientos / regulaciones para el P? ¿Esta representación del P está reconocida como válida por el Management? ¿Piensa que existen algunos Procedimientos que describan el P? ¿Piensa que hay una revisión / actualización de estos Procedimientos? ¿Piensa que estos Procedimientos y el P están alineados? Descripción ¿Este mapa / esquema contiene las actividades. los roles... A36: Procedimientos reconocidos y oficializados por el Management 12 13 ¿Los Procedimientos del P están reconocidos y oficializado por el Management? ¿Piensa que todos los que trabajan en el P utilizan (conocen) los Procedimientos? ¿El Management de la organización saben que existen estos procedimientos?¿Estos procedimientos tienen un circuito de aprobación oficial? 14 15 ¿Piensa que conocimiento consensuado? el está 16 ¿Piensa que toda la información necesaria para el trabajo del P está disponible para las personas involucradas en el P? ¿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? . A34: Alineación (información compartida) entre las unidades organizacionales involucradas en el Proceso 172 de 181 . y los instrumentos usados para realizar el P están descriptas? A24: Actividades estructuradas en Procedimientos 11 ¿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 los procedimientos y el P . A32: Conocimiento difundido A33: Conocimiento consensuado .. 8 .

7. ”NO”. Cuestionarios por la evaluación de los Operativos Cuestionario C3: Nivel Actual del Proceso FINALIDAD: identificar el “perfil” del nivel actual del Proceso examinado. no univoco”. Roberto García Nro. “Parcialmente / Si. 17 Pregunta ¿Piensa que Resultados repetibles? los son Descripción ¿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? ¿Cuales son y cual es su fin? Atributo de Referencia A31: Sistemático (repetitivo).1. Las posibles respuestas son: “SÍ”. 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.Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic.1. Pregunta Descripción 173 de 181 Atributo de Referencia . 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. 18 ¿Piensa que se puede efectuar un seguimiento sobre las fases del P? ¿Hay algunos Indicadores internos de la performance del P? ¿Piensa que estos Indicadores son controlados constantemente? A38: Se puede efectuar un seguimiento sobre las fases del P A41: Hay indicadores internos 19 20 21 ¿Hay una gestión que persiga el mejoramiento basada en la performance observada en los indicadores? ¿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 A44: Gestionado estratégicamente. o “NA” (No Aplicable: si la pregunta no tiene sentido en el contexto analizado). APLICACIÓN: se compila con los personales operativos del Proceso en la fase Relevamiento.3 DESCRIPCIÓN Nro.

. su secuencia. los roles. 7 ¿Esta representación del P está estructurada? ¿Existe una norma que establece reglas / lineamientos / regulaciones para el P? ¿Esta representación del P está reconocida como válida por el Management? ¿Existen algunos Procedimientos que describan el P? ¿Hay una revisión / actualización de estos Procedimientos? ¿Estos Procedimientos y el P 8 ... Roberto García Nro.. 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? ¿Existen algunos documentos (mapa / esquema representativo) que contienen una descripción (aunque sea resumida / esquemática) del P? ¿Este mapa / esquema contiene las actividades.. y los instrumentos usados para realizar el P están descriptas? ¿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)? 174 de 181 A24: Actividades estructuradas en Procedimientos A37: Hay revisión y actualización (mantenimiento) de los procedimientos A25 Coherencia entre los procedimientos A35: Coherencia entre 11 12 . 9 ..Sistemas de Información Gestión de Proyectos Informáticos Prof... 5 ¿Existe una estabilización en el P? A23: Estabilizado 6 ¿El P documentado? está A14: Documentación existente pero parcial . tienen los conocimientos sobre el mismo consolidados (individualmente o por (sub)grupos)..... las responsabilidades.. Lic. A22: Representado gráficamente en forma esquemática A26: Existe una norma ... aunque no estén documentados. A28: Represtación unívoca del P . 1 Pregunta ¿El Proceso existe? (P) Descripción ¿El P tiene un nombre (A01)? ¿Conoce los limites (cuando empieza y cuando termina)(A11)? ¿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? ¿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. los input / output? Atributo de Referencia A01: Existente A11: Identificado 2 ¿El P fue ejecutado al menos una vez? 3 ¿El P tiene una secuencia operativa identificable? ¿Existe conocimiento acerca del P? A02: Teórico A03: Parcialmente realizado A12: Realizado de hecho . A21: Definido 4 A13: Conocimiento parcial en evolución A27: Conocimiento consolidado .. 10 ¿Las modalidades operativas....

. A36: Procedimientos reconocidos y oficializados por el Management 13 ¿Los Procedimientos del P están reconocidos y oficializado por el Management? ¿Todos los que trabajan en el P utilizan (conocen) los Procedimientos? ¿El Management de la organización saben que existen estos procedimientos?¿Estos procedimientos tienen un circuito de aprobación oficial? 14 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? ¿Los Resultados son repetibles? ¿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? . A32: Conocimiento difundido A33: Conocimiento consensuado . Roberto García Nro.Sistemas de Información Gestión de Proyectos Informáticos Prof.... Lic. 17 18 ¿Se puede efectuar un seguimiento sobre las fases del P? ¿Hay algunos Indicadores internos de la performance del P? ¿Estos Indicadores son controlados constantemente? ¿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? ¿Cuales son y cual es su fin? 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 A41: Hay indicadores internos 19 20 ¿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 .. Pregunta están alineados? Descripción Atributo de Referencia los procedimientos y el P ..

176 de 181 .Sistemas de Información Gestión de Proyectos Informáticos Prof. 21 Pregunta ¿Hay una gestión que persiga el mejoramiento basada en la performance observada en los indicadores? Descripción ¿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? Atributo de Referencia A44: Gestionado estratégicamente. Roberto García Nro. Lic.

eventualmente. 34 Ver Anexo: Cuestionarios 177 de 181 . APLICACIÓN: se completa con los Notas: 32 33 Ver Anexo: Cuestionarios Ver párrafo siguiente. porque se refiere a la Gestión Estratégica) en la Fase: Relevamiento. DESCRIPCIÓN: identifica el grado de “dominio (control) sobre del proceso a través de indicadores”. 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.Nivel 4 PARTE II (Dueños) 34 33 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). 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.Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. La descripción de cada pregunta se presenta en gris en la tabla. La descripción de cada pregunta se presenta en gris en la tabla. El cuestionario tiene la finalidad de identificar las características del Proceso actual y. de evaluar el grado de las mismas a través de la visión del personal operativo entrevistado. Cuestionario C4 . DESCRIPCIÓN: hay un cuestionario C4 por cada nivel objetivo.

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

etc). Definirán un área funcional Actor BD BE (Eventos de Negocios) Big Bang Modalidad de puesta en producción que se realiza para todos los clientes. Productos. threat) Data base CPU DAFO DB 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. Están compuestas por la condición que se va a probar y los resultados esperados de alto nivel asociados. en forma conjunta Error en algún módulo del sistema Plan que considera inversiones. Son funcionalidades que ofrece un sistema para ingresar. Definirán un área funcional 179 de 181 Eventos de Negocios (BE) . gastos iniciales. upgrades. Condición de Prueba de más alto nivel. Derivan de los requerimientos funcionales y del usuario. eliminar y actualizar registros. Fortalezas. líneas. roll out Despliegue DTC Derivan de los requerimientos funcionales y del usuario. Roberto García GLOSARIO ABM Altas. Oportunidades que se realiza para un proyecto (en inglés SWOT: strong. oportunity. Implantación. mantenimiento de la aplicación.Sistemas de Información Gestión de Proyectos Informáticos Prof. etc. weak. Coordinador Persona encargada de coordinar y llevar adelante todas las tareas dentro de una etapa Procesador de la computadora (Central Processing Unit) Análisis de Debilidades. capacitación. Amenazas. Lic. Sumarizadas de Pueden describir funcionalidades (ej: suspensión – conexión) o categorías (ej: Prueba (STC) Clientes. Bajas y Modificaciones. Persona que interviene y participa en la elaboración de las distintas actividades definidas dentro de una tarea o fase Base de Datos Condición de Prueba de más alto nivel. Están compuestas por (Condiciones de la condición que se va a probar y los resultados esperados de alta nivel Detalle de asociados. etc. Bug Business Plan Condiciones de Detalle de Prueba (DTC) Condiciones Representan agrupaciones lógicas de condiciones de detalle de prueba. generalización. Prueba) Entregables Son los documentos que se obtienen como resultado de la ejecución de las tareas.

roll out Implica verificar que el conjunto de los desarrollos cubran los requerimientos de negocio predefinidos. Lic. Asegurar que cada punto de decisión sea pasado con su valor mínimo. Roberto García FCE Generalización GST (Global System Test) Hito Factores Claves de Éxito. Evaluar periódicamente la realización total del proyecto para asegurar que se cumplen los estándares de calidad establecidos para el proyecto. Punto de control que aparece al final de cada fase. 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. máximo y algún valor intermedio. Existen dos clases: – Hito GO / NO GO: son aquellos donde se determinan la continuidad o no del proyecto. despliegue Es solo un conjunto de archivos relacionados entre sí. que puede estar guardado en cualquier soporte magnético (disco rígido.Sistemas de Información Gestión de Proyectos Informáticos Prof. Mega Bits Implantación In house Legacy Llave en mano MBs 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 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. Persona encargada de llevar adelante las tareas a su cargo Actividad que puede ser desarrollada por una persona o un grupo de personas Implantación. Implantación. – Hito de validación: son aquellos que permiten validar y controlar la realización de las tareas y de los entregables de una fase. Para que este 180 de 181 Proyecto Prueba Caja Blanca Prueba Caja Negra QA (Quality Assurance) Responsable Rol Roll Out Sitio Web . Asegurar que todas las condiciones de error que el módulo debe detectar sean correctamente ejecutadas. 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. cd. despliegue.. generalización.. despliegue. etc. Generalización. roll out Paquete cerrado. Aseguramiento de la calidad.). desarrollos propios Sistemas ya existentes en la Cía 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.

(de un sistema) Se refiere a los volúmenes de información. Es decir un servidor conectado a Internet y que tiene como función servir páginas web. contiene un website determinado. es decir que hace posible que un sitio se pueda visualizar navegando la web. en el caso del web hosting.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». junto con el VAN. Sitio Web VAN Volumetría Web Hosting Web Server Web Site 181 de 181 . (Condiciones Pueden describir funcionalidades (ej: suspensión – conexión) o categorías (ej: Sumarizadas de Clientes. El servicio de web hosting brinda la posibilidad de «publicar» un sitio en la Web. SLA SO (Service Level Agreement) Compromiso de nivel de servicio Sistema Operativo STC Representan agrupaciones lógicas de condiciones de detalle de prueba. Productos. El nombre de un espacio dentro de un servidor. Prueba) TIR Tasa Interna de Retorno. Dado que Internet es una red gigante de servidores conectados entre sí. transacciones y tráfico en general que es capaz de manejar un sistema en situaciones normales y picos. junto con el TIR determinar la rentabilidad de un proyecto. es un conjunto de números que conforman una dirección IP única. Indicador económico que ayuda. a determinar la rentabilidad de un proyecto Valor Anual Neto. Indicador económico que permite. Esta dirección permite identificar unívocamente a ese espacio que. es necesario que cada website tenga una identidad propia (un nombre) para poder ser ubicado. en el lenguaje de Internet. etc).

Sign up to vote on this title
UsefulNot useful