Sie sind auf Seite 1von 181

Sistemas de Información

Gestión de Proyectos Informáticos


Prof. Lic. Roberto García

METODOLOGÍA

para

DESARROLLO

de

SISTEMAS de INFORMACIÓN

Gestión de Proyectos

Teoría.doc 23/03/2011 1
ÍNDICE
OBJETIVO .................................................................................................................................... 4

ALCANCE ..................................................................................................................................... 4

LA EVOLUCIÓN DEL SOFTWARE ............................................................................................. 4

UNA PERSPECTIVA INDUSTRIAL ............................................................................................. 5

OBREROS DE LA FÁBRICA DE SOFTWARE. .......................................................................... 6

EL SOFTWARE ............................................................................................................................ 6

CARACTERÍSTICAS DEL SOFTWARE ...................................................................................... 6

ORGANIZACIÓN DEL EQUIPO DEL PROYECTO ................................................................... 10

ROLES DEL INGENIERO DEL SOFTWARE ............................................................................. 11

EQUIPO DE PROYECTO ........................................................................................................... 11

RESPONSABILIDADES ............................................................................................................. 12

INGENIERÍA DEL SOFTWARE .................................................................................................. 19

MODELOS DE PROCESO DEL SOFTWARE ........................................................................... 20

PRODUCTO Y PROCESO ......................................................................................................... 23

DIAGRAMA RESUMEN .............................................................................................................. 24

DIAGRAMA DE FASES .............................................................................................................. 25

DIAGRAMA DE ETAPAS, TAREAS Y ENTREGABLES POR FASE ....................................... 27

IMPLANTACIÓN Y CIERRE DEL PROYECTO ......................................................................... 35


DESCRIPCIÓN DE LAS FASES ............................................................................................. 38

FASE: ESTUDIO PRELIMINAR .............................................................................................. 39

FASE: ESTUDIO FACTIBILIDAD ........................................................................................... 40

FASE: DESCRIPCIÓN DE NECESIDADES ........................................................................... 46


DESCRIPCIÓN DE FASES ........................................................................................................ 47
FASE: DESCRIPCIÓN DE NECESIDADES .......................... ¡ERROR! M ARCADOR NO DEFINIDO.

FASE: DISEÑO GLOBAL ....................................................................................................... 55

FASE: PROCESO DE COMPRAS ......................................... ¡ERROR! M ARCADOR NO DEFINIDO.

FASE: DISEÑO DETALLADO ................................................................................................ 60

FASE: DISEÑO DETALLADO ................................................................................................ 61

FASE: CONSTRUCCIÓN ........................................................................................................ 74

FASE: CONSTRUCCIÓN ........................................................................................................ 75


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

FASE: PRODUCCIÓN ............................................................................................................. 91

FASE: BALANCE DEL PROYECTO....................................................................................... 95

CARPETA DE PROYECTOS ..................................................................................................... 97


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

ANEXO: MODELO DE PLAN DE PROYECTO ....................................................................... 153


ACUERDO DE SERVICIO DE PROYECTO ............................................................................................................ 156
CONTRATO DE SERVICIO DE PRODUCCIÓN ..................................................................................................... 162
MODELO ÚNICO DE CONTRATO DE SERVICIO .................................................................................................. 168

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

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

OBJETIVO Y ALCANCE

OBJETIVO
El objetivo de esta publicación es generar una guía para la gestión de proyectos informáticos
basados en el desarrollo de software y brindar un enfoque práctico para establecer los
lineamientos generales, el marco metodológico y los responsables en la gestión de un proyecto
a lo largo de todo el ciclo de vida del mismo..
Pretende servir a estudiantes y profesionales, brindando una introducción completa al tema de
la ingeniería de software.

El formato y estilo de esta primera edición está orientada tanto a los aspectos teóricos, como a
los prácticos; ya que se incluye fichas y documentos que se utilizan en los proyectos de
desarrollo de software.

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

LA EVOLUCIÓN DEL SOFTWARE


Roger S. Pressman, dice en su obra que el Software es a la vez un producto y el vehículo de
entrega de un producto.
Como producto puede residir en un teléfono celular inteligente o una computadora central
donde produce, transforma, adquiere, modifica muestra y transmite información tan compleja
como un bit o una presentación multimedia.

Como vehículo para hacer entrega del producto actúa como la base de control de una PC
(Sistema Operativo), la comunicación de información (Redes) y creación y control de otros
programas (Entornos y herramientas de programación).

A lo largo de mi carrera he leído en no poca bibliografía que la programación es “un arte”, y


quizás en algún modo lo sea, pero este “arte” no tiene nada de intuitivo ya que se basa en
teorías sólidas y metodologías probadas y adoptadas por la industria del software; de acuerdo
a las necesidades / motivaciones de las empresas que consume este “arte” (el software).

Es por ello que quienes estamos en el área de la enseñanza, debemos orientar y ayudar a
quienes quieren ser expertos en esta profesión fascinante a contextualizar el concepto de
“arte”.

Esta publicación pretende que los alumnos comprendan, dominen y fundamentalmente


apliquen técnicas y herramientas para crear desarrollos sólidos y perdurables con base en una
documentación orientada a la calidad, ya que es esto lo que las empresas requieren y
necesitan del software.

En lo que a mí respecta (y desde ya pido disculpas a quienes opinen diferente) el software


antes que creativo debe ser eficiente y eficaz, es decir cumplir con las necesidades de los
usuarios y que permita ser construido y mantenido con el mínimo costo y esfuerzo posible.

El software ha sufrido una serie de cambios importantes desde los años 50 del siglo pasado de
la mano de avances tecnológicos impresionantes.

En el comienzo de la era informática el desarrollo de software se realizaba prácticamente sin


planificación y con un esfuerzo enorme, el hardware era de propósito general y el software se
diseñaba a medida; la falta de documentación en los antiguos sistemas los hacía poco menos
que inentendibles para quienes no habían participado en su diseño y desarrollo.

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

Con el advenimiento de facilidades como la multiprogramación y los sistemas multiusuario se


abrió un nuevo mundo de aplicaciones, lo que generó una mayor sofisticación del hardware y
software.

Luego aparecieron los sistemas de tiempo real y la primera generación de sistemas de gestión
de bases de datos. El software a partir de allí se estableció como producto y tuvo una amplia
distribución.

Los aspectos de depuración comenzó a tener relevancia ya que la mayor complejidad y


diversidad en los sistemas provocaron la aparición de fallas y como consecuencia de esto
nació el mantenimiento.
Mayor complejidad, demanda, fallas y necesidades especificas, dio lugar al software
personalizado. El mantenimiento de este software dio lugar a una crisis en la construcción del
software.

Luego los sistemas de tiempo real y la primera generación de sistemas de gestión de bases de
datos aparecieron los sistemas distribuidos y las redes de área local y global que provocaron
una importante presión sobre los desarrolladores de software.
La aparición del microprocesador (ejemplo la familia PIC) produjo muchos productos
“inteligentes” (partes de automóviles, robots, artefactos del hogar, etc.) y la aparición de la
computadora personal con su formidable y rápido acceso para él público masivo impactó
fuertemente en el desarrollo del software.

Hace ya mucho tiempo se supero el concepto de las computadoras individuales y se oriento al


uso colectivo de computadoras y software. Los entornos centralizados pasaron a ser
cliente/servidor, la aparición de Internet facilitó la aparición de las tecnologías orientadas a
objetos, los sistemas expertos y el software de inteligencia artificial.

Como seguramente el lector podrá percibir en la muy apretada síntesis hasta aquí desarrollada,
los problemas relacionados con el software han persistido a lo largo de la evolución de los
sistemas informáticos y lastimosamente continúan aumentando. Los motivos del aumento en la
problemática del desarrollo del software tiene múltiple aristas.

1. Las empresas requieren un software que explote más y mejor el hardware (que día a
día es más sofisticado y especifico)
2. Los desarrolladores se ven expuestos a esta “carrera” (en términos de adquirir
habilidades) para satisfacer la demanda de este nuevo software.
3. Las empresas y aún los individuos comunes se han hecho dependientes al software.
(imaginen no más lo que significa el uso de los productos como Cajeros automáticos,
Pagos de servicios, Compras vía internet, o Webs Banking si fallaran)
4. La comunidad de desarrolladores lucha por la construcción de un software confiable.
5. Lo anteriormente mencionado impacta en la habilidad de soportar el desarrollo con
diseños pobres, documentación inadecuada y falta de recursos apropiados.

Una perspectiva industrial


Al principio el software se utilizaba para gestionar el hardware que era el factor principal en el
presupuesto del proyecto. Por tal motivo, se aplicaron controles, métodos y herramientas
conocidas como ingeniería del hardware y el software no era más que un añadido.

En relación con lo mencionado, es muy lógico que a la programación se la asociara a “un arte”
ya que existía muy pocos métodos formales.
Actualmente la construcción del software es en cuanto al costo de un proyecto el elemento mas
importante.
Cabe aquí cuestionar (en función de orientar al lector novel) ¿ Por qué se demora tanto tiempo
en crear el software?, ¿ Por qué es tan oneroso?, ¿ Porque el software cuando se implementa
no se encuentra libre de errores? (lo que aumenta el costo de mantenimiento de los sistemas).

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

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

Obreros de la fábrica de software.


Los “obreros del bit”, nuestros queridos ingenieros del software deben poseer herramientas
metodológicas basadas en teorías sólidas para lograr la creación y renovación de aplicaciones.

El ingeniero del software debe tener métodos y herramientas para asegurar la calidad y el
mantenimiento de los costos dentro de la razonabilidad que las empresas puedan destinar de
su presupuesto para obtener un software que sea sustentable.

Las aplicaciones que utilizan datos críticos de la organización debe tener una consideración
particular por parte del ingeniero de sistema (y por ende técnicas y herramientas específicas) a
fin de resguardar lo más precioso que tiene una empresa (sus datos y el software que contiene
las reglas de su negocio).

Un aspecto sobre el cual los ingenieros del software deben tener especial atención es la
criticidad en cuanto al uso de los sistemas en una empresa. La salida de servicio de sistemas
sensibles de una organización implica la pérdida de enormes sumas de dinero.
En este aspecto los ingenieros del software deberán comprender y utilizar las recomendaciones
de entes dedicados al aseguramiento de la calidad y productividad como las normas ISO e
ITIL.

Sin la intención de que lo expuesto sea toda las “preocupaciones” que los ingenieros deban
atender (de hecho no se mencionó aspectos de seguridad y conectividad entre otros), es
necesario que el lector comprenda la multiplicidad de aspectos que deberá resolver como
“obrero del bit”; de allí la necesidad de apegarse a los métodos, el desarrollo de técnicas y el
estricto uso de las herramientas de diseño y construcción de un software.

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

Creo conveniente y estimo necesario considerar algo más que la mencionada definición formal
y para ello exploraremos los siguientes aspectos.

Características del software


Cuando el ingeniero del software construye un software mediante el proceso creativo (análisis,
diseño, construcción, etc.) se traduce finalmente en una forma física. El software es un
elemento del sistema que es lógico en lugar de físico por lo tanto:

a) El software se desarrolla, no se fabrica. La fase de construcción del software depende de


la completitud de la fase de descripción de las necesidades y cuando digo completitud me
refiero a que no puede existir faltantes en cuanto a la funcionalidad pretendida como a la
documentación detallada de cada función pretendida.
Es necesario comprender el concepto “de lo general a lo particular” ya que el desarrollador
NECESITA todos los detalles funcionales para proceder a la escritura del código y NO DEBE

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

“crear intuitivamente” la funcionalidad del sistema (en esto me baso en cuestionar el concepto
de “arte”).
Para asegurar el desarrollo del software, es necesario el apego irrestricto al uso de una
metodología y utilización de sus herramientas.

b) El software no se estropea. La falla en el software es consecuencia directa de los defectos


en el análisis y diseño del mismo refiriéndonos a la funcionalidad que se espera que cumpla.
No es menos importarte (es crucial) efectuar un buen diseño de las pruebas que será sometido
el software para asegurar su funcionalidad antes de su puesta en producción.
Como un componente vital que se incluye en el proceso de pruebas es diseñar un adecuado
circuito para resolver las no conformidades que se detecten a fin de que estos se resuelvan.

Es muy importante que el lector observe que los defectos no detectados del software, hacen
que el mismo falle durante las primeras etapas de su vida, de allí la necesidad de una
estrategia consistente para evitar la aparición de errores en la puesta en producción.
Es muy obvio que el ingeniero del software pondrá especial atención a la corrección (sin
introducir nuevos errores), para asegurar que estos no vuelven a aparecer.

Lamentablemente el software en producción, se deteriora. ¿el motivo? El software esta


sometido a las solicitudes de cambios por mantenimiento.
Las solicitudes de cambio por mantenimiento puede ser por nuevas necesidades o correctivos
a funciones existentes.
La introducción de solicitudes de cambios puede generar nuevos defectos que antes de que
desaparezcan se solicita un nuevo cambio que introduce nuevos errores y así sucesivamente;
esto provoca que el mantenimiento del software tiene una complejidad que debe ser tenida
muy en cuenta.

c) Componentes del Software


Cuando se diseña nuevo software se utilizan los llamados CI‟s,(ítems Componentes) estos
componentes estándares pueden ser reutilizables y son creados por el ingeniero del software
para utilizarlo en diferentes lugares de la aplicación.
La reutilización de componentes (CI‟s), permite minimizar la tasa de errores (un componente
siempre se comporta de igual modo) y redunda en una mayor productividad (generado una sola
vez es utilizado en múltiples lugares).

d) Aplicaciones del Software


El software puede construirse siempre que se haya previamente definido un conjunto especifico
de pasos procedimentales (algoritmo).
Se debe tener en cuenta el contenido, es decir el significado y forma de la información de
entrada y salida.
Otro aspecto es el determinismo, predecibilidad del orden y del tiempo de llegada de los datos;
los datos llegan en orden y se ejecuta un proceso.

e) Software de gestión
El procesamiento de información comercial es el área de mayor desarrollo de aplicaciones. Los
sistemas (inventarios, producción, contables, facturación, RRHH, etc.) han evolucionado hacia
el software de sistemas de información de gestión (conocidos como ERP) que accede a una o
más bases de datos donde está contenida la información comercial para facilitar la toma de
decisiones.

f) Crisis en el desarrollo del software.


La definición de crisis como el punto decisivo sobre los problemas que un ingeniero del
software deberá afrontar en el desarrollo del software, no se limita al software que no funciona,
si no que abarca los problemas asociados a como desarrollar software, como mantener el
software existente y como afrontar la demanda creciente.

ESTRUCTURA DE LA GUÍA DE GESTIÓN

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

Con el propósito de generar una metodología que acompañe el esfuerzo del ingeniero del
software en la creación de aplicaciones a continuación se presenta la estructura de la misma.

Niveles de Desagregación
Esta guía propone 3 niveles de desagregación, donde la entidad FASE es la que reviste mayor
peso como entidad. Las etapas comprendidas en cada fase, se desarrollan en forma
secuencial, mientras que las tareas de una misma, pueden ejecutarse en forma paralela.

FASE
ETAPA

TAREA

Cada fase se define a través de:


- etapas
- hitos

FASES 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

Cada etapa se define a través de:


- sus tareas,
- entregables (los principales entregables de las tareas de una misma etapa)
- el coordinador (la figura responsable de coordinar todas las tareas dentro de esta
etapa)

ETAPAS TAREAS ENTREGABLES COORDINADOR

- Ejecución de Confiabilización de Datos


- Conversión de Datos
PREPARACIÓN - Aprobación de Conversión de Datos Líder
- Aprobación Conversión Datos
IMPLANTACIÓN - Carga Inicial y Parametrización Funcional
- Capacitación
- Comunicación

Cada tarea se define a través de:


- su descripción,
- los inputs,
- los outputs (o entregables)
- los actores (lista de participantes de la tarea) y
- el responsable (figura responsable de ejecutar esta tarea)

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

4.3.1.1 Descr i p ció n de Req uer im i en t o s Fu n ci on ales


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

INPUT OUTPUT ACTORES RESPONSABLE


- Descripción de la - Especificación - Líder funcional - Líder funcional
Necesidad Funcional - Líder
- Procesos de informática
Negocio - Usuarios

Cada entregable se define a través de:


- Nombre
- Objetivo
- Contenido
- Responsable

NOM BRE
Descripción de la Necesidad
OBJETIVO
Describir el objetivo y alcance de la necesidad de un nuevo
sistema o una modificación
CONTENIDO

Proyecto:...............................................................................................
Responsable:.........................................Sector:......................................
Participantes:.........................................................................................

- Objetivo del Proyecto


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

RESPONSA BLE
Líder Funcional

Hitos
En la finalización de la mayoría de las fases, se desarrollan tareas de revisión, análisis,
aprobación y/o convalidación de los principales entregables de las mismas. Estas tareas, por su
relevancia, determinan en sí mismas el cierre de la fase.
Luego del cierre de la fase y considerando el resultado global de la misma, se conforma una
instancia de validación.

Por lo tanto, cada hito se define a través de:


- Tarea de cierre de la fase
- Los inputs,
- Los outputs (o entregables)
- Los actores (lista de participantes)
- El responsable (figura responsable del hito)
- Check list

A su vez, los hitos se pueden clasificar en:


- Hitos de Go- No Go: Aquellos hitos donde se decide la continuación, interrupción y/o
postergación de un proyecto
- Hitos de Validación: Aquellos hitos donde se validan y se controla la realización de
las tareas y de los entregables de una fase.

ORGANIZACIÓN DEL PROYECTO

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

CONCEPTOS SOBRE GESTIÓN DE PROYECTOS

EL ESPECTRO DE LA GESTIÓN
La gestión eficaz de un proyecto de software se centra en las tres „pes‟: personal, problema y
proceso.

Personal
El modelo de Madurez de gestión de personal define las siguientes áreas prácticas clave para
el personal que desarrolla soft:
 Reclutamiento
 Selección
 Gestión de rendimiento
 Entrenamiento
 Retribución
 Desarrollo de la carrera
 Diseño de la organización y del trabajo
 Desarrollo cultural y espíritu de equipo.

Los participantes
El proceso del software lo componen participantes que pueden clasificarse en una de cinco
categorías:
1. Gestores superiores
2. Gestores (técnicos) del proyecto
3. Profesionales
4. Clientes
5. Usuarios finales
Para ser eficaz, el equipo del proyecto debe organizarse de manera que maximice las
habilidades y capacidades de cada persona. Éste es el trabajo del jefe del equipo.

Los jefes del equipo


Cuando seleccionamos a alguien para dirigir un proyecto de software se tienen en cuenta
las siguientes habilidades, propuestas por el modelo MOI:
 Motivación
 Organización
 Ideas e innovación
Otro punto de vista de las características que definen a un gestor de proyecto eficiente resalta
cuatro apartados clave:
 Resolución del problema
 Dotes de gestión
 Incentivo de los logros
 Influencia y construcción de espíritu de equipo

El equipo de software
La mejor estructura de equipo depende del estilo de gestión de una organización, el número de
personas que compondrá el equipo, sus niveles de preparación y la dificultad general del
problema. Se sugieren tres organigramas de equipo genéricos:
Descentralizado democrático DD). No tiene un jefe permanente, se nombran
coordinadores de tareas a corto plazo. La comunicación entre los miembros es
horizontal.
Descentralizado controlado (DC). Tiene un jefe definido que coordina tareas y jefes
secundarios con responsabilidades sobre sub tareas. Comunicación entre subgrupos e
individuos es horizontal. Vertical a lo largo de la jerarquía de control.
Centralizado controlado (CC). El jefe del equipo se encarga de la resolución de
problemas a alto nivel y la coordinación interna del equipo. La comunicación entre el
jefe y los miembros es vertical.

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

Paradigmas de organización para equipos de ingeniería de software:


Paradigma cerrado: estructura al equipo con una jerarquía tradicional de autoridad.
Paradigma aleatorio: estructura al equipo libremente y depende de la iniciativa
individual de los miembros del equipo.
Paradigma abierto: estructura el equipo de manera que consiga algunos de los
controles asociados con el paradigma cerrado.
Paradigma sincronizado: se basa en la compartimentación natural de un problema y
organiza los miembros del equipo para trabajar en partes del problema con poca
comunicación activa entre ellos.

Aspectos sobre la coordinación y la comunicación


Hay muchos motivos por los que los proyectos de software pueden tener problemas: la escala
(tamaño), la incertidumbre, la interoperatividad (comunicación soft nuevo con el anterior).
Las técnicas de coordinación se categorizan de la siguiente manera:
 Formal, enfoque impersonal: incluyen documentos, entregas memorandos técnicos,
etc.
 Formal, procedimientos interpersonales: actividades de garantía de calidad.
Incluyen reuniones de revisión de estado e inspecciones de diseño y de código.
 Informal, procedimientos interpersonales: incluyen reunioes de grupo para
divulgación de información, resolución de problemas, definición de requisistos etc..
 Comunicación electrónica: videoconferencia, correos electronicos.
 Red interpersonal: discusiones informales con personas que no están en el proyecto
pero que pueden tener experiencia.

ORGANIZACIÓN DEL EQUIPO DEL PROYECTO


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

ROLES DEL INGENIERO DEL SOFTWARE


En esta sección se definen los roles que intervienen en un Equipo de Proyecto. Los mismos no
se encuentran asociados a un sector o persona específica de la organización, sino que, en
cambio, se definen de manera tal que, de acuerdo al tipo de proyecto, su envergadura y
cantidad de entidades involucradas, una persona podrá adoptar más de un rol o por el contrario
un rol podrá estar compuesto por más de una persona.

Cabe destacar, que independientemente de los roles específicos, cada integrante del equipo
del proyecto deberá garantizar el cumplimiento de las normas de la empresa.

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

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

COM ITÉ DIRECTOR

RESPONSABLE OWNER DEL RESPONSABLE


FUNCIONAL PROYECTO INFORM ÁTICO

COM ITÉ EJECUTIVO

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:

- Monitorear el avance del Plan Director de Sistemas de Información


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

El Comité Director podrá delegar sus responsabilidades de acuerdo a la envergadura del


proyecto.

COMITÉ EJECUTIVO
Integrado por los roles Owner del Proyecto, Responsable Funcional, Responsable Informático y
los Usuarios Finales. Sus principales responsabilidades son:

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

- Participar de la planificación, administración y el control del Proyecto informático.


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

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

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

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

- Brindar soporte funcional, a través de asesoramiento


- Realizar la administración de los sistemas en producción
- Reparar y restaurar el servicio
- Asegurar la consistencia de la información
- Monitorear la performance de la operación del sistema luego de su puesta en marcha
- Evaluar cumplimiento de los objetivos del sistema
- Identificar cambios y mejoras potenciales
- Detectar desvíos

OWNER DEL PROYECTO


Sus principales responsabilidades son:

- Identificar las necesidades en uno o más procesos de negocio de la organización que


requiera la solución informática correspondiente.
- Al ser el principal beneficiario del proyecto, es el responsable de “velar” en términos
generales por el cumplimiento de la metodología.

RESPONSABLE FUNCIONAL
Sus principales responsabilidades son:

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

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

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

LÍDER FUNCIONAL
Sus principales responsabilidades son:

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

RESPONSABLE INFORMÁTICO
Sus principales responsabilidades son:

- Proveer el Sistema Solución o nuevo Sistema a desarrollar, garantizando la coherencia


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

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

LÍDER INFORMÁTICO
Sus principales responsabilidades son:

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

USUARIO FINAL
Sus principales responsabilidades son:

- Colaborar y validar la definición de los requerimientos


- Participar y validar las pruebas funcionales del sistema
- Evaluar el sistema una vez implantado.

QUALITY ASSURANCE
Sus principales responsabilidades son:

- Determinar los estándares de calidad adecuados para el proyecto y cómo satisfacerlos


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

RESPONSABLE SOPORTE AL CAMBIO


Sus principales responsabilidades son:

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

RESPONSABLE CAPACITACIÓN
Sus principales responsabilidades son:

- Definir la Estrategia de Capacitación


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

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

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

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

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

- Colaborar en el análisis costo/beneficio de un proyecto.


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

EXPERTO EN SEGURIDAD INFORMÁTICA


Sus principales responsabilidades son:

- Participar del estudio de factibilidad técnico.


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

EXPERTO EN PROCESOS DE NEGOCIO


Sus principales responsabilidades son:

- Brindar asesoramiento sobre el proceso impactado por la solución informática


- Analizar el impacto del proyecto en el proceso impactado
- Realizar el análisis de alto nivel de todos los nuevos proyectos, evaluando los impactos en
los sistemas y en otros proyectos en curso
- Participar en la elaboración de los manuales de procesos.

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

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

- Colaborar en la definición de indicadores


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

EXPERTO ECONÓMICO/FINANCIERO
Sus principales responsabilidades son:

- Colaborar en el Análisis Costo Beneficio y en el Business Plan de las alternativas de


solución.

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

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

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

- Asesorar acerca de la información que brinda el Sistema y sus funciones en general.


- Definir y habilitar nuevos perfiles y usuarios
- Controlar los Procesos Rutinarios inherentes al sistema
- Coordinar las actividades de capacitación necesarias una vez que el sistema está en
producción.

SOPORTE USUARIOS
Sus principales responsabilidades son:

- Recibir las consultas y reclamos del usuario


- Responsable del primer nivel de asistencia al usuario
- Diagnosticar el problema, resolver y/o derivar

SOPORTE FUNCIONAL
Sus principales responsabilidades son:

- Recibir las consultas y reclamos sobre el funcionamiento de un sistema


- Diagnosticar el problema, resolver y/o derivar
- Identificar nuevos requerimientos y derivarlos al Administrador Funcional

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

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

- Recibir las consultas e incidentes técnicos


- Diagnosticar el problema, resolver y/o derivar
- Verificar y velar por el mantenimiento operativo:
- Hardware
- Software de base
- Bases de Datos
- Conectividad
- Ambiente Operativo

SOPORTE APLICATIVO
Sus principales responsabilidades son:

- Ejecutar las modificaciones necesarias sobre el aplicativo (como respuesta a incidentes o


debido a nuevas funcionalidades)
- Realizar las pruebas correspondientes
- Mantener la gestión de configuración del aplicativo
- Documentar los cambios en los manuales de sistemas y de usuario

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

- Asegurar la integridad y coherencia de los datos


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

ADMINISTRACIÓN Y CONTROL DEL PROYECTO


Desde un punto de vista macro, se pueden identificar las siguientes pautas para la
1
administración y control del Proyecto.

Cada proyecto definirá:


- La Composición del Grupo de Trabajo, esquema, responsabilidades
- Cronograma consensuado
- Periodicidad de reuniones de seguimiento
- Modalidad del informe de seguimiento que mínimamente deberá contener:
- Estado
- Puntos de atención
- Decisiones a tomar
- Acciones, indicando responsables y fechas
- Próximos Pasos
- Control Presupuestario

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

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

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

INGENIERÍA DEL SOFTWARE

Proceso, métodos y herramientas


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

Una visión general de la ingeniería del software


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

Las fases y los pasos relacionados descriptos se complementan con un


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

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

EL PROCESO DEL SOFTWARE


Se establece:
 Un marco común del proceso, definiendo un pequeño número de actividades del marco de
trabajo.
 Un conjunto de tareas que permiten que las actividades del marco de trabajo se adapten a
las características del proyecto del software y a los requisitos del equipo de proyecto.
 Las actividades de protección, tales como garantía de calidad del software, gestión de
configuración del software y medición, abarcan el modelo de proceso. Estas son
independientes de cualquier actividad del marco de trabajo.

Para determinar el estado actual de madurez del proceso, el SEI (Software Engineering
Institute) utiliza un cuestionario de evaluación y esquema de cinco grados (Ver Cuestionario en
anexo xx):
Nivel 1: Inicial.- Se definen pocos procesos, y el éxito depende del esfuerzo individual.

