Beruflich Dokumente
Kultur Dokumente
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
EL SOFTWARE ............................................................................................................................ 6
RESPONSABILIDADES ............................................................................................................. 12
3 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
OBJETIVO Y ALCANCE
OBJETIVO
El objetivo de esta publicación es generar una guía para la gestión de proyectos informáticos
basados en el desarrollo de software y brindar un enfoque práctico para establecer los
lineamientos generales, el marco metodológico y los responsables en la gestión de un proyecto
a lo largo de todo el ciclo de vida del mismo..
Pretende servir a estudiantes y profesionales, brindando una introducción completa al tema de
la ingeniería de software.
El formato y estilo de esta primera edición está orientada tanto a los aspectos teóricos, como a
los prácticos; ya que se incluye fichas y documentos que se utilizan en los proyectos de
desarrollo de software.
ALCANCE
El alcance de esta guía abarca los aspectos metodológicos involucrados desde la identificación
de necesidades y la consecuente creación del proyecto hasta la puesta en producción del
software, incluyendo su administración y soporte.
Como vehículo para hacer entrega del producto actúa como la base de control de una PC
(Sistema Operativo), la comunicación de información (Redes) y creación y control de otros
programas (Entornos y herramientas de programación).
Es por ello que quienes estamos en el área de la enseñanza, debemos orientar y ayudar a
quienes quieren ser expertos en esta profesión fascinante a contextualizar el concepto de
“arte”.
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.
4 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
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.
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.
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.
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.
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.
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.
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.
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.
7 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
Con el propósito de generar una metodología que acompañe el esfuerzo del ingeniero del
software en la creación de aplicaciones a continuación se presenta la estructura de la misma.
Niveles de Desagregación
Esta guía propone 3 niveles de desagregación, donde la entidad FASE es la que reviste mayor
peso como entidad. Las etapas comprendidas en cada fase, se desarrollan en forma
secuencial, mientras que las tareas de una misma, pueden ejecutarse en forma paralela.
FASE
ETAPA
TAREA
FASES ETAPAS
I
M PREPARACIÓN
P IMPLANTACIÓN
L
A
N
T PUESTA EN
A PRODUCCIÓN
C
I
O
FORMALIZACIÓN
N
PUESTA EN
PRODUCCIÓN
HITO 5 :
SISTEMA EN PRODUCCIÓN
8 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
NOM BRE
Descripción de la Necesidad
OBJETIVO
Describir el objetivo y alcance de la necesidad de un nuevo
sistema o una modificación
CONTENIDO
Proyecto:...............................................................................................
Responsable:.........................................Sector:......................................
Participantes:.........................................................................................
RESPONSA BLE
Líder Funcional
Hitos
En la finalización de la mayoría de las fases, se desarrollan tareas de revisión, análisis,
aprobación y/o convalidación de los principales entregables de las mismas. Estas tareas, por su
relevancia, determinan en sí mismas el cierre de la fase.
Luego del cierre de la fase y considerando el resultado global de la misma, se conforma una
instancia de validación.
9 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
EL ESPECTRO DE LA GESTIÓN
La gestión eficaz de un proyecto de software se centra en las tres „pes‟: personal, problema y
proceso.
Personal
El modelo de Madurez de gestión de personal define las siguientes áreas prácticas clave para
el personal que desarrolla soft:
Reclutamiento
Selección
Gestión de rendimiento
Entrenamiento
Retribución
Desarrollo de la carrera
Diseño de la organización y del trabajo
Desarrollo cultural y espíritu de equipo.
Los participantes
El proceso del software lo componen participantes que pueden clasificarse en una de cinco
categorías:
1. Gestores superiores
2. Gestores (técnicos) del proyecto
3. Profesionales
4. Clientes
5. Usuarios finales
Para ser eficaz, el equipo del proyecto debe organizarse de manera que maximice las
habilidades y capacidades de cada persona. Éste es el trabajo del jefe del equipo.
El equipo de software
La mejor estructura de equipo depende del estilo de gestión de una organización, el número de
personas que compondrá el equipo, sus niveles de preparación y la dificultad general del
problema. Se sugieren tres organigramas de equipo genéricos:
Descentralizado democrático DD). No tiene un jefe permanente, se nombran
coordinadores de tareas a corto plazo. La comunicación entre los miembros es
horizontal.
Descentralizado controlado (DC). Tiene un jefe definido que coordina tareas y jefes
secundarios con responsabilidades sobre sub tareas. Comunicación entre subgrupos e
individuos es horizontal. Vertical a lo largo de la jerarquía de control.
Centralizado controlado (CC). El jefe del equipo se encarga de la resolución de
problemas a alto nivel y la coordinación interna del equipo. La comunicación entre el
jefe y los miembros es vertical.
10 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
Cabe destacar, que independientemente de los roles específicos, cada integrante del equipo
del proyecto deberá garantizar el cumplimiento de las normas de la empresa.
EQUIPO DE PROYECTO
El siguiente diagrama describe una propuesta genérica de la constitución del Equipo del
Proyecto. Cabe señalar, que el Comité Director definirá la organización particular para cada
proyecto, de acuerdo a la envergadura del mismo.
11 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
LÍDER LÍDER
Q FUNCIONAL INFORM ÁTICO
U
A
L EXPERTO EN
EXPERTO
I PROCESOS DE U
RESPONSABLE INFORM ÁTICO
T NEGOCIO S
SOPORTE AL
Y U
CAM BIO EXPERTO
RESPONSABLE A
SEGURIDAD R
CAPACITACIÓN
A EXPERTO EN INFORM ÁTICA I
S CALIDA D O
EXPERTO
S EXPERTO S
ECONÓM ICO/
U TECNOLÓGICO
FINA NCIERO ADM INISTRA DOR
R F
FUNCIONAL
A PROVEEDOR I
N EXPERTO EN N
(INTERNO o
C REDES A
EXTERNO)
E L
EQUIPO DE IM PLANTACIÓN E
S
SOPORTE SOPORTE
USUARIOS ADM INISTRA DOR APLICATIVO
FUNCIONAL
SOPORTE SOPORTE
FUNCIONAL SOPORTE SEGURIDAD
TÉCNICO
EQUIPO DE PRODUCCIÓN
RESPONSABILIDADES
COMITÉ DIRECTOR
Integrado por los responsables ejecutivos de las áreas funcionales, informáticas y de calidad.
Sus principales responsabilidades son:
COMITÉ EJECUTIVO
Integrado por los roles Owner del Proyecto, Responsable Funcional, Responsable Informático y
los Usuarios Finales. Sus principales responsabilidades son:
12 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
EQUIPO DE IMPLANTACIÓN
Integrado por los roles Líder Funcional, Líder Informático, Responsable de Soporte al Cambio,
Responsable de Capacitación, Experto tecnológico, Experto informático, Experto en Procesos
de Negocio, Experto Económico/Financiero, Experto en Calidad, Experto en Seguridad
Informática, Experto en Redes, Administrador Funcional y el Proveedor (Interno o Externo). Sus
principales responsabilidades son:
- Generar y ejecutar el diseño global y detallado, los análisis técnicos y funcionales, los
planes de trabajo y estrategias de implantación.
- Informar el avance del proyecto al Comité Ejecutivo.
- Implementar bajo la coordinación del Líder Informático, los elementos informáticos
(hardware, software de base y de aplicación, redes, capacitación técnica).
- Poner en marcha los nuevos procedimientos definidos bajo la responsabilidad del Líder
Funcional.
EQUIPO DE PRODUCCIÓN
Integrado por los roles Administrador Funcional, Soporte Usuarios, Soporte Funcional, Soporte
Técnico, Soporte en Seguridad y Soporte Aplicativo. Sus principales responsabilidades son:
RESPONSABLE FUNCIONAL
Sus principales responsabilidades son:
- Asesorar al Comité Director con respecto a las decisiones estratégicas vinculadas con la
funcionalidad del Sistema y con sus aspectos económicos.
- Coordinar esfuerzos de todos los servicios involucrados en el Proyecto.
- Establecer los recursos funcionales requeridos para el Proyecto, y elevar necesidades
respecto a los recursos no funcionales necesarios para el éxito del Proyecto.
- Participar de la definición de esquemas de acceso, seguridad y controles.
- Validar tareas de prueba piloto e implantación.
13 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
- Garantizar la coherencia global del Sistema desde el punto de vista funcional (definiendo
procedimientos funcionales, evaluando impactos en la Organización, etc.).
- Junto al Usuario final evaluar beneficios e impactos del Proyecto (en procesos y sistemas)
en áreas usuarias priorizando las necesidades.
- Definir los lineamientos generales del Plan de Capacitación del Sistema junto al
Responsable Informático.
- Validar el Business Plan del Proyecto.
- Definir y revisar el Acuerdo de Servicio de Proyecto en conjunto con el Responsable
Informático.
- Participar en el aseguramiento de la logística necesaria para soportar el Sistema.
- Identificar, en conjunto con el Usuario Final, los impactos organizacionales que genera un
cambio de Sistemas/Procesos, la población afectada y el dimensionamiento respecto de las
tareas, competencias y localizaciones necesarias previas al cambio.
LÍDER FUNCIONAL
Sus principales responsabilidades son:
- Preparar las especificaciones funcionales y los requerimientos del Usuario para los
Sistemas en desarrollo.
- Administrar y documentar los requerimientos de acceso, seguridad y controles.
- Validar diseños funcionales y detallados.
- Asegurar la capacitación de los usuarios finales
- Participar y aprobar de las pruebas del producto.
- Supervisar al equipo de implantación en sus aspectos funcionales.
- Coordinar la prueba piloto desde el punto de vista funcional, organizacional, participar de la
logística (elegir sitios pilotos y su preparación)
- Coordinar los soportes funcionales locales y la asistencia funcional.
- Fijar objetivos de explotación y seguimiento.
- Evaluar, en la fase de Prueba, si las aplicaciones y entorno satisfacen los requerimientos
funcionales.
- Interactuar principalmente con el Responsable Funcional y Líder informático.
- Elaborar el Business Plan del Proyecto junto al Responsable Funcional.
- Participar en la elaboración de los manuales de usuarios
RESPONSABLE INFORMÁTICO
Sus principales responsabilidades son:
14 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
LÍDER INFORMÁTICO
Sus principales responsabilidades son:
- Garantizar que el Proyecto, desde el punto de vista informático se realice en tiempo y forma
cumpliendo los objetivos y planes de trabajo aprobados por el Comité Ejecutivo.
- Definir la arquitectura informática y el desarrollo del Sistema.
- Nexo con los proveedores involucrados, intermediando entre estos y el Líder Funcional.
- Asegurar capacitación informática del equipo de implantación.
- Garantizar el cumplimiento de los aspectos informáticos del proyecto (requerimientos,
desarrollo, etc.)
- Definir las especificaciones detalladas del nuevo Sistema o producto.
- Definir los ambientes de desarrollo, prueba, capacitación y operación del Sistema.
- Asegurar la logística informática necesaria para soportar el Sistema y sus sucesivas
versiones.
- Definir desarrollo de adecuaciones necesarias para soportar las especificaciones
funcionales recibidas y las de integración con otros Sistemas existentes y/o planificados.
- Monitorear el avance y calidad de las tareas e informar y corregir los desvíos.
- Organizar el Proyecto y preparar los planes de trabajo.
- Interactuar principalmente con el Responsable Informático y el Líder Funcional.
USUARIO FINAL
Sus principales responsabilidades son:
QUALITY ASSURANCE
Sus principales responsabilidades son:
- Analizar y definir las acciones necesarias para abordar el impacto organizacional generado
por la implementación del Proyecto.
- Plan de Distribución Dotacional
- Plan de Comunicación
RESPONSABLE CAPACITACIÓN
Sus principales responsabilidades son:
15 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
EXPERTO TECNOLÓGICO
Este rol estará llevado a cabo por un grupo de expertos de distintas especialidades.
Sus principales responsabilidades son:
- Asegurar que el sistema a implantar respete los lineamientos del Plan Tecnológico de la
Compañía.
- Participar de los estudios de mercado, del análisis de productos y de la identificación de
alternativas.
- Colaborar en las pruebas en maqueta.
- Garantizar la coherencia tecnológica de las ofertas presentadas por los proveedores
respecto de la tecnología actual y proyectada.
EXPERTO INFORMÁTICO
Este rol estará llevado a cabo por un grupo de expertos de distintas especialidades.
Sus principales responsabilidades son:
16 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
EXPERTO EN CALIDAD
El experto en calidad es la persona responsable de asegurar la orientación del proyecto hacia
los clientes
Sus principales responsabilidades son:
EXPERTO ECONÓMICO/FINANCIERO
Sus principales responsabilidades son:
EXPERTO EN REDES
Este rol estará llevado a cabo por un grupo de expertos de distintas especialidades.
Sus principales responsabilidades son:
- Evaluar el impacto que produce incorporar un nuevo flujo de datos, en equipos y vínculos
de comunicación.
- Definir los protocolos de comunicación, las rutas básicas y alternativas, los anchos de
banda requeridos, los mecanismos de backup para routers y vínculos, y los sistemas de
estadísticas para monitoreo del estado de salud de la red.
ADMINISTRADOR FUNCIONAL
Las funciones y responsabilidades del Administrador Funcional están descriptas en el Manual
de Normas y Procedimientos vigentes de la Compañía.
En general, sus principales responsabilidades son:
SOPORTE USUARIOS
Sus principales responsabilidades son:
SOPORTE FUNCIONAL
Sus principales responsabilidades son:
SOPORTE TÉCNICO
Normalmente, este rol estará soportado por un grupo de especialistas de distintas disciplinas y
sectores.
Sus principales responsabilidades son:
17 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
SOPORTE APLICATIVO
Sus principales responsabilidades son:
SOPORTE SEGURIDAD
Este rol estará soportado por un grupo de especialistas de distintas disciplinas y sectores. Sus
principales responsabilidades son:
Notas:
1 La administración y control del proyecto deberán ser profundizados en la 2° etapa junto con la definición de las
herramientas comunes a utilizar para la administración y control.
18 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
INTODUCCIÓN A LA METODOLOGÍA
Definimos un proceso de software como un marco de trabajo de las fases, etapas y tareas que
se requieren para construir software de alta calidad.
19 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
Para determinar el estado actual de madurez del proceso, el SEI (Software Engineering
Institute) utiliza un cuestionario de evaluación y esquema de cinco grados (Ver Cuestionario en
anexo xx):
Nivel 1: Inicial.- Se definen pocos procesos, y el éxito depende del esfuerzo individual.
El SEI ha asociado las ACP a cada uno de los niveles de madurez. Cada ACP se describe
identificando las características siguientes:
Objetivos
Compromisos (requisitos para lograr los objetivos)
Capacidades (elementos que deben encontrarse)
Actividades (tareas especificas)
Métodos para supervisar la implementación
Métodos para verificar la implementación
20 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
Desarrollo.
La orientación del diseño debe alcanzar documentación que permita traducir los requerimientos
funcionales a programas.
Implementación. Una vez que se ha generado un código, debe efectuarse las pruebas de los
programas. El proceso de pruebas se centra en los procesos lógicos internos del software.
Asimismo se incluye las actividades de capacitación e implementación, que se apoya en las
estrategias diseñadas en la fase de diseño.
21 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
EL MODELO DRA
Modelo en espiral
Es un modelo de proceso evolutivo que acompaña la naturaleza interactiva de la construcción
de prototipos con los aspectos del modelo lineal secuencial.
El modelo en espiral se divide en actividades estructurales, también llamadas regiones de
tareas:
Comunicación con el cliente
22 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
TECNOLOGÍA DE PROCESOS
Los modelos de procesos tratados se deben adaptar para utilizarse por el equipo de proyecto.
Para conseguirlo, se han desarrollado herramientas de tecnología de procesos que permiten
que una organización de software construya un modelo automatizado de la estructura común
del proceso, conjuntos de tareas y actividades de protección.
PRODUCTO Y PROCESO
Las personas obtienen tanta satisfacción del proceso creativo que del producto final. La
dualidad de producto y proceso es un elemento importante para mantener ocupada a la gente
creativa hasta que se finalice la transición de la programación a la ingeniería del software.
23 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
DIAGRAMA RESUMEN
En esta primera aproximación del modelo, se presenta un esquema resumen con las fases
generales y los hitos de continuación o detención (go no-go) del proyecto.
Dentro del ciclo de vida del proyecto, se debe generar dos contratos:
24 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
DIAGRAMA DE FASES
A continuación, se presenta un diagrama completo con todas las fases de un proyecto, los hitos
go, no-go, y de control y los acuerdos y contratos de servicio.
25 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
26 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
D
N
E
E
S
C
C
E - Identificar Necesidades
R S DESCRIPCIÓN - Relevamiento Global Líder
I - Descripción de la Necesidad
I NECESIDADES - Descripición de Objetivos y Alcance Funcional
P - Especificar Requerimiento
D
C
A
I
D
Ó E
N
S
de
- Carta de Decisión
HITO 0: APROBACIÓN PROYECTO - Acuerdo de Servicio
El objetivo de las fases Descripción de las necesidades y el Estudio preliminar del Sistema es el análisis
de un conjunto concreto de necesidades para proponer una solución a corto plazo, que tenga en cuenta
restricciones económicas, técnicas, legales y operativas.
La solución obtenida como resultado del estudio será la definición de uno o varios proyectos que afecten a
uno o varios sistemas de información ya existentes o nuevos.
Para ello, se identifican los requisitos que se ha de satisfacer y se estudia, si procede, la situación actual.
27 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
A partir del estado inicial, la situación actual y los requisitos planteados, se estudian las alternativas de
solución.
Dichas alternativas pueden incluir soluciones que impliquen desarrollos a medida, soluciones basadas en
la adquisición de productos software del mercado o soluciones mixtas. Se describe cada una de las
alternativas, indicando los requisitos que cubre.
Una vez descritas cada una de las alternativas planteadas, se valora su impacto en la organización, la
inversión a realizar en cada caso y los riesgos asociados. Esta información se analiza con el fin de evaluar
las distintas alternativas y seleccionar la más adecuada, definiendo y estableciendo su planificación.
Descripción de Necesidades
Identificar Necesidades
Relevamiento Global
Descripción de Objetivos y Alcances
Especificar Requerimientos.
Estudio Preliminar
Alineamiento al Plan Maestro de Sistemas
Alineamiento al Plan Tecnológico
Alineamiento al Plan Estrategico
Identificación de Alternativas
Análisis de Factibilidad Técnica
Identificación de la Modalidad del Proyecto
Análisis Impacto del Proyecto
Análisis de Costo Beneficio
Business Plan
Análisis DAFO (Debilidades y Fortalezas)
Identificación de Métricas
Elaboración del Informe Ejectivo del Estudio de Factibilidad
Actualización Plan Maestro
Análisis de Presupuesto
Confección del Acuerdo de Servicio.
28 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
ANÁLISIS
- Análisis Económico - Dictamen Económico Compras
ECONÓMICO
- Acta de Adjudicación
HITO 2: ADJUDICACIÓN - Documento de Compra
El objetivo de este proceso es la obtención de una especificación global del sistema de información que
satisfaga las necesidades de información de los usuarios y sirva de base para el posterior diseño detallado
del sistema.
Se lleva a cabo la descripción inicial del sistema de información, a partir de los productos generados en el
proceso Estudio Preliminar.
Se delimita el alcance del sistema, se genera un catálogo de requisitos generales y se describe el sistema
mediante unos modelos iniciales de alto nivel.
También se identifican los usuarios que participan en el proceso de análisis, determinando sus perfiles,
responsabilidades y dedicaciones necesarias. Así mismo se elabora el plan de trabajo a seguir.
La definición de requisitos del nuevo sistema se realiza con el objetivo de elaborar el catálogo de
requisitos detallado, que permita describir con precisión el sistema de información, y que además sirva de
base para comprobar que es completa la especificación de los modelos obtenidos en las actividades
Identificación de requerimientos
29 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
Para la obtención de requisitos se toman como punto de partida el catálogo de requisitos y los modelos
elaborados en la actividad Definición del Sistema, completándolos mediante sesiones de trabajo con los
usuarios.
Estas sesiones de trabajo tienen como objetivo reunir la información necesaria para obtener la
especificación detallada del nuevo sistema.
Las técnicas que ayudan a la recopilación de esta información pueden variar en función de las
características del proyecto y los tipos de usuario a entrevistar. Entre ellas podemos citar las reuniones,
entrevistas, Joint Application Design (JAD), etc.
Durante estas sesiones de trabajo se propone utilizar la especificación de los casos de uso como ayuda y
guía en el establecimiento de requisitos. Esta técnica facilita la comunicación con los usuarios y en el
análisis orientado a objetos constituye la base de la especificación.
A continuación se identifican las facilidades que ha de proporcionar el sistema, y las restricciones a que
está sometido en cuanto a rendimiento, frecuencia de tratamiento, seguridad y control de accesos, etc.
Toda esta información se incorpora al catálogo de requisitos.
Con la información recopilada, se estructura el sistema de información en subsistemas, para facilitar la
especificación de los distintos modelos y la traza de requisitos.
En paralelo, se generan los distintos modelos que sirven de base para el diseño. En el caso de análisis
estructurado, se procede a la elaboración y descripción detallada del modelo de datos y de procesos, y en
el caso de un análisis orientado a objetos, se elaboran el modelo de clases y el de interacción de objetos,
mediante el análisis de los casos de uso.
Se especifican, asimismo, todas las interfaces entre el sistema y el usuario, tales como formatos de
pantallas, diálogos, formatos de informes y formularios de entrada.
En la actividad impacto de la arquitectura técnica se efectúa el Análisis de Consistencia y Especificación
de Requisitos, se realiza la verificación y validación de los modelos, con el fin de asegurar que son:
- Completos, puesto que cada modelo obtenido contiene toda la información necesaria recogida en
el catálogo de requisitos.
- Consistentes, ya que cada modelo es coherente con el resto de los modelos.
- Correctos, dado que cada modelo sigue unos criterios de calidad predeterminados en relación a
la técnica utilizada, calidad de diagramas, elección de nombres, normas de calidad, etc.).
La participación activa de los usuarios es una condición imprescindible para el análisis del sistema de
información, ya que dicha participación constituye una garantía de que los requisitos identificados son
comprendidos e incorporados al sistema y, por tanto, de que éste será aceptado. Para facilitar la
colaboración de los usuarios, se pueden utilizar técnicas interactivas, como diseño de diálogos y
prototipos, que permiten al usuario familiarizarse con el nuevo sistema y colaborar en la construcción y
perfeccionamiento del mismo.
30 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
- Impacto Organizacional
- Impacto Organizacional
- Estrategia de Implantación
- Estrategia de Implantación
- Plan de Pruebas Funcionales
- Elaboración Plan de Pruebas Funcionales
- Estrategia de Confiabilización
- Estrategia de Confiabilización
DEFINICIÓN - Estrategia de Conversión de Líder
- Estrategia de Conversión de Datos
ESTRATEGIAS Datos Funcional
- Estrategia de Carga de Datos
- Estrategia de Carga de Datos
- Plan Acción para el Cambio
- Plan de Acción para el Cambio
- Plan de Capacitación
- Plan de Capacitación
- Plan de Comunicación
- Plan de Comunicación
31 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
El objetivo de la Fase de Diseño Detallado es la definición de la arquitectura del sistema y del entorno
tecnológico que le va a dar soporte, junto con la especificación detallada de los componentes del sistema
de información.
A partir de dicha información, se generan todas las especificaciones de construcción relativas al propio
sistema, así como la descripción técnica del plan de pruebas, la definición de los requisitos de
implantación y el diseño de los procedimientos de migración y carga inicial, éstos últimos cuando proceda.
En general, el orden real de ejecución de las mismas depende de las particularidades del sistema de
información y, por lo tanto, de generación de sus productos.
Se completan los catálogos de requisitos y normas, en función de la definición del entorno tecnológico, con
aquellos aspectos relativos al diseño y construcción que sea necesario contemplar.
Asimismo, se crea un catálogo de excepciones del sistema, en el que se registran las situaciones de
funcionamiento secundario o anómalo que se estime oportuno considerar y, por lo tanto, diseñar y probar.
Este catálogo de excepciones se utiliza como referencia en la especificación técnica de las pruebas del
sistema.
Los subsistemas de soporte contienen los elementos o servicios comunes al sistema y a la instalación, y
generalmente están originados por la interacción con la infraestructura técnica o la reutilización de otros
sistemas, con un nivel de complejidad técnica mayor.
También se especifica en detalle el entorno tecnológico del sistema de información, junto con su
planificación de capacidades (capacity planning), y sus requisitos de operación, administración, seguridad
y control de acceso.
En el caso de Diseño Orientado a Objetos, conviene señalar que el diseño de la persistencia de los
objetos se lleva a cabo sobre bases de datos relacionales, y que el diseño detallado del sistema de
información se realiza en paralelo con la actividad de Diseño de la Arquitectura de Soporte, y se
corresponde con las siguientes actividades:
Diseño de Casos de Uso Reales.
Diseño de Clases
En el caso de que sea necesario, se realiza la definición de un plan de migración y carga inicial de datos.
32 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
Una vez que se tiene el modelo de clases, se comienza el diseño físico en la actividad Diseño Físico de
Datos.
2.- El segundo bloque de actividades complementa el diseño del sistema de información. En él se generan
todas las especificaciones necesarias para la construcción del sistema de información:
Generación de Especificaciones de Construcción.
Diseño de la Migración y Carga Inicial de Datos
Especificación Técnica del Plan de Pruebas
Establecimiento de Requisitos de Implantación
Fase de Construcción
En este proceso se genera el código de los componentes del Sistema de Información, se desarrollan todos
los procedimientos de operación y seguridad y se elaboran todos los manuales de usuario final y de
explotación con el objetivo de asegurar el correcto funcionamiento del Sistema para su posterior
implantación.
Para conseguir dicho objetivo, en este proceso se realizan las pruebas unitarias, las pruebas de
integración de los subsistemas y componentes y las pruebas del sistema, de acuerdo al plan de pruebas
establecido.
En dicho producto se recoge la información relativa al entorno de construcción del sistema de información,
la especificación detallada de los componentes y la descripción de la estructura física de datos, tanto
bases de datos como sistemas de ficheros. Opcionalmente, incluye un plan de integración del sistema de
información, en el que se especifica la secuencia y organización de la construcción de los distintos
componentes.
Una vez configurado el entorno de construcción, se realiza la codificación y las pruebas de los distintos
componentes que conforman el sistema de información, mediante las siguientes actividades genericas:
Generación del Código de los Componentes y Procedimientos, que se hace según las especificaciones de
construcción del sistema de información, y conforme al plan de integración del sistema de información.
Ejecución de las Pruebas Unitarias, dónde se llevan a cabo las verificaciones definidas en el plan de
pruebas para cada uno de los componentes
Ejecución de las Pruebas de Integración, que incluye la ejecución de las verificaciones asociadas a los
subsistemas y componentes, a partir de los componentes verificados individualmente, y la evaluación de
los resultados.
Una vez construido el sistema de información y realizadas las verificaciones correspondientes, se lleva a
cabo la integración final del sistema de información en la actividad de Pruebas globales (GST),
comprobando tanto las interfaces entre subsistemas y sistemas externos como los requisitos, de acuerdo
a las verificaciones establecidas en el plan de pruebas para el nivel de pruebas del sistema.
En la actividad Elaboración de los Manuales del sistema Usuario, se genera la documentación de usuario
final o explotación, conforme a los requisitos definidos en el proceso Diseño del Sistema de Información.
33 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
La formación necesaria para que los usuarios finales sean capaces de utilizar el sistema de forma
satisfactoria se especifica en la actividad Plan de Capacitación.
34 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
COMIENZA FASE DE
PRODUCCIÓN
B P
A R
L O Líder
A Y BALANCE DEL Funcional -
- Balance del Proyecto - Informe de Cierre del Proyecto
N E PROYECTO Líder
Informático
C C
E T
de O
Este proceso tiene como objetivo principal la entrega y aceptación del sistema en su totalidad, y la
realización de todas las actividades necesarias para el paso a producción del mismo.
35 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
Conviene señalar la participación del usuario de operación en las pruebas de implantación, del usuario
final en las pruebas de aceptación, y del responsable de mantenimiento.
Para ello se toman como punto de partida los productos software probados, obtenidos en la fase de
Construcción del Sistema de Información y su documentación asociada.
Se realizan las pruebas de implantación y de aceptación del sistema en su totalidad. Responden a los
siguientes propósitos:
Las pruebas de implantación cubren un rango muy amplio, que va desde la comprobación de
cualquier detalle de diseño interno hasta aspectos tales como las comunicaciones.
Se debe comprobar que el sistema puede gestionar los volúmenes de información requeridos,
se ajusta a los tiempos de respuesta deseados y que los procedimientos de respaldo,
seguridad e interfaces con otros sistemas funcionan correctamente.
Se debe verificar también el comportamiento del sistema bajo las condiciones más extremas.
Las pruebas de aceptación se realizan por y para los usuarios. Tienen como objetivo validar
formalmente que el sistema se ajusta a sus necesidades.
Asimismo, se llevan a cabo las tareas necesarias para la preparación del mantenimiento, siempre y
cuando se haya decidido que éste va a efectuarse. En cualquier caso, es necesario que la persona que
vaya a asumir el mantenimiento conozca el sistema, antes de su incorporación al entorno de producción.
Además hay que determinar los servicios (y niveles para cada uno) que requiere el sistema que se va a
implantar, y el acuerdo que se adquiere una vez que se inicie la producción. Hay que distinguir entre
servicios de gestión de operaciones (servicios por lotes, seguridad, comunicaciones, etc.) y servicios al
cliente (servicio de atención a usuario, mantenimiento, etc.) que se deben negociar en cuanto a recursos,
horarios, costo, etc.
Se fija el nivel con el que se prestará el servicio como indicador de la calidad del mismo.
Conviene señalar que la implantación puede ser un proceso iterativo que se realiza de acuerdo al plan
establecido para el comienzo de la producción del sistema en su entorno de operación. Para establecer
este plan se tiene en cuenta:
El cumplimiento de los requisitos de implantación definidos en la fase de Descripción de las
Necesidades.
La estrategia de transición del sistema antiguo al nuevo.
36 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
PRODUCCIÓN
Administrador
EVOLUCIÓN - Nuevos Requerimientos - Nuevo Proyecto
Funcional
Es importante señalar, que en la fase de Producción las etapas no presentan una secuencialidad, ya que
las tareas correspondientes a esta fase pueden realizarse en forma paralela independientemente de la
etapa a la que pertenecen.
37 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
38 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
39 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
- Carta de Decisión
HITO 0: APROBACIÓN PROYECTO - Acuerdo de Servicio
Los resultados del Estudio de factibilidad del Sistema constituirán la base para tomar la
decisión de seguir adelante o abandonar. Si se decide seguir adelante pueden surgir uno o varios
proyectos que afecten a uno o varios sistemas de información. Dichos sistemas se desarrollarán
según el resultado obtenido en el estudio de viabilidad y teniendo en cuenta la cartera de proyectos
para la estrategia de implantación del sistema global.
Se ha considerado que este proceso es obligatorio, aunque el nivel de profundidad con el que
se lleve a cabo dependerá de cada caso. La conveniencia de la realización del estudio de la
situación actual depende del valor añadido previsto para la especificación de requisitos y para el
planteamiento de alternativas de solución. En las alternativas se considerarán soluciones "a
medida", soluciones basadas en la adquisición de productos software del mercado o soluciones
mixtas.
Para valorar las alternativas planteadas y determinar una única solución, se estudiará el
impacto en la organización de cada una de ellas, la inversión y los riesgos asociados.
El resultado final de este proceso son los productos relacionados con la solución que se
propone para cubrir la necesidad concreta que se planteó en el proceso, y que depende de:
40 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
Solución propuesta:
Descripción de la solución.
Modelo de descomposición en subsistemas.
Matriz de procesos/localización geográfica.
Matriz datos/localización geográfica.
Entorno tecnológico y comunicaciones.
Estrategia de implantación global del sistema.
Descripción de los procesos manuales.
41 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
42 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
8 Análisis DAFO
Análisis DAFO. Identificación de Factores Claves de Éxito., riesgos, barreras/restricciones, aspectos
legales (marco regulatorio).
9 Identificación de Métricas
Identificación de métricas operativas, funcionales y financieras, y sus objetivos, con las que se podrá
evaluar los resultados de haber realizado el proyecto.
12 Análisis de Presupuesto
Analizar y definir el presupuesto a asignar para las etapas del proyecto.
Identificar y designar el o los owners de presupuesto.
44 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
2
RESPONSABLE: - Comité Director
Notas:
2
El Comité Director delegará su responsabilidad de acuerdo a la importancia del proyecto.
45 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
FASE
DESCRIPCIÓN DE NECESIDADES
46 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
0.- DESCRIPCIÓN
D
N
E E
S C
C
E - Identificar Necesidades
R S DESCRIPCIÓN - Relevamiento Global Líder
I - Descripción de la Necesidad
I NECESIDADES - Descripición de Objetivos y Alcance Funcional
P D - Especificar Requerimiento
C
A
I
D
Ó E
N
S
de
Se recogen de forma detallada los requisitos funcionales que el sistema de información debe
cubrir, catalogándolos, lo que permite hacer la traza a lo largo de los procesos de desarrollo.
Además, se identifican los requisitos no funcionales del sistema, es decir, las facilidades que ha de
proporcionar el sistema, y las restricciones a que estará sometido, en cuanto a rendimiento,
frecuencia de tratamiento, seguridad, etc.
Para facilitar el análisis del sistema se identifican los subsistemas de análisis, y se elaboran
los modelos de Casos de Uso y de Clases, en desarrollos orientados a objetos, y de Datos y
Procesos en desarrollos estructurados. Se ha incorporado una actividad específica para la definición
de Interfaces de Usuario al tiempo que se van obteniendo y depurando los requisitos y los anteriores
modelos. Se especificarán todas las interfaces entre el sistema y el usuario, como formatos de
pantallas, diálogos, formatos de informes y formularios de entrada.
En este proceso se inicia también la especificación del Plan de Pruebas, que se completará
en el proceso Diseño del Sistema de Información.
47 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
Los productos resultantes del Análisis del Sistema de Información, dependen del tipo de
desarrollo de que se trate y se detallan a continuación especificando los que son distintos, según los
dos tipos de desarrollo mencionados:
• Descripción general del entorno tecnológico.
• Glosario de términos.
• Catálogo de normas.
• Catálogo de requisitos.
• Especificación de interfaz de usuario.
• Modelo de procesos.
Se realiza una descripción general de la necesidad planteada por el usuario, y se estudian las posibles
restricciones de carácter económico, técnico, operativo y legal que puedan afectar al sistema. Antes de
48 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
iniciar el estudio de los requisitos del sistema se establecen los objetivos generales del Estudio de
Viabilidad, teniendo en cuenta las restricciones identificadas anteriormente.
Una vez establecido el alcance, se identifican las unidades organizativas afectadas por el sistema, así
como su estructura y responsables de las mismas. Para determinar los responsables se tiene en cuenta a
quiénes afecta directamente y quiénes pueden influir en el éxito o fracaso del mismo.
En función del alcance del sistema y los objetivos del Estudio de Viabilidad del Sistema, se determinan las
actividades y tareas a realizar. En particular, hay que decidir si se realiza o no el estudio de la situación
actual y, en el caso de considerarlo necesario, con qué objetivo.
Si el sistema pertenece al ámbito de un Plan de Sistemas de Información, los criterios que pueden orientar
sobre la necesidad de llevar a cabo el estudio de la situación actual dependen de la arquitectura de
información propuesta, en cuanto a la identificación de los sistemas de información actuales, implicados en
el ámbito de este estudio, que se haya decidido conservar.
Se identifican los usuarios participantes de las distintas unidades organizativas afectadas para la
realización del Estudio de Viabilidad del Sistema, determinando previamente sus perfiles y
responsabilidades.
Debe comunicarse el plan de trabajo a los usuarios identificados como implicados en el Estudio de
Viabilidad, solicitando su aceptación y esperado su confirmación.
Teniendo en cuenta el objetivo del estudio de la situación actual, se realiza una valoración de la
información existente acerca de los sistemas de información afectados. En función de dicha valoración, se
especifica el nivel de detalle con que se debe llevar a cabo el estudio.
49 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
Como resultado de esta actividad se genera un diagnóstico, estimando la eficiencia de los sistemas de
información existentes e identificando los posibles problemas y las mejoras.
Esta actividad incluye la determinación de los requisitos generales, mediante una serie de sesiones de
trabajo con los usuarios participantes, que hay que planificar y realizar.
Una vez finalizadas, se analiza la información obtenida definiendo los requisitos y sus prioridades, que se
añaden al catálogo de requisitos que servirá para el estudio y valoración de las distintas alternativas de
solución que se propongan.
Para empezar la comunicación entre cliente y desarrollador se lleva a cabo una reunión o entrevista
preliminar. Se sugiere que el analista empiece preguntando cuestiones de contexto libre, es decir un
conjunto de preguntas que llevarán a un entendimiento básico del problema. Pero el formato de pregunta-
respuesta de reunión tipo, no es un enfoque que haya tenido mucho éxito. Esta sesión de preguntas y
respuestas debería emplearse solamente en el primer encuentro y sustituírse después por una modalidad
que combine elementos de resolución de problema, negociación y especificación.
50 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
El Despliegue de la Función Calidad (DFC) es una técnica de gestión de calidad que traduce las
necesidades del cliente en requisitos técnico del software. DFC identifica 3 tipos de requisitos:
- Requisitos normales: se declaran objetivos y metas para un producto o sistema durante reuniones
con el cliente. Si estos requisitos están presentes el cliente estará satisfecho.
- Requisitos esperados: son implícitos al producto o sistema y pueden ser tan fundamentales que el
cliente no los declara explícitamente. Su ausencia será motivo de una insatisfacción significativa.
- Requisitos innovadores: estas características van más allá de las expectativas del cliente y suelen
ser muy satisfactorias. El producto entregado contiene ciertas capacidades no esperadas.
El despliegue de función se utiliza para determinar el valor de cada función requerida para el sistema.
El primer principio operativo de análisis requiere el examen del dominio de la información. Este
dominio contiene 3 visiones diferentes:
1) el contenido de la información – datos y control -
2) el flujo de la información – como cambian los datos y control -
3) la estructura de la información – organización interna de datos y control –
7.1.2 Modelado
Los modelos se crean para entender mejor la entidad que se va a construir y es fundamental para un
buen trabajo de análisis:
51 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
- Modelos funcionales: el soft. transforma la información y para hacerlo, debe realizar al menos tres
funciones genéricas: entrad, procesamiento y salida. Este modelo empieza con un sencillo modelo a
nivel de contexto (DFD Nivel 0).
- Modelos de comportamiento: la mayoría del software responde a los acontecimientos del mundo
exterior (estímulo- respuesta). Esto forma parte de este modelo, que muestra los estados del soft y los
acontecimientos que causan que cambie de estado.
7.1.3 Partición
Es dividir los problemas que son demasiados grandes o complejos para entenderlos globalmente. La
partición descompone a un problema en sus partes constitutivas.
El enfoque de partición también puede aplicarse al dominio de la información y al de comportamiento.
Visión esencial: de los requisitos del software presenta las funciones a conseguir y la información a
procesar mínimos sin tener en cuenta los detalles de la implementación.
Visión de implementación: de los requisitos del software introduce la manifestación en el mundo real de
las funciones de procesamiento y las estructuras de la información.
7.2.1 Enfoque
7.3 ESPECIFICACION
7.3.2 Representación:
Los requisitos del soft pueden especificarse de varias maneras. Directrices a seguir:
- El formato de la representación y el contenido debería estar relacionados con el problema.
- La información contenida dentro de la especificación debería estar escalonada.
- La numeración de párrafos y diagramas debería indicar el nivel de detalle que se muestra.
- Los diagramas y otras formas de notación deberían restringirse en número y ser consistentes
den su empleo.
52 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
En muchos casos una especificación de requisitos puede estar acompañada de un prototipo ejecutable o
en papel o un manual del usuario.
Es llevada a cabo tanto por el desarrollador como por el cliente. Inicialmente la revisión se lleva a cabo a
nivel macroscópico. Se estudian las siguientes cuestiones:
- Metas y objetivos declarados.
- Descripto todas las interfaces importantes.
- Definidos el flujo y la estructura de la información
- Diagramas.
- Funciones principales
- Requisitos alternativos.
- Riesgos tecnológicos.
- Manual del usuario, etc.
53 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
FASE:
DISEÑO GLOBAL
54 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
Este proceso consta de un primer bloque de actividades, que se realizan en paralelo, y cuyo
objetivo es obtener el diseño global del sistema de información que comprende la partición física del
sistema de información, independiente de un entorno tecnológico concreto, la organización en
subsistemas de diseño, la especificación del entorno tecnológico sobre el que se despliegan dichos
subsistemas y la definición de los requisitos de operación, administración del sistema, seguridad y
control de acceso.
55 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
56 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
ESTABLECIMIENTO DE REQUISITOS
En esta actividad se lleva a cabo la definición, análisis y validación de los requisitos a partir de la
información facilitada por el usuario, completándose un catálogo de requisitos.
El objetivo de esta actividad es obtener un catálogo detallado de los requisitos, a partir del cual se pueda
comprobar que los productos generados en las actividades de modelización se ajustan a los requisitos de
usuario.
Esta actividad se descompone en un conjunto de tareas que, si bien tienen un orden, exige continuas
realimentaciones y solapamientos, entre sí y con otras tareas realizadas en paralelo.
Se propone como técnica de obtención de requisitos la especificación de los casos de uso o diagramas
híbridos. Dichas técnicas ofrece un diagrama simple y una guía de especificación en las sesiones de
trabajo con el usuario.
Se realiza en paralelo con el resto de las actividades de generación de modelos del análisis. Por tanto, se
asume la necesidad de una realimentación y ajuste continuo con respecto a la definición de los
subsistemas, sus dependencias y sus interfaces.
57 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
En referencia a los riesgos del proyecto el líder funcional deberá poder identificar aquellos riesgos que
puedan afectar la implementación del sistema.
Entre otros se deberá identificar y proponer soluciones (si los riesgos se presentan) los siguientes
aspectos.
Instalación del parque informático necesario para el desarrollo, prueba y puesta en marcha del
sistema.
Aparición de nuevas necesidades cuando el desarrollo del sistema ya se encuentra iniciado.
Atrasos en el plan de trabajo.
Aparición de problemas en la logística del proyecto (ambientes de capacitación / pruebas, etc.)
6 Quality Management
Definición e identificación de indicadores de calidad asociados a cada tarea e hito del proyecto.
Elaborar el Plan de Calidad.
El plan de calidad tiene íntima relación con la metodología de desarrollo implementada en el proyecto,
Particularmente los indicadores están asociados a la generación de documentación que todo proyecto de
desarrollo de un sistema debe poseer como por ejemplo:
58 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
59 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
FASE:
DISEÑO DETALLADO
60 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
- Impacto Organizacional
- Impacto Organizacional
- Estrategia de Implantación
- Estrategia de Implantación
- Plan de Pruebas Funcionales
- Elaboración Plan de Pruebas Funcionales
- Estrategia de Confiabilización
- Estrategia de Confiabilización
DEFINICIÓN - Estrategia de Conversión de Líder
- Estrategia de Conversión de Datos
ESTRATEGIAS Datos Funcional
- Estrategia de Carga de Datos
- Estrategia de Carga de Datos
- Plan Acción para el Cambio
- Plan de Acción para el Cambio
- Plan de Capacitación
- Plan de Capacitación
- Plan de Comunicación
- Plan de Comunicación
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.
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.
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.
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.
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.
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.
63 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
En esta actividad también se establecen los requisitos, normas y estándares originados como
consecuencia de la adopción de una determinada solución de arquitectura o infraestructura, que serán
aplicables tanto en este proceso como en la Construcción del Sistema de Información.
Se detallan a su vez, de acuerdo a las particularidades de la arquitectura del sistema propuesta, los
requisitos de operación, seguridad y control, especificando los procedimientos necesarios para su
cumplimiento.
Como resultado de esta actividad, se actualizan los catálogos de requisitos y normas, y se generan los
siguientes productos:
Diseño de la Arquitectura del Sistema, como producto que engloba el particionamiento físico del
sistema de información y la descripción de subsistemas de diseño.
Entorno Tecnológico del Sistema, que a su vez comprende la especificación del entorno
tecnológico, las restricciones técnicas y la planificación de capacidades.
Catálogo de Excepciones.
Procedimientos de Operación y Administración del Sistema.
Procedimientos de Seguridad y Control de Acceso.
Estas especificaciones definen la construcción del sistema de información a partir de las unidades básicas
de construcción (en adelante, componentes), entendiendo como tales unidades independientes y
coherentes de construcción y ejecución, que se corresponden con un empaquetamiento físico de los
elementos del diseño de detalle, como pueden ser módulos, clases o especificaciones de interfaz.
La división del sistema de información en subsistemas de diseño proporciona, por continuidad, una
primera división en subsistemas de construcción, definiendo para cada uno de ellos los componentes que
lo integran. Si se considera necesario, un subsistema de diseño se podrá dividir a su vez en sucesivos
niveles para mayor claridad de las especificaciones de construcción.
Las dependencias entre subsistemas de diseño proporcionan información para establecer las
dependencias entre los subsistemas de construcción y, por lo tanto, definir el orden o secuencia que se
debe seguir en la construcción y en la realización de las pruebas.
También se generan las especificaciones necesarias para la creación de las estructuras de datos en los
gestores de bases de datos o sistemas de ficheros.
El producto resultante de esta actividad es el conjunto de las especificaciones de construcción del sistema
de información, que comprende:
Especificación del entorno de construcción.
Descripción de subsistemas de construcción y dependencias.
Descripción de componentes.
Plan de integración del sistema de información.
Especificación detallada de componentes.
Especificación de la estructura física de datos.
Prototipo
Realización de prototipo
64 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
Se identifican los distintos grupos de usuarios de acuerdo con las funciones que realizan, conocimientos y
habilidades que poseen, y características del entorno en el que trabajan. La identificación de los diferentes
perfiles permite conocer mejor las necesidades y particularidades de cada uno de ellos.
Asimismo, se determina la naturaleza de los procesos que se llevan a cabo (en lotes o en línea). Para
cada proceso en línea se especifica qué tipo de información requiere el usuario para completar su
ejecución realizando, para ello, una descomposición en diálogos que refleje la secuencia de la interfaz de
pantalla tipo carácter o pantalla gráfica.
Finalmente, se define el formato y contenido de cada una de las interfaces de pantalla especificando su
comportamiento dinámico.
Como resultado de esta actividad se genera la especificación de interfaz de usuario, como producto que
engloba los siguientes elementos:
Principios generales de la interfaz.
Catálogo de perfiles de usuario.
Descomposición funcional en diálogos.
Catálogo de controles y elementos de diseño de interfaz de pantalla.
Formatos individuales de interfaz de pantalla.
Modelo de navegación de interfaz de pantalla.
Formatos de impresión.
Prototipo de interfaz interactiva.
Prototipo de interfaz de impresión.
Estos últimos sirven de guía en la utilización de diferentes estilos de diseño, tanto en el ámbito global del
sistema de información, como en el diseño de detalle.
65 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
Con este fin, se aconseja la consulta de los datos de otros proyectos existentes, disponible en el Histórico
de Proyectos. Si esto no fuera suficiente, se puede contar en esta actividad con la participación de perfiles
técnicos, con una visión global de la instalación.
Esta actividad se realiza en paralelo al diseño detallado, debido a que existe una constante realimentación,
tanto en la especificación de los subsistemas con sus interfaces y dependencias, como en la aplicación de
esqueletos o patrones en el diseño.
Para ello, una vez identificadas las clases participantes dentro de un caso de uso, es necesario completar
los escenarios que se recogen del análisis, incluyendo las clases de diseño que correspondan y teniendo
en cuenta las restricciones del entorno tecnológico, esto es, detalles relacionados con la implementación
del sistema.
Es necesario analizar los comportamientos de excepción para dichos escenarios. Algunos de ellos pueden
haber sido identificados en el proceso de análisis, aunque no se resuelven hasta este momento. Dichas
excepciones se añadirán al catálogo de excepciones para facilitar las pruebas.
Algunos de los escenarios detallados requerirán una nueva interfaz de usuario. Por este motivo es
necesario diseñar el formato de cada una de las pantallas o impresos identificados.
Es importante validar que los subsistemas definidos en la tarea Identificación de Subsistemas de Diseño
tienen la mínima interfaz con otros subsistemas.
Por este motivo, se elaboran los escenarios al nivel de subsistemas y, de esta forma, se delimitan las
interfaces necesarias para cada uno de ellos, teniendo en cuenta toda la funcionalidad del sistema que
recogen los casos de uso.
Además, durante esta actividad pueden surgir requisitos de implementación, que se recogen en el
catálogo de requisitos.
DISEÑO DE CLASES
El propósito de esta actividad, que se realiza sólo en el caso de Diseño Orientado a Objetos, es
transformar el modelo de clases lógico, que proviene del análisis, en un modelo de clases de diseño.
Dicho modelo recoge la especificación detallada de cada una de las clases, es decir, sus atributos,
operaciones, métodos, y el diseño preciso de las relaciones establecidas entre ellas, bien sean de
agregación, asociación o jerarquía.
Para llevar a cabo todos estos puntos, se tienen en cuenta las decisiones tomadas sobre el entorno
tecnológico y el entorno de desarrollo elegido para la implementación.
Se identifican las clases de diseño, que denominamos clases adicionales, en función del estudio de los
escenarios de los casos de uso, que se está realizando en paralelo en la actividad Diseño de Casos de
Uso Reales, y aplicando los mecanismos genéricos de diseño que se consideren convenientes por el tipo
de especificaciones tecnológicas y de desarrollo.
Entre ellas se encuentran clases abstractas, que integran características comunes con el objetivo de
especializarlas en clases derivadas. Se diseñan las clases de interfaz de usuario, que provienen del
66 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
análisis. Como consecuencia del estudio de los escenarios secundarios que se está realizando, pueden
aparecer nuevas clases de interfaz.
También hay que considerar que, por el diseño de las asociaciones y agregaciones, pueden aparecer
nuevas clases, o desaparecer incluyendo sus atributos y métodos en otras, si se considera conveniente
por temas de optimización.
La jerarquía entre las clases se va estableciendo a lo largo de esta actividad, a medida que se van
identificando comportamientos comunes en las clases, aunque haya una tarea propia de diseño de la
jerarquía.
Otro de los objetivos del diseño de las clases es identificar para cada clase, los atributos, las operaciones
que cubren las responsabilidades que se identificaron en el análisis, y la especificación de los métodos
que implementan esas operaciones, analizando los escenarios del Diseño de Casos de Uso Reales.
Se determina la visibilidad de los atributos y operaciones de cada clase, con respecto a las otras clases
del modelo.
Una vez que se ha elaborado el modelo de clases, se define la estructura física de los datos
correspondiente a ese modelo, en la actividad Diseño Físico de Datos.
Además, en los casos en que sea necesaria una migración de datos de otros sistemas o una carga inicial
de información, se realizará su especificación a partir del modelo de clases y las estructuras de datos de
los sistemas origen.
Como resultado de todo lo anterior se actualiza el modelo de clases del análisis, una vez recogidas las
decisiones de diseño.
Esta actividad es compleja, por lo que es aconsejable utilizar herramientas de apoyo para la realización de
sus tareas.
67 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
En esta actividad se inicia la definición del plan de pruebas, el cual sirve como guía para la realización de
las pruebas, y permite verificar que el sistema de información cumple las necesidades establecidas por el
usuario, con las debidas garantías de calidad.
El plan de pruebas es un producto formal que define los objetivos de la prueba de un sistema, establece y
coordina una estrategia de trabajo, y provee del marco adecuado para elaborar una planificación paso a
paso de las actividades de prueba.
El plan se inicia en el proceso Análisis del Sistema de Información, definiendo el marco general, y
estableciendo los requisitos de prueba de aceptación, relacionados directamente con la especificación de
requisitos.
Dicho plan se va completando y detallando a medida que se avanza en los restantes procesos del ciclo de
vida del software, Diseño del Sistema de Información, Construcción del Sistema de Información e
Implantación y Aceptación del Sistema.
En esta actividad también se avanza en la definición de las pruebas de aceptación del sistema. Con la
información disponible, es posible establecer los criterios de aceptación de las pruebas incluidas en dicho
nivel, al poseer la información sobre los requisitos que debe cumplir el sistema, recogidos en el catálogo
de requisitos.
Documentación Operativa
Generación de la documentación que contenga los aspectos operativos y de seguridad necesarios para la
puesta en producción y mantenimiento del sistema.
Esta documentación se irá completando hasta la Puesta en Producción.
- Proveedor
Impacto Organizacional 4
Identificar con tiempo suficiente los impactos en la Organización que genera un cambio de
Sistemas/Procesos a efectos de poder planear acciones de cambio.
Se tomará como base el ítem “Impacto” del documento “Estudio de Factibilidad Técnico/Funcional”
generado en la fase de Estudio Preliminar.
Estrategia de implantación
Definir la estrategia de implantación del proyecto.
Identificar el modo de implantación: big bang, roll-out (en etapas).
Definir fases y releases.
Notas:
4
La ubicación de esta tarea en la Etapa de Diseño Detallado, responde a una cuestión temporal.
69 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
Para ello, se toma como referencia el plan de migración y carga inicial de datos, que recoge las
estructuras físicas de datos del sistema o sistemas origen implicadas en la conversión, la prioridad en las
cargas y secuencia a seguir, las necesidades previas de depuración de la información, así como los
requisitos necesarios para garantizar la correcta implementación de los procedimientos de migración sin
comprometer el funcionamiento de los sistemas actuales.
Notas:
5
De acuerdo a las Normas vigentes, los datos de Producción deberán tener la aprobación del Administrador Funcional
6
La descripción de la estrategia de pruebas funcionales está incluida en el documento general del plan de pruebas dentro del Anexo
Carpeta de Proyectos.
70 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
A partir de dicho plan, y de acuerdo a la estructura física de los datos del nuevo sistema, obtenida en la
actividad Diseño Físico de Datos, y a las características de la arquitectura y del entorno tecnológico
propuesto en la actividad Definición de la Arquitectura del Sistema, se procede a definir y diseñar en
detalle los procedimientos y procesos necesarios para realizar la migración.
Se completa el plan de pruebas específico establecido en el plan de migración y carga inicial, detallando
las pruebas a realizar, los criterios de aceptación o rechazo de la prueba y los responsables de la
organización, realización y evaluación de resultados.
Como resultado de esta actividad, se actualiza el plan de migración y carga inicial de datos con la
información siguiente:
Especificación del entorno de migración.
Definición de procedimientos de migración.
Diseño detallado de módulos.
Especificación técnica de las pruebas.
Planificación de la migración y carga inicial.
Es importante considerar que una carga inicial de información no tiene el mismo alcance y complejidad
que una migración de datos, de modo que las tareas de esta actividad se deben llevar a cabo en mayor o
menor medida en función de las características de los datos a cargar.
Plan de Capacitación 8
Elaboración del Plan de Capacitación
Lanzamiento de todas las tareas de preparación previas a la capacitación (logística, manuales, ambientes,
comunicación de la capacitación, definición de la modalidad de capacitación, herramientas, etc.)
Notas:
7
La ubicación de esta tarea en la Etapa de Diseño Detallado, responde a una cuestión temporal. Sin embargo, la culminación de la
misma, deberá haberse cumplido previo a la implantación.
8
La ubicación de esta tarea en la Etapa de Diseño Detallado, responde a una cuestión temporal. Sin embargo, la culminación de la
misma, deberá haberse cumplido previo a la implantación.
71 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
Plan de Comunicación 9
Elaboración del Plan de Comunicación
Notas:
9
La ubicación de esta tarea en la Etapa de Diseño Detallado, responde a una cuestión temporal. Sin embargo, la culminación de la
misma, deberá haberse cumplido previo a la implantación.
72 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
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
73 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
FASE:
CONSTRUCCIÓN
74 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
FASE: CONSTRUCCIÓN
La construcción del Sistema de Información tiene como objetivo final el desarrollo y prueba de
los distintos componentes del sistema de información, a partir del conjunto de especificaciones
lógicas y físicas del mismo, obtenido en el Proceso de Diseño global y detallado del Sistema de
Información.
Para conseguir dicho objetivo, se recoge la información relativa al producto del diseño
Especificaciones de construcción, se prepara el entorno de construcción, se genera el código
(programación) de cada uno de los componentes del sistema y se van realizando (a medida que se
vaya finalizando la programación) las pruebas unitarias de cada uno de los componentes y las de
integración entre subsistemas si las hubiere.
Si fuera necesario realizar una migración de datos, es en este proceso donde se lleva a cabo
la construcción de los componentes de migración, los procedimientos de migración y carga inicial de
datos.
75 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
Entre estos medios, cabe destacar la preparación de los puestos de trabajo, equipos físicos y lógicos,
gestores de bases de datos, bibliotecas de programas, herramientas de generación de código, bases de
datos o ficheros de prueba, entre otros.
Las características del entorno de construcción y sus requisitos de operación y seguridad, así como las
especificaciones de construcción de la estructura física de datos, se establecen en la actividad Generación
de Especificaciones de Construcción, y constituyen el punto de partida para la realización de esta
actividad.
En paralelo a esta actividad, se desarrollan las actividades relacionadas con las pruebas unitarias y de
integración del sistema de información. Esto permite una construcción incremental, en el caso de que así
se haya especificado en el plan de pruebas y en el plan de integración del sistema de información.
76 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
Previamente a la generación del código, se prepara la infraestructura tecnológica necesaria para realizar la
codificación y las pruebas de los distintos componentes y procedimientos asociados, de acuerdo a las
características del entorno de migración especificado en el plan de migración y carga inicial de datos.
Finalmente, se llevan a cabo las verificaciones establecidas en la especificación técnica del plan de
pruebas propio de la migración.
Los requisitos de documentación especifican aspectos relativos a los tipos de documentos a elaborar y
estándares a seguir en la generación de los mismos, y para cada uno de ellos:
Formato y soporte en el que se desarrollarán
Estructura
Distribución y mantenimiento de la documentación y número de copias a editar.
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.
77 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
En esta actividad se realizan las pruebas unitarias de cada uno de los componentes del sistema de
información, una vez codificados, con el objeto de comprobar que su estructura es correcta y que se
ajustan a la funcionalidad establecida.
En el plan de pruebas se ha definido el entorno necesario para la realización de cada nivel de prueba, así
como las verificaciones asociadas a las pruebas unitarias, la coordinación y secuencia a seguir en la
ejecución de las mismas y los criterios de registro y aceptación de los resultados.
Prueba Individual
Prueba Unitaria de Módulos y Programa. (Cabe aclarar que esta prueba podría realizarse en la etapa de
desarrollo).
Las pruebas unitarias no requieren de datos operativos dado que el objetivo que se desea alcanzar es
comprobar el funcionamiento lógico del componente. De todos modos resulta deseable que los datos
utilizados conlleven la coherencia de las reglas de negocio que el sistema debe tratar en producción.
Asegurar el correcto funcionamiento de cada módulo en forma aislada utilizando dos enfoques: prueba de
caja blanca y prueba de caja negra (ver glosario)
Prueba de Cadena
Asegurar el correcto funcionamiento de un conjunto de módulos componentes del sistema que se
relacionan entre sí y que cumplen una funcionalidad única dentro del mismo.
Asegurar la correcta integración entre módulos y sus interfaces.
Generar un informe de los casos de prueba que en la prueba unitaria por motivos técnicos no pudieron ser
generados a fin de que en las pruebas globales se ponga mayor atención a los resultados de estas.
Prueba de Integración
Probar la integridad técnica del sistema en su totalidad, incluyendo todas las interfaces que el sistema
genera entre módulos propios y hacia otros sistemas sin que estas últimas sean necesariamente
procesadas por otros sistemas (esto se realiza en la prueba global).
Particularmente los analistas que participan de esta prueba deben verificar el correcto impacto en la
registración de los datos en la base de datos utilizada; por esta razón estos analistas funcionales deben
poseer un conocimiento detallado del modelo de datos del sistema y el diseño de datos de las interfaces
con sistemas externos.
78 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
La estrategia a seguir en las pruebas de integración se establece en el plan de pruebas, dónde se habrá
tenido en cuenta el plan de integración del sistema de información, siempre y cuando se haya especificado
en la tarea Definición de Componentes y Subsistemas de Construcción.
Esta actividad se puede realizar en paralelo a las actividades Generación del Código de los Componentes
y elaboración de los Procedimientos y Ejecución de las Pruebas Unitarias. Sin embargo, es necesario que
los componentes objeto de las pruebas de integración se hayan verificado de manera unitaria.
Prueba Global
Prueba funcional en ambiente de prueba con los siguientes objetivos:
- Asegurar que las funcionalidades introducidas funcionan según los requerimientos especificados por
los usuarios.
- Probar la integridad funcional y técnica entre los sistemas impactados por la implantación del nuevo
sistema (incluye interfaces entre sistemas).
- Probar las Interfaces con otros sistemas.
- Llevar adelante la Prueba de Aceptación del usuario
- Asegurar que los beneficios acordados con el usuario son producidos por el sistema
- Asegurar que cada Evento de Negocio funciona a lo largo de las aplicaciones.
El líder informático es responsable de ejecutar la prueba.
El líder funcional es responsable de redactar el informe de prueba y aprobar la misma.
En la realización de estas pruebas es importante comprobar la cobertura de los requisitos, dado que su
incumplimiento puede comprometer la aceptación del sistema por el equipo de operación responsable de
realizar las pruebas de implantación del sistema, que se llevarán a cabo en el proceso Implantación y
Aceptación del Sistema.
Prueba de Compatibilidad
Pruebas de compatibilidad con los sistemas actuales o próximos a implementarse.
(Se participará a estas pruebas a los administradores funcionales de los sistemas involucrados)
79 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
Preparación
Preparar las pruebas piloto. Dado que se trata de una prueba en producción y con datos de producción, se
llevarán adelante tareas previas a la puesta en Producción de un sistema, pero circunscriptas al contexto
de la prueba piloto.
1. Armar el plan de Implantación de Prueba Piloto
- Definición de Usuarios y Perfiles
- Incorporar el sistema al circuito de solicitud de claves de acceso
2. Preparación de la implantación (referidas a los datos y actores involucrados en la prueba piloto)
(Los inputs, outputs, actores y responsables de estas tareas son los descriptos en la Etapa
“Preparación de la implantación” de la fase “Implantación”)
- Ejecución de Confiabilización de Datos
- Conversión de Datos
- Aprobación de Conversión de Datos
- Carga Inicial de los datos y Parametrización
- Capacitación a los sectores técnicos y funcionales impactados
- Comunicación a los sectores técnicos y funcionales impactados
3. Preparar el sitio:
- Preparación de documentación.
- Instalación de los productos/software.
- Escribir los procedimientos.
- Instructivos de instalación
Prueba Piloto
Llevar adelante la prueba piloto propiamente dicha.
80 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
Plan de Implantación
De acuerdo a la estrategia de Implantación ya definida y a los resultados de la Prueba Piloto definir el Plan
de Implantación.
Establecer sitios, recursos, cronogramas de implantación.
Plan de Soporte
De acuerdo al Plan de Implantación, definir el esquema de Soporte a la Implantación.
En función de las necesidades, el líder funcional y el líder informático convocarán a los actores
correspondientes.
81 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
Este protocolo deberá ser aprobado por el líder funcional del proyecto.
82 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
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
83 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
FASE DE
IMPLANTACIÓN
84 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
FASE: IMPLANTACIÓN
Este proceso tiene como objetivo principal, la entrega y aceptación del sistema en su totalidad,
que puede comprender varios sistemas de información desarrollados de manera independiente,
según se haya establecido en el proceso de Estudio de Factibilidad del Sistema, y un segundo
objetivo que es llevar a cabo las actividades oportunas para el paso a producción del sistema.
Se establece el plan de implantación, una vez revisada la estrategia de implantación y se detalla el equipo
que lo realizará.
Para el inicio de este proceso se toman como punto de partida los componentes del sistema
probados de forma unitaria e integrados en el proceso Construcción del Sistema de Información, así
como la documentación asociada. El Sistema se someterá a las Pruebas de Implantación con la
participación del usuario de operación cuya responsabilidad, entre otros aspectos, es comprobar el
comportamiento del sistema bajo las condiciones más extremas. También se someterá a las Pruebas
de Aceptación cuya ejecución es responsabilidad del usuario final.
En este proceso se elabora el plan de mantenimiento del sistema de forma que el responsable
del mantenimiento conozca el sistema antes de que éste pase a producción. También se establece el
acuerdo de nivel de servicio requerido una vez que se inicie la producción. El acuerdo de nivel de
servicio hace referencia a servicios de gestión de operaciones, de soporte a usuarios y al nivel con el
que se prestarán dichos servicios.
85 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
Conversión de Datos
Realizar la Conversión de los Datos del sistema origen al sistema actual. Esta conversión/migración se
desarrolla con un proceso AUTOMÁTICO.
El Líder Funcional será responsable de convocar al Administrador Funcional del sistema origen.
86 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
Capacitación
Capacitación de los usuarios finales, capacitadores y todos los actores involucrados en la operación del
sistema.
Garantizar que las tareas lanzadas en el plan de capacitación se hayan completado (logística, manuales,
ambientes, comunicación de la capacitación, definición de la modalidad de capacitación, herramientas,
etc.)
Cabe señalar que la capacitación se podrá realizar a lo largo del ciclo de vida del proyecto de acuerdo al
plan de capacitación.
Para la definición de la formación hay que tener en cuenta las características funcionales y técnicas
propias del sistema de información, así como los requisitos relacionados con la formación del usuario final,
establecidos en la tarea Especificación de Requisitos de Implantación.
Comunicación
Asegurar que el usuario final, soporte funcional, como así también todos los sectores involucrados, estén
en conocimiento del alcance en cuanto a contenidos y fechas de las nuevas funcionalidades del proyecto a
implantar
87 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
Realización Implantación
Realización de la implantación con la colaboración del líder funcional y soportes (in situ, a distancia,
soporte de las mesas de ayuda funcional, etc.)
Esta tarea implica la implantación del sistema en forma total (en caso de big bang) o de una de sus etapas
(roll-out).
Aceptación de la Implantación
Aceptación del protocolo de implantación con su validación por parte del líder funcional y recepción
provisoria del sistema/etapa.
Esta tarea implica la aceptación y recepción provisoria del sistema en forma total (en caso de big bang) o
de una de sus etapas (roll-out).
Firma del Contrato de Servicio entre el Usuario y los proveedores (internos y externos) del servicio.
Notas:
10
Normalmente los Proveedores del Servicio corresponden a: Soporte a Usuarios, Soporte Funcional, Soporte Técnico, Soporte
Aplicativo, Soporte Seguridad.
88 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
Notas:
11
En este momento deberá estar finalizado el documento de procedimientos de producción, el cual se anexará a esta
documentación
12
Los roles de soporte enunciados podrán corresponder a más de un sector, de acuerdo a la organización.
89 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
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
90 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
FASE: PRODUCCIÓN
Administrador
EVOLUCIÓN - Nuevos Requerimientos - Nuevo Proyecto
Funcional
Es importante señalar, que en la fase de Producción las etapas no presentan una secuencialidad, ya que
las tareas correspondientes a esta fase pueden realizarse en forma paralela independientemente de la
etapa a la que pertenecen.
Procesos de Backup
Realizar los procesos de backup de acuerdo al Plan de Backup.
Notificar los resultados del backup a los actores correspondientes
Procesos de Seguridad
Realizar los procesos de seguridad.
Asegurar la integridad y coherencia de los datos
Verificar y controlar los logs de auditoría.
Asegurar la confidencialidad: identificación, autenticación y control de accesos
Generar los informes correspondientes y actualizar el tablero de mando.
Procesos de Performance
Realizar los procesos de performance.
Notas:
13
Los indicadores del tablero de mando se definirán en el contrato de servicio de producción
91 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
Relevar y asegurar performance del procesamiento, tiempos de CPU, número de procesos levantados,
número de usuarios conectados, capacidad y tráfico de red.
Tuning de BD, SO y Red.
Generar los informes correspondientes y actualizar el tablero de mando.
Otros Procesos
Procesos extraordinarios.
Upgrades de Hardware, Sistema Operativo, etc.
Soporte en tareas para recuperación de información para Legales, Auditoría, otros sistemas, etc.
ETAPA: SOPORTE
Atención a Usuarios
Atender a los usuarios, recibir y registrar los llamados por consultas, reclamos y/o problemas.
Diagnosticar e identificar criticidad y el origen del incidente, resolver y/o derivar los reclamos según
corresponda (soporte funcional, soporte aplicativo u otro actor).
Realizar seguimiento de los incidentes.
Comunicar la solución al usuario.
Mantener los indicadores de gestión de atención a usuarios actualizando el tablero de mando.
Soporte Funcional
Recibir consultas y asesorar acerca de la información que brinda el sistema y sus funcionalidades en
general.
Diagnosticar, identificando la criticidad y el origen del problema, y resolver o derivar la consulta.
Soporte Técnico
Recibir incidentes técnicos.
Notas:
16
Los indicadores del tablero de mando se definirán en el contrato de servicio de producción
17
Los indicadores del tablero de mando se definirán en el contrato de servicio de producción
93 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
Soporte Aplicativo
Recibir incidentes aplicativos y realizar el diagnóstico, identificando la criticidad y el origen del problema.
Resolver y/o derivar el incidente a los actores correspondientes, priorizando la criticidad del problema.
Corregir la aplicación eliminando la causa del incidente (corrección del bug).
19
Realizar los tests y preparar el pasaje a producción.
Realizar la gestión de configuración.
Actualizar documentación de Sistemas, de Usuario y de Procesos registrando las modificaciones de
nuevas versiones, patchs, etc.
ETAPA: EVOLUCIÓN
Nuevos Requerimientos
Centralizar los requerimientos sobre nuevas funcionalidades y/o modificaciones al sistema. Generar la
necesidad de evolución y el requerimiento para un nuevo sistema/release
Esta evolución o nuevo sistema, o release seguirá el ciclo de un proyecto, de acuerdo a la Guía de
Gestión de Proyectos.
Notas:
18
Los indicadores del tablero de mando se definirán en el contrato de servicio de producción
19
La aprobación del pasaje a producción y la puesta en producción se llevarán de acuerdo a las Normas vigentes.
94 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
95 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
CARPETA de
PROYECTOS
96 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
CARPETA DE PROYECTOS
En este capítulo se describen los entregables obligatorios originados en cada una de las fases descritas
anteriormente.
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
RESPONSABLE
Líder Funcional
97 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
Proyecto: ........................................................
Subproyecto: ........................................................
DATOS GENERALES
Requirente <Gerencia> <Nombre y Apellido> <Interno>
Responsable Gestión en <Gerencia> <Nombre y Apellido> <Interno>
DRI
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
20
ESPECIFICACIÓN FUNCIONAL
1. Funcionalidades
- Alcance de las funcionalidades
- Descripción detallada de las funcionalidades.
- Descripción de aspectos de seguridad de la funcionalidad
- Definición de usuarios y perfiles de la funcionalidad
2. Requerimientos a los sistemas impactados
3. Descripción de aspectos de volumetría y performance
4. Principales cambios a los procesos
- Definición de procesos/subprocesos a implementar/cambiar
5. Reportes
6. Puntos abiertos
7. Temas a desarrollar en una etapa posterior
8. Posibles indicadores
Notas:
20
Debido a la importancia del entendimiento de los requerimientos funcionales por parte del líder informático y su equipo, se
realizarán rondas de aclaraciones y actualización entre funcional e informático, que generarán modificaciones y/o aclaraciones a
este documento. La revisión se realiza para asegurar que se ha identificado adecuadamente el marco del proyecto, se ha
definido correctamente las funcionalidades, el rendimiento y las interfaces.
Los procesos/sub-procesos definidos en la especificación funcional y resultantes de las rondas de validación entre líder funcional
y líder informático serán los procesos/sub-procesos que implementará el sistema y que deberán ser volcados en el manual de
procesos para el usuario final.
98 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
ENCABEZADO
- Id Requrimiento: código de identificación del requerimiento generado en forma secuencial y
automáticamente en la base de Lotus Notes.
- Nombre referencial: nombre del requerimiento basado en la función asociada.
Ej: CRM – Nota de crédito
- Proyecto: nombre del proyecto Ej: CRM URSI
- Subproyecto: nombre del subproyecto Ej: CRM - Fase 1
- Estado: estado del requerimiento según el flujograma de gestión de la demanda (preliminar, en
análisis de impacto, en negociación con el usuario, definitivo)
DATOS GENERALES
- Requirente: nombre del sector y persona que realiza el requerimiento (usuario final)
- Responsable de gestión en DRI: nombre del sector y persona responsable de la gestión del
requerimiento en la DRI
- Fecha requerida de implantación: dd/mm/aa
- Fecha estimada de respuesta del F1: dd/mm/aa
- Prioridad: nivel de prioridad definido por el usuario para el estudio preliminar del requerimiento.
Se elaborará una tabla de criterios para guiar a los usuarios.
DESCRIPCIÓN DE LA NECESIDAD
- Describir el objetivo y alcance de la necesidad de un nuevo sistema o una modificación.
Identificar si se reemplaza a un sistema, si es una ampliación, una modificación o algo nuevo.
- Identificar procesos y subprocesos impactados, según la lista de procesos establecidos
ESPECIFICACIÓN FUNCIONAL
(Los siguientes puntos se aplicarán según corresponda de acuerdo a las características del
requerimiento y de los sistemas que impacta)
99 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
6. Puntos abiertos
7. Temas a desarrollar en una etapa posterior
8. Posibles indicadores: definir indicadores, momento adecuado de la medición y definir valores
estándares para ese indicador.
100 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
NOMBRE
21
Estudio de Factibilidad Técnico/Funcional
OBJETIVO
Estudio de la funcionalidad, el rendimiento y las restricciones que puedan afectar a la
posibilidad de realización del sistema. Análisis y evaluación de distintas alternativas para
el desarrollo del sistema.
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................
Notas:
21
Dentro del ámbito de la Unidad de Negocios Red, el “Estudio de Factibilidad” se denomina “Estudio de Oportunidad”.
22
PMO: modelo objetivo presente
23
FMO: modelo objetivo futuro
24
Se deberá describir el sistema/producto con el soporte tecnológico (Hardware, Software, Base de Datos, Redes, Puestos de
Trabajo, etc.)
101 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
NOMBRE
Estudio de Factibilidad Económica
OBJETIVO
Estudio de inversiones y gastos frente al beneficio final producido por el sistema.
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................
- Contexto
- Alternativas. Escenarios posibles
- Contexto
- Inversiones y gastos del proyecto
- Beneficios
- Valor actual neto
- Tasa interna de retorno
- Período de recupero
- Máxima necesidad de fondos y años en los que ocurre
- Estado de resultados proyectado
- Cash flow proyectado
- Conclusión
RESPONSABLE
Líder funcional con colaboración del líder informático y de un experto económico.
102 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
MÉTRICAS CLAVES
NOMBRE
Métricas Claves
OBJETIVO
Identificar las métricas/indicadores claves para la evaluación del proyecto (aquellas
asociadas a la motivación/justificación del proyecto para medir así los impactos
esperados versus los reales).
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................
103 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
NOMBRE
Informe Ejecutivo de Estudio de Factibilidad
OBJETIVO
Describir sintéticamente las alternativas desarrolladas en los estudios de factibilidad
técnico/funcional y económico para ser presentado al Comité.
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................
Objetivo
-
Alternativas
-
- Descripción técnica/funcional
- Estudio económico
- Plazos Estimados
- Impacto
- Conclusión
RESPONSABLE
Líder Funcional
104 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
CARTA DE DECISIÓN
NOMBRE
Carta de Decisión
OBJETIVO
Informe de la decisión resultante del hito 0.
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................
-Proyecto Aprobado?
- Alternativa Elegida
- Observaciones
- Proyecto Rechazado?
- Fundamentos
- Modalidad del Proyecto
- Presupuesto (todos los recursos + tiempo interno de compra)
- Plazos (Gantt Macro)
- Responsables (Compromiso de disponibilidad)
RESPONSABLE
Comité Director
105 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
APROBACIÓN DE HITOS
Fecha estimada de
finalización
Fecha real de finalización
SITUACIÓN DE ENTREGABLES
Comentarios
ANEXOS
106 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
- 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
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
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
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
RESPONSABLE
Líder informático
109 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
NOMBRE
Plan General de Trabajo
OBJETIVO
Definir macro tareas, plazos e hitos de control
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................
110 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
EQUIPO DE TRABAJO
NOMBRE
Equipo de Trabajo
OBJETIVO
Identificar, dentro de la estructura de la organización, las personas que cumplen los
distintos roles definidos para el proyecto
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................
111 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
ALCANCE FUNCIONAL
DEFINICIONES PENDIENTES
FECHAS DE IMPLEMENTACIÓN
112 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
ALCANCE FUNCIONAL
- Breve descripción de los límites y alcance que tendrá la solución
FECHAS DE IMPLEMENTACIÓN
- Describir el plan de trabajo con un cronograma asociado.
113 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
114 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
NOMBRE
Especificación Técnica de Detalle
OBJETIVO
Describir la especificación técnica de detalle (estructura de datos detallada y
representaciones algorítmicas del software). Se describe también el diseño de las
interfaces.
CONTENIDO
RESPONSABLE
Líder Informático
115 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
PROYECTO: .................................................................
SUBPROYECTO: .................................................................
Sistema/Módulo impactado: .........................................
- Gráfico de alto nivel del sistema (Soporte gráfico que describe el sistema en sí mismo)
- Flujo de información entre aplicaciones, grupos funcionales e interfaces externas a nivel
conceptual (flow de procesos)
- Diagrama identificando los componentes generales del proceso.
- Funcionalidades:
- Diseño Macro de Funcionalidades:
- Descripción de funcionalidades del sistema y funciones involucradas.
- Flow del aplicativo: descripción de cómo, a nivel macro, la función será llevada a cabo por
el sistema
- Definición de entidades
- Bases para identificar reportes, pantallas, procesos, módulos
- Bases para identificar procesos manuales y computarizados.
- Resolución de la funcionalidad:
- Descripción gráfica
- Descripción detallada
- Interfaces
- Descripción Funcional
- Descripción Técnica
- Módulos:
- Resolución de los módulos:
- Flow Chart estructurado / Arquitectura técnica
- Input – Output del módulo
- Descripción del Módulo
- Pseudocódigo
- Definición de archivos
- Códigos de Error
- Descripción
- Causa
- Umbrales
- Acciones
- Controles de procesos
116 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
- Estructura de Datos
- Diccionario de Datos
- Elemento de Datos
- Registro / Estructura
- Archivos
- Referencias Cruzadas
- Base de Datos:
- Diseño lógico
- Diseño físico
- Tablas
- Indices
- Foreign Keys
- Reportes
- Descripción Funcional
- Layout
- Ejemplo
- Pantallas
- Descripción Funcional
- Layout
- Ejemplo
ANEXOS
117 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
NOMBRE
Plan Detallado de Trabajo
OBJETIVO
Definir el detalle de las tareas, plazos e hitos de control
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................
118 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
NOMBRE
Plan de Pruebas Técnicas – Plan de Pruebas Funcionales
OBJETIVO
Describir un plan general para la integración del software y una descripción de las
pruebas específicas.
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................
Plan de Pruebas:
-
- Objetivo y Alcance
- Contexto / Ambiente de prueba
- Datos (generación)
- Interfaces
- Plataforma
- Condiciones generales de prueba:
- Datos de Entrada
- Resultado Esperado
- Responsable de la prueba
- Documentación del input de la prueba
- Descripción de la documentación que respaldará la prueba
- Criterio de entrada
- Criterio de salida (cota de calidad)
- Criterio de aceptación
- Circuito de resolución de incidentes de prueba
- Métricas
RESPONSABLE
Líder informático
Líder funcional para Prueba Global (Prueba Funcional)
119 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
NOMBRE
Plan de Contingencia y de Desastre
OBJETIVO
Definir un plan que detalle las tareas y responsables para cada situación de contingencia
que se pudiera presentar en el software y/o hardware.
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................
120 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
PLAN DE BACKUP
NOMBRE
Plan de Backup
OBJETIVO
Definir el plan de backup para el sistema operativo, datos y aplicación (servidores y
puestos de trabajo)
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................
121 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
NOMBRE
Documento de Soporte a la Mesa de Ayuda
OBJETIVO
Describir la información que debe brindarse a la Mesa de Ayuda para que pueda conocer
y satisfacer las inquietudes o inconvenientes que manifiesten los usuarios.
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................
- Horarios de Atención
- Horario de utilización que tienen los usuarios del sistema.
- Horario de Soporte al Aplicativo
- Soporte del aplicativo
- Lista de responsables por cada tema.
- Alternativas de comunicación en sus distintos horarios.
- Configuración
- Esquema de configuración del equipo standard informático utilizado (Puesto de trabajo)
- Esquema de conectividad y comunicaciones con equipo central o procesamiento
distribuido
- Equipo (host)
- Nombre, mnemónico y direcciones IP Eth/X25 y X25
- Ubicación física del Equipo
- Asistencia MASIT en Host
- Usuario normalizado para todas las operaciones permitidas (Control de performance
(Monitor), administración de procesos generados por los usuarios, etc.)
- Instructivo de uso del mismo
- Cortes programados
- Referentes por Cortes programados
- Casos en que quieran ser informados
- Edificios y lugares que pudieran estar afectados
- Análisis de puesta en marcha
- Impacto de llamadas en la puesta en marcha
- Cantidad de llamadas promedio ponderadas de consultas
- Aplicación
- Mensajes más comunes de error.
- Soluciones a esos mensajes
- Circuito de derivación de problemas.
- Conocimiento por parte de las áreas involucradas el circuito.
- Estadísticas
- Que datos requerirán de la MASIT
- Casos o seguimientos especiales.
- Interlocutores
- Responsables del sistema
- Administradores.
- Interlocutores de los sectores involucrados
- Definición de las funcionalidades del sistema.
- Breve descripción de la finalidad del sistema.
- Detalle de usuarios del sistema
- Nómina de los usuarios definidos
- Descripción de la distribución geográfica de los usuarios
RESPONSABLE
Líder informático con la colaboración del líder funcional
122 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
123 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
NOMBRE
Documento de Soporte a Operaciones/Soporte Técnico
OBJETIVO
Describir la información necesaria para que los sectores técnicos puedan administrar y
dar soporte al hardware y software involucrado en el proyecto.
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................
- Backup
- Instructivo y menú de backup.
- Periodo de retención y reciclaje de las cintas.
- Información a resguardar (File System, directorios, etc.)
- Responsables del mismo (nombre, teléfono, radio, etc.)
- Contingencia
- Especificación de los servers de contingencia.
- Responsable del lanzamiento de la contingencia.
- Plan de contingencia, procedimientos, etc.
- Control de Interfaces
- Se deberá proveer toda la información necesaria para el control de las interfaces
(origen/destino, periodicidad, manual/automática, etc.)
- Carpeta Operativa.
- Se deberá proveer la misma, para ser utilizada en los casos en que el sector tenga
que intervenir. (Instructivos, procedimientos, etc.)
RESPONSABLE
Líder informático
124 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
125 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
NOMBRE
Procedimiento de Gestión de Configuración
OBJETIVO
Definir un procedimiento de Gestión de Configuración mediante el cual se establecen los
mecanismos para realizar modificaciones o actualizaciones a cualquier elemento
producido durante el ciclo de vida del un proyecto y su posterior mantenimiento.
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................
126 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
IMPACTO ORGANIZACIONAL
NOMBRE
Impacto Organizacional
OBJETIVO
Conocer con tiempo suficiente los impactos en la Organización que genera un cambio de
Sistemas/Procesos a efectos de poder planear acciones de cambio.
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................
Procesos a implantar/cambiar
-
Sistemas a implantar/cambiar
-
Población afectada
-
- Cantidad
- Localización
- Tipo de contrato (D/C - F/C)
- Especialidades / Puestos
- Dimensionamiento del impacto respecto a las tareas / competencias /
localizaciones necesarias previas al cambio
RESPONSABLE
Líder Funcional
127 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
ESTRATEGIA DE IMPLANTACIÓN
NOMBRE
Estrategia de Implantación
OBJETIVO
Definir la estrategia de implantación de un proyecto
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................
- Modo de Implantación:
- Big Bang
- Roll-out (en etapas)
- Fases (descripción, alcance, contenido)
- Releases
- Cronograma General Por fases, Releases y Sitios
RESPONSABLE
Líder Funcional
128 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
129 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
ESTRATEGIA DE CONFIABILIZACIÓN
NOMBRE
Estrategia de Confiabilización
OBJETIVO
Establecer un plan de confiabilización en caso que sea necesario.
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................
Confiabilización de Datos
-
- Objetivo
- Validaciones a aplicar sobre la fuente
- Categorización y tipificación de errores
- Identificación de la Distribución física de los datos (dónde) y plataforma para
realizar la detección de errores.
- Definición de Módulos de Detección, Ordenamiento y Comparación de Datos
entre fuentes
- Esquema de corrección de datos sobre la fuente a confiabilizar
- Indicadores de permanencia de errores en la fuente
- Plan de Confiabilización
- Responsables
RESPONSABLE
Líder funcional
130 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
NOMBRE
Estrategia de Conversión de Datos
OBJETIVO
Establecer un plan de conversión de datos en caso que sea necesario.
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................
Conversión de Datos
-
- Identificación de información a ser convertida
- Identificación de fuente de obtención de nuevos datos
- Requerimientos de conversión
- Criterios de Conversión
- Modalidad
- Big bang
- Por etapas
- Dependencia y secuencialidad de procesos de conversión
- Criterios de depuración previos a la conversión
- Condiciones a probar para la conversión y lineamientos generales para la
prueba de conversión.
- Controles y criterios de aceptación de conversión
- Condiciones claves y estándares de conversión ; determinar valores a asumir
por defecto
- Plan de Conversión
- Documento de la Conversión
- Responsables
RESPONSABLE
Líder funcional
131 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
NOMBRE
Estrategia de Carga de Datos
OBJETIVO
Establecer un plan de Carga de Datos en caso que sea necesario.
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................
132 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
NOMBRE
Plan de Acción para el Cambio
OBJETIVO
Definir las acciones necesarias para abordar el impacto organizacional generado por la
implementación del Proyecto.
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................
133 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
PLAN DE CAPACITACIÓN
NOMBRE
Plan de Capacitación
OBJETIVO
Definir las acciones necesarias para capacitar a los actores involucrados
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................
Identificación
- del temario/contenido (procesos, funcionalidades del sistema,
seguridad del sistema, etc.)
- Herramientas
- Logística
- Salas
- Materiales
- Ambiente
- Datos
- Aplicación
- Server y Puestos de Trabajo
- Asistentes
- Modalidad
- Presencial
- A distancia
- Trainers/Formadores/Capacitadores (en caso de tratarse de una capacitación
presencial)
- Comunicación de la Capacitación
- Plan de Capacitación
RESPONSABLE
Responsable Capacitación
134 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
PLAN DE COMUNICACIÓN
NOMBRE
Plan de Comunicación
OBJETIVO
Definir las acciones necesarias para “comunicar”.
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................
135 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
FASE: CONSTRUCCIÓN
MANUAL DE SISTEMAS
NOMBRE
Manual de Sistemas
OBJETIVO
25
Documentar la información técnica del Sistema
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................
Notas:
25
El Manual de Sistemas deberá incluir la Especificación Técnica de Detalle (Diseño detallado) actualizada.
136 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
MANUAL DE USUARIO
NOMBRE
Manual de Usuario
OBJETIVO
Documentar las funcionalidades del sistema apuntadas al uso del mismo
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................
137 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
MANUAL DE PROCESOS
NOMBRE
Manual de Procesos
OBJETIVO
Describir el nuevo proceso/nueva forma de operación que implementará el proyecto
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................
26
- Descripción del Proceso
RESPONSABLE
Líder funcional + dueño del proceso
Notas:
26
La base de este manual son los procesos/sub-procesos definidos en la especificación funcional
138 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
PROTOCOLO DE PRUEBA
Se definirán protocolos para las distintas pruebas y sus respectivos informes:
- Prueba Individual
- Prueba de Cadena
- Prueba de Integración
- Prueba Global
- Prueba de Performance, stress, volumen y seguridad
- Prueba de Compatibilidad
NOMBRE
Protocolo de Prueba
OBJETIVO
Describir detalladamente los casos de prueba, los resultados esperados y obtenidos.
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................
- Objeto de la Prueba
- Procedimientos de Prueba
- Casos/ Condiciones detalladas de prueba (DTC):
- Descripción del caso
- Entorno
- Datos de Entrada
- Acciones
- Resultado esperado
- Resultado obtenido
27
- Observaciones
RESPONSABLE
Líder Informático (Prueba Individual, de Cadena, de Integración, de Performance, stress,
volumen y seguridad)
Líder funcional (Prueba Global)
Notas:
27
Se incluirán por ejemplo los pendientes de prueba.
139 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
APROBACIÓN DE PRUEBA
Se realizarán los informes de aprobación de prueba correspondientes a cada prueba:
- Prueba Individual
- Prueba de Cadena
- Prueba de Integración
- Prueba Global
- Prueba de Performance, stress, volumen y seguridad
- Prueba de Compatibilidad
NOMBRE
Aprobación de Prueba
OBJETIVO
Documentar la aprobación de la prueba
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................
Objeto de la Prueba
-
Resumen Ejecutivo del resultado de la prueba
-
Criterio de Aceptación
-
Prueba Aprobada
-
28
- Observaciones
- Prueba Rechazada
- Justificación
- Recomendación
RESPONSABLE
Líder Informático (Prueba Individual, de Cadena, de Integración, de Performance, stress,
volumen y seguridad)
Líder funcional (Prueba Global)
Notas:
28
Se incluirán por ejemplo los pendientes de prueba.
140 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
NOMBRE
Protocolo de Prueba Piloto
OBJETIVO
Describir detalladamente los casos de prueba a realizar en la Prueba Piloto, los
resultados esperados y los resultados obtenidos en la misma.
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................
Notas:
29
Se incluirán por ejemplo los pendientes de prueba.
141 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
NOMBRE
Homologación de Prueba Piloto
OBJETIVO
Documentar la aprobación y homologación de la prueba piloto
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................
Objeto de la Prueba
-
Resumen Ejecutivo del resultado de la prueba
-
Criterio de Aceptación
-
Prueba Aprobada
-
30
- Observaciones
- Prueba Rechazada
- Justificación
- Recomendación
RESPONSABLE
Líder funcional
Notas:
30
Se incluirán por ejemplo los pendientes de prueba.
142 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
PLAN DE IMPLANTACIÓN
NOMBRE
Plan de Implantación
OBJETIVO
Establecer el plan de implantación de un proyecto.
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................
143 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
PLAN DE SOPORTE
NOMBRE
Plan de Soporte
OBJETIVO
Establecer el plan de soporte a la implantación.
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................
- Objetivo y alcance
- Circuito de atención, recepción, diagnóstico, derivación y resolución de incidentes
- Identificación de nivel de criticidad de incidentes
- Tipo de soporte por sitio de implantación
- In situ
- Funcional
- Técnico
- Centralizado
- Funcional
- Técnico
- Disponibilidad y horario de atención de soporte por sitio
RESPONSABLE
Líder funcional / Líder informático
144 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
PROTOCOLO DE IMPLANTACIÓN
NOMBRE
Protocolo de Implantación
OBJETIVO
Definir el protocolo de pruebas para la Implantación
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................
Sitio
-
Procedimientos de Prueba
-
Documentación Asociada
-
Casos:
-
- Descripción del caso
- Entorno
- Datos de Entrada
- Acciones
- Resultado esperado
- Observaciones
RESPONSABLE
Líder funcional
145 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
PROCEDIMIENTO DE PRODUCCIÓN
NOMBRE
Procedimiento de Producción
OBJETIVO
Definir qué, cómo y cuándo se desarrollan las tareas de producción
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................
- Procedimientos de Backup
- Descripción
- Responsable
- Observaciones
- Procedimientos de Seguridad
- Descripción
- Responsable
- Observaciones
- Procedimientos de Performance
- Descripción
- Responsable
- Observaciones
- Control de Procedimientos Rutinarios
- Descripción
- Responsable
- Observaciones
- Anexo: Documentación de Soporte
- Documento de Soporte a Mesa de Ayuda
- Documento de Soporte a Operación/Soporte Técnico
RESPONSABLE
Líder informático
146 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
ACUERDO DE IMPLANTACIÓN
NOMBRE
Acuerdo de Implantación
OBJETIVO
Documentar la decisión de implantar el proyecto
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................
- Fecha
- Breve Descripción del Proyecto
- Responsables
- Firmas
- Observaciones
RESPONSABLE
Líder funcional
147 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
FASE: IMPLANTACIÓN
NOMBRE
Aprobación Conversión de Datos
OBJETIVO
Documentar la aprobación de la conversión de Datos
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................
- Criterio de Aceptación
- Muestreo estadístico
- Resumen de Volúmenes Convertidos
- Volumen Previo
- Volumen Final
- Tiempos de conversión
- Conversión Aprobada
- Observaciones
- Conversión Rechazada
- Justificación
- Recomendación
RESPONSABLE
Líder funcional
148 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
RECEPCIÓN PROVISORIA
NOMBRE
Recepción Provisoria
OBJETIVO
Documentar la Recepción Provisoria del Sistema (Aprobación), informando los
resultados de la Prueba de Aceptación del Mismo.
CONTENIDO
Fecha:.. ../....../......
Proyecto:...........................................................……..................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................
Notas:
31
Se incluirán por ejemplo los pendientes de prueba.
149 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
NOMBRE
Informe Sistema en Producción
OBJETIVO
Documentar Puesta en Producción de un Sistema
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................
150 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
FASE: PRODUCCIÓN
TABLERO DE MANDO
NOMBRE
Tablero de Mando
OBJETIVO
Presentar los indicadores para medir los procesos técnicos (seguridad, performance,
procesos rutinarios) y el soporte (atención a usuarios, soporte funcional, soporte técnico,
soporte aplicativo)
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................
- Procesos Técnicos
- Procesos de Seguridad
- Indicador 1
- Indicador n
- Procesos de Performance
- Indicador 1
- Indicador n
- Procesos Rutinarios
- Indicador 1
- Indicador n
- Soporte
- Atención de Usuarios
- Indicador 1
- Indicador n
- Soporte Funcional
- Indicador 1
- Indicador n
RESPONSABLE
El Tablero de Mando será completado por el responsable de cada proceso.
El contrato de servicio de producción define los indicadores del tablero de mando, la metodología de
medición, responsable de medición.
151 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
152 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
A continuación, se adjunta el archivo con el modelo completo (incluye todas las tareas descriptas en la
Guía de Gestión de Proyectos de Sistemas):
153 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
154 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
ACUERDO y CONTRATO
de SERVICIO
155 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
MODELO
....................................................................................………………………..
....................................................................................………………………..
156 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
1.1. El presente acuerdo tiene por objeto fijar los términos y condiciones del servicio de provisión de la
solución informática <nombre-solución-informática> ………………………...
..........................................................................................................................................................................
......................................................................................................................................
SERVICIOS A PRESTAR
Describir los entregables, tareas y responsabilidades de acuerdo a la Guía de Gestión de Proyectos
de Sistemas.
2.1. Servicios. Describir completamente los servicios a prestar (contenido, tipo, forma, etc.)
(Enumerar los entregables a cargo del proveedor)
2.2. Obligaciones del PROVEEDOR. Describir todas las obligaciones que deberá cumplir el proveedor
para la prestación del servicio objeto del presente contrato (modalidad de intervención, modo de
requerimiento, etc.)
(Enumerar las tareas y responsabilidades del proveedor para cumplir con lo enunciado en 2.1)
2.3. Obligaciones del CLIENTE. Describir todas las obligaciones que deberá cumplir el cliente
(especificaciones, cooperación, asistencia, etc.)
(Enumerar los entregables, tareas y responsabilidades del cliente para cumplir con lo enunciado en
2.1)
2.4. Procesos. Describir y/o referenciar el/los proceso/s asociado/s al servicio objeto de este contrato.
2.5. Elementos que intervienen para la prestación. En caso de necesitar identificar dichos elementos se
deberá utilizar un formulario Anexo, indicando en cada caso tipos de equipos, cantidades, números de
serie, ubicación precisa, etc. Asimismo, en caso de producirse modificaciones en los elementos deberá
incluirse la modificación en el Anexo mencionado previamente. En este caso se detallarán altas, bajas y
modificaciones de equipos. En ningún caso el PROVEEDOR podrá producir modificaciones sin recibir
autorización formal por parte del CLIENTE.
2.6. Formas de Intervención. El CLIENTE definirá las actuaciones que deberá realizar el PROVEEDOR
para intervenir (como por ejemplo, retrasos en el cumplimiento de plazos acordados). A los fines de estas
actuaciones regirán los tiempos indicativos detallados en un Anexo a tal efecto. Asimismo, el proveedor
deberá informar al cliente de manera fehaciente los avances y tiempos estimados de cada intervención.
2.7. Ámbito. Determinar los lugares para la prestación, que se detallarán en un Anexo. Deberá
mantenerse actualizado con las modificaciones, de existir.
2.8. Pruebas de aceptación. El PROVEEDOR se compromete a informar por escrito la finalización de las
tareas vinculadas a este servicio, a efectos de que el CLIENTE dé comienzo a las pruebas de aceptación
respectivas. Si se le solicitara al PROVEEDOR participar de las mismas, se le informará de esta situación
en tiempo y forma, debiendo el mismo confirmar de igual modo su disponibilidad.
En este punto se describirán las condiciones de la Aceptación de la Implantación y la Generación del
Documento de Recepción Provisoria del Proyecto (previo a la Puesta en Producción).
157 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
ROLES INTERVINIENTES
En el anexo de descripción de roles, se detallarán los nombres y sectores de la organización que
cumplen cada rol.
En el caso en que un rol sea llevado a cabo por más de una persona o por más de un sector, se
identificará claramente las responsabilidades de cada sector y persona o grupo de personas.
3.1. PROVEEDOR. Identificar con nombre, rol, dirección, teléfono y e-mail de las personas que
intervendrán para brindar el servicio. Esta información deberá ser completada en una ficha.
El PROVEEDOR presentará al CLIENTE en un Anexo al presente dicha ficha, que deberá ser actualizado
por el PROVEEDOR toda vez que correspondiere.
La modificación de la nómina de personal no altera la responsabilidad del PROVEEDOR en cuanto a
confidencialidad y daños emergentes por acción u omisión.
Asimismo, deberá el PROVEEDOR, informar con la debida anticipación los listados correspondientes al
personal que se encuentre disponible para su convocatoria.
3.2. CLIENTE. Identificar el o los responsables de interactuar con el proveedor. Para ello se deberá
completar con nombre, rol, dirección y teléfono la ficha que se encuentra en un Anexo.
El CLIENTE presentará al PROVEEDOR la ficha indicada, que deberá ser actualizada por el CLIENTE
toda vez que correspondiere.
4.1. Describir otros servicios adicionales (esquema de seguimiento, etc.) que estén involucrados y que no
formen parte del Servicio objeto del presente contrato.
4.2. Seguimiento de Proyecto. Se acordarán entre las partes la metodología de seguimiento de proyectos.
Se definirán los indicadores de seguimiento:
- Desvío de Presupuesto
- Desvío de Plazos
- Desvío de funciones entregados respecto a funcionalidades solicitadas
- Incidentes
- Otros
4.3. Se detallará en un Anexo los informes preestablecidos (frecuencia de prestación, etc.) con los
tiempos previstos de solicitud. Cualquier otro informe deberá acordarse en el momento por ambas
PARTES.
4.4. Ambas PARTES pueden proveer o solicitar nuevos servicios no comprendidos en el presente
contrato, pero que se desprendan del objeto del mismo.
En ese caso, el CLIENTE deberá realizar una descripción del servicio y deberá enviar tal descripción al
PROVEEDOR quien notificará al CLIENTE, a los _____ días, si desea proceder a la negociación de la
inclusión del nuevo servicio.
Si ambas PARTES deciden continuar para la prestación del nuevo servicio, se propondrá una definición
del servicio, precios y tiempos.
4.5 El presente contrato puede ser modificado o ajustado de común acuerdo de las partes.
5.1. Entre las PARTES se establecerán los datos de prestación y contraprestación del servicio contratado,
registrando al inicio del contrato, los insumos, gastos imprescindibles, viáticos, horas extras, guardias
pasivas y todo aquel que fuera necesario detallar. Dichos precios se especificarán en un Anexo,
diferenciando aquellos de única vez (no recurrentes) de los periódicos (recurrentes), indicando para
estos últimos expresamente la periodicidad de cada cargo.
158 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
5.2. El CLIENTE efectuará las transferencias presupuestarias que surjan de las prestaciones solicitadas al
PROVEEDOR, contra conformidad del CLIENTE del servicio entregado. En el caso de trabajos adicionales
requeridos por el CLIENTE, el PROVEEDOR contestará formalmente la posibilidad de hacerlo en tiempo y
forma y cotizará las tareas para que se efectúen las transferencias presupuestarias y de hs.
extraordinarias en caso de necesidad.
6.2. Indicadores. Los indicadores de evaluación y seguimiento del presente contrato deberán detallarse en
un Anexo.
Se definirán los reportes de monitoreo, el tablero de mando y los indicadores que lo componen, junto
con los responsables de medición, valores de referencia, umbrales.
Se identificarán aquellos indicadores correspondientes a la performance de los aspectos técnicos del
sistema y al soporte (a usuarios, funcional, técnico, aplicativo). A través de estos indicadores se
medirán los servicios que el proveedor está prestando.
RESPONSABILIDADES
7.1. El PROVEEDOR deberá disponer de los medios para prestar el servicio. El CLIENTE deberá brindar
las condiciones para que el PROVEEDOR pueda dar el servicio de acuerdo al nivel de calidad acordado.
7.2. Las PARTES se obligan a cumplir estrictamente toda disposición reglamentaria y demás normas,
procedimientos y políticas de la compañía dictadas o a dictarse por el sector competente y que resulte
aplicable.
7.3. Ninguna de las PARTES será responsable por los retrasos o fallas de operación o performance
derivadas de actos o hechos ajenos al control de cada parte.
7.4. La parte afectada por un evento de caso fortuito o fuerza mayor, deberá notificar rápida y
fehacientemente a la otra acerca de todo retraso o falla que origine hasta que desaparezca el evento que
lo causa. La parte afectada actuará de buena fe para solucionar la causa de retraso o falla, y ambas partes
procederán con diligencia una vez que la causa del retraso o falla haya cesado o desaparecido.
REGISTRACIÓN Y COMUNICACIÓN
8.1. Las PARTES se comprometen a divulgar en los sectores intervinientes ,incluyendo las áreas de
Calidad corporativas así como las propias de los sectores que participan en el contrato, la firma del
presente contrato, de conformidad con las disposiciones de la normativa vigente.
159 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
VIGENCIA
9.1. El presente contrato tendrá vigencia desde __________ y hasta __________ (de acuerdo al plan de
proyecto). Finalizada, o antes de finalizada la vigencia del presente contrato, las PARTES en forma
expresa podrán decidir la prórroga del Contrato o, en su caso, la celebración de otro.
9.2. Como excepción al plazo de vigencia fijado en el punto anterior, se pacta que: cesará la vigencia de
este Contrato, si existiere una situación no prevista que altere significativamente la voluntad bilateral
articulada en el presente, y ante ello, cualquiera de las PARTES optase por denunciar el Contrato
comunicándolo fehacientemente a la otra, dentro de los ______ días de serle notificada aquella situación.
9.3. Si en algún hito go no-go del proyecto se acuerda no continuar con el mismo, de común acuerdo entre
las partes cesará la vigencia del acuerdo.
10.1. El PROVEEDOR garantizará todo defecto atribuible a su intervención por un período acordado
por las PARTES medido en días corridos, contados a partir del momento en que el CLENTE verifique
el normal funcionamiento del servicio intervenido, lo cual conlleva implícito la no reiteración de la
intervención por un mismo motivo atribuible a fallas por la propia intervención del PROVEEDOR.
CONDUCTAS FRAUDULENTA
11.1. Las PARTES acuerdan trabajar estrechamente y en forma conjunta para combatir el uso
fraudulento del servicio objeto del presente contrato, o consecuencia derivada de éste.
12.1. Las PARTES no podrán transferir ni ceder en todo o en parte, a título gratuito u oneroso, el
presente contrato, salvo expresa autorización formal por parte de la otra PARTE.
13.2. En el caso de incumplimiento de obligaciones estipuladas en este contrato (con respecto a los
plazos e indicadores), el CLIENTE deberá intimar al PROVEEDOR a subsanar la situación en un
plazo que de acuerdo a la circunstancia resulte razonable.
CONFIDENCIALIDAD
14.1. Toda la información que sea intercambiada en virtud del presente, será tratada en forma
confidencial.
14.2. En tal sentido, las PARTES se comprometen a tratar en forma confidencial toda información técnica,
comercial, referida a los sistemas, ingeniería, datos técnicos, registros comerciales, correspondencia,
datos sobre costos, listas de clientes, etc., que resulte de la solicitud de cualquiera de las PARTES.
160 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
ORGANISMO DE CONTROL.
15.1. Se designa como Organismo de Control, a todos los efectos que diere lugar el presente
contrato a ..........................................................................................................................….
COMPETENCIA
16.1. Las PARTES se comprometen a cumplir el presente contrato de buena fe. Sin embargo ante
cualquier controversia o reclamo relativo a la interpretación, aplicación, revisión o consecuencias del
mismo, que no pudieran resolverse mediante negociaciones amigables entre las PARTES, se elevará
al Organismo de Control la petición de arbitraje correspondiente.
161 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
MODELO
......................................................................................................................
Y <el usuario>..........................................................................................
......................................................................................................................
1.1. El presente acuerdo tiene por objeto fijar los términos y condiciones del servicio de
..........................................................................................................................................................................
..........................................................................................................................................................................
....................................................................................................................
162 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
SERVICIOS A PRESTAR
Definir los servicios a prestar basándose en los entregables del Proyecto definidos en la Guía de
Gestión (Documentación de Puesta en Producción, Procedimiento de Producción, Planes de backup,
Planes de Contingencia, Pliego de Compra, etc.)
La descripción del servicio, deberá contener mínimamente estos ítems:
2.2. Obligaciones del PROVEEDOR. Describir todas las obligaciones que deberá cumplir el proveedor
para la prestación del servicio objeto del presente acuerdo (modalidad de intervención, modo de
requerimiento, etc.)
2.3. Obligaciones del CLIENTE. Describir todas las obligaciones que deberá cumplir el cliente
(especificaciones, cooperación, asistencia, etc.)
2.4. Procesos. Describir y/o referenciar el/los proceso/s asociado/s al servicio objeto de este acuerdo.
2.5. Elementos que intervienen para la prestación. En caso de necesitar identificar dichos elementos se
deberá utilizar un formulario Anexo, indicando en cada caso tipos de equipos, cantidades, números de
serie, ubicación precisa, etc. Asimismo, en caso de producirse modificaciones en los elementos deberá
incluirse la modificación en el Anexo mencionado previamente. En este caso se detallarán altas, bajas y
modificaciones de equipos. En ningún caso el PROVEEDOR podrá producir modificaciones sin recibir
autorización formal por parte del CLIENTE.
2.6. Formas de Intervención. El CLIENTE definirá las actuaciones que deberá realizar el PROVEEDOR
para intervenir (como por ejemplo, para restitución de un servicio interrumpido). A los fines de estas
actuaciones regirán los tiempos indicativos detallados en un Anexo a tal efecto. Asimismo, el proveedor
deberá informar al cliente de manera fehaciente los avances y tiempos estimados de cada intervención.
2.7. Ámbito. Determinar los lugares para la prestación, que se detallarán en un Anexo. Deberá
mantenerse actualizado con las modificaciones, de existir.
2.8. Pruebas de aceptación. El PROVEEDOR se compromete a informar por escrito la finalización de las
tareas vinculadas a este servicio, a efectos de que el CLIENTE dé comienzo a las pruebas de aceptación
respectivas. Si se le solicitara al PROVEEDOR participar de las mismas, se le informará de esta situación
en tiempo y forma, debiendo el mismo confirmar de igual modo su disponibilidad.
ROLES INTERVINIENTES
En el anexo de descripción de roles, se detallarán los nombres y sectores de la organización que
cumplen cada rol.
En el caso en que un rol sea llevado a cabo por más de una persona o por más de un sector, se
identificará claramente las responsabilidades de cada sector y persona o grupo de personas.
3.1. PROVEEDOR. Identificar con nombre, rol, dirección, teléfono y e-mail de las personas que
intervendrán para brindar el servicio. Esta información deberá ser completada en una ficha.
163 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
El PROVEEDOR presentará al CLIENTE en un Anexo al presente dicha ficha, que deberá ser actualizado
por el PROVEEDOR toda vez que correspondiere.
La modificación de la nómina de personal no altera la responsabilidad del PROVEEDOR en cuanto a
confidencialidad y daños emergentes por acción u omisión.
Asimismo, deberá el PROVEEDOR, informar con la debida anticipación los listados correspondientes al
personal que se encuentre disponible para su convocatoria.
3.2. CLIENTE. Identificar el o los responsables de interactuar con el proveedor. Para ello se deberá
completar con nombre, rol, dirección y teléfono la ficha que se encuentra en un Anexo.
El CLIENTE presentará al PROVEEDOR la ficha indicada, que deberá ser actualizada por el CLIENTE
toda vez que correspondiere.
4.1. Describir otros servicios adicionales (capacitación, energía, horarios, etc.) que estén involucrados y
que no formen parte del Servicio objeto del presente acuerdo.
4.2. Capacitación. El CLIENTE brindará capacitación ante requerimiento del PROVEEDOR, de acuerdo a
temarios vigentes y según modalidad que se establezca para cada caso. El PROVEEDOR se compromete
a presentar al CLIENTE el plan de capacitación anual o específico requerido.
4.3. El CLIENTE se reserva el derecho de requerir al PROVEEDOR los informes vinculados que estime
conveniente respecto de sus actuaciones. Se detallará en un Anexo los informes preestablecidos, con los
tiempos previstos de solicitud. Cualquier otro informe deberá acordarse en el momento por ambas
PARTES.
4.4. Ambas PARTES pueden proveer o solicitar nuevos servicios no comprendidos en el presente
acuerdo, pero que se desprendan del objeto del mismo.
En ese caso, el CLIENTE deberá realizar una descripción del servicio y deberá enviar tal descripción al
PROVEEDOR quien notificará al CLIENTE, a los _____ días, si desea proceder a la negociación de la
inclusión del nuevo servicio.
Si ambas PARTES deciden continuar para la prestación del nuevo servicio, se propondrá una definición
del servicio, precios y tiempos.
4.5 El presente acuerdo puede ser modificado o ajustado de común acuerdo de las partes.
5.1. Entre las PARTES se establecerán los datos de prestación y contraprestación del servicio contratado,
registrando al inicio del acuerdo, los insumos, gastos imprescindibles, viáticos, horas extras, guardias
pasivas y todo aquel que fuera necesario detallar. Dichos precios se especificarán en un Anexo,
diferenciando aquellos de única vez (no recurrentes) de los periódicos (recurrentes), indicando para
estos últimos expresamente la periodicidad de cada cargo.
5.2. El CLIENTE efectuará las transferencias presupuestarias que surjan de las prestaciones solicitadas al
PROVEEDOR, contra conformidad del CLIENTE del servicio entregado. En el caso de trabajos adicionales
requeridos por el CLIENTE, el PROVEEDOR contestará formalmente la posibilidad de hacerlo en tiempo y
forma y cotizará las tareas para que se efectúen las transferencias presupuestarias y de hs.
extraordinarias en caso de necesidad.
164 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
Deberán ser establecidas explícitamente tomando como base los indicadores de calidad de servicio
que se definan en el ítem 6.2. del presente, contemplando los rangos y/o escalas que para los
mismos AMBAS PARTES definan y acuerden.
Se clasificarán en:
5.3.1. Penalidades para el CLIENTE
5.3.2. Penalidades para el PROVEEDOR.
En ambos casos, las penalidades definidas y acordadas deberán guardar coherencia en un todo con
las responsabilidades específicas detalladas según lo sugerido en el ítem 7.
6.1. Satisfacción del cliente. El CLIENTE se reserva el derecho de realizar las encuestas de satisfacción a
clientes (internos y/o externos) que estime necesarias.
6.2. Indicadores. Los indicadores de evaluación y seguimiento del presente acuerdo deberán detallarse en
un Anexo.
Se definirán los reportes de monitoreo, el tablero de mando y los indicadores que lo componen, junto
con los responsables de medición, valores de referencia, umbrales.
Se identificarán aquellos indicadores correspondientes a la performance de los aspectos técnicos del
sistema y al soporte (a usuarios, funcional, técnico, aplicativo). A través de estos indicadores se
medirán los servicios que el proveedor está prestando.
RESPONSABILIDADES
7.1. El PROVEEDOR deberá disponer de los medios para prestar el servicio. El CLIENTE deberá brindar
las condiciones para que el PROVEEDOR pueda dar el servicio de acuerdo al nivel de calidad acordado.
7.2. Las PARTES se obligan a cumplir estrictamente toda disposición reglamentaria y demás normas,
procedimientos y políticas de la compañía dictadas o a dictarse por el sector competente y que resulte
aplicable.
7.3. Ninguna de las PARTES será responsable por los retrasos o fallas de operación o performance
derivadas de actos o hechos ajenos al control de cada parte.
7.4. La parte afectada por un evento de caso fortuito o fuerza mayor, deberá notificar rápida y
fehacientemente a la otra acerca de todo retraso o falla que origine hasta que desaparezca el evento que
lo causa. La parte afectada actuará de buena fe para solucionar la causa de retraso o falla, y ambas partes
procederán con diligencia una vez que la causa del retraso o falla haya cesado o desaparecido.
7.5. El PROVEEDOR tomará las precauciones necesarias para evitar daños en los espacios y áreas
operativas, equipos y propiedades del CLIENTE.
REGISTRACIÓN Y COMUNICACIÓN
8.1. Las PARTES se comprometen a divulgar en los sectores intervinientes ,incluyendo las áreas de
Calidad corporativas así como las propias de los sectores que participan en el acuerdo, la firma del
presente acuerdo, de conformidad con las disposiciones de la normativa vigente.
VIGENCIA
9.1. El presente acuerdo tendrá vigencia por un período de __________ a partir de la fecha de su
suscripción. Finalizada, o hasta un mes antes de finalizada la vigencia del presente acuerdo, las PARTES
en forma expresa podrán decidir la prórroga del Acuerdo o, en su caso, la celebración de otro.
165 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
9.2. Como excepción al plazo de vigencia fijado en el punto anterior, se pacta que: cesará la vigencia de
este Acuerdo, si existiere una situación no prevista que altere significativamente la voluntad bilateral
articulada en el presente, y ante ello, cualquiera de las PARTES optase por denunciar el Acuerdo
comunicándolo fehacientemente a la otra, dentro de los ______ días de serle notificada aquella situación.
10.1. El PROVEEDOR garantizará todo defecto atribuible a su intervención por un período acordado
por las PARTES medido en días corridos, contados a partir del momento en que el CLENTE verifique
el normal funcionamiento del servicio intervenido, lo cual conlleva implícito la no reiteración de la
intervención por un mismo motivo atribuible a fallas por la propia intervención del PROVEEDOR.
CONDUCTAS FRAUDULENTAS
11.1. Las PARTES acuerdan trabajar estrechamente y en forma conjunta para combatir el uso
fraudulento del servicio objeto del presente acuerdo, o consecuencia derivada de éste.
12.1. Las PARTES no podrán transferir ni ceder en todo o en parte, a título gratuito u oneroso, el
presente acuerdo, salvo expresa autorización formal por parte de la otra PARTE.
13.2. En el caso de incumplimiento de obligaciones estipuladas en este acuerdo (con respecto a los
plazos e indicadores), el CLIENTE deberá intimar al PROVEEDOR a subsanar la situación en un
plazo que de acuerdo a la circunstancia resulte razonable.
CONFIDENCIALIDAD
14.1. Toda la información que sea intercambiada en virtud del presente, será tratada en forma
confidencial.
14.2. En tal sentido, las PARTES se comprometen a tratar en forma confidencial toda información técnica,
comercial, referida a los sistemas, ingeniería, datos técnicos, registros comerciales, correspondencia,
datos sobre costos, listas de clientes, etc., que resulte de la solicitud de cualquiera de las PARTES.
ORGANISMO DE CONTROL.
166 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
15.1. Se designa como Organismo de Control, a todos los efectos que diere lugar el presente
acuerdo a ..........................................................................................................................….
COMPETENCIA
16.1. Las PARTES se comprometen a cumplir el presente acuerdo de buena fe. Sin embargo ante
cualquier controversia o reclamo relativo a la interpretación, aplicación, revisión o consecuencias del
mismo, que no pudieran resolverse mediante negociaciones amigables entre las PARTES, se elevará
al Organismo de Control la petición de arbitraje correspondiente.
167 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
168 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
Anexo XXX
Cuestionarios
169 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
FINALIDAD: identificar las exigencias del Cliente y organizar / planificar las actividades.
Cuestionario C1
Identificación de objetivos
Fecha:
Proceso:
Requisitos:
Resultados
previstos:
Instrumentos:
7.1.1.1 DESCRIPCIÓN
Requisitos: El Dueño del Proceso debe expresar cuidadosamente sus requisitos y los resultados
que espera obtener a través de la aplicación de la Metodología.
170 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
FINALIDAD: determinar el “perfil” del Nivel Objetivo / Supuesto del proceso examinado.
DESCRIPCIÓN: el cuestionario retoma los atributos de los niveles de un proceso, los ordena
lógicamente y los traduce en preguntas a proponer al entrevistado para evaluar el perfil del nivel objetivo /
supuesto. Las preguntas se deben referir al tiempo final (instancia a la cual el dueño piensa alcanzar el
objetivo) identificado con el Dueño. El tiempo final puede ser hoy si la evaluación debe medir la distancia
entre “lo que piensa el Dueño del proceso” (en este caso el nivel es supuesto) y “lo que es efectivamente
el proceso actual o real”. El tiempo final puede ser, en cambio, el momento que el Dueño define como
objetivo para efectuar una acción de mejora, una reestructuración organizativa, una acción de reingeniería,
etc. (está relacionado con el nivel objetivo). En este caso la Metodología debe medir la distancia entre la
madurez del proceso actual y la misma del proceso objetivo. Las posibles respuestas a las preguntas del
cuestionario C2 son: “SÍ”,”NO”, o “NA” (No Aplicable: si la pregunta no tiene sentido en el contexto
analizado). Se reserva un espacio de “Notas” para eventuales consideraciones (a solicitar). El perfil
objetivo identificado puede coincidir con uno de los niveles definidos o ser intermedio entre dos o más de
estos.
APLICACIÓN: se completa con el Dueño del Proceso en la fase Planeamiento si se requiere evaluar
la distancia entre el Nivel actual y el objetivo / supuesto.
7.1.1.2 DESCRIPCIÓN
171 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
172 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
DESCRIPCIÓN: el cuestionario retoma los atributos de los niveles de un proceso, los ordena
lógicamente y los traduce en preguntas a proponer al entrevistado para evaluar el perfil del nivel actual.
Las posibles respuestas son: “SÍ”, “Parcialmente / Si, no univoco”, ”NO”, o “NA” (No Aplicable: si la
pregunta no tiene sentido en el contexto analizado). Se reserva un espacio para eventuales
consideraciones. El perfil identificado puede coincidir con uno de los niveles definidos o ser intermedio
entre dos o más de estos.
APLICACIÓN: se compila con los personales operativos del Proceso en la fase Relevamiento.
7.1.1.3 DESCRIPCIÓN
173 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
174 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
175 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
176 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
32
Cuestionario C4 – Nivel X: Descripción del Proceso
DESCRIPCIÓN: hay un cuestionario C4 por cada nivel objetivo. El cuestionario tiene la finalidad de
identificar las características del Proceso actual y, eventualmente, de evaluar el grado de las mismas a
través de la visión del personal operativo entrevistado. La descripción de cada pregunta se presenta en
gris en la tabla.
33
APLICACIÓN: se completa con el personal operativo del Proceso (a excepción del “C4-4 Parte II”
que se completa con los Dueños, porque se refiere a la Gestión Estratégica) en la Fase: Relevamiento.
34
Cuestionario C4 - Nivel 4 PARTE II (Dueños)
FINALIDAD: puntualizar detalles en la Gestión del Proceso (en particular acerca de “indicadores”) si
existen mas Dueños involucrados en el análisis (por ejemplo cuando se analizan dos procesos
relacionados para identificar problemas en las interfases).
DESCRIPCIÓN: identifica el grado de “dominio (control) sobre del proceso a través de indicadores”.
La descripción de cada pregunta se presenta en gris en la tabla.
APLICACIÓN: se completa con los
Notas:
32
Ver Anexo: Cuestionarios
33
Ver párrafo siguiente.
34
Ver Anexo: Cuestionarios
177 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
GLOSARIO
178 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
GLOSARIO
ABM Altas, Bajas y Modificaciones. Son funcionalidades que ofrece un sistema para
ingresar, eliminar y actualizar registros.
BD Base de Datos
Big Bang Modalidad de puesta en producción que se realiza para todos los clientes,
líneas, etc. en forma conjunta
Business Plan Plan que considera inversiones, gastos iniciales, upgrades, capacitación,
mantenimiento de la aplicación, etc.
Condiciones de Derivan de los requerimientos funcionales y del usuario. Están compuestas por
Detalle de la condición que se va a probar y los resultados esperados de alto nivel
Prueba (DTC) asociados.
Coordinador Persona encargada de coordinar y llevar adelante todas las tareas dentro de
una etapa
DB Data base
DTC Derivan de los requerimientos funcionales y del usuario. Están compuestas por
(Condiciones de la condición que se va a probar y los resultados esperados de alta nivel
Detalle de asociados.
Prueba)
Entregables Son los documentos que se obtienen como resultado de la ejecución de las
tareas.
GST (Global Implica verificar que el conjunto de los desarrollos cubran los requerimientos
System Test) de negocio predefinidos.
Hito Punto de control que aparece al final de cada fase. Existen dos clases:
– Hito GO / NO GO: son aquellos donde se determinan la continuidad o no
del proyecto.
– Hito de validación: son aquellos que permiten validar y controlar la
realización de las tareas y de los entregables de una fase.
NOC / SOC Network Operation Center / Service Operation Center provee monitoreo de la
Red 24x7 asegurando que los eventuales inconvenientes sean rápidamente
identificados y resueltos
Proyecto Proyecto de sistemas es todo aquel que comienza con la identificación de una
necesidad y culmina con la implantación de la solución informática.
Prueba Caja Definir casos de prueba de modo tal que cada línea de código sea ejecutada y
Blanca cada condición de bifurcación o decisión del código sea alcanzada con todos
los casos posibles. Asegurar que cada punto de decisión sea pasado con su
valor mínimo, máximo y algún valor intermedio. Asegurar que todas las
condiciones de error que el módulo debe detectar sean correctamente
ejecutadas.
Prueba Caja Definir casos de prueba teniendo en cuenta la función que cada módulo
Negra cumple estableciendo datos de entrada al módulo y sus correspondientes
resultados esperados.
Rol Actividad que puede ser desarrollada por una persona o un grupo de personas
Sitio Web Es solo un conjunto de archivos relacionados entre sí, que puede estar
guardado en cualquier soporte magnético (disco rígido, cd, etc.). Para que este
180 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García
SO Sistema Operativo
TIR Tasa Interna de Retorno. Indicador económico que ayuda, junto con el VAN, a
determinar la rentabilidad de un proyecto
VAN Valor Anual Neto. Indicador económico que permite, junto con el TIR
determinar la rentabilidad de un proyecto.
Web Server Es decir un servidor conectado a Internet y que tiene como función servir
páginas web.
181 de 181