Nivel 2: Repetible.- Para repetir éxitos anteriores en proyectos con aplicaciones


similares se aplica la disciplina necesaria para el proceso.

Nivel 3: Definido.- En este nivel se incluyen todas las características definidas en el


nivel 2.

Nivel 4: Gestionado.- Mediante la utilización de medidas detalladas, se comprenden y


se controlan cuantitativamente tanto los productos como los procesos.

Nivel 5: Optimización.- Mediante un resultado cuantitativo del proceso y de las ideas y


tecnologías innovadoras se posibilita una mejora del proceso.

El SEI ha asociado las ACP a cada uno de los niveles de madurez. Cada ACP se describe
identificando las características siguientes:
 Objetivos
 Compromisos (requisitos para lograr los objetivos)
 Capacidades (elementos que deben encontrarse)
 Actividades (tareas especificas)
 Métodos para supervisar la implementación
 Métodos para verificar la implementación

MODELOS DE PROCESO DEL SOFTWARE


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

EL MODELO LINEAL SECUENCIAL


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

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

detallado), construcción e implementación. En este trabajo no se incluye la fase de


mantenimiento de un sistema en producción. El ciclo de vida básico acompaña a las
actividades siguientes:

Ingeniería y modelado de Sistemas/Información.


Como el software siempre forma parte de un sistema más grande, el trabajo comienza
estableciendo requisitos de todos los elementos del sistema y asignando al software
algún subgrupo de estos requisitos.

Análisis de los requisitos del software.


El proceso de reunión de requisitos se intensifica y se centra especialmente en el
software.

Diseño (global y detallado).


Es un proceso de muchos pasos que se centra en cuatro atributos distintos de un
programa:
El diseño básicamente se resuelve mediante el estudio y la generación de herramientas
orientadas a los siguientes aspectos:
 Estructura de datos
 Arquitectura del software
 Representaciones de interfaz
 Detalle procedimental (algoritmo)

La generación de las herramientas de trabajo (ej. DFD, DD, Diagramas de estructuras,


Diagrama de Clases, Diagrama E-R, etc) traduce requisitos en una representación del software
que se pueda evaluar por calidad antes de que comience la generación de código. El diseño se
documenta.
En esta fase, además se definen las estrategias de capacitación, pruebas (unitarias y globales)
y de puesta en producción del sistema.

Desarrollo.
La orientación del diseño debe alcanzar documentación que permita traducir los requerimientos
funcionales a programas.

Implementación. Una vez que se ha generado un código, debe efectuarse las pruebas de los
programas. El proceso de pruebas se centra en los procesos lógicos internos del software.
Asimismo se incluye las actividades de capacitación e implementación, que se apoya en las
estrategias diseñadas en la fase de diseño.

Problemas en el modelo lineal ciclo de vida básico:


1. Los proyectos reales raras veces siguen el modelo secuencial que propone el modelo.
2. A menudo es difícil que el cliente exponga explícitamente todos los requisitos.
3. El cliente debe tener paciencia. Una versión de trabajo del (los) programa (s) no estará
disponible hasta que el proyecto esté muy avanzado.
4. Los responsables del desarrollo del software siempre se retrasan respecto de los planes de
trabajos concebidos.

EL MODELO DE CONSTRUCCIÓN DE PROTOTIPOS


Un cliente a menudo define un conjunto de objetivos generales para el software, pero no
identifica los requisitos detallados de entrada, procesamiento, o salida. En estas y en
otras muchas situaciones, un paradigma de construcción de prototipos puede ofrecer el
mejor enfoque.

El paradigma de construcción de prototipos comienza con la recolección de requisitos. El


desarrollador y el cliente encuentran y definen los objetivos globales para el software,
identifican los requisitos conocidos, y las áreas del esquema en donde es obligatoria más

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

definición. Entonces aparece un “diseño rápido”. El diseño rápido lleva a la construcción de un


prototipo.
El prototipo lo evalúa el cliente/usuario y lo utiliza para refinar los requisitos del software a
desarrollar. La interacción ocurre cuando el prototipo satisface las necesidades del cliente, a la
vez que permite que el desarrollador comprenda mejor lo que necesita hacer.

Problemas del modelo de construcción de prototipos:


1. El cliente ve lo que parece ser una versión de trabajo del software, sin saber que con la
prisa de hacer que funcione no se ha tenido en cuenta la calidad del software global o la
facilidad de mantenimiento a largo plazo.
2. El desarrollador a menudo hace compromisos de implementación para hacer que el
prototipo funcione rápidamente.

EL MODELO DRA

El Desarrollo Rápido de Aplicaciones (DRA) es un modelo de proceso del desarrollo del


software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto. Es una
adaptación a alta velocidad del modelo lineal secuencial utilizando un enfoque de construcción
basado en componentes. Comprende las siguientes fases:
 Modelado de gestión:
Responde: qué información conduce el proceso, qué información se genera, quién la
genera, a dónde va y quién la procesa.
 Modelado de datos:
Se definen las características de cada uno de los objetos y las relaciones entre los
objetos
 Modelado de proceso:
Las descripciones del proceso se crean para añadir, modificar, suprimir, o recuperar un
objeto de datos.
 Generación de aplicaciones:
Trabaja para utilizar componentes ya existentes o a crear componentes reutilizables.
 Pruebas y entrega:
Se deben probar todos los componentes nuevos y las interfaces.

Problemas del modelo DRA:


 Para proyectos grandes, requiere recursos humanos suficientes para crear los equipos
DRA.
 Requiere clientes y desarrolladores comprometidos en las rápidas actividades necesarias.

MODELOS DE PROCESOS EVOLUTIVOS DE SOFTWARE


Modelo incremental
Combina elementos del modelo ciclo de vida básico con la filosofía interactiva de construcción
de prototipos. Cada secuencia lineal produce un incremento del software.
Cuando se utiliza un modelo incremental, el primer incremento es un producto esencial
(núcleo).
El plan afronta la modificación del producto central para cumplir las necesidades del cliente.
Este proceso se repite hasta que se elabore el producto completo. A diferencia de la
construcción de prototipos, se centra en la entrega de un producto operacional en cada
incremento. Es útil cuando no está disponible el personal para una implementación completa
en la fecha límite.

Modelo en espiral
Es un modelo de proceso evolutivo que acompaña la naturaleza interactiva de la construcción
de prototipos con los aspectos del modelo lineal secuencial.
El modelo en espiral se divide en actividades estructurales, también llamadas regiones de
tareas:
 Comunicación con el cliente

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

 Planificación: definir recursos, tiempo y otras informaciones relacionadas con el


proyecto.
 Análisis de riesgos: evaluar riesgos técnicos y de gestión.
 Ingeniería: construir una o más representaciones de la aplicación.
 Construcción y adaptación: construir, probar, instalar y proporcionar soporte al
usuario.
 Evaluación del cliente: obtener la reacción del cliente.
En todos los casos se aplican las actividades de protección.

Modelo de ensamblaje de componentes


El modelo de ensamblaje de componentes configura aplicaciones desde componentes
preparados de software(“clases”). Es un modelo evolutivo e interactivo.
Se identifican las clases candidatas. Esto se lleva a cabo examinando los datos que se van a
manejar por parte de la aplicación y el algoritmo que se va a aplicar para conseguir el
tratamiento. Las clases creadas se almacenan en una biblioteca de clases. Una vez
identificadas las clases candidatas se examina si ya existen y en ese caso se vuelven a utilizar.
Se compone así la primera interacción de la aplicación a construirse.
Este modelo lleva a la reutilización del software.

Modelo de desarrollo concurrente


Define una serie de acontecimientos que dispararán transiciones de estado a estado para cada
una de las actividades de la ingeniería del software. Todas las actividades existen
concurrentemente, pero residen en estados diferentes.

MODELO DE MÉTODOS FORMALES


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

TÉCNICAS DE CUARTA GENERACIÓN


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

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

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

DIAGRAMA DE FASES Y ETAPAS

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

Habiendo efectuado un repaso de los diferentes modelos de diseño de aplicaciones existentes,


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

DIAGRAMA RESUMEN
En esta primera aproximación del modelo, se presenta un esquema resumen con las fases
generales y los hitos de continuación o detención (go no-go) del proyecto.

Es importante resaltar que un proyecto de sistemas se inicia con la identificación de las


necesidades, y culmina con la implantación y la puesta en producción del sistema junto con el
balance o cierre correspondiente.
Desde el momento en que el sistema se pasa a producción, comienza una nueva fase que no
está incluída en el ciclo de vida del proyecto: la fase de Producción. Ésta, tiene vida propia y
finalizará cuando el sistema deje de operar.

Dentro del ciclo de vida del proyecto, se debe generar dos contratos:

1. Acuerdo de Servicio de Proyecto, suscripto entre el Owner del Proyecto y el Responsable


Informático y que acompaña al proyecto durante todo su ciclo de vida
2. Contrato de Servicio de Producción entre el usuario del sistema y los proveedores (internos
y externos) del servicio. Este contrato acompaña al sistema durante toda su vida de
producción.

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

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

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

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

DIAGRAMA DE ETAPAS, TAREAS Y ENTREGABLES POR FASE


Vamos describir el diagrama de las etapas, enunciaremos las tareas y entregables de cada una de las
fases que compone la metodología que adoptamos.

DESCRIPCIÓN DE NECESIDADES Y ESTUDIO PRELIMINAR

FASES ETAPAS TAREAS ENTREGABLES COORDINADOR

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

- Alineamiento Plan Maestro Sistemas


E P
- Alineamiento Plan Tecnológico
S R - Alineamiento Plan Estratégico
T E - Identificación de Alternativas
U L - Estudio Factibilidad Técnico/
- Análisis Factibilidad Técnica
Funcional
D I - Identificación Modalidad de Proyecto
- Estudio Factibilidad Económico
I M - Análisis Impacto del Proyecto Líder
ESTUDIO DE - Métricas Claves
O I - Análisis Costo Beneficio Funcional
FACTIBILIDAD - Informe Ejecutivo Estudio
N - Business Plan
Factiibilidad
- Análisis DAFO
A - Plan Maestro Actualizado
- Identificación Métricas
R - Acuerdo de Servicio (Borrador)
- Elaboración Inf. Ejecutivo Est. Factiblidad
- Actualización Plan Maestro
- Análisis de Presupuesto
- Confección del Acuerdo de Servicio

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

Si en la organización se ha realizado con anterioridad un Plan de Sistemas de Información que afecte al


sistema objeto de este estudio, se dispondrá de un conjunto de productos que proporcionarán información
a tener en cuenta en todo el proceso.

Las actividades que engloba este proceso se menciona a continuación:

Descripción de Necesidades
 Identificar Necesidades
 Relevamiento Global
 Descripción de Objetivos y Alcances
 Especificar Requerimientos.

Estudio Preliminar
 Alineamiento al Plan Maestro de Sistemas
 Alineamiento al Plan Tecnológico
 Alineamiento al Plan Estrategico
 Identificación de Alternativas
 Análisis de Factibilidad Técnica
 Identificación de la Modalidad del Proyecto
 Análisis Impacto del Proyecto
 Análisis de Costo Beneficio
 Business Plan
 Análisis DAFO (Debilidades y Fortalezas)
 Identificación de Métricas
 Elaboración del Informe Ejectivo del Estudio de Factibilidad
 Actualización Plan Maestro
 Análisis de Presupuesto
 Confección del Acuerdo de Servicio.

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

DISEÑO GLOBAL Y PROCESO DE COMPRAS

FASES ETAPAS TAREAS ENTREGABLES COORDINADOR

D G - Descripción Requerimientos Funcionales


I L - Especificación Funcional
- Análisis de Requerimientos
S - Plan Maestro Actualizado
O - Impacto en Arquitectura Técnica
E - Arquitectura Técnica
B - Realización de Especificación
Ñ Actualizada
A ESPECIFICACIÓN - Plan General de Trabajo Líder
- Especificación Técnica
O L GENERAL - Definición de Equipo de Trabajo Funcional
- Plan General de Trabajo
- Administración de Riesgo
- Equipo de Trabajo
- Quality Management
- Carta de Decisión Actualizada
- Revisión Modalidad de Proyecto
- Est Fact Económica Act.
- Revisión de Business Plan

HITO 1: CONVALIDACIÓN ESPECIFICACIÓN - Especifiación Convalidada

P C - Requerimiento de Compras - Requerimiento de Compras


R O - Preparación Pliego - Pliego
O CONCURSO Compras
M - Convalidación Pliego - Circulares Aclaratorias
C P - Publicación - Ofertas (Técnica y Económica)
E R
S A
O - Análisis Ofertas - Preinforme Técnico Líder
S ANALÍSIS
- Pruebas de Funcionamiento en Maqueta - Preinforme Técnico de Pruebas Informático
de TÉCNICO
- Emisión Dictamen Técnico - Dictamen Técnico

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

DISEÑO DETALLADO Y CONSTRUCCIÓN

FASES ETAPAS TAREAS ENTREGABLES COORDINADOR


D D - Especificación Técnica de Detalle - Espec. técnica de Detalle
I E - Diseño Tecnología - Plan Detallado de Trabajo
S T - Plan Detallado de Trabajo - Plan de Pruebas Técnicas
E A - Diseño del Modelo de Datos - Plan de Contingencia y de
Ñ L DISEÑO - Prototipo Desastre Líder
O L DETALLADO - Elaboración Plan de Pruebas Técnicas - Plan de Backup Informático
A - Plan de Contingencia y Desastre - Doc. Soporte Mesa de Ayuda
- Plan de Backup - Doc. Soporte a Operaciones/
D
- Documentación Operativa Soporte
O - Definición Proc. Gestión de Configuración - Proc. Gestión de Configuración

- 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

HITO 3: APROBACIÓN DISEÑO DETALLADO Especificación Técnica de Detalle

- Desarrollo de Programas - Programas, Módulos &


- Adecuaciones de Programas Parametrización
PARAMETRIZACIÓN - Parametrización Líder
- Manual de Sistemas
Y DESARROLLO - Elaboracion Manuales de Sistemas Informático
- Manual de Usuario
- Elaboracion Manuales de Usuario - Manual de Procesos
C - Elaboración Manual de Procesos
O - Prueba Individual
N - Prueba de Cadena
S - Prueba de Integración - Protocolos de Prueba Líder
T PRUEBAS - Prueba Global - Aprobación de Pruebas Informático
R - Prueba de Perf., stress, volumen &
U seguridad
- Pruebas de Compatibilidad
C
C - Preparación
- Protocolo de Prueba Piloto Líder
I PRUEBA PILOTO - Prueba Piloto
- Homologación Prueba Piloto Funcional
Ó - Homologación Prueba Piloto
N
- Revisión del Acuerdo de Servicio y - Acuerdo de Servicio Revisado
Alcance - Plan de Implantación
DEFINICIÓN - Plan de Implantación - Plan de Soporte
Líder
PLAN DE - Plan de Soporte - Protocolo de Implantación
Funcional
IMPLANTACIÓN - Elaboración Protocolo de Implantación - Procedimiento de Producción
- Definición Procedimiento de Producción - Proc. Gestión de Configuración
- Actualización Gestión de Configuración actualizado

HITO 4: DECISIÓN DE IMPLANTACIÓN - Acuerdo de Implantación

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

Fase de Diseño Detallado.

El objetivo de la Fase de Diseño Detallado es la definición de la arquitectura del sistema y del entorno
tecnológico que le va a dar soporte, junto con la especificación detallada de los componentes del sistema
de información.

A partir de dicha información, se generan todas las especificaciones de construcción relativas al propio
sistema, así como la descripción técnica del plan de pruebas, la definición de los requisitos de
implantación y el diseño de los procedimientos de migración y carga inicial, éstos últimos cuando proceda.

Las actividades de este proceso se agrupan en dos grandes bloques.


1.- En un primer bloque de actividades, que se llevan a cabo en paralelo, se obtiene el diseño de detalle
del sistema de información. La realización de estas actividades exige una continua realimentación.

En general, el orden real de ejecución de las mismas depende de las particularidades del sistema de
información y, por lo tanto, de generación de sus productos.

Se establece el particionamiento físico del sistema de información, así como su organización en


subsistemas de diseño, la especificación del entorno tecnológico, y sus requisitos de operación,
administración, seguridad y control de acceso.

Se completan los catálogos de requisitos y normas, en función de la definición del entorno tecnológico, con
aquellos aspectos relativos al diseño y construcción que sea necesario contemplar.

Asimismo, se crea un catálogo de excepciones del sistema, en el que se registran las situaciones de
funcionamiento secundario o anómalo que se estime oportuno considerar y, por lo tanto, diseñar y probar.
Este catálogo de excepciones se utiliza como referencia en la especificación técnica de las pruebas del
sistema.

El sistema de información se estructura en subsistemas de diseño. Éstos a su vez se clasifican como de


soporte o específicos, al responder a propósitos diferentes.

Los subsistemas de soporte contienen los elementos o servicios comunes al sistema y a la instalación, y
generalmente están originados por la interacción con la infraestructura técnica o la reutilización de otros
sistemas, con un nivel de complejidad técnica mayor.

También se especifica en detalle el entorno tecnológico del sistema de información, junto con su
planificación de capacidades (capacity planning), y sus requisitos de operación, administración, seguridad
y control de acceso.

El diseño detallado del sistema de información, siguiendo un enfoque estructurado, comprende un


conjunto de actividades que se llevan a cabo en paralelo a la Definición de la Arquitectura del Sistema.

El alcance de cada una de estas actividades se resume a continuación:


 Diseño de la Arquitectura de Soporte
 Diseño de la Arquitectura de Módulos del Sistema
 Diseño Físico de Datos

En el caso de Diseño Orientado a Objetos, conviene señalar que el diseño de la persistencia de los
objetos se lleva a cabo sobre bases de datos relacionales, y que el diseño detallado del sistema de
información se realiza en paralelo con la actividad de Diseño de la Arquitectura de Soporte, y se
corresponde con las siguientes actividades:
 Diseño de Casos de Uso Reales.
 Diseño de Clases
En el caso de que sea necesario, se realiza la definición de un plan de migración y carga inicial de datos.

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

Una vez que se tiene el modelo de clases, se comienza el diseño físico en la actividad Diseño Físico de
Datos.

2.- El segundo bloque de actividades complementa el diseño del sistema de información. En él se generan
todas las especificaciones necesarias para la construcción del sistema de información:
 Generación de Especificaciones de Construcción.
 Diseño de la Migración y Carga Inicial de Datos
 Especificación Técnica del Plan de Pruebas
 Establecimiento de Requisitos de Implantación

Fase de Construcción

En este proceso se genera el código de los componentes del Sistema de Información, se desarrollan todos
los procedimientos de operación y seguridad y se elaboran todos los manuales de usuario final y de
explotación con el objetivo de asegurar el correcto funcionamiento del Sistema para su posterior
implantación.

Para conseguir dicho objetivo, en este proceso se realizan las pruebas unitarias, las pruebas de
integración de los subsistemas y componentes y las pruebas del sistema, de acuerdo al plan de pruebas
establecido.

Asimismo, se define la formación de usuario final y, si procede, se construyen los procedimientos de


migración y carga inicial de datos.

El producto Especificaciones de Construcción del Sistema de Información, es la base para la construcción


del sistema de información.

En dicho producto se recoge la información relativa al entorno de construcción del sistema de información,
la especificación detallada de los componentes y la descripción de la estructura física de datos, tanto
bases de datos como sistemas de ficheros. Opcionalmente, incluye un plan de integración del sistema de
información, en el que se especifica la secuencia y organización de la construcción de los distintos
componentes.

Se asegura la disponibilidad de la infraestructura necesaria para la generación del código de los


componentes y procedimientos del sistema de información.

Una vez configurado el entorno de construcción, se realiza la codificación y las pruebas de los distintos
componentes que conforman el sistema de información, mediante las siguientes actividades genericas:
Generación del Código de los Componentes y Procedimientos, que se hace según las especificaciones de
construcción del sistema de información, y conforme al plan de integración del sistema de información.

Ejecución de las Pruebas Unitarias, dónde se llevan a cabo las verificaciones definidas en el plan de
pruebas para cada uno de los componentes

Ejecución de las Pruebas de Integración, que incluye la ejecución de las verificaciones asociadas a los
subsistemas y componentes, a partir de los componentes verificados individualmente, y la evaluación de
los resultados.

Una vez construido el sistema de información y realizadas las verificaciones correspondientes, se lleva a
cabo la integración final del sistema de información en la actividad de Pruebas globales (GST),
comprobando tanto las interfaces entre subsistemas y sistemas externos como los requisitos, de acuerdo
a las verificaciones establecidas en el plan de pruebas para el nivel de pruebas del sistema.

En la actividad Elaboración de los Manuales del sistema Usuario, se genera la documentación de usuario
final o explotación, conforme a los requisitos definidos en el proceso Diseño del Sistema de Información.

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

La formación necesaria para que los usuarios finales sean capaces de utilizar el sistema de forma
satisfactoria se especifica en la actividad Plan de Capacitación.

Si se ha establecido la necesidad de realizar una migración de datos, la construcción y pruebas de los


componentes y procedimientos relativos a dicha migración y a la carga inicial de datos se realiza en la
actividad Estrategia de Conversión y Estrategia de Carga de Datos.

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

IMPLANTACIÓN Y CIERRE DEL PROYECTO

FASES ETAPAS TAREAS ENTREGABLES COORDINADOR

- Ejecución de Confiabilización de Datos


I - Conversión de Datos
M PREPARACIÓN - Aprobación de Conversión de Datos Líder
- Aprobación Conversión Datos
P IMPLANTACIÓN - Carga Inicial y Parametrización Funcional
L - Capacitación
A - Comunicación
N
T PUESTA EN - Realización Implantación Líder
- Recepción Provisoria Informático
A PRODUCCIÓN - Aceptación Implantación
C
I
O - Contrato de Servicio Producción
FORMALIZACIÓN - Contrato de Servicio de Producción - Doc. Soporte Mesa de Ayuda
N Administrador
PUESTA EN - Documentación Puesta en Producción actualizado
Funcional
PRODUCCIÓN (Anexo el Proc. de Producción) - Doc. Soporte a Operaciones/
Soporte actualizado

HITO 5: SISTEMA EN PRODUCCIÓN - Informe Sistema en Producción

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.

En primer lugar, se revisa la estrategia de implantación que ya se determinó en la Fase de Estudio


Preliminar. Se estudia su alcance y, en función de sus características, se define un plan de implantación y
se especifica el equipo que lo va a llevar a cabo.

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

Conviene señalar la participación del usuario de operación en las pruebas de implantación, del usuario
final en las pruebas de aceptación, y del responsable de mantenimiento.

Las actividades previas al inicio de la producción incluyen la preparación de la infraestructura necesaria


para configurar el entorno, la instalación de los componentes, la activación de los procedimientos
manuales y automáticos asociados y, cuando proceda, la migración o carga inicial de datos.

Para ello se toman como punto de partida los productos software probados, obtenidos en la fase de
Construcción del Sistema de Información y su documentación asociada.

Se realizan las pruebas de implantación y de aceptación del sistema en su totalidad. Responden a los
siguientes propósitos:
 Las pruebas de implantación cubren un rango muy amplio, que va desde la comprobación de
cualquier detalle de diseño interno hasta aspectos tales como las comunicaciones.
Se debe comprobar que el sistema puede gestionar los volúmenes de información requeridos,
se ajusta a los tiempos de respuesta deseados y que los procedimientos de respaldo,
seguridad e interfaces con otros sistemas funcionan correctamente.
Se debe verificar también el comportamiento del sistema bajo las condiciones más extremas.

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

Asimismo, se llevan a cabo las tareas necesarias para la preparación del mantenimiento, siempre y
cuando se haya decidido que éste va a efectuarse. En cualquier caso, es necesario que la persona que
vaya a asumir el mantenimiento conozca el sistema, antes de su incorporación al entorno de producción.

Además hay que determinar los servicios (y niveles para cada uno) que requiere el sistema que se va a
implantar, y el acuerdo que se adquiere una vez que se inicie la producción. Hay que distinguir entre
servicios de gestión de operaciones (servicios por lotes, seguridad, comunicaciones, etc.) y servicios al
cliente (servicio de atención a usuario, mantenimiento, etc.) que se deben negociar en cuanto a recursos,
horarios, costo, etc.

Se fija el nivel con el que se prestará el servicio como indicador de la calidad del mismo.

Conviene señalar que la implantación puede ser un proceso iterativo que se realiza de acuerdo al plan
establecido para el comienzo de la producción del sistema en su entorno de operación. Para establecer
este plan se tiene en cuenta:
 El cumplimiento de los requisitos de implantación definidos en la fase de Descripción de las
Necesidades.
 La estrategia de transición del sistema antiguo al nuevo.

Finalmente, se realizan las acciones necesarias para el inicio de la producción.

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

PRODUCCIÓN

FASES ETAPAS TAREAS ENTREGABLES COORDINADOR


- Procesos Backup
- Procesos Seguridad
ADMINISTRACIÓN Soporte
- Procesos Performance - Tablero de Mando
TÉCNICA Técnico
- Control de Procesos Rutinarios
- Otros procesos

P - Administración de Usuarios y Perfiles


R ADMINISTRACIÓN - Mantenimiento de Datos, Tablas y Administrador
- Tablero de Mando
O FUNCIONAL Parámetros Funcional
D - Capacitación Nuevos Usuarios
U
C - Atención a Usuarios
C - Soporte Funcional Administrador
SOPORTE - Tablero de Mando
I - Soporte Técnico Funcional
Ó - Soporte Aplicativo
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

DESCRIPCIÓN DE LAS FASES

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

FASE: ESTUDIO PRELIMINAR

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

FASE: ESTUDIO FACTIBILIDAD

FASE ETAPAS TAREAS ENTREGABLES COORDINADOR


- Alineamiento Plan Maestro Sistemas
E P
- Alineamiento Plan Tecnológico
S R - Alineamiento Plan Estratégico
T E - Identificación de Alternativas
U L - Estudio Factibilidad Técnico/
- Análisis Factibilidad Técnica
Funcional
D I - Identificación Modalidad de Proyecto
- Estudio Factibilidad Económico
I M - Análisis Impacto del Proyecto Líder
ESTUDIO DE - Métricas Claves
O I - Análisis Costo Beneficio Funcional
FACTIBILIDAD - Informe Ejecutivo Estudio
N - Business Plan
Factiibilidad
- Análisis DAFO
A - Plan Maestro Actualizado
- Identificación Métricas
R - Acuerdo de Servicio (Borrador)
- Elaboración Inf. Ejecutivo Est. Factiblidad
- Actualización Plan Maestro
- Análisis de Presupuesto
- Confección del Acuerdo de Servicio

- Carta de Decisión
HITO 0: APROBACIÓN PROYECTO - Acuerdo de Servicio

1 ETAPA: ESTUDIO DE FACTIBILIDAD

El propósito de este proceso es analizar un conjunto concreto de necesidades, con la idea de


proponer una solución a corto plazo. Los criterios con los que se hace esta propuesta no serán
estratégicos sino tácticos y relacionados con aspectos económicos, técnicos, legales y operativos.

Los resultados del Estudio de factibilidad del Sistema constituirán la base para tomar la
decisión de seguir adelante o abandonar. Si se decide seguir adelante pueden surgir uno o varios
proyectos que afecten a uno o varios sistemas de información. Dichos sistemas se desarrollarán
según el resultado obtenido en el estudio de viabilidad y teniendo en cuenta la cartera de proyectos
para la estrategia de implantación del sistema global.

Se ha considerado que este proceso es obligatorio, aunque el nivel de profundidad con el que
se lleve a cabo dependerá de cada caso. La conveniencia de la realización del estudio de la
situación actual depende del valor añadido previsto para la especificación de requisitos y para el
planteamiento de alternativas de solución. En las alternativas se considerarán soluciones "a
medida", soluciones basadas en la adquisición de productos software del mercado o soluciones
mixtas.

Para valorar las alternativas planteadas y determinar una única solución, se estudiará el
impacto en la organización de cada una de ellas, la inversión y los riesgos asociados.

El resultado final de este proceso son los productos relacionados con la solución que se
propone para cubrir la necesidad concreta que se planteó en el proceso, y que depende de:

Si la solución conlleva desarrollo a medida o no:

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


 Impacto en la organización.
 Coste/beneficio de la solución.
 Valoración de riesgos de la solución.
 Enfoque del plan de trabajo de la solución.
 Planificación de la solución.

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

 Solución propuesta:
 Descripción de la solución.
 Modelo de descomposición en subsistemas.
 Matriz de procesos/localización geográfica.
 Matriz datos/localización geográfica.
 Entorno tecnológico y comunicaciones.
 Estrategia de implantación global del sistema.
 Descripción de los procesos manuales.

Si la alternativa incluye desarrollo:


 Modelo abstracto de datos/Modelo de procesos.
 Modelo de negocio/Modelo de dominio.

Si la alternativa incluye un producto software estándar de mercado:


 Descripción del producto.
 Evolución del producto.
 Costes ocasionados por el producto.
 Estándares del producto.
 Descripción de adaptación si es necesaria.

Si en la organización se ha realizado con anterioridad un Plan de Sistemas de Información


que afecte al sistema objeto de este estudio, se dispondrá de un conjunto de productos que
proporcionarán información a tener en cuenta en todo el proceso.

2 Alineamiento Plan Maestro de Sistemas


Análisis de coherencia del proyecto con el Plan Maestro de Sistemas

INPUT OUTPUT ACTORES RESPONSABLE


- Descripción de la - Validación - Líder funcional - Líder informático
Necesidad (F1) alineamiento - Líder Informático
- Plan Maestro de - Experto tecnológico
Sistemas

3 Alineamiento Plan Tecnológico


Análisis de coherencia del proyecto con el Plan Tecnológico

INPUT OUTPUT ACTORES RESPONSABLE


- Descripción de la - Validación - Experto tecnológico - Experto tecnológico
Necesidad (F1) alineamiento - Líder informático
- Plan Tecnológico - Líder funcional

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

4 Alineamiento Plan Estratégico


Análisis de coherencia del proyecto con los lineamientos estratégicos de la Compañía, y análisis de
impacto en los procesos de negocio y / o en los clientes

INPUT OUTPUT ACTORES RESPONSABLE


- Descripción de la - Validación - Líder funcional - Líder funcional
Necesidad (F1) alineamiento - Experto tecnológico
- Lineamientos - Líder informático
Estratégicos - Experto en procesos

5 Identificación de Alternativas – Análisis Factibilidad Técnica – Identificación


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

INPUT OUTPUT ACTORES RESPONSABLE


- Descripción de la - Estudio de - Líder funcional - Líder informático
Necesidad (F1) Factibilidad - Líder Informático
- Plan Maestro técnico/funcional - Experto tecnológico
- Lineamientos - Experto seguridad
Tecnológicos informática

6 Análisis de Impacto del Proyecto


Se identifican el impacto de cada alternativa en función de:
- Procesos
- Usuarios.

INPUT OUTPUT ACTORES RESPONSABLE


- Descripción de la - Estudio de - Líder funcional - Líder funcional
Necesidad (F1) Factibilidad - Experto en procesos
- Estudio de técnico/funcional - Usuario
Factibilidad
técnico/funcional

7 Análisis Costo Beneficio – Business Plan


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

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

INPUT OUTPUT ACTORES RESPONSABLE


- Descripción de la - Estudio de - Líder funcional - Líder funcional
Necesidad (F1) Factibilidad - Experto
- Estudio de económico económico/financier
Factibilidad o
técnico/funcional - Experto informático

8 Análisis DAFO
Análisis DAFO. Identificación de Factores Claves de Éxito., riesgos, barreras/restricciones, aspectos
legales (marco regulatorio).

INPUT OUTPUT ACTORES RESPONSABLE


- Descripción de la - Análisis DAFO - Líder funcional - Líder funcional
Necesidad (F1) - Factores Claves de - Experto
- Estudio de Éxito. económico/financier
Factibilidad - Riesgos o
técnico/funcional - Experto informático
- Estudio de
Factibilidad
económico

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.

INPUT OUTPUT ACTORES RESPONSABLE


- Descripción de la - Métricas clave para - Líder funcional - Líder funcional
Necesidad (F1) evaluación - Experto
- Estudio de - Valores objetivo de económico/financier
Factibilidad las métricas o
técnico/funcional - Experto informático
- Estudio de - Experto en calidad
Factibilidad
económico

10 Elaboración del Informe Ejecutivo de Estudio de Factibilidad


En base a los Estudios de Factibilidad Técnico/Funcional y Económico se elabora un Resumen Ejecutivo
para la presentación al Comité Director.

INPUT OUTPUT ACTORES RESPONSABLE


- Estudio de - Informe Ejecutivo de - Líder Informático - Líder funcional
Factibilidad Estudio de - Líder Funcional
Técnico/Funcional Factibilidad
- Estudio de
Factibilidad
Económica

11 Actualización del Plan Maestro


Una vez aprobado el proyecto, se deberá actualizar el Plan Maestro de Sistemas incluyendo el nuevo
proyecto, y sus impactos.
Esta tarea se llevará a cabo después de la Aprobación del Proyecto (Hito 0)
43 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García

INPUT OUTPUT ACTORES RESPONSABLE


- Plan Maestro de - Plan Maestro - Líder Informático - Líder Informático
Sistemas Actualizado

12 Análisis de Presupuesto
Analizar y definir el presupuesto a asignar para las etapas del proyecto.
Identificar y designar el o los owners de presupuesto.

INPUT OUTPUT ACTORES RESPONSABLE


- Estudio de - Asignación - Comité Director - Comité Director
Factibilidad Presupuestaria - Comité Ejecutivo
Técnica/Funcional - Designación de
- Estudio de owner/s de
Factibilidad presupuesto
Económica

13 Confección de Acuerdo de Servicio


Confección del Borrador del Acuerdo de Servicio entre el Owner del Proyecto y el Responsable Informático
para el Proyecto de Sistemas.
En proyectos de gran envergadura, el responsable funcional y el responsable informático llevarán adelante
la negociación de este acuerdo.

INPUT OUTPUT ACTORES RESPONSABLE


- Estudio de - Acuerdo de Servicio - Owner del Proyecto - Líder Funcional
Factibilidad (Borrador) - Líder Informático
Técnica/Funcional - Líder Funcional
- Experto en Calidad

HITO 0: APROBACIÓN DEL PROYECTO

El Comité Director analizará la información generada en la Fase Estudio


Preliminar y tomará la DECISIÓN de aprobación del proyecto en forma conjunta.
Obtención asignación de partida presupuestaria.
Revisión y firma del Acuerdo de Servicio

INPUT: - Informe Ejecutivo Estudio de Factibilidad


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

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

2
RESPONSABLE: - Comité Director

Check-list  Designación del Owner del Proyecto


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

“APROBACIÓN DEL PROYECTO” constituye el HITO 0


de Validación del Owner del Proyecto.

Notas:
2
El Comité Director delegará su responsabilidad de acuerdo a la importancia del proyecto.
45 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García

FASE

DESCRIPCIÓN DE NECESIDADES

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

0.- DESCRIPCIÓN

ETAPAS TAREAS ENTREGABLES COORDINADOR

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

1.- Análisis del Sistema de Información

El propósito de este proceso es conseguir la especificación detallada del sistema de


información, a través de un catálogo de requisitos y una serie de modelos que cubran las
necesidades de información de los usuarios para los que se desarrollará el sistema de información y
que serán la entrada para el proceso de Diseño del Sistema de Información.

En primer lugar se describe inicialmente el sistema de información, a partir de los productos


generados en el proceso Estudio de Factibilidad del Sistema. Se delimita su alcance, se genera un
catálogo de requisitos generales y se describe el sistema mediante unos modelos iniciales de alto
nivel.

Se recogen de forma detallada los requisitos funcionales que el sistema de información debe
cubrir, catalogándolos, lo que permite hacer la traza a lo largo de los procesos de desarrollo.
Además, se identifican los requisitos no funcionales del sistema, es decir, las facilidades que ha de
proporcionar el sistema, y las restricciones a que estará sometido, en cuanto a rendimiento,
frecuencia de tratamiento, seguridad, etc.

Para facilitar el análisis del sistema se identifican los subsistemas de análisis, y se elaboran
los modelos de Casos de Uso y de Clases, en desarrollos orientados a objetos, y de Datos y
Procesos en desarrollos estructurados. Se ha incorporado una actividad específica para la definición
de Interfaces de Usuario al tiempo que se van obteniendo y depurando los requisitos y los anteriores
modelos. Se especificarán todas las interfaces entre el sistema y el usuario, como formatos de
pantallas, diálogos, formatos de informes y formularios de entrada.

Finalizados los modelos, se realiza un análisis de consistencia, mediante una verificación y


validación, lo que puede forzar la modificación de algunos de los modelos obtenidos.

Una vez realizado dicho análisis de consistencia se elabora el producto Especificación de


Requisitos Software, que constituye un punto de referencia en el desarrollo del software y la línea
base de referencia para las peticiones de cambio sobre los requisitos inicialmente especificados.

En este proceso se inicia también la especificación del Plan de Pruebas, que se completará
en el proceso Diseño del Sistema de Información.

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

Los productos resultantes del Análisis del Sistema de Información, dependen del tipo de
desarrollo de que se trate y se detallan a continuación especificando los que son distintos, según los
dos tipos de desarrollo mencionados:
• Descripción general del entorno tecnológico.
• Glosario de términos.
• Catálogo de normas.
• Catálogo de requisitos.
• Especificación de interfaz de usuario.

Además, en Análisis Estructurado.


• Plan de migración y carga inicial de datos.

• Contexto del sistema.

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

• Descripción de interfaz con otros sistemas.

• Modelo de procesos.

• Modelo lógico de datos normalizado.

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


• Descripción de subsistemas de análisis.
• Descripción de interfaces entre subsistemas.
• Modelo de clases de análisis.
• Comportamiento de clases de análisis. / Diagramas híbridos
• Análisis de la realización de los casos de uso.

En este proceso es muy importante la participación de los usuarios, a través de técnicas


interactivas, como diseño de diálogos y prototipos, que permiten al usuario familiarizarse con el nuevo
sistema y colaborar en la construcción y perfeccionamiento del mismo.

2.- ETAPA: DESCRIPCIÓN DE NECESIDADES

INPUT OUTPUT ACTORES RESPONSABLE


- Necesidad - Descripción de la - Líder funcional - Líder funcional
Necesidad (F1) - Owner del Proyecto
- Usuario Final

2.1 Identificar Necesidades - Relevamiento Global - Descripción de Objetivos y


Alcance – Especificar Requerimiento.
Ante una necesidad detectada (mejora de un proceso, nuevo proceso, introducción de un nuevo servicio),
y una motivación clara y definida se lleva adelante un relevamiento global.
Definir el objetivo y alcance del proyecto y realizar la especificación del requerimiento funcional.

Se realiza una descripción general de la necesidad planteada por el usuario, y se estudian las posibles
restricciones de carácter económico, técnico, operativo y legal que puedan afectar al sistema. Antes de

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

iniciar el estudio de los requisitos del sistema se establecen los objetivos generales del Estudio de
Viabilidad, teniendo en cuenta las restricciones identificadas anteriormente.

Si el sistema objeto de estudio se encuentra en el ámbito de un Plan de Sistemas de Información vigente,


se debe de tomar como referencia el catálogo de requisitos y la arquitectura de información resultante del
mismo, como información adicional para la descripción general del sistema y determinación de los
requisitos iniciales.

3.- ESTABLECER EL ALCANCE DEL SISTEMA

Se analiza el alcance de la necesidad planteada y se identifican las restricciones relativas a la


sincronización con otros proyectos, que puedan interferir en la planificación y futura puesta a punto del
sistema objeto del estudio. Esta información se recoge en el catálogo de requisitos.

Si el sistema pertenece al ámbito de un Plan de Sistemas de Información, se debe tener en cuenta la


arquitectura de información propuesta para analizar el alcance del sistema e identificar los sistemas de
información que quedan fuera del ámbito del estudio. Además, se estudia el plan de proyectos, para
determinar las posibles dependencias con
otros proyectos.

Una vez establecido el alcance, se identifican las unidades organizativas afectadas por el sistema, así
como su estructura y responsables de las mismas. Para determinar los responsables se tiene en cuenta a
quiénes afecta directamente y quiénes pueden influir en el éxito o fracaso del mismo.

En función del alcance del sistema y los objetivos del Estudio de Viabilidad del Sistema, se determinan las
actividades y tareas a realizar. En particular, hay que decidir si se realiza o no el estudio de la situación
actual y, en el caso de considerarlo necesario, con qué objetivo.

Si el sistema pertenece al ámbito de un Plan de Sistemas de Información, los criterios que pueden orientar
sobre la necesidad de llevar a cabo el estudio de la situación actual dependen de la arquitectura de
información propuesta, en cuanto a la identificación de los sistemas de información actuales, implicados en
el ámbito de este estudio, que se haya decidido conservar.

Se identifican los usuarios participantes de las distintas unidades organizativas afectadas para la
realización del Estudio de Viabilidad del Sistema, determinando previamente sus perfiles y
responsabilidades.

Debe comunicarse el plan de trabajo a los usuarios identificados como implicados en el Estudio de
Viabilidad, solicitando su aceptación y esperado su confirmación.

4.- ESTUDIO DE LA SITUACIÓN ACTUAL

La situación actual es el estado en el que se encuentran los sistemas de información existentes en el


momento en el que se inicia su estudio.

Teniendo en cuenta el objetivo del estudio de la situación actual, se realiza una valoración de la
información existente acerca de los sistemas de información afectados. En función de dicha valoración, se
especifica el nivel de detalle con que se debe llevar a cabo el estudio.

Si es necesario, se constituye un equipo de trabajo específico para su realización y se identifican los


usuarios participantes en el mismo.

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

Si se decide documentar la situación actual, normalmente es conveniente dividir el sistema actual en


subsistemas. Si es posible se describirá cada uno de los subsistemas, valorando qué información puede
ser relevante para la descripción.

Como resultado de esta actividad se genera un diagnóstico, estimando la eficiencia de los sistemas de
información existentes e identificando los posibles problemas y las mejoras.

5.- DEFINICIÓN DE REQUISITOS DEL SISTEMA

Esta actividad incluye la determinación de los requisitos generales, mediante una serie de sesiones de
trabajo con los usuarios participantes, que hay que planificar y realizar.

Una vez finalizadas, se analiza la información obtenida definiendo los requisitos y sus prioridades, que se
añaden al catálogo de requisitos que servirá para el estudio y valoración de las distintas alternativas de
solución que se propongan.

6.- CONCEPTOS Y PRINCIPIOS DEL ANALISIS


Tanto el desarrollador como el cliente tienen un papel activo en el análisis y especificación de los
requisitos.

6.1 ANALISIS DE REQUISITOS

Es una tarea que permite al ingeniero de sistemas:


- Especificar la función y rendimiento del soft.
- Indicar la interfaz del soft con otros elementos del sistema
- Establecer las restricciones que debe cumplir el soft
- Construir los modelos de dominios de datos, funcional y comportamiento
- Proporciona al diseñador y al cliente los medios para valorar la calidad una vez que se ha
construido el software.

El análisis de requisitos se puede dividir en 5 áreas:


1) Reconocimiento del problema
2) Evaluación y síntesis - qué ¿? -
3) Modelado del sistema
4) Especificación del software
5) Revisión

El desarrollador puede no estar seguro de que un enfoque específico consiga apropiadamente el


funcionamiento y rendimiento adecuados. Por esta y otras muchas razones, se puede llevar a cabo un
enfoque alternativo del análisis de requisitos, denominado prototipato o creación de prototipos.

6.2 TECNICAS DE COMUNICACIÓN

6.2.1 Inicio del proceso

Para empezar la comunicación entre cliente y desarrollador se lleva a cabo una reunión o entrevista
preliminar. Se sugiere que el analista empiece preguntando cuestiones de contexto libre, es decir un
conjunto de preguntas que llevarán a un entendimiento básico del problema. Pero el formato de 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.

6.2.2 técnicas para facilitar las especificaciones de una aplicación.

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

El enfoque de Técnicas para Facilitar las Especificaciones de la Aplicación (TFEA), es partidario de la


creación de un equipo conjunto de clientes y desarrolladores que trabajan juntos para identificar el
problema, proponer soluciones, negociar diferentes enfoques y especificar un conjunto preliminar de
requisitos de la solución.
TFEA – DIRECTRICES BÁSICAS:
- La reunión se celebra en un lugar neutral y acuden tanto clientes como los desarrolladores.
- Se establecen normas de preparación y de participación.
- Se sugiere una agenda lo suficientemente formal como para cubrir todos los puntos importantes pero
lo suficientemente informal como para animar el libre flujo de ideas.
- Un coordinador para coordinar la reunión.
- Se usa un mecanismo de definición – gràficos, carteles, pizarra, hojas de trabajo –
- Objetivo: identificar el problema, proponer elementos de solución.

6.2.3 Despliegue de la función de calidad

El Despliegue de la Función Calidad (DFC) es una técnica de gestión de calidad que traduce las
necesidades del cliente en requisitos técnico del software. DFC identifica 3 tipos de requisitos:
- Requisitos normales: se declaran objetivos y metas para un producto o sistema durante reuniones
con el cliente. Si estos requisitos están presentes el cliente estará satisfecho.
- Requisitos esperados: son implícitos al producto o sistema y pueden ser tan fundamentales que el
cliente no los declara explícitamente. Su ausencia será motivo de una insatisfacción significativa.
- Requisitos innovadores: estas características van más allá de las expectativas del cliente y suelen
ser muy satisfactorias. El producto entregado contiene ciertas capacidades no esperadas.

El despliegue de función se utiliza para determinar el valor de cada función requerida para el sistema.

7.- PRINCIPIOS DEL ANALISIS

Todos los métodos de análisis se relacionan por un conjunto de Principios operativos:


1) Debe representarse y entenderse el dominio de información de un problema.
2) Deben definirse las funciones que debe realizar el sotf.
3) Debe representarse el comportamiento del soft (como consecuencia de acontecimientos externos)
4) Deben dividirse los modelos que representan información, función y comportamiento.
5) El modelo del análisis debería ir desde la información esencial hasta el detalle de la
implementación.

Directrices para la ingeniería de requisitos(Davis):


- Entender el problema antes de crear el modelo de análisis.
- Desarrollar prototipos que permitan al usuario entender cómo será la interacción hombre-máquina.
- Registrar el origen y la razón de cada requisito.
- Usar múltiples planeamientos de requisitos.
- Dar prioridad a los requisitos.
- Trabajar para eliminar la ambigüedad.

7.1 El dominio de la información.

El primer principio operativo de análisis requiere el examen del dominio de la información. Este
dominio contiene 3 visiones diferentes:
1) el contenido de la información – datos y control -
2) el flujo de la información – como cambian los datos y control -
3) la estructura de la información – organización interna de datos y control –

7.1.2 Modelado

Los modelos se crean para entender mejor la entidad que se va a construir y es fundamental para un
buen trabajo de análisis:
51 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García

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

7.1.3 Partición

Es dividir los problemas que son demasiados grandes o complejos para entenderlos globalmente. La
partición descompone a un problema en sus partes constitutivas.
El enfoque de partición también puede aplicarse al dominio de la información y al de comportamiento.

7.1.4 Visiones esenciales y de implementación

Visión esencial: de los requisitos del software presenta las funciones a conseguir y la información a
procesar mínimos sin tener en cuenta los detalles de la implementación.
Visión de implementación: de los requisitos del software introduce la manifestación en el mundo real de
las funciones de procesamiento y las estructuras de la información.

7.2 CREACION DE PROTOTIPOS

7.2.1 Enfoque

La creación de prototipos puede ser cerrada o abierta:


- Cerrada: Prototipo desechable: sirve únicamente como una basta demostración de los requisitos.
Después se desecha.
- Abierta: Prototipo evolutivo: es empleado como primera parte de una actividad de análisis a la que
seguirá el diseño y la construcción. Es la primera evolución del sistema terminado.

7.2.2 Métodos y herramientas para el desarrollo de prototipos.

Para crear rápidamente prototipos existen:


- Técnicas de cuarta generación: amplia gama de lenguajes de consultas e informes de bases de
datos, generadores de programas.
- Componentes de software reutilizables: ensamblar, más que construir, con componentes ya
existentes.
- Especificaciones formales y entornos para prototipos

7.3 ESPECIFICACION

7.3.1 Principios de la especificación:


1) Separar la funcionalidad de la implementación.
2) Desarrollar un modelo de comportamiento
3) Establecer el contexto en que opera el software.
4) Definir el entorno en que va a opera el sistema.
5) Crear el modelo intuitivo en vez de un diseño o modelo de implementación.
6) Establecer el contenido y la estructura de una especificación de manera que acepte cambios.

7.3.2 Representación:

Los requisitos del soft pueden especificarse de varias maneras. Directrices a seguir:
- El formato de la representación y el contenido debería estar relacionados con el problema.
- La información contenida dentro de la especificación debería estar escalonada.
- La numeración de párrafos y diagramas debería indicar el nivel de detalle que se muestra.
- Los diagramas y otras formas de notación deberían restringirse en número y ser consistentes
den su empleo.
52 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García

- Las representaciones deben permitir revisiones.

7.3.4 La especificación de los requisitos del software.

Esquema como estructura para la especificación:


- Introducción
- Descripción de la información
- descripción funcional
- descripción del comportamiento
- criterios de validación
- bibliografía
- apéndice

En muchos casos una especificación de requisitos puede estar acompañada de un prototipo ejecutable o
en papel o un manual del usuario.

7.4 REVISION DE LA ESPECIFICACION

Es llevada a cabo tanto por el desarrollador como por el cliente. Inicialmente la revisión se lleva a cabo a
nivel macroscópico. Se estudian las siguientes cuestiones:
- Metas y objetivos declarados.
- Descripto todas las interfaces importantes.
- Definidos el flujo y la estructura de la información
- Diagramas.
- Funciones principales
- Requisitos alternativos.
- Riesgos tecnológicos.
- Manual del usuario, etc.

Directrices para una revisión detallada:


- Conectores persuasivos.
- Términos imprecisos
- Listas incompletas.
- Verbos de significados imprecisos.
- Pronombres de significados ambiguos.
- Frases que impliquen certidumbre. Etc.

La especificación firmada se convierte en un contrato para el desarrollo del software.

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

FASE:

DISEÑO GLOBAL

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

FASE: DISEÑO GLOBAL

FASE ETAPAS TAREAS ENTREGABLES COORDINADOR


D G - Descripción Requerimientos Funcionales
I - Especificación Funcional
L - Análisis de Requerimientos
S - Plan Maestro Actualizado
O - Impacto en Arquitectura Técnica
E - Arquitectura Técnica
B - Realización de Especificación
Actualizada
Ñ A ESPECIFICACIÓN - Plan General de Trabajo Líder
- Especificación Técnica
O GENERAL - Definición de Equipo de Trabajo Funcional
L - Plan General de Trabajo
- Administración de Riesgo
- Equipo de Trabajo
- Quality Management
- Carta de Decisión Actualizada
- Revisión Modalidad de Proyecto
- Est Fact Económica Act.
- Revisión de Business Plan

HITO 1: CONVALIDACIÓN ESPECIFICACIÓN - Especifiación Convalidada

El propósito del Diseño del Sistema de Información es obtener la definición de la arquitectura


del sistema y del entorno tecnológico que le va a dar soporte, junto con la especificación detallada de
los componentes. A partir de dicha información, se generan todas las especificaciones de
construcción relativas al propio sistema, así como la especificación técnica del plan de pruebas, la
definición de los requisitos de implantación y el diseño de los procedimientos de migración y carga
inicial, éstos últimos cuando proceda.

El diseño de la arquitectura del sistema dependerá en gran medida de las características de la


instalación, de modo que se ha de tener en cuenta una participación activa de los responsables de
sistemas y explotación de las organizaciones para las que se desarrolla el sistema de información.

Este proceso consta de un primer bloque de actividades, que se realizan en paralelo, y cuyo
objetivo es obtener el diseño global del sistema de información que comprende la partición física del
sistema de información, independiente de un entorno tecnológico concreto, la organización en
subsistemas de diseño, la especificación del entorno tecnológico sobre el que se despliegan dichos
subsistemas y la definición de los requisitos de operación, administración del sistema, seguridad y
control de acceso.

De este primer bloque de actividades se obtienen los siguientes productos:


• Catálogo de requisitos (se completa).
• Catálogo de excepciones.
• Catálogo de normas para el diseño y construcción.
• Diseño de la arquitectura del sistema.
• Entorno tecnológico del sistema.
• Procedimientos de operación y administración del sistema.
• Procedimientos de seguridad y control de acceso.
• Diseño detallado de los subsistemas de soporte.
• Modelo físico de datos optimizado.
• Asignación de esquemas físicos de datos.
Además, en Diseño Estructurado.
• Diseño de la arquitectura modular. (Diagrama de Procesos)

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

• Diseño de interfaz de usuario.

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


• Diseño de la realización de casos de uso.
• Modelo de clases de diseño.
• Comportamiento de clases de diseño.
• Diseño de interfaz de usuario.
Al igual que en el proceso de Análisis del Sistema de Información, antes de proceder a la
especificación de los componentes, se realiza una verificación y validación, con objeto de analizar la
consistencia entre los distintos modelos y formalizar la aceptación del diseño de la arquitectura del
sistema por parte de los usuarios.

Un segundo bloque de actividades complementa el diseño del sistema de información, en el que


se generan todas las especificaciones necesarias para la construcción del sistema de información:
• Las especificaciones de construcción de los componentes del sistema (módulos o clases,
según el caso) y de las estructuras de datos.
• Los procedimientos de migración y sus componentes asociados.
• La definición y revisión del plan de pruebas, y el diseño de las verificaciones de los niveles de
prueba establecidos.
• El catálogo de excepciones que permite establecer un conjunto de verificaciones
relacionadas con el propio diseño o con la arquitectura del sistema.
• La especificación de los requisitos de implantación.

ETAPA: ESPECIFICACIÓN GENERAL

1 Descripción de Requerimientos Funcionales


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

INPUT OUTPUT ACTORES RESPONSABLE


- Descripción de la - Especificación - Líder funcional - Líder funcional
Necesidad (F1) Funcional (F1) - Líder informático
- Procesos de Negocio - Usuarios
- Experto en Procesos de Negocio

DEFINICIÓN DEL SISTEMA


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

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

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


la Especificación
Análisis detallado de la especificación funcional, considerando también aspectos de seguridad, clases de
usuarios, perfiles, performance del sistema, volumetría, etc.
Definición del Modelo de Información del Sistema.
Análisis de impacto en la arquitectura técnica e interfaces con otros sistemas. Flujograma.
Elaboración de la especificación técnica del producto.

INPUT OUTPUT ACTORES RESPONSABLE


- Especificación - Plan Maestro - Líder funcional - Líder informático
Funcional (F1) Actualizado - Líder informático
- Arquitectura Técnica - Arquitectura Técnica - Experto tecnológico
- Plan Maestro Actualizada - Experto informático
- Especificación - Experto en seguridad informática
técnica (F2)

ESTABLECIMIENTO DE REQUISITOS
En esta actividad se lleva a cabo la definición, análisis y validación de los requisitos a partir de la
información facilitada por el usuario, completándose un catálogo de requisitos.

El objetivo de esta actividad es obtener un catálogo detallado de los requisitos, a partir del cual se pueda
comprobar que los productos generados en las actividades de modelización se ajustan a los requisitos de
usuario.

Esta actividad se descompone en un conjunto de tareas que, si bien tienen un orden, exige continuas
realimentaciones y solapamientos, entre sí y con otras tareas realizadas en paralelo.

No es necesaria la finalización de una tarea para el comienzo de la siguiente. Lo que se tiene en un


momento determinado es un catálogo de requisitos especificado en función de la progresión del proceso
de análisis.

Se propone como técnica de obtención de requisitos la especificación de los casos de uso o diagramas
híbridos. Dichas técnicas ofrece un diagrama simple y una guía de especificación en las sesiones de
trabajo con el usuario.

IDENTIFICACIÓN DE SUBSISTEMAS DE ANÁLISIS


El objetivo de esta actividad es común tanto para análisis estructurado como para análisis orientado a
objetos, y el esfuerzo está orientado a facilitar el análisis del sistema de información llevando a cabo la
descomposición del sistema en subsistemas.

Se realiza en paralelo con el resto de las actividades de generación de modelos del análisis. Por tanto, se
asume la necesidad de una realimentación y ajuste continuo con respecto a la definición de los
subsistemas, sus dependencias y sus interfaces.

3 Plan General de Trabajo


Confección del plan general de trabajo (cronograma), identificando tareas, hitos de entregables, recursos
(externos e internos).

INPUT OUTPUT ACTORES RESPONSABLE


- Especificación Técnica (F2) - Plan General de - Líder informático - Líder informático
- Especificación Funcional (F1) Trabajo - Líder funcional

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

4 Definición de Equipo de Trabajo


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

INPUT OUTPUT ACTORES RESPONSABLE


- Descripción de la - Equipo de Trabajo - Líder informático - Líder funcional
Necesidad (F1) - Plan General de - Líder funcional
- Especificación Trabajo (actualizado)
técnica (F2)
- Plan General de
Trabajo

5 Administración del riesgo


Análisis de riesgos, identificación, cuantificación de fuentes de riesgos, síntomas de riesgos, lista de
oportunidades (a seguir o a ignorar), planes de contingencia.

INPUT OUTPUT ACTORES RESPONSABLE


- Especificación - Análisis de Riesgo - Líder funcional - Líder funcional
técnica (F2) - Líder informático
- Plan General de - Experto informático
Trabajo - Experto en
seguridad
informática

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

6 Quality Management
Definición e identificación de indicadores de calidad asociados a cada tarea e hito del proyecto.
Elaborar el Plan de Calidad.

INPUT OUTPUT ACTORES RESPONSABLE


- Especificación - Indicadores de - Líder funcional - Líder funcional
técnica (F2) Calidad - Líder informático
- Plan General de - Plan Quality - Quality Assurance
Trabajo Management - Experto en calidad
- Especificación
funcional (F1)

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

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

 Documentos de especificación funcional (f1)


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

HITO 1: CONVALIDACIÓN ESPECIFICACIÓN

El Comité Ejecutivo analizará, revisará y convalidará la Especificación resultante


en forma conjunta.

INPUT: - Información Generada en la Fase Diseño Global


- Especificación técnica (F2)
- Especificación funcional (F1)
OUTPUT: - Especificación funcional validada (F1 validado)
- Especificación técnica validada (F2 validado)
- Indicadores de Calidad
- Plan Quality Management
ACTORES: - Líder informático
- Líder funcional
- Experto tecnológico
- Usuario
RESPONSABLE: - Comité Ejecutivo

Check-list  Definición del Equipo de Trabajo


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

“CONVALIDACIÓN ESPECIFICACIÓN” constituye el


HITO 1 de Validación del Owner del Proyecto.

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

FASE:

DISEÑO DETALLADO

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

FASE: DISEÑO DETALLADO

FASE ETAPAS TAREAS ENTREGABLES COORDINADOR


D D - Especificación Técnica de Detalle - Espec. técnica de Detalle
I E - Diseño Tecnología - Plan Detallado de Trabajo
S T - Plan Detallado de Trabajo - Plan de Pruebas Técnicas
E A - Diseño del Modelo de Datos - Plan de Contingencia y de
Ñ L DISEÑO - Prototipo Desastre Líder
O L DETALLADO - Elaboración Plan de Pruebas Técnicas - Plan de Backup Informático
A - Plan de Contingencia y Desastre - Doc. Soporte Mesa de Ayuda
- Plan de Backup - Doc. Soporte a Operaciones/
D
- Documentación Operativa Soporte
O - Definición Proc. Gestión de Configuración - Proc. Gestión de Configuración

- 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

HITO 3: APROBACIÓN DISEÑO DETALLADO Especificación Técnica de Detalle

ETAPA: DISEÑO DETALLADO 3

Especificación técnica de detalle – Diseño Tecnología - Plan Detallado de


Trabajo– Diseño del Modelo de Datos
Elaboración de la especificación técnica detallada del Proyecto, revisando y validando el detalle de la
arquitectura tecnológica, incluyendo los aspectos técnicos de detalle.
Elaboración del Plan de Trabajo de detalle. Identificación de hitos y tareas.
Especificación detallada del Modelo de Datos.
Determinación de las características del puesto de trabajo.

INPUT OUTPUT ACTORES RESPONSABLE


- Especificación - Especificación - Líder informático - Líder informático
técnica (F2) técnica de Detalle - Líder funcional
- Especificación (f3) - Experto tecnológico
funcional (F1) - Plan Detallado de - Experto informático
Trabajo - Experto en
seguridad
informática
- Proveedor

ELABORACIÓN DEL MODELO DE DATOS


El objetivo de esta actividad es identificar las necesidades de información de cada uno de los procesos
que conforman el sistema de información, con el fin de obtener un modelo de datos que contemple todas
las entidades, relaciones, atributos y reglas de negocio necesarias para dar respuesta a dichas
necesidades.

El modelo de datos se elabora siguiendo un enfoque descendente (top-down).


Notas:
3
El principal actor en la fase de Diseño Detallado es el proveedor (interno y externo), mientras que en la fase “Diseño Global” es la
empresa.
61 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García

A partir del modelo conceptual de datos, obtenido en la tarea Análisis de Requerimientos del Sistema, se
incorporan a dicho modelo todas las entidades que vayan apareciendo, como resultado de las
funcionalidades que se deban cubrir y de las necesidades de información del usuario. Es necesario tener
en cuenta el catálogo de requisitos.

Una vez construido el modelo conceptual y definidas sus entidades, se resuelven las relaciones complejas
y se completa la información de entidades, relaciones, atributos y ocurrencias de las entidades, generando
el modelo lógico de datos.

Como última tarea en la definición del modelo, se asegura la normalización hasta la cuarta forma normal
para obtener el modelo lógico de datos normalizado. Finalmente, si procede, se describen las necesidades
de migración y carga inicial de los datos.

DISEÑO FÍSICO DE DATOS


En esta actividad se define la estructura física de datos que utilizará el sistema, a partir del modelo lógico
de datos normalizado o modelo de clases, de manera que teniendo presentes las características
específicas del sistema de gestión de datos concreto a utilizar, los requisitos establecidos para el sistema
de información, y las particularidades del entorno tecnológico, se consiga una mayor eficiencia en el
tratamiento de los datos.

También se analizan los caminos de acceso a los datos utilizados por cada módulo/clase del sistema en
consultas y actualizaciones, con el fin de mejorar los tiempos de respuesta y optimizar los recursos de
máquina.

Las tareas de esta actividad se realizan de forma iterativa y en paralelo con las realizadas en las
actividades Definición de la Arquitectura del Sistema, dónde se especifican los detalles de arquitectura e
infraestructura y la planificación de capacidades, Diseño de la Arquitectura de Soporte dónde se
determinan y diseñan los servicios comunes que pueden estar relacionados con la gestión de datos
(acceso a bases de datos, ficheros, áreas temporales, sincronización de bases de datos, etc.), Diseño de
Casos de Uso Reales y de Clases, para desarrollo orientado a objetos, y Diseño de la Arquitectura de
Módulos del Sistema, para desarrollo estructurado, dónde se especifica la lógica de tratamiento y las
interfaces utilizadas.

En el caso de diseño orientado a objetos, esta actividad también es necesaria. La obtención del modelo
físico de datos se realiza aplicando una serie de reglas de transformación a cada elemento del modelo de
clases que se está generando en la actividad Diseño de Clases.

Asimismo, en esta actividad hay que considerar los estándares y normas establecidos para el diseño
aplicando, cuando proceda, los mecanismos genéricos de diseño identificados en la tarea Identificación de
Mecanismos Genéricos de Diseño.

DISEÑO DE LA ARQUITECTURA DE MÓDULOS DEL SISTEMA


El objetivo de esta actividad, que sólo se realiza en el caso de Diseño Estructurado, es definir los
módulos del sistema de información, y la manera en que van a interactuar unos con otros, intentando que
cada módulo trate total o parcialmente un proceso específico y tenga una interfaz sencilla.

Para cada uno de los subsistemas específicos, identificados en la tarea Identificación de los Subsistemas
de Diseño, se diseña la estructura modular de los procesos que lo integran, tomando como punto de
partida los modelos obtenidos en la tarea Validación de los Modelos del proceso de Análisis del Sistema
de Información y el catálogo de requisitos.

Dicha estructura se irá completando con los módulos que vayan apareciendo como consecuencia del
diseño de la interfaz de usuario, así como de la optimización del diseño físico de datos.

Durante el diseño de los módulos, se pueden identificar características o comportamientos comunes


relacionados con accesos a las bases de datos o ficheros, lógica de tratamiento, llamadas a otros

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

módulos, gestión de errores, etc. que determinen la necesidad de realizar su implementación como
subsistemas de soporte.

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

ELABORACIÓN DEL MODELO DE PROCESOS


El objetivo de esta actividad es analizar las necesidades del usuario para establecer el conjunto de
procesos que conforma el sistema de información. Para ello, se realiza una descomposición de dichos
procesos siguiendo un enfoque descendente (top-down), en varios niveles de abstracción, donde cada
nivel proporciona una visión más detallada del proceso definido en el nivel anterior.

Con el fin de facilitar el desarrollo posterior, se debe llegar a un nivel de descomposición en el que los
procesos obtenidos sean claros y sencillos, es decir, buscar un punto de equilibrio en el que dichos
procesos tengan significado por sí mismos dentro del sistema global y a su vez la máxima independencia y
simplicidad.

Se recomienda el uso de Diagramas de Flujos de Datos, Diagramas Híbridos y Diagrama de Estructura.

DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA


En esta actividad se define la arquitectura general del sistema de información, especificando las distintas
particiones físicas del mismo, la descomposición lógica en subsistemas de diseño y la ubicación de cada
subsistema en cada partición, así como la especificación detallada de la infraestructura tecnológica
necesaria para dar soporte al sistema de información.

El particionamiento físico del sistema de información se especifica identificando los nodos y las
comunicaciones entre los mismos, con cierta independencia de la infraestructura tecnológica que da
soporte a cada nodo.

Con el fin de organizar y facilitar el diseño, se realiza una división del sistema de información en
subsistemas de diseño, como partes lógicas coherentes y con interfaces claramente definidas.

Se establece una distinción entre subsistemas específicos del sistema de información (en adelante,
subsistemas específicos) y subsistemas de soporte, con la finalidad de independizar, en la medida de lo
posible, las funcionalidades a cubrir por el sistema de información de la infraestructura que le da soporte.
En la mayoría de los casos, los subsistemas específicos provienen directamente de las especificaciones
de análisis y de los subsistemas de análisis, mientras que los subsistemas de soporte provienen de la
necesidad de interacción del sistema de información con la infraestructura y con el resto de los sistemas,
así como de la reutilización de módulos o subsistemas ya existentes en la instalación.

Debido a que la definición de los subsistemas de soporte puede exigir la participación de distintos perfiles
técnicos, se propone el diseño de ambos tipos de subsistemas en actividades distintas, aunque en
paralelo.

Una vez identificados y definidos los distintos subsistemas de diseño, se determina su ubicación óptima de
acuerdo a la arquitectura propuesta. La asignación de dichos subsistemas a cada nodo permite disponer,
en función de la carga de proceso y comunicación existente entre los nodos, de la información necesaria
para realizar una estimación de las necesidades de infraestructura tecnológica que da soporte al sistema
de información.

Este factor es especialmente crítico en arquitecturas multinivel o cliente/servidor, donde las


comunicaciones son determinantes en el rendimiento final del sistema.

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

Se propone crear un catálogo de excepciones en el que se especifiquen las situaciones anómalas o


secundarias en el funcionamiento y ejecución del sistema de información, y que se irá completando a
medida que se avance en el diseño detallado de los subsistemas

En esta actividad también se establecen los requisitos, normas y estándares originados como
consecuencia de la adopción de una determinada solución de arquitectura o infraestructura, que serán
aplicables tanto en este proceso como en la Construcción del Sistema de Información.

Se detallan a su vez, de acuerdo a las particularidades de la arquitectura del sistema propuesta, los
requisitos de operación, seguridad y control, especificando los procedimientos necesarios para su
cumplimiento.

Como resultado de esta actividad, se actualizan los catálogos de requisitos y normas, y se generan los
siguientes productos:
 Diseño de la Arquitectura del Sistema, como producto que engloba el particionamiento físico del
sistema de información y la descripción de subsistemas de diseño.
 Entorno Tecnológico del Sistema, que a su vez comprende la especificación del entorno
tecnológico, las restricciones técnicas y la planificación de capacidades.
 Catálogo de Excepciones.
 Procedimientos de Operación y Administración del Sistema.
 Procedimientos de Seguridad y Control de Acceso.

GENERACIÓN DE ESPECIFICACIONES DE CONSTRUCCIÓN


En esta actividad se generan las especificaciones para la construcción del sistema de información, a partir
del diseño detallado.

Estas especificaciones definen la construcción del sistema de información a partir de las unidades básicas
de construcción (en adelante, componentes), entendiendo como tales unidades independientes y
coherentes de construcción y ejecución, que se corresponden con un empaquetamiento físico de los
elementos del diseño de detalle, como pueden ser módulos, clases o especificaciones de interfaz.

La división del sistema de información en subsistemas de diseño proporciona, por continuidad, una
primera división en subsistemas de construcción, definiendo para cada uno de ellos los componentes que
lo integran. Si se considera necesario, un subsistema de diseño se podrá dividir a su vez en sucesivos
niveles para mayor claridad de las especificaciones de construcción.

Las dependencias entre subsistemas de diseño proporcionan información para establecer las
dependencias entre los subsistemas de construcción y, por lo tanto, definir el orden o secuencia que se
debe seguir en la construcción y en la realización de las pruebas.

También se generan las especificaciones necesarias para la creación de las estructuras de datos en los
gestores de bases de datos o sistemas de ficheros.

El producto resultante de esta actividad es el conjunto de las especificaciones de construcción del sistema
de información, que comprende:
 Especificación del entorno de construcción.
 Descripción de subsistemas de construcción y dependencias.
 Descripción de componentes.
 Plan de integración del sistema de información.
 Especificación detallada de componentes.
 Especificación de la estructura física de datos.

Prototipo
Realización de prototipo

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

INPUT OUTPUT ACTORES RESPONSABLE


- Especificación - Prototipo - Líder funcional - Líder informático
Técnica de Detalle - Líder informático
(Diseño detallado) - Proveedor

DEFINICIÓN DE INTERFACES DE USUARIO


En esta actividad se especifican las interfaces entre el sistema y el usuario: formatos de pantallas,
diálogos, e informes, principalmente. El objetivo es realizar un análisis de los procesos del sistema de
información en los que se requiere una interacción del usuario, con el fin de crear una interfaz que
satisfaga todos los requisitos establecidos, teniendo en cuenta los diferentes perfiles a quiénes va dirigido.

Al comienzo de este análisis es necesario seleccionar el entorno en el que es operativa la interfaz,


considerando estándares internacionales y de la instalación, y establecer las directrices aplicables en los
procesos de diseño y construcción. El propósito es construir una interfaz de usuario acorde a sus
necesidades, flexible, coherente, eficiente y sencilla de utilizar, teniendo en cuenta la facilidad de cambio a
otras plataformas, si fuera necesario.

Se identifican los distintos grupos de usuarios de acuerdo con las funciones que realizan, conocimientos y
habilidades que poseen, y características del entorno en el que trabajan. La identificación de los diferentes
perfiles permite conocer mejor las necesidades y particularidades de cada uno de ellos.

Asimismo, se determina la naturaleza de los procesos que se llevan a cabo (en lotes o en línea). Para
cada proceso en línea se especifica qué tipo de información requiere el usuario para completar su
ejecución realizando, para ello, una descomposición en diálogos que refleje la secuencia de la interfaz de
pantalla tipo carácter o pantalla gráfica.

Finalmente, se define el formato y contenido de cada una de las interfaces de pantalla especificando su
comportamiento dinámico.

Como resultado de esta actividad se genera la especificación de interfaz de usuario, como producto que
engloba los siguientes elementos:
 Principios generales de la interfaz.
 Catálogo de perfiles de usuario.
 Descomposición funcional en diálogos.
 Catálogo de controles y elementos de diseño de interfaz de pantalla.
 Formatos individuales de interfaz de pantalla.
 Modelo de navegación de interfaz de pantalla.
 Formatos de impresión.
 Prototipo de interfaz interactiva.
 Prototipo de interfaz de impresión.

DISEÑO DE LA ARQUITECTURA DE SOPORTE


En esta actividad se lleva a cabo la especificación de la arquitectura de soporte, que comprende el diseño
de los subsistemas de soporte identificados en la actividad de Definición de la Arquitectura del Sistema, y
la determinación de los mecanismos genéricos de diseño.

Estos últimos sirven de guía en la utilización de diferentes estilos de diseño, tanto en el ámbito global del
sistema de información, como en el diseño de detalle.

El diseño de los subsistemas de soporte, conceptualmente, es similar al diseño de los subsistemas


específicos, aunque debe cumplir con unos objetivos claros de reutilización.

De esta manera, se consigue simplificar y abstraer el diseño de los subsistemas específicos de la


complejidad del entorno tecnológico, dotando al sistema de información de una mayor independencia de la
infraestructura que le da soporte.

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

Con este fin, se aconseja la consulta de los datos de otros proyectos existentes, disponible en el Histórico
de Proyectos. Si esto no fuera suficiente, se puede contar en esta actividad con la participación de perfiles
técnicos, con una visión global de la instalación.

Esta actividad se realiza en paralelo al diseño detallado, debido a que existe una constante realimentación,
tanto en la especificación de los subsistemas con sus interfaces y dependencias, como en la aplicación de
esqueletos o patrones en el diseño.

Los productos resultantes de esta actividad son:


 Diseño Detallado de los Subsistemas de Soporte.
 Mecanismos Genéricos de Diseño y Construcción.

DISEÑO DE CASOS DE USO REALES


Esta actividad, que se realiza solo en el caso de Diseño Orientado a Objetos, tiene como propósito
especificar el comportamiento del sistema de información para un caso de uso, mediante objetos o
subsistemas de diseño que interactúan, y determinar las operaciones de las clases e interfaces de los
distintos subsistemas de diseño.

Para ello, una vez identificadas las clases participantes dentro de un caso de uso, es necesario completar
los escenarios que se recogen del análisis, incluyendo las clases de diseño que correspondan y teniendo
en cuenta las restricciones del entorno tecnológico, esto es, detalles relacionados con la implementación
del sistema.

Es necesario analizar los comportamientos de excepción para dichos escenarios. Algunos de ellos pueden
haber sido identificados en el proceso de análisis, aunque no se resuelven hasta este momento. Dichas
excepciones se añadirán al catálogo de excepciones para facilitar las pruebas.

Algunos de los escenarios detallados requerirán una nueva interfaz de usuario. Por este motivo es
necesario diseñar el formato de cada una de las pantallas o impresos identificados.

Es importante validar que los subsistemas definidos en la tarea Identificación de Subsistemas de Diseño
tienen la mínima interfaz con otros subsistemas.

Por este motivo, se elaboran los escenarios al nivel de subsistemas y, de esta forma, se delimitan las
interfaces necesarias para cada uno de ellos, teniendo en cuenta toda la funcionalidad del sistema que
recogen los casos de uso.

Además, durante esta actividad pueden surgir requisitos de implementación, que se recogen en el
catálogo de requisitos.

DISEÑO DE CLASES
El propósito de esta actividad, que se realiza sólo en el caso de Diseño Orientado a Objetos, es
transformar el modelo de clases lógico, que proviene del análisis, en un modelo de clases de diseño.
Dicho modelo recoge la especificación detallada de cada una de las clases, es decir, sus atributos,
operaciones, métodos, y el diseño preciso de las relaciones establecidas entre ellas, bien sean de
agregación, asociación o jerarquía.

Para llevar a cabo todos estos puntos, se tienen en cuenta las decisiones tomadas sobre el entorno
tecnológico y el entorno de desarrollo elegido para la implementación.

Se identifican las clases de diseño, que denominamos clases adicionales, en función del estudio de los
escenarios de los casos de uso, que se está realizando en paralelo en la actividad Diseño de Casos de
Uso Reales, y aplicando los mecanismos genéricos de diseño que se consideren convenientes por el tipo
de especificaciones tecnológicas y de desarrollo.

Entre ellas se encuentran clases abstractas, que integran características comunes con el objetivo de
especializarlas en clases derivadas. Se diseñan las clases de interfaz de usuario, que provienen del
66 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García

análisis. Como consecuencia del estudio de los escenarios secundarios que se está realizando, pueden
aparecer nuevas clases de interfaz.

También hay que considerar que, por el diseño de las asociaciones y agregaciones, pueden aparecer
nuevas clases, o desaparecer incluyendo sus atributos y métodos en otras, si se considera conveniente
por temas de optimización.

La jerarquía entre las clases se va estableciendo a lo largo de esta actividad, a medida que se van
identificando comportamientos comunes en las clases, aunque haya una tarea propia de diseño de la
jerarquía.

Otro de los objetivos del diseño de las clases es identificar para cada clase, los atributos, las operaciones
que cubren las responsabilidades que se identificaron en el análisis, y la especificación de los métodos
que implementan esas operaciones, analizando los escenarios del Diseño de Casos de Uso Reales.

Se determina la visibilidad de los atributos y operaciones de cada clase, con respecto a las otras clases
del modelo.
Una vez que se ha elaborado el modelo de clases, se define la estructura física de los datos
correspondiente a ese modelo, en la actividad Diseño Físico de Datos.

Además, en los casos en que sea necesaria una migración de datos de otros sistemas o una carga inicial
de información, se realizará su especificación a partir del modelo de clases y las estructuras de datos de
los sistemas origen.

Como resultado de todo lo anterior se actualiza el modelo de clases del análisis, una vez recogidas las
decisiones de diseño.

VERIFICACIÓN Y ACEPTACIÓN DE LA ARQUITECTURA DEL SISTEMA


El objetivo de esta actividad es garantizar la calidad de las especificaciones del diseño del sistema de
información y la viabilidad del mismo, como paso previo a la generación de las especificaciones de
construcción.

Para cumplir dicho objetivo, se llevan a cabo las siguientes acciones:


 Verificación de la calidad técnica de cada modelo o especificación
 Aseguramiento de la coherencia entre los distintos modelos
 Aceptación del diseño de la arquitectura por parte de Explotación y Sistemas.

Esta actividad es compleja, por lo que es aconsejable utilizar herramientas de apoyo para la realización de
sus tareas.

Elaboración del Plan de Pruebas Técnicas


Definición de la estrategia y elaboración del Plan de Pruebas Técnicas en base al Especificación Técnica
de Detalle.
Ver estrategia de pruebas.

INPUT OUTPUT ACTORES RESPONSABLE


- Especificación - Plan de Pruebas - Líder informático - Líder informático
Técnica de Detalle Técnicas - Líder funcional
(Diseño detallado) - Experto tecnológico
- Experto informático
- Experto en
seguridad
informática
- Proveedor

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

En esta actividad se inicia la definición del plan de pruebas, el cual sirve como guía para la realización de
las pruebas, y permite verificar que el sistema de información cumple las necesidades establecidas por el
usuario, con las debidas garantías de calidad.

El plan de pruebas es un producto formal que define los objetivos de la prueba de un sistema, establece y
coordina una estrategia de trabajo, y provee del marco adecuado para elaborar una planificación paso a
paso de las actividades de prueba.

El plan se inicia en el proceso Análisis del Sistema de Información, definiendo el marco general, y
estableciendo los requisitos de prueba de aceptación, relacionados directamente con la especificación de
requisitos.

Dicho plan se va completando y detallando a medida que se avanza en los restantes procesos del ciclo de
vida del software, Diseño del Sistema de Información, Construcción del Sistema de Información e
Implantación y Aceptación del Sistema.

Se plantean los siguientes niveles de prueba:


 Pruebas unitarias.
 Pruebas de integración.
 Pruebas del sistema.
 Pruebas de implantación.
 Pruebas de aceptación.

En esta actividad también se avanza en la definición de las pruebas de aceptación del sistema. Con la
información disponible, es posible establecer los criterios de aceptación de las pruebas incluidas en dicho
nivel, al poseer la información sobre los requisitos que debe cumplir el sistema, recogidos en el catálogo
de requisitos.

Plan de contingencia y de desastre – Plan de Backup


Construcción del plan de contingencia y de desastre y del plan de backup.

INPUT OUTPUT ACTORES RESPONSABLE


- Especificación - Plan de - Líder informático - Líder informático
Técnica de Detalle Contingencia y de - Líder funcional
(Diseño detallado) Desastre - Experto tecnológico
- Plan de Backup - Experto informático
- Experto en
seguridad
informática
- Proveedor

Documentación Operativa
Generación de la documentación que contenga los aspectos operativos y de seguridad necesarios para la
puesta en producción y mantenimiento del sistema.
Esta documentación se irá completando hasta la Puesta en Producción.

INPUT OUTPUT ACTORES RESPONSABLE


- Especificación - Documento de - Líder informático - Líder informático
Técnica de Detalle Soporte a Mesa de - Líder funcional
(Diseño detallado) Ayuda - Experto tecnológico
- Documento de - Experto informático
Soporte a - Experto en
Operaciones/Soport seguridad
e Técnico informática
68 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García

- Proveedor

Definición del Procedimiento de Gestión de Configuración


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

INPUT OUTPUT ACTORES RESPONSABLE


- Arquitectura técnica - Procedimiento de - Líder Informático - Líder Informático
- Especificación Gestión de - Experto Informático
técnica Configuración
- Plan General de
Trabajo
- Equipo de Trabajo

ETAPA: DEFINICIÓN DE ESTRATEGIAS

Impacto Organizacional 4
Identificar con tiempo suficiente los impactos en la Organización que genera un cambio de
Sistemas/Procesos a efectos de poder planear acciones de cambio.
Se tomará como base el ítem “Impacto” del documento “Estudio de Factibilidad Técnico/Funcional”
generado en la fase de Estudio Preliminar.

INPUT OUTPUT ACTORES RESPONSABLE


- Especificación - Impacto - Líder funcional - Líder funcional
Técnica de Detalle Organizacional - Usuarios
(Diseño detallado) - Responsable de
- Estudio de Soporte al cambio
Factibilidad
Técnico/Funcional

Estrategia de implantación
Definir la estrategia de implantación del proyecto.
Identificar el modo de implantación: big bang, roll-out (en etapas).
Definir fases y releases.

INPUT OUTPUT ACTORES RESPONSABLE


- Especificación - Estrategia de - Líder funcional - Líder funcional
técnica de detalle implantación - Líder informático
(Diseño detallado)
- Impacto
Organizacional

Notas:
4
La ubicación de esta tarea en la Etapa de Diseño Detallado, responde a una cuestión temporal.
69 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García

Elaboración del Plan de Pruebas Funcionales


Definición de la estrategia y elaboración del Plan de Pruebas Funcionales, Armado de Condiciones de
5
Prueba, Armado de Set de Datos, Set de Pruebas , Estrategia de Prueba.

INPUT OUTPUT ACTORES RESPONSABLE


- Impacto - Plan de Pruebas - Líder funcional - Líder funcional
6
Organizacional Funcionales - Usuarios
- Especificación - Líder informático
técnica de detalle
(Diseño detallado)

Especificación del Entorno de Pruebas


El objetivo de esta tarea es la definición detallada y completa del entorno necesario para la realización de
las pruebas del sistema: unitarias, de integración, de implantación y de aceptación.

Se propone considerar los siguientes conceptos en la especificación del entorno:


 Entorno tecnológico: hardware, software y comunicaciones.
 Restricciones técnicas del entorno.
 Requisitos de operación y seguridad del entorno de pruebas.
 Herramientas de prueba relacionadas con la extracción de juegos de ensayo, análisis de
resultados, utilidades de gestión del entorno, etc.
 Planificación de capacidades previstas, o la información que estime oportuno el departamento
técnico para efectuar dicha planificación.
 Procedimientos de promoción de elementos entre entornos (desarrollo, pruebas, explotación, etc.).
 Procedimientos de emergencia y de recuperación, así como de vuelta atrás.

Estrategia de Migración, Confiabilización, Conversión de Datos y Carga inicial de


Datos
Definir la estrategia de confiabilización.

INPUT OUTPUT ACTORES RESPONSABLE


- Especificación - Estrategia de - Líder funcional - Líder funcional
técnica de detalle confiabilización - Líder informático
(Diseño detallado) - Estrategia de - Proveedor
- Estrategia de conversión de datos - Experto informático
Implantación

DISEÑO DE LA MIGRACIÓN Y CARGA INICIAL DE DATOS


Esta actividad sólo se lleva a cabo cuando es necesaria una carga inicial de información, o una migración
de datos de otros sistemas, cuyo alcance y estrategia a seguir se habrá establecido previamente.

Para ello, se toma como referencia el plan de migración y carga inicial de datos, que recoge las
estructuras físicas de datos del sistema o sistemas origen implicadas en la conversión, la prioridad en las
cargas y secuencia a seguir, las necesidades previas de depuración de la información, así como los
requisitos necesarios para garantizar la correcta implementación de los procedimientos de migración sin
comprometer el funcionamiento de los sistemas actuales.

Notas:
5
De acuerdo a las Normas vigentes, los datos de Producción deberán tener la aprobación del Administrador Funcional
6
La descripción de la estrategia de pruebas funcionales está incluida en el documento general del plan de pruebas dentro del Anexo
Carpeta de Proyectos.
70 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García

A partir de dicho plan, y de acuerdo a la estructura física de los datos del nuevo sistema, obtenida en la
actividad Diseño Físico de Datos, y a las características de la arquitectura y del entorno tecnológico
propuesto en la actividad Definición de la Arquitectura del Sistema, se procede a definir y diseñar en
detalle los procedimientos y procesos necesarios para realizar la migración.

Se completa el plan de pruebas específico establecido en el plan de migración y carga inicial, detallando
las pruebas a realizar, los criterios de aceptación o rechazo de la prueba y los responsables de la
organización, realización y evaluación de resultados.

Asimismo, se determinan las necesidades adicionales de infraestructura, tanto para la implementación de


los procesos como para la realización de las pruebas.

Como resultado de esta actividad, se actualiza el plan de migración y carga inicial de datos con la
información siguiente:
 Especificación del entorno de migración.
 Definición de procedimientos de migración.
 Diseño detallado de módulos.
 Especificación técnica de las pruebas.
 Planificación de la migración y carga inicial.

Es importante considerar que una carga inicial de información no tiene el mismo alcance y complejidad
que una migración de datos, de modo que las tareas de esta actividad se deben llevar a cabo en mayor o
menor medida en función de las características de los datos a cargar.

Plan Acción para el Cambio 7


Estrategia de Desarrollo y organización (cambios de especialidades, competencias, estructuras, procesos
de trabajo, etc.)

INPUT OUTPUT ACTORES RESPONSABLE


- Impacto - Plan de Acción para - Líder funcional - Responsable
Organizacional el Cambio - Usuarios Soporte al Cambio
- Estrategia de - Responsable de
Implantación Capacitación

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

INPUT OUTPUT ACTORES RESPONSABLE


- Impacto - Plan de - Líder funcional - Responsable de
Organizacional Capacitación - Usuarios Capacitación
- Estrategia de - Líder informático
Implantación - Responsable de
Capacitación

Notas:
7
La ubicación de esta tarea en la Etapa de Diseño Detallado, responde a una cuestión temporal. Sin embargo, la culminación de la
misma, deberá haberse cumplido previo a la implantación.
8
La ubicación de esta tarea en la Etapa de Diseño Detallado, responde a una cuestión temporal. Sin embargo, la culminación de la
misma, deberá haberse cumplido previo a la implantación.
71 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García

Plan de Comunicación 9
Elaboración del Plan de Comunicación

INPUT OUTPUT ACTORES RESPONSABLE


- Impacto - Plan de - Líder funcional - Responsable
Organizacional Comunicación - Usuarios Soporte al Cambio
- Estrategia de - Responsable de
Implantación Soporte al Cambio

Notas:
9
La ubicación de esta tarea en la Etapa de Diseño Detallado, responde a una cuestión temporal. Sin embargo, la culminación de la
misma, deberá haberse cumplido previo a la implantación.
72 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García

HITO 3: APROBACIÓN DISEÑO DETALLADO

El líder funcional analizará, revisará y convalidará la Especificación Técnica de


Detalle.

INPUT: - Todos los entregables de la fase


OUTPUT: - Convalidación de entregables de la fase
ACTORES: - Líder informático
- Líder funcional
- Usuario
RESPONSABLE: - Líder funcional

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

“APROBACIÓN DISEÑO DETALLADO”


constituye el HITO 3 de validación del Owner del
Proyecto.

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

FASE:

CONSTRUCCIÓN

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

FASE: CONSTRUCCIÓN

FASE ETAPAS TAREAS ENTREGABLES COORDINADOR

- Desarrollo de Programas - Programas, Módulos &


- Adecuaciones de Programas Parametrización
PARAMETRIZACIÓN - Parametrización Líder
- Manual de Sistemas
Y DESARROLLO - Elaboracion Manuales de Sistemas Informático
- Manual de Usuario
- Elaboracion Manuales de Usuario - Manual de Procesos
C - Elaboración Manual de Procesos
O - Prueba Individual
N - Prueba de Cadena
S - Prueba de Integración - Protocolos de Prueba Líder
T PRUEBAS - Prueba Global - Aprobación de Pruebas Informático
R - Prueba de Perf., stress, volumen &
U seguridad
- Pruebas de Compatibilidad
C
C - Preparación
- Protocolo de Prueba Piloto Líder
I PRUEBA PILOTO - Prueba Piloto
- Homologación Prueba Piloto Funcional
Ó - Homologación Prueba Piloto
N
- Revisión del Acuerdo de Servicio y - Acuerdo de Servicio Revisado
Alcance - Plan de Implantación
DEFINICIÓN - Plan de Implantación - Plan de Soporte
Líder
PLAN DE - Plan de Soporte - Protocolo de Implantación
Funcional
IMPLANTACIÓN - Elaboración Protocolo de Implantación - Procedimiento de Producción
- Definición Procedimiento de Producción - Proc. Gestión de Configuración
- Actualización Gestión de Configuración actualizado

HITO 4: DECISIÓN DE IMPLANTACIÓN - Acuerdo de Implantación

La construcción del Sistema de Información tiene como objetivo final el desarrollo y prueba de
los distintos componentes del sistema de información, a partir del conjunto de especificaciones
lógicas y físicas del mismo, obtenido en el Proceso de Diseño global y detallado del Sistema de
Información.

Se desarrollan los procedimientos de operación y seguridad y se elaboran los manuales de


usuario final y de explotación, estos últimos cuando proceda.

Para conseguir dicho objetivo, se recoge la información relativa al producto del diseño
Especificaciones de construcción, se prepara el entorno de construcción, se genera el código
(programación) de cada uno de los componentes del sistema y se van realizando (a medida que se
vaya finalizando la programación) las pruebas unitarias de cada uno de los componentes y las de
integración entre subsistemas si las hubiere.

Si fuera necesario realizar una migración de datos, es en este proceso donde se lleva a cabo
la construcción de los componentes de migración, los procedimientos de migración y carga inicial de
datos.

Como resultado de dicho proceso se obtiene:


• Resultado de las pruebas unitarias.
• Evaluación del resultado de las pruebas de integración.
• Evaluación del resultado de las pruebas del sistema.
• Producto software:

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

 Código fuente de los componentes.


 Procedimientos de operación y administración del sistema.
 Procedimientos de seguridad y control de acceso.
 Manuales de usuario.
 Especificación de la formación a usuarios finales.
 Código fuente de los componentes de migración y carga inicial de datos.
 Procedimientos de migración y carga inicial de datos.
 Evaluación del resultado de las pruebas de migración y carga inicial de datos.

ETAPA: PARAMETRIZACIÓN Y DESARROLLO

Desarrollo de Programas - Adecuación de Programas – Parametrización –


Elaboración de Manuales de Sistemas
Desarrollo y codificación de la funcionalidad del sistema.
Actualización de Documentación de Sistemas.
Elaboración Manuales de Sistemas
Control y Seguimiento del Desarrollo

INPUT OUTPUT ACTORES RESPONSABLE


- Especificación - Programas, Módulos - Líder informático - Líder informático
Técnica de Detalle & Parametrización - Proveedor
(Diseño detallado) - Manual de Sistemas

PREPARACIÓN DEL ENTORNO DE GENERACIÓN Y CONSTRUCCIÓN


El objetivo de esta actividad es asegurar la disponibilidad de todos los medios y facilidades para que se
pueda llevar a cabo la construcción del sistema de información.

Entre estos medios, cabe destacar la preparación de los puestos de trabajo, equipos físicos y lógicos,
gestores de bases de datos, bibliotecas de programas, herramientas de generación de código, bases de
datos o ficheros de prueba, entre otros.

Las características del entorno de construcción y sus requisitos de operación y seguridad, así como las
especificaciones de construcción de la estructura física de datos, se establecen en la actividad Generación
de Especificaciones de Construcción, y constituyen el punto de partida para la realización de esta
actividad.

GENERACIÓN DEL CÓDIGO DE LOS COMPONENTES Y PROCEDIMIENTOS


El objetivo de esta actividad es la codificación de los componentes del sistema de información, a partir de
las especificaciones de construcción obtenidas en el proceso Diseño del Sistema de Información, así como
la construcción de los procedimientos de operación y seguridad establecidos para el mismo.

En paralelo a esta actividad, se desarrollan las actividades relacionadas con las pruebas unitarias y de
integración del sistema de información. Esto permite una construcción incremental, en el caso de que así
se haya especificado en el plan de pruebas y en el plan de integración del sistema de información.

CONSTRUCCIÓN DE LOS COMPONENTES Y PROCEDIMIENTOS DE MIGRACIÓN Y


CARGA INICIAL DE DATOS

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

El objetivo de esta actividad es la codificación y prueba de los componentes y procedimientos de


migración y carga inicial de datos, a partir de las especificaciones recogidas en el plan de migración y
carga inicial de datos obtenido en el proceso Diseño del Sistema de Información.

Previamente a la generación del código, se prepara la infraestructura tecnológica necesaria para realizar la
codificación y las pruebas de los distintos componentes y procedimientos asociados, de acuerdo a las
características del entorno de migración especificado en el plan de migración y carga inicial de datos.

Finalmente, se llevan a cabo las verificaciones establecidas en la especificación técnica del plan de
pruebas propio de la migración.

Elaboración de Manuales de Usuario


Elaboración Manuales de Usuario.

INPUT OUTPUT ACTORES RESPONSABLE


- Especificación - Manual de Usuario - Líder informático - Líder funcional
Técnica de Detalle - Líder funcional
(Diseño detallado) - Responsable de
Capacitación
- Proveedor

Elaboración de los Manuales de Usuario


El objetivo de esta tarea es elaborar la documentación de usuario, tanto usuario final como de explotación,
de acuerdo a los requisitos establecidos en la tarea Especificación de Requisitos de Documentación de
Usuario, y recogidos en el catálogo de requisitos.

Los requisitos de documentación especifican aspectos relativos a los tipos de documentos a elaborar y
estándares a seguir en la generación de los mismos, y para cada uno de ellos:
 Formato y soporte en el que se desarrollarán
 Estructura
 Distribución y mantenimiento de la documentación y número de copias a editar.

Elaboración del Manual de Procesos


Describir los nuevos circuitos de información de acuerdo a la forma de operación del nuevo sistema de
información que implementará.
El manual se basa en los procesos/sub-procesos definidos en la especificación funcional.

INPUT OUTPUT ACTORES RESPONSABLE


- Especificación - Manual de Procesos - Experto en procesos - Líder funcional
funcional (F1) - Líder funcional
- Especificación - Responsable de
Técnica de Detalle capacitación
(Diseño detallado)

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

EJECUCIÓN DE LAS PRUEBAS INDIVIDUALES

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

En esta actividad se realizan las pruebas unitarias de cada uno de los componentes del sistema de
información, una vez codificados, con el objeto de comprobar que su estructura es correcta y que se
ajustan a la funcionalidad establecida.

En el plan de pruebas se ha definido el entorno necesario para la realización de cada nivel de prueba, así
como las verificaciones asociadas a las pruebas unitarias, la coordinación y secuencia a seguir en la
ejecución de las mismas y los criterios de registro y aceptación de los resultados.

Prueba Individual
Prueba Unitaria de Módulos y Programa. (Cabe aclarar que esta prueba podría realizarse en la etapa de
desarrollo).
Las pruebas unitarias no requieren de datos operativos dado que el objetivo que se desea alcanzar es
comprobar el funcionamiento lógico del componente. De todos modos resulta deseable que los datos
utilizados conlleven la coherencia de las reglas de negocio que el sistema debe tratar en producción.

Asegurar el correcto funcionamiento de cada módulo en forma aislada utilizando dos enfoques: prueba de
caja blanca y prueba de caja negra (ver glosario)

INPUT OUTPUT ACTORES RESPONSABLE


- Plan de Pruebas - Protocolo de Prueba - Líder informático - Líder informático
Técnicas - Aprobación de
Prueba

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

INPUT OUTPUT ACTORES RESPONSABLE


- Plan de Pruebas - Protocolo de Prueba - Líder informático - Líder informático
Técnicas - Aprobación de
Prueba

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

INPUT OUTPUT ACTORES RESPONSABLE


- Plan de Pruebas - Protocolo de Prueba - Líder informático - Líder informático
Técnicas - Aprobación de
Prueba

EJECUCIÓN DE LAS PRUEBAS DE INTEGRACIÓN


El objetivo de las pruebas de integración es verificar si los componentes o subsistemas interactúan
correctamente a través de sus interfaces, tanto internas como externas, cubren la funcionalidad
establecida, y se ajustan a los requisitos especificados en las verificaciones correspondientes.

Particularmente los analistas que participan de esta prueba deben verificar el correcto impacto en la
registración de los datos en la base de datos utilizada; por esta razón estos analistas funcionales deben
poseer un conocimiento detallado del modelo de datos del sistema y el diseño de datos de las interfaces
con sistemas externos.

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

La estrategia a seguir en las pruebas de integración se establece en el plan de pruebas, dónde se habrá
tenido en cuenta el plan de integración del sistema de información, siempre y cuando se haya especificado
en la tarea Definición de Componentes y Subsistemas de Construcción.

Esta actividad se puede realizar en paralelo a las actividades Generación del Código de los Componentes
y elaboración de los Procedimientos y Ejecución de las Pruebas Unitarias. Sin embargo, es necesario que
los componentes objeto de las pruebas de integración se hayan verificado de manera unitaria.

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

INPUT OUTPUT ACTORES RESPONSABLE


- Plan de Pruebas - Protocolo de Prueba - Líder informático - Líder funcional
Funcionales - Aprobación de - Líder funcional
Prueba - Usuarios

EJECUCIÓN DE LAS PRUEBAS GLOBALES DEL SISTEMA


El objetivo de las pruebas del sistema es comprobar la integración del sistema de información
globalmente, verificando el funcionamiento correcto de las interfaces entre los distintos subsistemas que lo
componen y con el resto de sistemas de información con los que se comunica.

En la realización de estas pruebas es importante comprobar la cobertura de los requisitos, dado que su
incumplimiento puede comprometer la aceptación del sistema por el equipo de operación responsable de
realizar las pruebas de implantación del sistema, que se llevarán a cabo en el proceso Implantación y
Aceptación del Sistema.

Prueba de Performance, Volumen, Stress y Seguridad


Pruebas de Performance, Volumen, Stress y Seguridad

INPUT OUTPUT ACTORES RESPONSABLE


- Plan de Pruebas - Protocolo de Prueba - Líder informático - Líder informático
Técnicas - Aprobación de - Líder funcional
Prueba - Usuarios
- Experto informático
- Experto en
seguridad
informática

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

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

INPUT OUTPUT ACTORES RESPONSABLE


- Plan de Pruebas - Protocolo de Prueba - Líder informático - Líder informático
Técnicas - Aprobación de - Líder funcional
Prueba - Experto informático
- Administrador
funcional

ETAPA: PRUEBAS PILOTO

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

Prueba Piloto
Llevar adelante la prueba piloto propiamente dicha.

INPUT OUTPUT ACTORES RESPONSABLE


- Plan de Pruebas - Protocolo de Prueba - Líder informático - Líder funcional
funcionales Piloto - Líder funcional
- Plan de pruebas - Administrador
técnicas funcional
- Aprobación de - Usuario
Prueba Global
- Aprobación de
Prueba de
Performance,
Volumen, Stress y
Seguridad
- Aprobación de
Prueba de
Compatibilidad

Homologación Prueba Piloto


Aprobación Prueba Piloto.

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

INPUT OUTPUT ACTORES RESPONSABLE


- Protocolo de Prueba - Homologación de - Líder informático - Líder funcional
Piloto Prueba Piloto - Líder funcional
- Administrador
funcional
- Usuario

ETAPA: DEFINICIÓN PLAN DE IMPLANTACIÓN

Revisión del Acuerdo de Servicio y Alcance


De acuerdo a los resultados de las Pruebas, se evaluará y renegociará él alcance del sistema a implantar,
determinándose los pendientes y sus plazos de entrega.
Estas redefiniciones actualizarán el Acuerdo de Servicio del Proyecto, conformando un anexo.
En proyectos de gran envergadura, la negociación del Acuerdo de Servicio será llevada a cabo por el
Responsable Funcional y el Responsable Informático.

INPUT OUTPUT ACTORES RESPONSABLE


- Acuerdo de Servicio - Acuerdo de Servicio - Líder funcional - Líder funcional /
- Protocolo/Aprobació Revisado - Líder informático Líder informático
n Prueba Global
- Protocolo/Homologa
ción Prueba Piloto

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

INPUT OUTPUT ACTORES RESPONSABLE


- Estrategia de - Plan de Implantación - Líder funcional - Líder funcional
Implantación - Líder informático
- Acuerdo de Servicio - Proveedor
Revisado - Administrador
funcional

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

INPUT OUTPUT ACTORES RESPONSABLE


- Plan de Implantación - Plan de Soporte - Líder funcional - Líder funcional /
- Líder informático Líder informático
- Proveedor

Elaboración Protocolo de Implantación


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

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

Este protocolo deberá ser aprobado por el líder funcional del proyecto.

INPUT OUTPUT ACTORES RESPONSABLE


- Plan de Implantación - Protocolo de - Líder funcional - Líder funcional
Implantación - Líder informático
- Proveedor
- Administrador
funcional

Definición de Procedimiento de Producción


Definir el procedimiento de producción/explotación.
Comprende qué, cómo y cuándo se desarrollan las tareas de producción.

INPUT OUTPUT ACTORES RESPONSABLE


- Plan de Backup - Procedimiento de - Líder informático - Líder informático
- Plan de Producción - Líder funcional
Contingencia y - Experto en
Desastre seguridad
- Manual de Usuario informática
- Manual de Sistemas - Experto informático

Actualización del Procedimiento de Gestión de Configuración


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

INPUT OUTPUT ACTORES RESPONSABLE


- Procedimiento de - Procedimiento de - Líder Informático - Líder Informático
Gestión de Gestión de - Experto Informático
Configuración Configuración
actualizado

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

6.1.1.1 HITO 4: DECISIÓN DE IMPLANTACIÓN

El Líder Funcional analiza y revisa los informes de Prueba y Planes de


Implantación y toma la DECISIÓN de Implantación.

INPUT: - Informes de Pruebas


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

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

“DECISIÓN DE IMPLANTACIÓN” constituye el HITO 4 de


validación del Owner del Proyecto.

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

FASE DE
IMPLANTACIÓN

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

FASE: IMPLANTACIÓN

FASE ETAPAS TAREAS ENTREGABLES COORDINADOR

- Ejecución de Confiabilización de Datos


I - Conversión de Datos
M PREPARACIÓN - Aprobación de Conversión de Datos Líder
- Aprobación Conversión Datos
P IMPLANTACIÓN - Carga Inicial y Parametrización Funcional
L - Capacitación
A - Comunicación
N
T PUESTA EN - Realización Implantación Líder
- Recepción Provisoria Informático
A PRODUCCIÓN - Aceptación Implantación
C
I
O - Contrato de Servicio Producción
FORMALIZACIÓN - Contrato de Servicio de Producción - Doc. Soporte Mesa de Ayuda
N PUESTA EN - Documentación Puesta en Producción actualizado
Administrador
Funcional
PRODUCCIÓN (Anexo el Proc. de Producción) - Doc. Soporte a Operaciones/
Soporte actualizado

HITO 5: SISTEMA EN PRODUCCIÓN - Informe Sistema en Producción

Este proceso tiene como objetivo principal, la entrega y aceptación del sistema en su totalidad,
que puede comprender varios sistemas de información desarrollados de manera independiente,
según se haya establecido en el proceso de Estudio de Factibilidad del Sistema, y un segundo
objetivo que es llevar a cabo las actividades oportunas para el paso a producción del sistema.

Se establece el plan de implantación, una vez revisada la estrategia de implantación y se detalla el equipo
que lo realizará.

Para el inicio de este proceso se toman como punto de partida los componentes del sistema
probados de forma unitaria e integrados en el proceso Construcción del Sistema de Información, así
como la documentación asociada. El Sistema se someterá a las Pruebas de Implantación con la
participación del usuario de operación cuya responsabilidad, entre otros aspectos, es comprobar el
comportamiento del sistema bajo las condiciones más extremas. También se someterá a las Pruebas
de Aceptación cuya ejecución es responsabilidad del usuario final.

En este proceso se elabora el plan de mantenimiento del sistema de forma que el responsable
del mantenimiento conozca el sistema antes de que éste pase a producción. También se establece el
acuerdo de nivel de servicio requerido una vez que se inicie la producción. El acuerdo de nivel de
servicio hace referencia a servicios de gestión de operaciones, de soporte a usuarios y al nivel con el
que se prestarán dichos servicios.

Como resultado de este proceso se obtienen los siguientes productos:


• Plan de implantación del sistema en su totalidad.
• Equipo de implantación que realizará la implantación.
• Plan de formación del equipo de implantación (esquema, materiales, recursos necesarios,
planificación y especificación de la formación de usuarios finales).
• Evaluación de las pruebas de implantación del sistema por parte del usuario de operación.
• Evaluación de las pruebas de aceptación del sistema por parte del usuario final.
• Plan de mantenimiento previo al paso a producción.

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

• Acuerdo de nivel de servicio del sistema.


• Sistema en producción.

ETAPA: PREPARACIÓN IMPLANTACIÓN

Ejecución de Confiabilización de Datos


Realizar la confiabilización de los Datos. Validar que los datos sean correctos de acuerdo al formato
establecido.
El Líder Funcional será responsable de convocar al Administrador Funcional y solicitar las autorizaciones
que correspondan en caso de necesitar datos del sistema origen.

INPUT OUTPUT ACTORES RESPONSABLE


- Estrategia de - Datos - Líder funcional - Líder funcional
Confiabilización Confiabilizados - Líder informático
- Proveedor
- Usuario
- Administrador
Funcional

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

INPUT OUTPUT ACTORES RESPONSABLE


- Estrategia de - Datos Convertidos - Líder funcional - Líder informático
Conversión de Datos - Líder informático
- Proveedor
- Usuario
- Administrador
Funcional

Aprobación de la Conversión de Datos


El Líder Funcional aprueba la conversión de datos realizada.
El Líder Funcional será responsable de convocar al Administrador Funcional del sistema origen.

INPUT OUTPUT ACTORES RESPONSABLE


- Estrategia de - Aprobación de - Líder funcional - Líder funcional
Conversión de Datos Conversión de Datos - Líder informático
- Datos Convertidos - Proveedor
- Usuario
- Administrador
Funcional

Carga Inicial y Parametrización


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

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

INPUT OUTPUT ACTORES RESPONSABLE


- Estrategia de Carga - Datos Cargados - Líder funcional - Líder funcional
Inicial de datos - Líder informático
- Datos iniciales - Proveedor
- Usuario
- Administrador
Funcional

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

INPUT OUTPUT ACTORES RESPONSABLE


- Plan de - Personal capacitado - Usuario final - Responsable de
Capacitación - Experto informático Capacitación
- Manual de Usuario - Proveedor
- Manual de Procesos - Responsable de
capacitación

DEFINICIÓN DE LA FORMACIÓN DE USUARIOS FINALES


En esta actividad se establecen las necesidades de formación del usuario final, con el objetivo de
conseguir la explotación eficaz del nuevo sistema.

Para la definición de la formación hay que tener en cuenta las características funcionales y técnicas
propias del sistema de información, así como los requisitos relacionados con la formación del usuario final,
establecidos en la tarea Especificación de Requisitos de Implantación.

El producto resultante de esta actividad es la especificación de la formación de usuarios finales, que


consta de los siguientes elementos:
 Esquema de formación
 Materiales y entornos de formación.

En el proceso Implantación y Aceptación del Sistema, se unifican las especificaciones de formación de


cada sistema de información implicado en la implantación y se elabora un único plan de formación que
esté alineado con el plan de implantación del sistema.

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

INPUT OUTPUT ACTORES RESPONSABLE


- Plan de - Personal - Usuario final - Líder funcional
Comunicación comunicado - Líder funcional
- Plan de Implantación - Administrador
funcional
- Responsable
Soporte al Cambio

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

ETAPA: PUESTA EN PRODUCCIÓN


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

Realización Implantación
Realización de la implantación con la colaboración del líder funcional y soportes (in situ, a distancia,
soporte de las mesas de ayuda funcional, etc.)

Esta tarea implica la implantación del sistema en forma total (en caso de big bang) o de una de sus etapas
(roll-out).

INPUT OUTPUT ACTORES RESPONSABLE


- Plan de Implantación - Sistema/etapa - Experto informático - Líder Informático
- Protocolo de implantado - Proveedor
Implantación - Soporte funcional
- Soporte técnico
- Soporte aplicativo
- Administrador
funcional
- Usuario
- Líder informático

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

INPUT OUTPUT ACTORES RESPONSABLE


- Sistema/etapa - Recepción - Líder funcional - Líder funcional
implantado Provisoria - Líder informático
- Usuario final
- Administrador
funcional

ETAPA: FORMALIZACIÓN PUESTA EN PRODUCCIÓN

Contrato de Servicio de Producción

Firma del Contrato de Servicio entre el Usuario y los proveedores (internos y externos) del servicio.

INPUT OUTPUT ACTORES RESPONSABLE


- Especificación - Contrato de Servicio - Usuario - Administrador
técnica/funcional (F1 de Producción - Proveedores del funcional
10
/ F2) Servicio
- Administrador
funcional
- Experto en Calidad

Notas:
10
Normalmente los Proveedores del Servicio corresponden a: Soporte a Usuarios, Soporte Funcional, Soporte Técnico, Soporte
Aplicativo, Soporte Seguridad.
88 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García

Documentación Puesta en Producción 11


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

INPUT OUTPUT ACTORES RESPONSABLE


- Documento de - Administrador - Líder Funcional
Soporte a Mesa de Funcional - Líder Informático
Ayuda actualizado - Líder Funcional
- Documento de - Líder informático
Soporte a - Experto Informático
Operaciones/Soport
e Técnico
actualizado

Notas:
11
En este momento deberá estar finalizado el documento de procedimientos de producción, el cual se anexará a esta
documentación
12
Los roles de soporte enunciados podrán corresponder a más de un sector, de acuerdo a la organización.
89 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García

HITO 5: SISTEMA EN PRODUCCIÓN

El Administrador Funcional y el Líder Funcional redactarán el informe del


Sistema en Producción de manera conjunta.

INPUT: - Recepción provisoria del sistema/etapa


OUTPUT: - Informe Sistema en Producción
ACTORES: - Líder informático
- Líder funcional
- Administrador funcional
- Usuario
RESPONSABLE: - Líder funcional
- Administrador funcional

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

“SISTEMA EN PRODUCCIÓN” constituye el HITO 5 de


Validación del OWNER DEL PROYECTO.

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

FASE: PRODUCCIÓN

FASE ETAPAS TAREAS ENTREGABLES COORDINADOR


- Procesos Backup
- Procesos Seguridad
ADMINISTRACIÓN Soporte
- Procesos Performance - Tablero de Mando
TÉCNICA Técnico
- Control de Procesos Rutinarios
- Otros procesos

P - Administración de Usuarios y Perfiles


R ADMINISTRACIÓN - Mantenimiento de Datos, Tablas y Administrador
- Tablero de Mando
O FUNCIONAL Parámetros Funcional
D - Capacitación Nuevos Usuarios
U
C - Atención a Usuarios
C - Soporte Funcional Administrador
SOPORTE - Tablero de Mando
I - Soporte Técnico Funcional
Ó - Soporte Aplicativo
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.

ETAPA: ADMINISTRACIÓN TÉCNICA

Procesos de Backup
Realizar los procesos de backup de acuerdo al Plan de Backup.
Notificar los resultados del backup a los actores correspondientes

INPUT OUTPUT ACTORES RESPONSABLE


- Plan de Backup - Backup - Soporte Técnico - Soporte Técnico
- Notificación del - Administrador
backup funcional

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

INPUT OUTPUT ACTORES RESPONSABLE


13
- Procedimientos de - Tablero de Mando - Soporte Seguridad - Soporte Seguridad
Producción

Procesos de Performance
Realizar los procesos de performance.

Notas:
13
Los indicadores del tablero de mando se definirán en el contrato de servicio de producción
91 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García

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

INPUT OUTPUT ACTORES RESPONSABLE


14
- Procedimientos de - Tablero de Mando - Soporte Técnico - Soporte Técnico
Producción - Soporte Aplicativo

Control de Procesos Rutinarios


Realizar el control de procesos rutinarios (espacio en disco, control de interfaces, etc.)
Controlar el correcto funcionamiento del sistema, conociendo los calendarios de procesamiento.
Generar los informes correspondientes, mantener los indicadores y actualizar el tablero de mando.

INPUT OUTPUT ACTORES RESPONSABLE


15
- Procedimientos de - Tablero de Mando - Soporte Técnico - Soporte Técnico
Producción

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

INPUT OUTPUT ACTORES RESPONSABLE


- Solicitud - Tarea realizada - Soporte Técnico - Soporte Técnico
extraordinaria - Administrador
Funcional

ETAPA: ADMINISTRACIÓN FUNCIONAL

Administración de Usuarios y Perfiles


Administración de Usuarios y Perfiles en el sistema y la plataforma de acuerdo a la norma vigente.

INPUT OUTPUT ACTORES RESPONSABLE


- Solicitud de ABM de - Solicitud realizada - Administrador - Administrador
usuarios y perfiles Funcional Funcional
- Soporte en
seguridad

Mantenimiento de Datos, Tablas y Parámetros


Mantener los datos, tablas y parámetros de los Sistemas en Producción
Verificar por muestreo la validez de la información contenida en las copias de resguardo
Restablecer, corregir datos
Se solicitará a soporte aplicativo las herramientas necesarias para restablecer los datos.

INPUT OUTPUT ACTORES RESPONSABLE


- Necesidad de - Corrección/actualiza - Administrador - Administrador
corrección/actualizac ción realizada Funcional Funcional
Notas:
14
Los indicadores del tablero de mando se definirán en el contrato de servicio de producción
15
Los indicadores del tablero de mando se definirán en el contrato de servicio de producción
92 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García

ión de datos - Soporte aplicativo

Capacitación Nuevos Usuarios


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

INPUT OUTPUT ACTORES RESPONSABLE


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

ETAPA: SOPORTE

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

INPUT OUTPUT ACTORES RESPONSABLE


16
- Consulta/Problema/ - Tablero de Mando - Usuario - Soporte a Usuarios
Reclamo/Incidente - Reclamo - Soporte a Usuarios
atendido/solucionad
o/derivado

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

INPUT OUTPUT ACTORES RESPONSABLE


17
- Incidente Funcional - Tablero de Mando - Usuario - Soporte Funcional
- Manual de Usuario - Incidente - Soporte Funcional
- Manual de Sistemas atendido/resuelto/de - Soporte a Usuarios
- Manual de Procesos rivado - Administrador
funcional

Soporte Técnico
Recibir incidentes técnicos.

Notas:
16
Los indicadores del tablero de mando se definirán en el contrato de servicio de producción
17
Los indicadores del tablero de mando se definirán en el contrato de servicio de producción
93 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García

Diagnosticar, identificando criticidad y el origen del problema.


Ejecutar las acciones correctivas o derivar a los actores correspondientes.

INPUT OUTPUT ACTORES RESPONSABLE


18
- Incidente Técnico - Tablero de Mando - Soporte Técnico - Soporte Técnico
- Incidente técnico - Soporte a Usuarios
atendido/resuelto/de - Soporte en
rivado seguridad

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

INPUT OUTPUT ACTORES RESPONSABLE


- Incidente Aplicativo - Incidente aplicativo - Soporte Aplicativo - Soporte Aplicativo
- Manuales de resuelto/derivado - Administrador
Sistemas, de - Manual de Sistemas Funcional.
Usuario y de actualizado - Soporte funcional
Procesos - Manual de Usuario - Soporte técnico
actualizado - Experto en Procesos
- Manual de Procesos
actualizado

ETAPA: EVOLUCIÓN

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

INPUT OUTPUT ACTORES RESPONSABLE


- Necesidad - Nuevo - Administrador - Administrador
Requerimiento Funcional Funcional
- Otros generadores
de necesidad

Notas:
18
Los indicadores del tablero de mando se definirán en el contrato de servicio de producción
19
La aprobación del pasaje a producción y la puesta en producción se llevarán de acuerdo a las Normas vigentes.
94 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García

FASE: BALANCE DEL PROYECTO

FASE ETAPAS TAREAS ENTREGABLES COORDINADOR


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

ETAPA: BALANCE DEL PROYECTO

Balance del Proyecto


Verificar que los objetivos hayan sido alcanzados.
Chequear presupuesto, tiempos e indicadores claves definidos en “Identificación de Métricas” de la fase
“Estudio Preliminar”.
Detectar oportunidades de mejora en la gestión del Proyecto.

INPUT OUTPUT ACTORES RESPONSABLE


- Indicadores Clave - Informe de Cierre - Líder funcional - Líder funcional
- Presupuesto - Líder informático
- Tablero de Mando - Administrador
funcional

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

CARPETA de
PROYECTOS

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

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

FASE: DESCRIPCIÓN DE NECESIDADES

DESCRIPCIÓN DE LA NECESIDAD (ver F1)

NOMBRE
Descripción de la Necesidad
OBJETIVO
Describir el objetivo y alcance de la necesidad de un nuevo sistema o una modificación
indicando si reemplaza sistemas actuales (en cuyo caso identificarlos)
CONTENIDO

Ver Sección DESCRIPCION DE LA NECESIDAD ubicada en el cuerpo del Documento


F1

RESPONSABLE
Líder Funcional

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

DOCUMENTO F1 - Requerimientos funcionales e impactos

NOMBRE REFERENCIAL: .....................................................................................................................

Proyecto: ........................................................
Subproyecto: ........................................................

Estado Preliminar En análisis de impacto En negociación c/usuario Definitivo

Preparado por: <Nombre y Apellido> Fecha de creación: <dd/mm/aa>


Actualizado por: <Nombre y Apellido> Fecha de actualización: <dd/mm/aa>
Aprobado por: <Nombre y Apellido> Fecha de aprobación: <dd/mm/aa>

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

1 Objetivo del proyecto/requerimiento 2.Alcance del proyecto/requerimiento


3 Breve descripción. 4. Beneficios esperados / motivación / justificación
5 Identificación de procesos y subprocesos impactados

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

DOCUMENTOS DE ANÁLISIS DE IMPACTOS

OTROS DOCUMENTOS RELACIONADOS – ANEXOS

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

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

Descripción de los campos del formulario

 ENCABEZADO
- Id Requrimiento: código de identificación del requerimiento generado en forma secuencial y
automáticamente en la base de Lotus Notes.
- Nombre referencial: nombre 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)

1. Funcionalidades: enumerar las funcionalidades requeridas


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

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

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

 DOCUMENTOS DE ANÁLISIS DE IMPACTO


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

 OTROS DOCUMENTOS RELACIONADOS – ANEXOS


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

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

FASE: ESTUDIO DE FACTIBILIDAD


ESTUDIO DE FACTIBILIDAD TÉCNICO/FUNCIONAL

NOMBRE
21
Estudio de Factibilidad Técnico/Funcional
OBJETIVO
Estudio de la funcionalidad, el rendimiento y las restricciones que puedan afectar a la
posibilidad de realización del sistema. Análisis y evaluación de distintas alternativas para
el desarrollo del sistema.
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................

- Idea/objetivo: (incluir ficha de descripción de la necesidad)


- Relevamiento
- Presentación contexto (dónde)
- Necesidades (relevamiento detallado)
- Problemáticas detectadas
- Situación actual (cómo se desarrolla hoy)
- Factibilidad técnica / funcional
22
- Diagnóstico de la situación actual (PMO )
23
- Alternativas. Escenarios de solución (FMO )
24
- Descripción de tipos de solución (producto, desarrollo, evolución, no hace
falta.)
- Impacto
- Plan Maestro de Sistemas. Arquitectura sistemas. Otros sistemas,
visión TMN, mapeo TOM
- Plan tecnológico
- Parque informático
- Procesos del cliente
- Usuario
- Organización
- Ventajas y desventajas de la alternativa
- Plazos estimados para llevar adelante la alternativa
- Riesgos de no ejecución
- Conclusión
RESPONSABLE
Líder Funcional + Líder Informático
(Este documento contiene el resultado de tareas que, según la Guía de Proyectos,
corresponden a distintos responsables. Será responsabilidad del líder funcional y el
informático, conformar en conjunto, este documento con los distintos informes.)

Notas:
21
Dentro del ámbito de la Unidad de Negocios Red, el “Estudio de Factibilidad” se denomina “Estudio de Oportunidad”.
22
PMO: modelo objetivo presente
23
FMO: modelo objetivo futuro
24
Se deberá describir el sistema/producto con el soporte tecnológico (Hardware, Software, Base de Datos, Redes, Puestos de
Trabajo, etc.)
101 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García

ESTUDIO FACTIBILIDAD ECONÓMICA

NOMBRE
Estudio de Factibilidad Económica
OBJETIVO
Estudio de inversiones y gastos frente al beneficio final producido por el sistema.
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................

- Contexto
- Alternativas. Escenarios posibles
- Contexto
- Inversiones y gastos del proyecto
- Beneficios
- Valor actual neto
- Tasa interna de retorno
- Período de recupero
- Máxima necesidad de fondos y años en los que ocurre
- Estado de resultados proyectado
- Cash flow proyectado
- Conclusión
RESPONSABLE
Líder funcional con colaboración del líder informático y de un experto económico.

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

MÉTRICAS CLAVES

NOMBRE
Métricas Claves
OBJETIVO
Identificar las métricas/indicadores claves para la evaluación del proyecto (aquellas
asociadas a la motivación/justificación del proyecto para medir así los impactos
esperados versus los reales).
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................

Seleccionar las métricas (indicadores) de acuerdo al proyecto: métricas operativas,


-
funcionales y financieras.
- Definición de cada métrica
- Identificar el responsable de la medición
- Definir el momento adecuado de la medición
- Definir valores
RESPONSABLE
Líder funcional

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

INFORME EJECUTIVO DE ESTUDIO DE FACTIBILIDAD

NOMBRE
Informe Ejecutivo de Estudio de Factibilidad
OBJETIVO
Describir sintéticamente las alternativas desarrolladas en los estudios de factibilidad
técnico/funcional y económico para ser presentado al Comité.
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................

Objetivo
-
Alternativas
-
- Descripción técnica/funcional
- Estudio económico
- Plazos Estimados
- Impacto
- Conclusión
RESPONSABLE
Líder Funcional

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

CARTA DE DECISIÓN

NOMBRE
Carta de Decisión
OBJETIVO
Informe de la decisión resultante del hito 0.
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................

-Proyecto Aprobado?
- Alternativa Elegida
- Observaciones
- Proyecto Rechazado?
- Fundamentos
- Modalidad del Proyecto
- Presupuesto (todos los recursos + tiempo interno de compra)
- Plazos (Gantt Macro)
- Responsables (Compromiso de disponibilidad)
RESPONSABLE
Comité Director

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

ACUERDO DE SERVICIO DE PROYECTO


El “Acuerdo de Servicio de Proyecto” se describe en el Anexo de “Acuerdos y Contratos de Servicios”.

DOCUMENTO MAILS DE APROBACIÓN DE HITOS

APROBACIÓN DE HITOS

Preparado <Apellido y nombre de la persona <Gerencia> Fecha de creación:


por que presenta el formulario para su <dd/mm/aa>
aprobación>

APROBACIÓN DE HITOS / CIERRE DE FASE

Proyecto: <Identificación del Proyecto>

Fase: <Nombre de la fase según el ciclo de vida del proyecto>

Nombre del Hito: <Número y nombre del hito>

Fecha estimada de
finalización
Fecha real de finalización

Responsables de aprobación <Nombre de los responsables> <Gerencia>

Fecha de aprobación <dd/mm/aa>

SITUACIÓN DE ENTREGABLES

Documentos entregados: Detalle de los documentos entregados:


- Entregable 1
- Entregable 2

Documentos pendientes: - Entregable 3

Comentarios

RECHAZO DEL HITO

Rechazado por: <Nombre de la persona que rechaza el hito> <Gerencia>

Motivo: <Motivo del rechazo>


<Comentarios sobre las razones del mismo>

Fecha de rechazo <dd/mm/aa>

ANEXOS

6.1.1.2 Descripción de los campos del formulario


- Aclaración
El mail irá dirigido al responsable de la gestión en la DRI.

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

- Preparado por: apellido y nombre de la persona que presenta el formulario para su


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

- Nombre del hito: número y nombre del hito según la descripción del campo anterior (fase)
- Fecha estimada de finalización: fecha de finalización estimada de la fase a aprobar
- Fecha real de finalización: fecha de finalización real de la fase a aprobar
- Responsables de la aprobación: apellido y nombre de los responsables de la aprobación del
hito
- Documentos entregados: nombrar o adjuntar los documentos que quedan aprobados. En caso
de nombrarlos, mencionar versión del documento que se aprueba
- Documentos pendientes: nombrar los documentos que quedan pendientes
- Comentarios: en caso de quedar algo pendiente, comentarlo claramente

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

FASE: DISEÑO GLOBAL

6.1.2 ESPECIFICACIÓN FUNCIONAL (ver F1)

NOMBRE
Especificación Funcional ó
Requerimiento Funcional de Bajo Nivel
OBJETIVO
Describir las funcionalidades y rendimiento deseado para el sistema y sus restricciones.
Se describe también la información de control y datos que sirven de entrada/salida al
sistema (especificación funcional).
CONTENIDO

Ver sección ESPECIFICACIÓN FUNCIONAL ubicada en el documento F1

RESPONSABLE
Líder funcional

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

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

ESPECIFICACIÓN TÉCNICA (ver F2)

NOMBRE
Especificación Técnica
OBJETIVO
Describir completamente la información, la funcionalidad detalladamente, con una
indicación de los requisitos de rendimiento, de las restricciones de diseño y aspectos de
volumetría, performance, dimensionamiento.
CONTENIDO

Ver sección DESCRIPCIÓN FUNCIONAL DE LA SOLUCIÓN ubicada en el documento


F2

RESPONSABLE
Líder informático

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

PLAN GENERAL DE TRABAJO (ver F2 – Fechas de implementación)

NOMBRE
Plan General de Trabajo
OBJETIVO
Definir macro tareas, plazos e hitos de control
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................

- Diagrama de Gantt identificando:


- Macro Tareas
- Plazos
- Responsables
- Hitos de control
- Identificación de tareas dentro de las fases y etapas del proyecto
- Proceso de Compra
- Diseño Detallado
- Construcción
- Desarrollo
- Pruebas
- Prueba Piloto
- Implantación
- Identificación de tareas críticas
- Identificación de tareas de Capacitación en el diagrama de Gantt
RESPONSABLE
Líder informático
El plan de trabajo deberá ser convalidado por el líder funcional

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

EQUIPO DE TRABAJO

NOMBRE
Equipo de Trabajo
OBJETIVO
Identificar, dentro de la estructura de la organización, las personas que cumplen los
distintos roles definidos para el proyecto
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................

- Para Cada Rol:


- Rol
- Responsables
- Nombre
- Sector
- Porcentaje de Dedicación
RESPONSABLE
Líder funcional

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

DOCUMENTO F2 - Solución técnica a los requerimientos funcionales

NOMBRE REFERENCIAL (F1): .................................................................


ID REQUERIMIENTO (F1): .................................................................

Proyecto: ............................. Subproyecto: .............................


Sistema afectado: ............................. Módulo afectado: .............................
Estado En Diseño Global En convalidación Aprobado

Preparado por: .................... Fecha de creación: <dd/mm/aa>


Actualizado por: .................... Fecha de actualización: <dd/mm/aa>
Aprobado por: .................... Fecha de aprobación: <dd/mm/aa>

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


Fecha estimada de comienzo: <dd/mm/aa>
Tiempo estimado de duración:

ALCANCE FUNCIONAL

DESCRIPCIÓN FUNCIONAL DE LA SOLUCIÓN


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

SUPUESTOS / PREMISAS / POSIBLES IMPACTOS

INTERFACES INVOLUCRADAS EN LA SOLUCIÓN


- Interfaces con otros sistemas

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


- Aspectos de volumetría, performance, dimensionamiento

FUNCIONALIDADES FUERA DE ALCANCE

DEFINICIONES PENDIENTES

FECHAS DE IMPLEMENTACIÓN

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

Descripción de los campos del formulario

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


- Nombre referencial: nombre del requerimiento funcional que figura en el F1
- ID Requerimiento: código de identificación del requerimiento que originó esta solución (F1)
- Proyecto: nombre del proyecto impactado
- Subproyecto: nombre del subproyecto
- Estado: estado de la propuesta de solución al requerimiento del usuario según el flujograma
de gestión de la demanda (en diseño global, en convalidación, aprobado)
- Fecha requerida de implantación: dd/mm/aa. Es la fecha en que se requiere tener la solución
implantada
- Fecha estimada de comienzo: dd/mm/aa . Es la fecha que Sistemas estima que puede
comenzar con el desarrollo
- Tiempo estimado de duración: Tiempo total de desarrollo de la solución planteada

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

 DESCRIPCIÓN FUNCIONAL DE LA SOLUCIÓN


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

 SUPUESTOS / PREMISAS / POSIBLES IMPACTOS


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

 INTERFACES INVOLUCRADAS EN LA SOLUCIÓN


- Describirlas

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


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

 FUNCIONALIDADES FUERA DE ALCANCE


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

 FECHAS DE IMPLEMENTACIÓN
- Describir el plan de trabajo con un cronograma asociado.

Ejemplo con cronograma modelo

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

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

FASE: DISEÑO DETALLADO

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

NOMBRE
Especificación Técnica de Detalle
OBJETIVO
Describir la especificación técnica de detalle (estructura de datos detallada y
representaciones algorítmicas del software). Se describe también el diseño de las
interfaces.
CONTENIDO

Ver sección ESPECIFICACIÓN TÉCNICA DE DETALLE del documento DISEÑO


DETALLADO

RESPONSABLE
Líder Informático

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

DOCUMENTO DISEÑO DETALLADO - Especificación técnica de detalle

PROYECTO: .................................................................
SUBPROYECTO: .................................................................
Sistema/Módulo impactado: .........................................

Estado Preliminar En Consolidación Definitivo

Preparado por: .................... Fecha de creación: <dd/mm/aa>


Actualizado por: .................... Fecha de actualización:
<dd/mm/aa>
Aprobado por: .................... Fecha de aprobación: <dd/mm/aa>

ESPECIFICACION TËCNICA DE DETALLE

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

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

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

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

- Definición de archivos

- Condiciones de pruebas potenciales

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

- Controles de procesos

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

- Descripción del Acceso a Base de Datos

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

- Reportes
- Descripción Funcional
- Layout
- Ejemplo

- Pantallas
- Descripción Funcional
- Layout
- Ejemplo

ANEXOS

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

PLAN DETALLADO DE TRABAJO

NOMBRE
Plan Detallado de Trabajo
OBJETIVO
Definir el detalle de las tareas, plazos e hitos de control
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................

- Diagrama de Gantt identificando:


- Detalle de Tareas
- Plazos
- Responsables
- Hitos de control
- Identificación de tareas dentro de las fases y etapas del proyecto
- Construcción
- Desarrollo
- Pruebas
- Prueba Piloto
- Implantación
- Identificación de tareas de Capacitación en el diagrama de Gantt
RESPONSABLE
Líder informático
El plan de trabajo deberá ser convalidado por el líder funcional

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

PLAN DE PRUEBAS TÉCNICAS - PLAN DE PRUEBAS FUNCIONALES


Se realizarán los planes de prueba correspondientes a cada prueba:
- Prueba Individual
- Prueba de Cadena
- Prueba de Integración
- Prueba Global (Pruebas Funcionales)
- Prueba de Performance, stress, volumen y seguridad
- Prueba de Compatibilidad

NOMBRE
Plan de Pruebas Técnicas – Plan de Pruebas Funcionales
OBJETIVO
Describir un plan general para la integración del software y una descripción de las
pruebas específicas.
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................

Plan de Pruebas:
-
- Objetivo y Alcance
- Contexto / Ambiente de prueba
- Datos (generación)
- Interfaces
- Plataforma
- Condiciones generales de prueba:
- Datos de Entrada
- Resultado Esperado
- Responsable de la prueba
- Documentación del input de la prueba
- Descripción de la documentación que respaldará la prueba
- Criterio de entrada
- Criterio de salida (cota de calidad)
- Criterio de aceptación
- Circuito de resolución de incidentes de prueba
- Métricas
RESPONSABLE
Líder informático
Líder funcional para Prueba Global (Prueba Funcional)

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

PLAN DE CONTINGENCIA Y DE DESASTRE

NOMBRE
Plan de Contingencia y de Desastre
OBJETIVO
Definir un plan que detalle las tareas y responsables para cada situación de contingencia
que se pudiera presentar en el software y/o hardware.
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................

Momento en que se declara la contingencia


-
Responsable/s de declarar la contingencia
-
Tipos de contingencia
-
(dependerá de la implementación de cada sistema)
- Plan de Tareas / Responsable
- Procedimiento de contingencia
- Esquema de seguridad
- Puesto de trabajo de contingencia
- Escenarios posibles de contingencia
- Identificación de interfaces críticas y propuestas de plan de contingencia
- Descripción de pruebas de plan de contingencia.
RESPONSABLE
Líder informático

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

PLAN DE BACKUP

NOMBRE
Plan de Backup
OBJETIVO
Definir el plan de backup para el sistema operativo, datos y aplicación (servidores y
puestos de trabajo)
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................

Definir políticas de backup:


-
- Sistema Operativo
- Datos
- Aplicación
- Servidores
- Puestos de Trabajo
- Definir Instructivo y Menú de Backup
- Designar Responsables
RESPONSABLE
Líder informático

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

DOCUMENTO DE SOPORTE A MESA DE AYUDA

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

RESPONSABLE
Líder informático con la colaboración del líder funcional
122 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García

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

DOCUMENTO DE SOPORTE A OPERACIONES/SOPORTE TÉCNICO

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

- Tipo de servicio requerido: Operación/ Instalación/ Administración de hardware


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

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

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

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

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

RESPONSABLE
Líder informático

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

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

PROCEDIMIENTO DE GESTIÓN DE CONFIGURACIÓN

NOMBRE
Procedimiento de Gestión de Configuración
OBJETIVO
Definir un procedimiento de Gestión de Configuración mediante el cual se establecen los
mecanismos para realizar modificaciones o actualizaciones a cualquier elemento
producido durante el ciclo de vida del un proyecto y su posterior mantenimiento.
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................

- Identificación y enumeración del tipo de elementos que se encuentran bajo el


procedimiento de Gestión de Configuración:
- Documentos (incluye cualquier documento generado en el ciclo de vida del
proyecto).
- Código fuente.
- Tablas o archivos de parámetros.
- Cualquier otro elemento que se pretenda tener control sobre los cambios que
sobre el mismo se puedan hacer.
- Definir a partir de que instante un elemento queda bajo el procedimiento de gestión de
configuración.
- Describir por cada tipo de elemento la información a conservar sobre versiones
anteriores cada vez que se realice un cambio a un elemento que ha sido puesto bajo el
procedimiento de gestión de configuración.
- Descripción de los pasos a seguir para incluir un nuevo elemento bajo la gestión de
configuración.
- Descripción de los pasos requeridos para obtener e identificar un elemento en proceso
de cambio.
- Identificación de personas o grupos autorizados a realizar los cambios sobre cada tipo
de elemento en cada una de las instancias del proyecto o durante la etapa de
mantenimiento.
- Descripción de los pasos para informar los cambios realizados a un elemento.
- Definición de las herramientas automatizadas que se utilizarán en la gestión de
configuración.
RESPONSABLE
Líder informático

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

IMPACTO ORGANIZACIONAL

NOMBRE
Impacto Organizacional
OBJETIVO
Conocer con tiempo suficiente los impactos en la Organización que genera un cambio de
Sistemas/Procesos a efectos de poder planear acciones de cambio.
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................

Procesos a implantar/cambiar
-
Sistemas a implantar/cambiar
-
Población afectada
-
- Cantidad
- Localización
- Tipo de contrato (D/C - F/C)
- Especialidades / Puestos
- Dimensionamiento del impacto respecto a las tareas / competencias /
localizaciones necesarias previas al cambio
RESPONSABLE
Líder Funcional

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

ESTRATEGIA DE IMPLANTACIÓN

NOMBRE
Estrategia de Implantación
OBJETIVO
Definir la estrategia de implantación de un proyecto
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................

- Modo de Implantación:
- Big Bang
- Roll-out (en etapas)
- Fases (descripción, alcance, contenido)
- Releases
- Cronograma General Por fases, Releases y Sitios
RESPONSABLE
Líder Funcional

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

PLAN DE PRUEBAS FUNCIONALES


Este documento se describe junto con el Plan de Pruebas Técnicas.

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

ESTRATEGIA DE CONFIABILIZACIÓN

NOMBRE
Estrategia de Confiabilización
OBJETIVO
Establecer un plan de confiabilización en caso que sea necesario.
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................

Confiabilización de Datos
-
- Objetivo
- Validaciones a aplicar sobre la fuente
- Categorización y tipificación de errores
- Identificación de la Distribución física de los datos (dónde) y plataforma para
realizar la detección de errores.
- Definición de Módulos de Detección, Ordenamiento y Comparación de Datos
entre fuentes
- Esquema de corrección de datos sobre la fuente a confiabilizar
- Indicadores de permanencia de errores en la fuente
- Plan de Confiabilización
- Responsables
RESPONSABLE
Líder funcional

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

ESTRATEGIA DE CONVERSIÓN DE DATOS

NOMBRE
Estrategia de Conversión de Datos
OBJETIVO
Establecer un plan de conversión de datos en caso que sea necesario.
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................

Conversión de Datos
-
- Identificación de información a ser convertida
- Identificación de fuente de obtención de nuevos datos
- Requerimientos de conversión
- Criterios de Conversión
- Modalidad
- Big bang
- Por etapas
- Dependencia y secuencialidad de procesos de conversión
- Criterios de depuración previos a la conversión
- Condiciones a probar para la conversión y lineamientos generales para la
prueba de conversión.
- Controles y criterios de aceptación de conversión
- Condiciones claves y estándares de conversión ; determinar valores a asumir
por defecto
- Plan de Conversión
- Documento de la Conversión
- Responsables
RESPONSABLE
Líder funcional

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

ESTRATEGIA DE CARGA DE DATOS

NOMBRE
Estrategia de Carga de Datos
OBJETIVO
Establecer un plan de Carga de Datos en caso que sea necesario.
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................

Identificación de la información a ser cargada


-
Identificación de fuente de obtención de nuevos datos
-
Determinar valores a asumir por defecto
-
Definir el proceso de carga
-
- Metodología
- Modalidad
- Big Bang
- Por Etapas
- Responsables
- Criterios de aceptación
- Circuito de corrección de errores
- Plan de Carga
RESPONSABLE
Líder funcional

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

PLAN DE ACCIÓN PARA EL CAMBIO

NOMBRE
Plan de Acción para el Cambio
OBJETIVO
Definir las acciones necesarias para abordar el impacto organizacional generado por la
implementación del Proyecto.
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................

- Definición del Plan de Distribución Dotacional


- Asignación de Responsables
- Identificación de Recursos Necesarios
- Definición de Plazos-Cronogramas (Gantt)
- Definición de Hitos de Control
RESPONSABLE
Responsable Soporte al Cambio

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

PLAN DE CAPACITACIÓN

NOMBRE
Plan de Capacitación
OBJETIVO
Definir las acciones necesarias para capacitar a los actores involucrados
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................

Identificación
- del temario/contenido (procesos, funcionalidades del sistema,
seguridad del sistema, etc.)
- Herramientas
- Logística
- Salas
- Materiales
- Ambiente
- Datos
- Aplicación
- Server y Puestos de Trabajo
- Asistentes
- Modalidad
- Presencial
- A distancia
- Trainers/Formadores/Capacitadores (en caso de tratarse de una capacitación
presencial)
- Comunicación de la Capacitación
- Plan de Capacitación
RESPONSABLE
Responsable Capacitación

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

PLAN DE COMUNICACIÓN

NOMBRE
Plan de Comunicación
OBJETIVO
Definir las acciones necesarias para “comunicar”.
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................

-Identificación de conceptos a comunicar (misión, alcance, objetivo y plazos) de la


implementación del sistema.
- Actores
- Responsable de la Comunicación
- Destinatarios
- Nombre
- Sector
- Medio de Comunicación
- Plan de Comunicación
- Circuito de Comunicación (Feedback)
RESPONSABLE
Responsable Soporte al Cambio

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

FASE: CONSTRUCCIÓN

PROGRAMAS, MÓDULOS y PARAMETRIZACIÓN


Si bien los programas, módulos y parametrizaciones no constituyen documentos en sí mismos, los mismos
deberán documentarse, a saber:

- Los programas y módulos desarrollados en la etapa de construcción deberán estar documentados en


el código.
- Se deberá generar un documento que describa cada uno de los parámetros del sistema, indicando
nombre y valor. El mismo deberá ser actualizado ante modificaciones en los parámetros.

MANUAL DE SISTEMAS

NOMBRE
Manual de Sistemas
OBJETIVO
25
Documentar la información técnica del Sistema
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................

Visión global del Sistema


-
Plataforma de soporte y especificaciones técnicas
-
Diagrama de módulos del Sistema y su interconexión
-
Diagrama de relaciones con otros Sistemas
-
Esquema de seguridad
-
Tablas y parámetros del Sistema
-
Diseño de base de datos
-
Diseños de archivos
-
Detalle de accesos a archivos de otras aplicaciones
-
Descripción de programas batch y on-line
-
Flow de encadenamiento de pantallas
-
Flow de encadenamientos de programas batch para los distintos tipos de corridas
-
Características de procesos especiales (cierres mensuales, anuales)
-
Cross - reference (pantalla - pgm - módulos, pgms archivos, módulos reutilizables
-
programas)
RESPONSABLE
Líder Informático

Notas:
25
El Manual de Sistemas deberá incluir la Especificación Técnica de Detalle (Diseño detallado) actualizada.
136 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García

MANUAL DE USUARIO

NOMBRE
Manual de Usuario
OBJETIVO
Documentar las funcionalidades del sistema apuntadas al uso del mismo
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................

Visión global del Sistema


-
Módulos componentes del Sistema.
-
Funciones on-line
-
- Flow de encadenamiento de pantallas.
- Pantallas con datos como ejemplo
- Descripción del objetivo
- Detalle de validaciones o controles generales
- Función de los campos
- Teclas de función con explicación de su funcionamiento
- Mensajes de error con su respectiva explicación
- Reportes
- Diseño de reportes
- Descripción del objetivo
- Frecuencia y condiciones para su generación.
- Descripción del contenido de los campos.
- Descripción de los totales de control.
- Interfaces con otros Sistemas
- Descripción del objetivo
- Frecuencia y condiciones para su generación
- Reportes de control
- Acciones a tomar en caso de diferencias o problemas en su generación
- Breve descripción de los archivos del Sistema y archivos relacionados de otras
aplicaciones
- Descripción de tablas y parámetros del Sistema.
- Mensajes de error del Sistema con detalle de acciones a tomar
RESPONSABLE
Líder Informático

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

MANUAL DE PROCESOS

NOMBRE
Manual de Procesos
OBJETIVO
Describir el nuevo proceso/nueva forma de operación que implementará el proyecto
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................
26
- Descripción del Proceso
RESPONSABLE
Líder funcional + dueño del proceso

Notas:
26
La base de este manual son los procesos/sub-procesos definidos en la especificación funcional
138 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García

PROTOCOLO DE PRUEBA
Se definirán protocolos para las distintas pruebas y sus respectivos informes:
- Prueba Individual
- Prueba de Cadena
- Prueba de Integración
- Prueba Global
- Prueba de Performance, stress, volumen y seguridad
- Prueba de Compatibilidad

NOMBRE
Protocolo de Prueba
OBJETIVO
Describir detalladamente los casos de prueba, los resultados esperados y obtenidos.
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................

- Objeto de la Prueba
- Procedimientos de Prueba
- Casos/ Condiciones detalladas de prueba (DTC):
- Descripción del caso
- Entorno
- Datos de Entrada
- Acciones
- Resultado esperado
- Resultado obtenido
27
- Observaciones

Ver detalles y formatos en las planillas anexadas

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

Notas:
27
Se incluirán por ejemplo los pendientes de prueba.
139 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García

APROBACIÓN DE PRUEBA
Se realizarán los informes de aprobación de prueba correspondientes a cada prueba:
- Prueba Individual
- Prueba de Cadena
- Prueba de Integración
- Prueba Global
- Prueba de Performance, stress, volumen y seguridad
- Prueba de Compatibilidad

NOMBRE
Aprobación de Prueba
OBJETIVO
Documentar la aprobación de la prueba
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................

Objeto de la Prueba
-
Resumen Ejecutivo del resultado de la prueba
-
Criterio de Aceptación
-
Prueba Aprobada
-
28
- Observaciones
- Prueba Rechazada
- Justificación
- Recomendación
RESPONSABLE
Líder Informático (Prueba Individual, de Cadena, de Integración, de Performance, stress,
volumen y seguridad)
Líder funcional (Prueba Global)

Notas:
28
Se incluirán por ejemplo los pendientes de prueba.
140 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García

PROTOCOLO DE PRUEBA PILOTO

NOMBRE
Protocolo de Prueba Piloto
OBJETIVO
Describir detalladamente los casos de prueba a realizar en la Prueba Piloto, los
resultados esperados y los resultados obtenidos en la misma.
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................

Objeto de la Prueba Piloto


-
Sitio
-
Procedimientos de Prueba
-
Documentación Asociada
-
Casos:
-
- Descripción del caso
- Entorno
- Datos de Entrada
- Acciones
- Resultado esperado
- Resultado obtenido
29
- Observaciones
RESPONSABLE
Líder funcional

Notas:
29
Se incluirán por ejemplo los pendientes de prueba.
141 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García

HOMOLOGACIÓN PRUEBA PILOTO

NOMBRE
Homologación de Prueba Piloto
OBJETIVO
Documentar la aprobación y homologación de la prueba piloto
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................

Objeto de la Prueba
-
Resumen Ejecutivo del resultado de la prueba
-
Criterio de Aceptación
-
Prueba Aprobada
-
30
- Observaciones
- Prueba Rechazada
- Justificación
- Recomendación
RESPONSABLE
Líder funcional

Notas:
30
Se incluirán por ejemplo los pendientes de prueba.
142 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García

PLAN DE IMPLANTACIÓN

NOMBRE
Plan de Implantación
OBJETIVO
Establecer el plan de implantación de un proyecto.
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................

- Sitios para la implantación


- Recursos físicos y humanos necesarios
- Plan de trabajo
- Cronograma
- Responsables
- Hitos
RESPONSABLE
Líder funcional

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

PLAN DE SOPORTE

NOMBRE
Plan de Soporte
OBJETIVO
Establecer el plan de soporte a la implantación.
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................

- Objetivo y alcance
- Circuito de atención, recepción, diagnóstico, derivación y resolución de incidentes
- Identificación de nivel de criticidad de incidentes
- Tipo de soporte por sitio de implantación
- In situ
- Funcional
- Técnico
- Centralizado
- Funcional
- Técnico
- Disponibilidad y horario de atención de soporte por sitio
RESPONSABLE
Líder funcional / Líder informático

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

PROTOCOLO DE IMPLANTACIÓN

NOMBRE
Protocolo de Implantación
OBJETIVO
Definir el protocolo de pruebas para la Implantación
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................

Sitio
-
Procedimientos de Prueba
-
Documentación Asociada
-
Casos:
-
- Descripción del caso
- Entorno
- Datos de Entrada
- Acciones
- Resultado esperado
- Observaciones
RESPONSABLE
Líder funcional

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

PROCEDIMIENTO DE PRODUCCIÓN

NOMBRE
Procedimiento de Producción
OBJETIVO
Definir qué, cómo y cuándo se desarrollan las tareas de producción
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................

- Procedimientos de Backup
- Descripción
- Responsable
- Observaciones
- Procedimientos de Seguridad
- Descripción
- Responsable
- Observaciones
- Procedimientos de Performance
- Descripción
- Responsable
- Observaciones
- Control de Procedimientos Rutinarios
- Descripción
- Responsable
- Observaciones
- Anexo: Documentación de Soporte
- Documento de Soporte a Mesa de Ayuda
- Documento de Soporte a Operación/Soporte Técnico
RESPONSABLE
Líder informático

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

ACUERDO DE IMPLANTACIÓN

NOMBRE
Acuerdo de Implantación
OBJETIVO
Documentar la decisión de implantar el proyecto
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................

- Fecha
- Breve Descripción del Proyecto
- Responsables
- Firmas
- Observaciones
RESPONSABLE
Líder funcional

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

FASE: IMPLANTACIÓN

APROBACIÓN CONVERSIÓN DE DATOS

NOMBRE
Aprobación Conversión de Datos
OBJETIVO
Documentar la aprobación de la conversión de Datos
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................

- Criterio de Aceptación
- Muestreo estadístico
- Resumen de Volúmenes Convertidos
- Volumen Previo
- Volumen Final
- Tiempos de conversión
- Conversión Aprobada
- Observaciones
- Conversión Rechazada
- Justificación
- Recomendación
RESPONSABLE
Líder funcional

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

RECEPCIÓN PROVISORIA

NOMBRE
Recepción Provisoria
OBJETIVO
Documentar la Recepción Provisoria del Sistema (Aprobación), informando los
resultados de la Prueba de Aceptación del Mismo.
CONTENIDO
Fecha:.. ../....../......
Proyecto:...........................................................……..................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................

Descripción del sistema/etapa recibido


-
Resumen Ejecutivo del resultado de la Prueba de Aceptación
-
Criterio de Aceptación
-
Prueba Aprobada
-
31
- Observaciones
- Prueba Rechazada
- Justificación
- Recomendación
- Documentación recibida (fuentes, manuales, etc.)
- Firma responsables
RESPONSABLE
Líder funcional

Notas:
31
Se incluirán por ejemplo los pendientes de prueba.
149 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García

CONTRATO DE SERVICIO DE PRODUCCION


Este documento se describe en el Anexo de “Acuerdo y Contrato de Servicio”.

INFORME SISTEMA EN PRODUCCIÓN

NOMBRE
Informe Sistema en Producción
OBJETIVO
Documentar Puesta en Producción de un Sistema
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................

- Resumen Ejecutivo de Estado General del Sistema


- Documentación Asociada
- Contrato de Servicio de Producción
- Pendientes (Hardware, Conectividad, Funcionalidades)
- Descripción
- Plazos de Entrega
- Comentarios
RESPONSABLE
Líder funcional
Administrador funcional

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

FASE: PRODUCCIÓN

TABLERO DE MANDO

NOMBRE
Tablero de Mando
OBJETIVO
Presentar los indicadores para medir los procesos técnicos (seguridad, performance,
procesos rutinarios) y el soporte (atención a usuarios, soporte funcional, soporte técnico,
soporte aplicativo)
CONTENIDO
Fecha:.. ../....../......
Proyecto:.......................................................................................................................
Responsable:....................................................... Sector:...............................................
Participantes:.................................................................................................................

- Procesos Técnicos
- Procesos de Seguridad
- Indicador 1
- Indicador n
- Procesos de Performance
- Indicador 1
- Indicador n
- Procesos Rutinarios
- Indicador 1
- Indicador n
- Soporte
- Atención de Usuarios
- Indicador 1
- Indicador n
- Soporte Funcional
- Indicador 1
- Indicador n
RESPONSABLE
El Tablero de Mando será completado por el responsable de cada proceso.

El contrato de servicio de producción define los indicadores del tablero de mando, la metodología de
medición, responsable de medición.

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

FASE: BALANCE DEL PROYECTO

INFORME DEL CIERRE DEL PROYECTO


Se deberá confeccionar un documento con el informe de cierre del Proyecto, donde resuman:

- Inversiones totales reales y presupuestadas


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

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

ANEXO: MODELO DE PLAN DE PROYECTO


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

A continuación, se presenta un cronograma resumido con las fases y etapas.

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

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

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

ACUERDO y CONTRATO
de SERVICIO

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

ACUERDO Y CONTRATO DE SERVICIO


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

ACUERDO DE SERVICIO DE PROYECTO


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

El Acuerdo de Servicio de Proyecto está basado en el Modelo Único de Contrato de Servicio.

MODELO

ACUERDO DE SERVICIO DE PROYECTO......………………………………...

ENTRE <Responsable Informático>…….....................................................

en adelante el denominado PROVEEDOR, representado por

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

Y <Owner del Proyecto>.........................................................................

en adelante el denominado CLIENTE, representado por

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

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

OBJETO Y CONSIDERACIONES INICIALES

1.1. El presente acuerdo tiene por objeto fijar los términos y condiciones del servicio de provisión de la
solución informática <nombre-solución-informática> ………………………...
..........................................................................................................................................................................
......................................................................................................................................

1.2. El servicio comprende los siguientes puntos: ..................................................................….


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

1.3. El presente acuerdo reemplaza integralmente a los siguientes documentos:


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

SERVICIOS A PRESTAR
Describir los entregables, tareas y responsabilidades de acuerdo a la Guía de Gestión de Proyectos
de Sistemas.
2.1. Servicios. Describir completamente los servicios a prestar (contenido, tipo, forma, etc.)
(Enumerar los entregables a cargo del proveedor)

2.2. Obligaciones del PROVEEDOR. Describir todas las obligaciones que deberá cumplir el proveedor
para la prestación del servicio objeto del presente contrato (modalidad de intervención, modo de
requerimiento, etc.)
(Enumerar las tareas y responsabilidades del proveedor para cumplir con lo enunciado en 2.1)

2.3. Obligaciones del CLIENTE. Describir todas las obligaciones que deberá cumplir el cliente
(especificaciones, cooperación, asistencia, etc.)
(Enumerar los entregables, tareas y responsabilidades del cliente para cumplir con lo enunciado en
2.1)

2.4. Procesos. Describir y/o referenciar el/los proceso/s asociado/s al servicio objeto de este contrato.

2.5. Elementos que intervienen para la prestación. En caso de necesitar identificar dichos elementos se
deberá utilizar un formulario Anexo, indicando en cada caso tipos de equipos, cantidades, números de
serie, ubicación precisa, etc. Asimismo, en caso de producirse modificaciones en los elementos deberá
incluirse la modificación en el Anexo mencionado previamente. En este caso se detallarán altas, bajas y
modificaciones de equipos. En ningún caso el PROVEEDOR podrá producir modificaciones sin recibir
autorización formal por parte del CLIENTE.

2.6. Formas de Intervención. El CLIENTE definirá las actuaciones que deberá realizar el PROVEEDOR
para intervenir (como por ejemplo, retrasos en el cumplimiento de plazos acordados). A los fines de estas
actuaciones regirán los tiempos indicativos detallados en un Anexo a tal efecto. Asimismo, el proveedor
deberá informar al cliente de manera fehaciente los avances y tiempos estimados de cada intervención.

2.7. Ámbito. Determinar los lugares para la prestación, que se detallarán en un Anexo. Deberá
mantenerse actualizado con las modificaciones, de existir.

2.8. Pruebas de aceptación. El PROVEEDOR se compromete a informar por escrito la finalización de las
tareas vinculadas a este servicio, a efectos de que el CLIENTE dé comienzo a las pruebas de aceptación
respectivas. Si se le solicitara al PROVEEDOR participar de las mismas, se le informará de esta situación
en tiempo y forma, debiendo el mismo confirmar de igual modo su disponibilidad.
En este punto se describirán las condiciones de la Aceptación de la Implantación y la Generación del
Documento de Recepción Provisoria del Proyecto (previo a la Puesta en Producción).

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

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

3.2. CLIENTE. Identificar el o los responsables de interactuar con el proveedor. Para ello se deberá
completar con nombre, rol, dirección y teléfono la ficha que se encuentra en un Anexo.
El CLIENTE presentará al PROVEEDOR la ficha indicada, que deberá ser actualizada por el CLIENTE
toda vez que correspondiere.

OTROS SERVICIOS VINCULADOS

4.1. Describir otros servicios adicionales (esquema de seguimiento, etc.) que estén involucrados y que no
formen parte del Servicio objeto del presente contrato.

4.2. Seguimiento de Proyecto. Se acordarán entre las partes la metodología de seguimiento de proyectos.
Se definirán los indicadores de seguimiento:
- Desvío de Presupuesto
- Desvío de Plazos
- Desvío de funciones entregados respecto a funcionalidades solicitadas
- Incidentes
- Otros

4.3. Se detallará en un Anexo los informes preestablecidos (frecuencia de prestación, etc.) con los
tiempos previstos de solicitud. Cualquier otro informe deberá acordarse en el momento por ambas
PARTES.

4.4. Ambas PARTES pueden proveer o solicitar nuevos servicios no comprendidos en el presente
contrato, pero que se desprendan del objeto del mismo.
En ese caso, el CLIENTE deberá realizar una descripción del servicio y deberá enviar tal descripción al
PROVEEDOR quien notificará al CLIENTE, a los _____ días, si desea proceder a la negociación de la
inclusión del nuevo servicio.
Si ambas PARTES deciden continuar para la prestación del nuevo servicio, se propondrá una definición
del servicio, precios y tiempos.

4.5 El presente contrato puede ser modificado o ajustado de común acuerdo de las partes.

PRECIOS Y PAGO. COSTOS Y PENALIDADES


Los puntos 5.1 y 5.2 se aplican en el caso en que el presupuesto sea del Owner del Proyecto.

5.1. Entre las PARTES se establecerán los datos de prestación y contraprestación del servicio contratado,
registrando al inicio del contrato, los insumos, gastos imprescindibles, viáticos, horas extras, guardias
pasivas y todo aquel que fuera necesario detallar. Dichos precios se especificarán en un Anexo,
diferenciando aquellos de única vez (no recurrentes) de los periódicos (recurrentes), indicando para
estos últimos expresamente la periodicidad de cada cargo.
158 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García

5.2. El CLIENTE efectuará las transferencias presupuestarias que surjan de las prestaciones solicitadas al
PROVEEDOR, contra conformidad del CLIENTE del servicio entregado. En el caso de trabajos adicionales
requeridos por el CLIENTE, el PROVEEDOR contestará formalmente la posibilidad de hacerlo en tiempo y
forma y cotizará las tareas para que se efectúen las transferencias presupuestarias y de hs.
extraordinarias en caso de necesidad.

5.3. Penalidades por incumplimiento.


Se deberán establecer rangos y escalas de calidad de servicio, definiendo niveles de incumplimiento
(del cliente y del proveedor) y asociarlo con las penalidades correspondientes.
Deberán ser establecidas explícitamente tomando como base los indicadores de calidad de servicio
que se definan en el ítem 6.2. del presente, contemplando los rangos y/o escalas que para los
mismos AMBAS PARTES definan y acuerden.
Se clasificarán en:
5.3.1. Penalidades para el CLIENTE
5.3.2. Penalidades para el PROVEEDOR.
En ambos casos, las penalidades definidas y acordadas deberán guardar coherencia en un todo con
las responsabilidades específicas detalladas según lo sugerido en el ítem 7.

CALIDAD DEL SERVICIO


6.1. Satisfacción del cliente. El CLIENTE se reserva el derecho de realizar las encuestas de satisfacción a
clientes (internos y/o externos) que estime necesarias.

6.2. Indicadores. Los indicadores de evaluación y seguimiento del presente contrato deberán detallarse en
un Anexo.
Se definirán los reportes de monitoreo, el tablero de mando y los indicadores que lo componen, junto
con los responsables de medición, valores de referencia, umbrales.
Se identificarán aquellos indicadores correspondientes a la performance de los aspectos técnicos del
sistema y al soporte (a usuarios, funcional, técnico, aplicativo). A través de estos indicadores se
medirán los servicios que el proveedor está prestando.

RESPONSABILIDADES

7.1. El PROVEEDOR deberá disponer de los medios para prestar el servicio. El CLIENTE deberá brindar
las condiciones para que el PROVEEDOR pueda dar el servicio de acuerdo al nivel de calidad acordado.

7.2. Las PARTES se obligan a cumplir estrictamente toda disposición reglamentaria y demás normas,
procedimientos y políticas de la compañía dictadas o a dictarse por el sector competente y que resulte
aplicable.

7.3. Ninguna de las PARTES será responsable por los retrasos o fallas de operación o performance
derivadas de actos o hechos ajenos al control de cada parte.

7.4. La parte afectada por un evento de caso fortuito o fuerza mayor, deberá notificar rápida y
fehacientemente a la otra acerca de todo retraso o falla que origine hasta que desaparezca el evento que
lo causa. La parte afectada actuará de buena fe para solucionar la causa de retraso o falla, y ambas partes
procederán con diligencia una vez que la causa del retraso o falla haya cesado o desaparecido.

REGISTRACIÓN Y COMUNICACIÓN

8.1. Las PARTES se comprometen a divulgar en los sectores intervinientes ,incluyendo las áreas de
Calidad corporativas así como las propias de los sectores que participan en el contrato, la firma del
presente contrato, de conformidad con las disposiciones de la normativa vigente.

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

VIGENCIA
9.1. El presente contrato tendrá vigencia desde __________ y hasta __________ (de acuerdo al plan de
proyecto). Finalizada, o antes de finalizada la vigencia del presente contrato, las PARTES en forma
expresa podrán decidir la prórroga del Contrato o, en su caso, la celebración de otro.

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

9.3. Si en algún hito go no-go del proyecto se acuerda no continuar con el mismo, de común acuerdo entre
las partes cesará la vigencia del acuerdo.

GARANTÍAS SOBRE LAS INTERVENCIONES

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

CONDUCTAS FRAUDULENTA

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

CESIÓN DEL CONTRATO

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

INCUMPLIMIENTO. RESOLUCIÓN DEL CONTRATO.

13.1. Ante situaciones de:


13.1.1. Disolución del sector
13.1.2. Falta de pago
13.1.3. Incumplimiento de las cláusulas detalladas precedentemente
se elevará al Organismo de Control, la petición de rescisión del presente contrato.

13.2. En el caso de incumplimiento de obligaciones estipuladas en este contrato (con respecto a los
plazos e indicadores), el CLIENTE deberá intimar al PROVEEDOR a subsanar la situación en un
plazo que de acuerdo a la circunstancia resulte razonable.

CONFIDENCIALIDAD

14.1. Toda la información que sea intercambiada en virtud del presente, será tratada en forma
confidencial.

14.2. En tal sentido, las PARTES se comprometen a tratar en forma confidencial toda información técnica,
comercial, referida a los sistemas, ingeniería, datos técnicos, registros comerciales, correspondencia,
datos sobre costos, listas de clientes, etc., que resulte de la solicitud de cualquiera de las PARTES.

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

14.2. La información resultante deberá ser clasificada según la categorización de la empresa.

14.3. En caso que fuera necesario se firmará un Acuerdo de Confidencialidad de la información.

ORGANISMO DE CONTROL.

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

COMPETENCIA

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

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

CONTRATO DE SERVICIO DE PRODUCCIÓN


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

MODELO

CONTRATO DE SERVICIO DE PRODUCCIÓN DE SISTEMAS DE .........


ENTRE ..<proveedor interno – externo>..................................................

en adelante el denominado PROVEEDOR, con domicilio en

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

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

Y <el usuario>..........................................................................................

en adelante el denominado CLIENTE, con domicilio en

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

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

OBJETO Y CONSIDERACIONES INICIALES

1.1. El presente acuerdo tiene por objeto fijar los términos y condiciones del servicio de
..........................................................................................................................................................................
..........................................................................................................................................................................
....................................................................................................................

1.2. El servicio comprende los siguientes puntos: ..................................................................….


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

1.3. El presente acuerdo reemplaza integralmente a los siguientes documentos:


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

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

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

- Identificación del nivel de criticidad de los incidentes


- Esquema de soporte, definiendo el circuito de atención, recepción, diagnóstico, derivación y
resolución de incidentes.
- Objetivo y Alcance
- Tipo de soporte
- In Situ, centralizado
- Funcional, Técnico
- Disponibilidad de Servicio
- Tiempos de intervención
- Capacitación (en caso que corresponda): nuevas funcionalidades, nuevos usuarios, etc.
2.1. Servicios. Describir completamente los servicios a prestar (contenido, tipo, forma, etc.)

2.2. Obligaciones del PROVEEDOR. Describir todas las obligaciones que deberá cumplir el proveedor
para la prestación del servicio objeto del presente acuerdo (modalidad de intervención, modo de
requerimiento, etc.)

2.3. Obligaciones del CLIENTE. Describir todas las obligaciones que deberá cumplir el cliente
(especificaciones, cooperación, asistencia, etc.)

2.4. Procesos. Describir y/o referenciar el/los proceso/s asociado/s al servicio objeto de este acuerdo.

2.5. Elementos que intervienen para la prestación. En caso de necesitar identificar dichos elementos se
deberá utilizar un formulario Anexo, indicando en cada caso tipos de equipos, cantidades, números de
serie, ubicación precisa, etc. Asimismo, en caso de producirse modificaciones en los elementos deberá
incluirse la modificación en el Anexo mencionado previamente. En este caso se detallarán altas, bajas y
modificaciones de equipos. En ningún caso el PROVEEDOR podrá producir modificaciones sin recibir
autorización formal por parte del CLIENTE.

2.6. Formas de Intervención. El CLIENTE definirá las actuaciones que deberá realizar el PROVEEDOR
para intervenir (como por ejemplo, para restitución de un servicio interrumpido). A los fines de estas
actuaciones regirán los tiempos indicativos detallados en un Anexo a tal efecto. Asimismo, el proveedor
deberá informar al cliente de manera fehaciente los avances y tiempos estimados de cada intervención.

2.7. Ámbito. Determinar los lugares para la prestación, que se detallarán en un Anexo. Deberá
mantenerse actualizado con las modificaciones, de existir.

2.8. Pruebas de aceptación. El PROVEEDOR se compromete a informar por escrito la finalización de las
tareas vinculadas a este servicio, a efectos de que el CLIENTE dé comienzo a las pruebas de aceptación
respectivas. Si se le solicitara al PROVEEDOR participar de las mismas, se le informará de esta situación
en tiempo y forma, debiendo el mismo confirmar de igual modo su disponibilidad.

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

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

El PROVEEDOR presentará al CLIENTE en un Anexo al presente dicha ficha, que deberá ser actualizado
por el PROVEEDOR toda vez que correspondiere.
La modificación de la nómina de personal no altera la responsabilidad del PROVEEDOR en cuanto a
confidencialidad y daños emergentes por acción u omisión.
Asimismo, deberá el PROVEEDOR, informar con la debida anticipación los listados correspondientes al
personal que se encuentre disponible para su convocatoria.

3.2. CLIENTE. Identificar el o los responsables de interactuar con el proveedor. Para ello se deberá
completar con nombre, rol, dirección y teléfono la ficha que se encuentra en un Anexo.
El CLIENTE presentará al PROVEEDOR la ficha indicada, que deberá ser actualizada por el CLIENTE
toda vez que correspondiere.

OTROS SERVICIOS VINCULADOS

4.1. Describir otros servicios adicionales (capacitación, energía, horarios, etc.) que estén involucrados y
que no formen parte del Servicio objeto del presente acuerdo.

4.2. Capacitación. El CLIENTE brindará capacitación ante requerimiento del PROVEEDOR, de acuerdo a
temarios vigentes y según modalidad que se establezca para cada caso. El PROVEEDOR se compromete
a presentar al CLIENTE el plan de capacitación anual o específico requerido.

4.3. El CLIENTE se reserva el derecho de requerir al PROVEEDOR los informes vinculados que estime
conveniente respecto de sus actuaciones. Se detallará en un Anexo los informes preestablecidos, con los
tiempos previstos de solicitud. Cualquier otro informe deberá acordarse en el momento por ambas
PARTES.

4.4. Ambas PARTES pueden proveer o solicitar nuevos servicios no comprendidos en el presente
acuerdo, pero que se desprendan del objeto del mismo.
En ese caso, el CLIENTE deberá realizar una descripción del servicio y deberá enviar tal descripción al
PROVEEDOR quien notificará al CLIENTE, a los _____ días, si desea proceder a la negociación de la
inclusión del nuevo servicio.
Si ambas PARTES deciden continuar para la prestación del nuevo servicio, se propondrá una definición
del servicio, precios y tiempos.

4.5 El presente acuerdo puede ser modificado o ajustado de común acuerdo de las partes.

PRECIOS Y PAGO. COSTOS Y PENALIDADES

5.1. Entre las PARTES se establecerán los datos de prestación y contraprestación del servicio contratado,
registrando al inicio del acuerdo, los insumos, gastos imprescindibles, viáticos, horas extras, guardias
pasivas y todo aquel que fuera necesario detallar. Dichos precios se especificarán en un Anexo,
diferenciando aquellos de única vez (no recurrentes) de los periódicos (recurrentes), indicando para
estos últimos expresamente la periodicidad de cada cargo.

5.2. El CLIENTE efectuará las transferencias presupuestarias que surjan de las prestaciones solicitadas al
PROVEEDOR, contra conformidad del CLIENTE del servicio entregado. En el caso de trabajos adicionales
requeridos por el CLIENTE, el PROVEEDOR contestará formalmente la posibilidad de hacerlo en tiempo y
forma y cotizará las tareas para que se efectúen las transferencias presupuestarias y de hs.
extraordinarias en caso de necesidad.

5.3. Penalidades por incumplimiento.


Se deberán establecer rangos y escalas de calidad de servicio, definiendo niveles de incumplimiento
(del cliente y del proveedor) y asociarlo con las penalidades correspondientes.

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

Deberán ser establecidas explícitamente tomando como base los indicadores de calidad de servicio
que se definan en el ítem 6.2. del presente, contemplando los rangos y/o escalas que para los
mismos AMBAS PARTES definan y acuerden.
Se clasificarán en:
5.3.1. Penalidades para el CLIENTE
5.3.2. Penalidades para el PROVEEDOR.
En ambos casos, las penalidades definidas y acordadas deberán guardar coherencia en un todo con
las responsabilidades específicas detalladas según lo sugerido en el ítem 7.

CALIDAD DEL SERVICIO

6.1. Satisfacción del cliente. El CLIENTE se reserva el derecho de realizar las encuestas de satisfacción a
clientes (internos y/o externos) que estime necesarias.

6.2. Indicadores. Los indicadores de evaluación y seguimiento del presente acuerdo deberán detallarse en
un Anexo.
Se definirán los reportes de monitoreo, el tablero de mando y los indicadores que lo componen, junto
con los responsables de medición, valores de referencia, umbrales.
Se identificarán aquellos indicadores correspondientes a la performance de los aspectos técnicos del
sistema y al soporte (a usuarios, funcional, técnico, aplicativo). A través de estos indicadores se
medirán los servicios que el proveedor está prestando.

RESPONSABILIDADES

7.1. El PROVEEDOR deberá disponer de los medios para prestar el servicio. El CLIENTE deberá brindar
las condiciones para que el PROVEEDOR pueda dar el servicio de acuerdo al nivel de calidad acordado.

7.2. Las PARTES se obligan a cumplir estrictamente toda disposición reglamentaria y demás normas,
procedimientos y políticas de la compañía dictadas o a dictarse por el sector competente y que resulte
aplicable.

7.3. Ninguna de las PARTES será responsable por los retrasos o fallas de operación o performance
derivadas de actos o hechos ajenos al control de cada parte.

7.4. La parte afectada por un evento de caso fortuito o fuerza mayor, deberá notificar rápida y
fehacientemente a la otra acerca de todo retraso o falla que origine hasta que desaparezca el evento que
lo causa. La parte afectada actuará de buena fe para solucionar la causa de retraso o falla, y ambas partes
procederán con diligencia una vez que la causa del retraso o falla haya cesado o desaparecido.

7.5. El PROVEEDOR tomará las precauciones necesarias para evitar daños en los espacios y áreas
operativas, equipos y propiedades del CLIENTE.

REGISTRACIÓN Y COMUNICACIÓN

8.1. Las PARTES se comprometen a divulgar en los sectores intervinientes ,incluyendo las áreas de
Calidad corporativas así como las propias de los sectores que participan en el acuerdo, la firma del
presente acuerdo, de conformidad con las disposiciones de la normativa vigente.

VIGENCIA

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

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

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

GARANTÍAS SOBRE LAS INTERVENCIONES

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

CONDUCTAS FRAUDULENTAS

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

CESIÓN DEL ACUERDO

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

INCUMPLIMIENTO. RESOLUCIÓN DEL ACUERDO.

13.1. Ante situaciones de:


13.1.1. Disolución del sector
13.1.2. Falta de pago
13.1.3. Incumplimiento de las cláusulas detalladas precedentemente se elevará al Organismo de
Control, la petición de rescisión del presente acuerdo.

13.2. En el caso de incumplimiento de obligaciones estipuladas en este acuerdo (con respecto a los
plazos e indicadores), el CLIENTE deberá intimar al PROVEEDOR a subsanar la situación en un
plazo que de acuerdo a la circunstancia resulte razonable.

CONFIDENCIALIDAD

14.1. Toda la información que sea intercambiada en virtud del presente, será tratada en forma
confidencial.

14.2. En tal sentido, las PARTES se comprometen a tratar en forma confidencial toda información técnica,
comercial, referida a los sistemas, ingeniería, datos técnicos, registros comerciales, correspondencia,
datos sobre costos, listas de clientes, etc., que resulte de la solicitud de cualquiera de las PARTES.

14.2. La información resultante deberá ser clasificada según la categorización de la empresa.

14.3. En caso que fuera necesario se firmará un Acuerdo de Confidencialidad de la información.

ORGANISMO DE CONTROL.

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

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

COMPETENCIA

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

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

MODELO ÚNICO DE CONTRATO DE SERVICIO


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

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

Anexo XXX
Cuestionarios

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

Cuestionario C1: Identificación de objetivos

FINALIDAD: identificar las exigencias del Cliente y organizar / planificar las actividades.

DESCRIPCIÓN: relevar esquemáticamente las informaciones relacionadas a una descripción formal


de las exigencias del Cliente y a los resultados previstos.

APLICACIÓN: se completa con el Dueño del Proceso en el fin de la fase Planeamiento.

Cuestionario C1
Identificación de objetivos

Fecha:

Nombre del Unidad


entrevistado: organizativa:

Proceso:

Requisitos: 

Resultados 
previstos:

Instrumentos: 

7.1.1.1 DESCRIPCIÓN

Requisitos: El Dueño del Proceso debe expresar cuidadosamente sus requisitos y los resultados
que espera obtener a través de la aplicación de la Metodología.

Resultados previstos: Output que se proveerá (Reporte, documentos varios, etc.).

Instrumentos: Los instrumentos (Cuestionarios, etc.) que se utilizarán en el trabajo.

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

Cuestionario C2: Nivel Objetivo / Supuesto del Proceso

FINALIDAD: determinar el “perfil” del Nivel Objetivo / Supuesto del proceso examinado.

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

APLICACIÓN: se completa con el Dueño del Proceso en la fase Planeamiento si se requiere evaluar
la distancia entre el Nivel actual y el objetivo / supuesto.

7.1.1.2 DESCRIPCIÓN

Nro. Pregunta Descripción Atributo de Referencia

¿El P tiene un nombre (A01)? ¿Conoce los A01: Existente


1 ¿Piensa que el
limites (cuando empieza y cuando A11: Identificado
Proceso (P) existe?
termina)(A11)?

¿El P fue enteramente ejecutado por las A02: Teórico


2 ¿Piensa que el P fue
personas involucradas? ¿En qué porcentaje y A03: Parcialmente
ejecutado por lo menos
por quién? ¿En este momento está en fase de realizado
una vez?
realización por primera vez? A12: Realizado de
hecho ....
¿Las actividades que componen el P y su A21: Definido
3 ¿Piensa que el P tiene
secuencia lógica-temporal son claras para las
una secuencia
personas que trabajan en el proceso?
operativa identificable?
¿Las personas que operan en el proceso, A13: Conocimiento
4 ¿Piensa que existe
tienen los conocimientos sobre el mismo parcial en evolución
conocimiento acerca
consolidados (individualmente o por A27: Conocimiento
del P?
(sub)grupos), aunque no estén consolidado ...
documentados, y sobre los instrumentos
necesarios para su realización?
¿El modo de operar el P (método de trabajo) A23: Estabilizado
5 ¿Piensa que existe una
está estabilizado? ¿Existen casos atípicos
estabilización en el P?
periódicamente difundidos y explicados?

¿Existen algunos documentos (mapa / A14: Documentación


6 ¿Piensa que el P está
esquema representativo) que contienen una existente pero parcial
documentado?
descripción (aunque sea resumida / ....
esquemática) del P?

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

Nro. Pregunta Descripción Atributo de Referencia

¿Este mapa / esquema contiene las A22: Representado


7 ¿Esta representación
actividades, su secuencia, los input / output? gráficamente en forma
del P piensa que está
esquemática
estructurada?
.... A26: Existe una norma
8 ¿Existe una norma que
....
establece reglas /
lineamientos /
regulaciones para el P?
.... A28: Represtación
9 ¿Esta representación
univoca del P ...
del P está reconocida
como válida por el
Management?
¿Las modalidades operativas, los roles, las A24: Actividades
10 ¿Piensa que existen
responsabilidades, y los instrumentos usados estructuradas en
algunos
para realizar el P están descriptas? Procedimientos
Procedimientos que
describan el P?
¿Estos procedimientos son periódicamente A37: Hay revisión y
11 ¿Piensa que hay una
actualizados también en función de las actualización
revisión / actualización
evoluciones del P? ¿Quién debería tener este (mantenimiento) de los
de estos
rol? procedimientos
Procedimientos?
¿Estos Procedimientos reflejan el modo A25 Coherencia entre
12 ¿Piensa que estos
operativo actual (A25)?¿Están alineados al los procedimientos
Procedimientos y el P
proceso (A35)? A35: Coherencia entre
están alineados?
los procedimientos y el
P ....
¿El Management de la organización saben A36: Procedimientos
13 ¿Los Procedimientos
que existen estos procedimientos?¿Estos reconocidos y
del P están
procedimientos tienen un circuito de oficializados por el
reconocidos y
aprobación oficial? Management
oficializado por el
Management?
¿La consulta de los procedimientos está A32: Conocimiento
14 ¿Piensa que todos los
disponible para todos los que trabajan en el difundido
que trabajan en el P
P? ¿Estos procedimientos son un soporte
utilizan (conocen) los
para quien trabaja en el P? ¿Estos siguen los
Procedimientos?
procedimientos en su trabajo? ¿Cómo se
podría garantizar la difusión y la aplicación de
los procedimientos?
¿Los conocimientos tecnológicos y los A33: Conocimiento
15 ¿Piensa que el
instrumentos (herramientas) de soporte son consensuado ....
conocimiento está
conocidos y aceptados por los Grupos de
consensuado?
Trabajo del P?
... A34: Alineación
16 ¿Piensa que toda la
(información
información necesaria
compartida) entre las
para el trabajo del P
unidades
está disponible para las
organizacionales
personas involucradas
involucradas en el
en el P?
Proceso

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

Nro. Pregunta Descripción Atributo de Referencia

¿Realizando nuevamente el P con los mismos A31: Sistemático


17 ¿Piensa que los
input y en las mismas condiciones de trabajo (repetitivo).
Resultados son
se consiguen los mismos output? ¿En el
repetibles?
mismo tiempo? ¿También intercambiando las
personas involucradas? ¿Los output son
lógicamente dependientes de las actividades
realizadas / no realizadas en el P? ¿Conozco
siempre el output que obtengo del proceso
según las actividades que se realizan o no?
¿En un momento cualquiera piensa que se A38: Se puede
18 ¿Piensa que se puede
puede identificar en cual de sus fases se efectuar un
efectuar un
encuentra el proceso?¿Existe una figura que seguimiento sobre las
seguimiento sobre las
verifica esto? fases del P
fases del P?

¿Cuales son y cual es su fin? A41: Hay indicadores


19 ¿Hay algunos
internos
Indicadores internos de
la performance del P?
¿La recolección de los datos de prestación en A43: Medido
20 ¿Piensa que estos
el P es metódica? ¿Existe un responsable en A42: Los indicadores
Indicadores son
la Organización de la recolección / están integrados como
controlados
elaboración de los datos? ¿Quién es? ¿La procedimiento normal
constantemente?
recolección de los datos es parte de los
procedimientos y del día a día?
¿Que utilización se hace de los datos A44: Gestionado
21 ¿Hay una gestión que
recolectados? ¿Se los comunican al estratégicamente.
persiga el
Management? ¿Se emprenden normalmente
mejoramiento basada
algunas actividades correctivas como
en la performance
consecuencia de datos fuera de lo normal?
observada en los
¿Cómo se administra el feedback de los datos
indicadores?
analizados?

Cuestionarios por la evaluación de los Operativos

Cuestionario C3: Nivel Actual del Proceso

FINALIDAD: identificar el “perfil” del nivel actual del Proceso examinado.

DESCRIPCIÓN: el cuestionario retoma los atributos de los niveles de un proceso, los ordena
lógicamente y los traduce en preguntas a proponer al entrevistado para evaluar el perfil del nivel actual.
Las posibles respuestas son: “SÍ”, “Parcialmente / Si, no univoco”, ”NO”, o “NA” (No Aplicable: si la
pregunta no tiene sentido en el contexto analizado). Se reserva un espacio para eventuales
consideraciones. El perfil identificado puede coincidir con uno de los niveles definidos o ser intermedio
entre dos o más de estos.

APLICACIÓN: se compila con los personales operativos del Proceso en la fase Relevamiento.

7.1.1.3 DESCRIPCIÓN

Nro. Pregunta Descripción Atributo de Referencia

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

Nro. Pregunta Descripción Atributo de Referencia

¿El P tiene un nombre (A01)? ¿Conoce los A01: Existente


1 ¿El Proceso (P)
limites (cuando empieza y cuando A11: Identificado
existe?
termina)(A11)?

¿El P fue enteramente ejecutado por las A02: Teórico


2 ¿El P fue ejecutado al
personas involucradas? ¿En que porcentaje y A03: Parcialmente
menos una vez?
por quien? ¿En este momento está en fase de realizado
realización por primera vez? A12: Realizado de
hecho ....
¿Las actividades que componen el P y su A21: Definido
3 ¿El P tiene una
secuencia lógica-temporal son claras para las
secuencia operativa
personas que trabajan en el proceso?
identificable?
¿Las personas que operan en el proceso, A13: Conocimiento
4 ¿Existe conocimiento
tienen los conocimientos sobre el mismo parcial en evolución
acerca del P?
consolidados (individualmente o por A27: Conocimiento
(sub)grupos), aunque no estén documentados, consolidado ...
y sobre los instrumentos necesarios para su
realización?
¿El modo de operar el P (método de trabajo) A23: Estabilizado
5 ¿Existe una
está estabilizado? ¿Existen casos atípicos
estabilización en el P?
periódicamente difundidos y explicados?

¿Existen algunos documentos (mapa / A14: Documentación


6 ¿El P está
esquema representativo) que contienen una existente pero parcial
documentado?
descripción (aunque sea resumida / ....
esquemática) del P?
¿Este mapa / esquema contiene las A22: Representado
7 ¿Esta representación
actividades, su secuencia, los input / output? gráficamente en forma
del P está
esquemática
estructurada?
.... A26: Existe una norma
8 ¿Existe una norma
....
que establece reglas /
lineamientos /
regulaciones para el
P?
.... A28: Represtación
9 ¿Esta representación
unívoca del P ...
del P está reconocida
como válida por el
Management?
¿Las modalidades operativas, los roles, las A24: Actividades
10 ¿Existen algunos
responsabilidades, y los instrumentos usados estructuradas en
Procedimientos que
para realizar el P están descriptas? Procedimientos
describan el P?
¿Estos procedimientos son periódicamente A37: Hay revisión y
11 ¿Hay una revisión /
actualizados también en función de las actualización
actualización de estos
evoluciones del P? ¿Quién debería tener este (mantenimiento) de los
Procedimientos?
rol? procedimientos
¿Estos Procedimientos reflejan el modo A25 Coherencia entre
12 ¿Estos
operativo actual (A25)?¿Están alineados al los procedimientos
Procedimientos y el P
proceso (A35)? A35: Coherencia entre

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

Nro. Pregunta Descripción Atributo de Referencia

están alineados? los procedimientos y el


P ....
¿El Management de la organización saben A36: Procedimientos
13 ¿Los Procedimientos
que existen estos procedimientos?¿Estos reconocidos y
del P están
procedimientos tienen un circuito de oficializados por el
reconocidos y
aprobación oficial? Management
oficializado por el
Management?
¿La consulta de los procedimientos está A32: Conocimiento
14 ¿Todos los que
disponible para todos los que trabajan en el P? difundido
trabajan en el P
¿Estos procedimientos son un soporte para
utilizan (conocen) los
quien trabaja en el P? ¿Estos siguen los
Procedimientos?
procedimientos en su trabajo? ¿Cómo se
podría garantizar la difusión y la aplicación de
los procedimientos?
¿Los conocimientos tecnológicos y los A33: Conocimiento
15 ¿El conocimiento está
instrumentos (herramientas) de soporte son consensuado ....
consensuado?
conocidos y aceptados por los Grupos de
Trabajo del P?
... A34: Alineación
16 ¿Toda la información
(información
necesaria para el
compartida) entre las
trabajo del P está
unidades
disponible para las
organizacionales
personas involucradas
involucradas en el
en el P?
Proceso
¿Los Resultados son ¿Realizando nuevamente el P con los mismos A31: Sistemático
17
repetibles? input y en las mismas condiciones de trabajo (repetitivo).
se consiguen los mismos output? ¿En el
mismo tiempo? ¿También intercambiando las
personas involucradas? ¿Los output son
lógicamente dependientes de las actividades
realizadas / no realizadas en el P? ¿Conozco
siempre el output que obtengo del proceso
según las actividades que se realizan o no?
¿En un momento cualquiera piensa que se A38: Se puede
18 ¿Se puede efectuar un
puede identificar en cual de sus fases se efectuar un
seguimiento sobre las
encuentra el proceso?¿Existe una figura que seguimiento sobre las
fases del P?
verifica esto? fases del P
¿Cuales son y cual es su fin? A41: Hay indicadores
19 ¿Hay algunos
internos
Indicadores internos
de la performance del
P?
¿La recolección de los datos de prestación en A43: Medido
20 ¿Estos Indicadores
el P es metódica? ¿Existe un responsable en A42: Los indicadores
son controlados
la Organización de la recolección / elaboración están integrados como
constantemente?
de los datos? ¿Quién es? ¿La recolección de procedimiento normal
los datos es parte de los procedimientos y del
día a día?

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

Nro. Pregunta Descripción Atributo de Referencia

¿Que utilización se hace de los datos A44: Gestionado


21 ¿Hay una gestión que
recolectados? ¿Se los comunican al estratégicamente.
persiga el
Management? ¿Se emprenden normalmente
mejoramiento basada
algunas actividades correctivas como
en la performance
consecuencia de datos fuera de lo normal?
observada en los
¿Cómo se administra el feedback de los datos
indicadores?
analizados?

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

FINALIDAD: describir el Proceso en términos de fases y de características para individualizar las


funcionalidades del nivel objetivo definido por el Dueño.

DESCRIPCIÓN: hay un cuestionario C4 por cada nivel objetivo. El cuestionario tiene la finalidad de
identificar las características del Proceso actual y, eventualmente, de evaluar el grado de las mismas a
través de la visión del personal operativo entrevistado. La descripción de cada pregunta se presenta en
gris en la tabla.
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.

Actor Persona que interviene y participa en la elaboración de las distintas


actividades definidas dentro de una tarea o fase

BD Base de Datos

BE (Eventos de Condición de Prueba de más alto nivel. Definirán un área funcional


Negocios)

Big Bang Modalidad de puesta en producción que se realiza para todos los clientes,
líneas, etc. en forma conjunta

Bug Error en algún módulo del sistema

Business Plan Plan que considera inversiones, gastos iniciales, upgrades, capacitación,
mantenimiento de la aplicación, etc.

Condiciones de 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.

Condiciones Representan agrupaciones lógicas de condiciones de detalle de prueba.


Sumarizadas de Pueden describir funcionalidades (ej: suspensión – conexión) o categorías (ej:
Prueba (STC) Clientes, Productos, etc).

Coordinador Persona encargada de coordinar y llevar adelante todas las tareas dentro de
una etapa

CPU Procesador de la computadora (Central Processing Unit)

DAFO Análisis de Debilidades, Amenazas, Fortalezas, Oportunidades que se realiza


para un proyecto (en inglés SWOT: strong, weak, oportunity, threat)

DB Data base

Datos para la Reutilización de los Datos provenientes de la Fase de Prueba Previa y


Prueba creación de Datos adicionales para asegurar que se hayan cubierto todas las
Condiciones de Detalle de Prueba.

Despliegue Implantación, generalización, roll out

DTC Derivan de los requerimientos funcionales y del usuario. Están compuestas por
(Condiciones de la condición que se va a probar y los resultados esperados de alta nivel
Detalle de asociados.
Prueba)

Entregables Son los documentos que se obtienen como resultado de la ejecución de las
tareas.

Eventos de Condición de Prueba de más alto nivel. Definirán un área funcional


Negocios (BE)
179 de 181
Sistemas de Información
Gestión de Proyectos Informáticos
Prof. Lic. Roberto García

FCE Factores Claves de Éxito.

Generalización Implantación, despliegue, roll out

GST (Global 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.

Implantación Generalización, despliegue, roll out

In house Paquete cerrado, desarrollos propios

Legacy Sistemas ya existentes en la Cía

Llave en mano Modalidad de contratación en la cual se implementan funcionalidades a un


precio fijo donde se establece la fecha de inicio y fecha de fin de la
implementación sin importar la cantidad de horas hombre utilizadas...

MBs Mega Bits

NOC / SOC Network Operation Center / Service Operation Center provee monitoreo de la
Red 24x7 asegurando que los eventuales inconvenientes sean rápidamente
identificados y resueltos

Proyecto Proyecto de sistemas es todo aquel que comienza con la identificación de una
necesidad y culmina con la implantación de la solución informática.

Prueba Caja 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.

QA (Quality Aseguramiento de la calidad. Evaluar periódicamente la realización total del


Assurance) proyecto para asegurar que se cumplen los estándares de calidad
establecidos para el proyecto.

Responsable Persona encargada de llevar adelante las tareas a su cargo

Rol Actividad que puede ser desarrollada por una persona o un grupo de personas

Roll Out Implantación, generalización, despliegue

Sitio Web Es solo un conjunto de archivos relacionados entre sí, que puede estar
guardado en cualquier soporte magnético (disco rígido, cd, etc.). Para que este

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

conjunto de archivos sea visible desde la Web será necesario almacenarlo en


un «web server».
Dado que Internet es una red gigante de servidores conectados entre sí, es
necesario que cada website tenga una identidad propia (un nombre) para
poder ser ubicado. El nombre de un espacio dentro de un servidor, en el
lenguaje de Internet, es un conjunto de números que conforman una dirección
IP única. Esta dirección permite identificar unívocamente a ese espacio que,
en el caso del web hosting, contiene un website determinado.

SLA (Service Level Agreement) Compromiso de nivel de servicio

SO Sistema Operativo

STC Representan agrupaciones lógicas de condiciones de detalle de prueba.


(Condiciones Pueden describir funcionalidades (ej: suspensión – conexión) o categorías (ej:
Sumarizadas de Clientes, Productos, etc).
Prueba)

TIR Tasa Interna de Retorno. Indicador económico que ayuda, junto con el VAN, a
determinar la rentabilidad de un proyecto

VAN Valor Anual Neto. Indicador económico que permite, junto con el TIR
determinar la rentabilidad de un proyecto.

Volumetría (de un sistema) Se refiere a los volúmenes de información, transacciones y


tráfico en general que es capaz de manejar un sistema en situaciones
normales y picos.

Web Hosting El servicio de web hosting brinda la posibilidad de «publicar» un sitio en la


Web, es decir que hace posible que un sitio se pueda visualizar navegando la
web.

Web Server Es decir un servidor conectado a Internet y que tiene como función servir
páginas web.

Web Site Sitio Web

181 de 181

Das könnte Ihnen auch gefallen