1

Las etapas metodológicas. La metodología es un método de trabaja conformado por una serie de métodos
o etapas generalmente obligatorias que responden a una cuestión normativa, en la cual participan los
recursos humanos específicos, cada uno con una tarea en particular. Estas etapas son:

1. Análisis Preliminar. Estamos en presencia de una etapa estrictamente metodología, porque el

proyecto no comenzó. Este análisis surge o bien se lleva a cabo como consecuencia o condicionado
por un requerimiento previo, o bien de una necesidad de información por parte del usuario a través
del nivel estratégico al líder. Esta Etapa fue creada/pensada en su momento a favor del líder. El
objetivo una vez concluida, tiene que ver con la decisión del líder, vinculada con el hecho de que
asuma o no la responsabilidad en cuanto a hacerse cargo del Proyecto. Cabe la posibilidad, una vez
finalizado este análisis, que el líder decida no hacerse caso del proyecto con una razón fundada o
motivo concreto, y este el momento donde se pone en juego la condicionalidad de la agresividad.

Clase 8 – Mie 16.09.20

(Continuación de análisis preliminar)

1) Gestión de proyecto. Implica poder definir si existe un verdadero motivo o una razón para
comenzar con un proyecto. En cuanto al motivo, el líder puede encontrarse ante dos
momentos diferentes :
• Momento “0”. A diferencia del momento 1 no existe un proyecto anterior y no existe
un sistema de información previo. Su razón de inicio es la inexistencia de un sistema

• Momento “1”. Existe un proyecto anterior y un sistema de información previo, pero con
la presencia de distintas situaciones que sirven de razón o motivo para comenzar un
proyecto nuevo, por cuanto estas razones o motivos obligan a que el sistema actual
debe ser discontinuado o desafectado , las cuales son:

I. Replanteo del sistema : esta razón o motivo es procedente, en los casos

cuando la organización decida cambiar o modificar su estrategia y/o su
cultura. En cuanto a estrategia, la posibilidad puede ser que habiendo
comprobado que están bien orientados en cuanto a lo que se espera del
negocio, deciden cambiar el objetivo pasando del corto plazo al mediano/largo
plazo o viceversa. Y cambio de cultura responde a que el nivel estratégico
considero y decidió conveniente, modificar o bien cambiar los servicios que
presta o bien los producto que eventualmente produce y comercializa.
II. Nuevo y/o significativo requerimiento interno o externo. Se trata de una
cuestión significativa en cuanto a la incidencia con relación al nuevo
requerimiento (tiene que ser lo suficientemente importante como para que la
influencia de las modificaciones sobre el sistema de información justifique que
deba ser cambiado). Un ejemplo es la implementación de la factura
electrónica, que obligo a determinadas organizaciones a cambiar el sistema.
III. Nueva herramienta tecnológica. Esta razón o motivo refiere a cuestiones que
en su momento eran excepcionales, pero que en la actualidad se transformó
en un tema habitual o corriente producto de la evolución tecnológica, lo que
condiciona naturalmente el ciclo de vida o producción de los sistemas de
información. Ejemplo : Implementación del sistema operativo Windows 10
(hubo que cambiar algunas soluciones que funcionaban bajo plataformas
anteriores y cuya adaptación al cambio, era de una incidencia de tal
 2

significación, que obligó al cambio de los sistemas de información

computarizados en producción.
IV. Situaciones no contempladas o no consideradas oportunamente. Esta razón
no debería existir, de no mediar la incapacidad o irresponsabilidad manifiesta
del líder del proyecto. Esta situación solo es factible cuando el líder no
interpretó debidamente el requerimiento del usuario o bien porque el usuario
no lo presento con la claridad necesaria. Ahora bien, por una u otra razón el
responsable directo de esta situación es el líder, sin duda alguna. El tema del
usuario que no presentó el requerimiento con claridad, tiene que ver con el
hecho de que los integrantes del nivel estratégico no están en condiciones
intelectuales o no cuentan con la formación necesaria, para presentar el
requerimiento con la claridad necesaria, ya que el único conocimiento que
poseen está vinculado con el negocio. Además, en general suelen no ser
profesionales. Una forma de solucionar esta situación, es recurrir a una
solución conocida recientemente relacionada con incorporar al nivel
estratégico un usuario final profesional, con lo cual, de esa manera estaríamos
asegurando que el usuario y el líder de proyecto podrán manejar e interpretar
un mismo lenguaje en forma fluida y clara, como para evitar de este modo, las
malas interpretaciones y de esa manera asegurar que el requerimiento sea
planteado con claridad necesaria.

2) Estudio de factibilidad. Los factores a estudiar, son:

• Económico, del cual la idea del líder es conocer cuál es el presupuesto que el usuario
tiene la intención de aportar en cuanto al desarrollo del proyecto.
• Técnico, el líder desea conocer cuál es la capacidad, cantidad y calidad técnica que
el usuario se encuentra en condiciones de aportar al desarrollo del proyecto :
equipamiento, instalaciones, insumos, logística, etc.
• Humano, el líder lo que intenta confirmar es si el usuario está en condiciones y acepta
hacerse cargo de los contratos vinculados con el staff del proyecto.
• Legal, como condición y por una cuestión de seguridad respecto del staff, se deberá
confirmar y asegurar que tanto la organización como sus actividades se encuentran
encuadradas y responden en su totalidad a las normas vigentes, como para evitar de
este modo estar alcanzado y afectado por alguna situación irregular.
• Tiempo, debe requerir por parte del líder una atención muy especial, por cuanto este
factor alcanza y participa de un compromiso particular dentro de la duración del
proyecto. en cuanto a la fecha pactada para cumplir con la entrega del sistema de
información computarizado. Requiere de atención especial porque todo lo bueno
hecho durante el proyecto, se puede derrumbar con el solo hecho de no cumplir con
la fecha de entrega, por lo tanto, esta situación es de suma importancia porque está
en juego la responsabilidad del líder.

El estudio de los factores económicos, técnicos y humanos tienen un objetivo en común,

vinculado con el hecho de que el líder y sus colaboradores, en cuanto a su obligación
vinculada con el desarrollo del proyecto, consiste solo en aportar la propiedad intelectual

• Gestión de calidad, investigar analizar e interpretar las normas vinculadas con la

certificación a la cual se encuentra adherida la organización. Tiene que ver
directamente con el desarrollo del proyecto bajo valores o estándares de excelencia,
como para que el producto final (la información) responda necesariamente de igual
modo a dichos estándares o indicadores. Para cumplir con este estudio el líder deberá:
 3

I. Planificar la calidad. se hace teniendo en cuenta la información, razón por la

cual la planificación debe estar basada en los requerimientos informativos.
II. Aseguramiento de la calidad. Responde partiendo de requerimiento
informativos, confirmar o negar su cumplimiento.
III. Monitoreo de la calidad. Implica que una vez confirmado el cumplimiento,
controlar y aplicar toda actualización y/o modificación que se manifiesten en
lo que respecta las normas de calidad.

• Administración de Riesgos. Un riesgo es una situación abstracta, por lo cual cabe la

posibilidad que puede ser definido desde distintos puntos de vista. Desde el punto de
vista del supuesto, el riesgo se trata de una situación totalmente desconocida que
genera a su vez complicaciones para intentar predecirlo o anticiparlo. Desde el punto
de vista de la intención el riesgo es una contingencia o amenaza según el momento y
la situación, porque si el riesgo es una contingencia entonces estamos ante una
situación que debe ser incorporada a un Plan preventivo o de contingencias siendo
que, cuando una contingencia forma parte de un plan preventivo o contingencia
automáticamente se convierte en una amenaza. Desde el punto de vista del
conocimiento el riesgo se considera un acto, un hecho o un suceso interno o externo
que tiene como objetivo mediato o inmediato en forma directa o indirecta bajo una
acción voluntaria o involuntaria, provocar una perdida de dimensiones desconocidas.
Una Pérdida representa un daño, perjuicio o deterioro.

Las tareas a realizar en este sentido, son :

• Identificar el riesgo. Imaginar, analizar y tratar de dar forma a un potencial riesgo en
cuanto a las siguientes características;
I. Origen o naturaleza.
II. Importancia en cuanto al alcance o área de incidencia que pueda afectar.
III. Posibilidad de ocurrencia

• Analizar el riesgo. Tener en cuenta que el punto de partida o condición para proceder
con el análisis del riesgo es haberlo identificado convenientemente. El análisis
consiste en intentar dimensionar o bien mensurar el impacto que puede producir el
riesgo en caso de ocurrencia o una eventual repetición y considerar los recursos
necesarios para enfrentarlo o bien solucionar la pérdida sufrida

• Determinación de acciones. Acciones ante la eventual ocurrencia de un riesgo:

I. Aceptar, vinculado con un riesgo imposible de ser previamente identificado,
de tal modo que, ante esta situación, no se cuenta con las herramientas
necesarias para poder enfrentarlo.
II. Mitigar, responde a una cuestión preventiva, es decir que de algún modo se
pudo identificar o analizar el riesgo o bien por las características propias del
riesgo se logra de algún modo disminuir o atemperar sus efectos o
consecuencias negativas que pueda producir.
III. Anular, puede darse ante la presencia de un riesgo que responde a
características de baja o muy baja significación, o bien cualquiera sea su
naturaleza y/o importancia puede haber sido identificado y analizado
oportunamente, con lo cual se cuenta entonces con las herramientas
necesarias para enfrentarlo.
 4

3) Gestión de modelos. Tiene como motivo que el líder pueda definir cuál es el modelo de
proyecto a aplicar según las siguientes situaciones a considerar: tipo de requerimiento, tipo
de organización y tiempo estimado de duración del proyecto.

I. Modelo cascada. Generalmente es utilizado ante un requerimiento simple en cuanto

al planteo, interpretación y resolución. Hablamos de tiempo vinculado con el proyecto
corto y medianamente corto, aplicado a todo tipo de organización prioritariamente con
aquellas que realizan actividades estacionales. La característica principal de este
modelo refiere, a que se trata de un modelo rígido, lo cual significa que una vez
comenzado el proyecto no permite incorporar modificaciones o nuevos
requerimientos.
II. Modelo incremental. El punto de partida es la organización y refiere a aquellas
organizaciones complejas, en particular a aquellas organizaciones familiares en
donde todo el mundo opina lo que quiere, dicen y deciden lo que quieren, con lo cual
las actividades se desarrollan en un ámbito de total desorden, razón por la cual los
requerimientos son inestables, con escaza claridad en cuanto al planteo y a la
interpretación. Este modelo es indiferente a todo tipo de plazo y se caracteriza por ser
totalmente flexible acorde a las circunstancias.
III. Modelo prototipo. Cuenta como punto de partida tanto el modelo cascada como el
modelo incremental y la incidencia que tiene la metodología sobre este modelo, refiere
y condiciona el cumplimiento de las sucesivas etapas, siendo que cada etapa a
cumplir es un prototipo nuevo en función a lo desarrollado en la etapa anterior.
IV. Modelo espiral. es el modelo ideal, ya que es aplicable a todo tipo de requerimiento a
todo tipo de organización, funciona en el largo y muy mediano plazo, además, cuenta
con la posibilidad de combinarlo con otros diferentes modelos. Es abierto y adaptable
a todo tipo de situación, pero para poder aplicarlo requiere de una condición vinculada
con los recursos humanos que participan, que requieren sólidos conocimientos, muy
buena preparación y amplia experiencia en cuanto a desarrollo de proyectos.

Clase 9 – Jue 17.09.20

(Continuación de análisis preliminar)

Potenciales situaciones. Una vez finalizado el análisis preliminar, realizado por el líder junto con los
analistas (funcional y documentador), por cuanto todo lo que se haya recolectado a lo largo de su
desarrollo debe haber quedado convenientemente documentado, para que una vez finalizado
puedan luego juntarse y analizar absolutamente su contenido, y poder tomar la decisión respectiva.

Las cuestiones negativas que pueden motivar no realizar el proyecto:

1) Pobre identificación (presentación y/o interpretación) del requerimiento.

2) Requerimiento que presenta dificultades en cuanto a su cumplimiento.
3) Insuficientes recursos económicos, humanos y/o técnico: El Estudio factibilidad abarcó los
factores vinculados con los recursos económicos, humanos y/o técnicos, que deben ser
cumplimentado con el usuario. El líder puede desistir por considerar que el presupuesto no
se encuentra acorde a las necesidades del proyecto, como no lo son los recursos técnicos o
bien que el usuario presente ciertas reticencias en cuanto a hacerse cargo de los contratos
de quienes conforman el Staff.
4) La imposibilidad de cumplir con las normas de calidad. La calidad tiene en consideración la
información (requerimientos informativos). Si por ejemplo el costo de obtener la información
 5

supera en alguna medida el beneficio que se pueda recuperar, no se estaría cumpliendo con
el requerimiento económico.
5) No pueda cumplir con el requerimiento de informativo confiablidad. Deberá evitar la flotación
y la dispersión de la información. Encontrar un canal confiable, también con un receptor
confiable. En la práctica se logra trabajando en red, lo que se evita es que flote y además en
cuanto a la dispersión se va a lograr que la información llegue a manos de un destinatario
confiable. Puede ser que llegado el momento no se cuente con los recursos técnicos
necesarios, con lo cual puede derivar en el hecho de que el líder no se haga cargo del
proyecto.
6) Existan riesgos que no puedan ser evitados, con lo cual esa situación complicaría la situación
del proyecto.
7) Una legalidad dudosa o peligrosa en cuanto a lo que refiere la organización y/o a las
actividades que realiza.
8) El líder considere que es imposible cumplir con fecha prevista para proceder con la entregar
del sistema.

Dejando de lado estas cuestiones, si el resultado del análisis preliminar fue satisfactorio se entiende que el
proyecto puede llevarse a cabo. Este es el momento en el cual se dispara la segunda etapa, primera del
proyecto. El relevamiento.

1. Relevamiento. Significa intentar conocer lo máximo acerca de algo. En este caso concreto el
relevamiento debería permitir conocer lo máximo acerca de la organización y su funcionamiento. La
razón por la cual se debería relevar:
• Estrategia. Intentar conocer el objetivo, por cuanto el objetivo planteado en la estrategia se
relacionará directamente a futuro con la filosofía del sistema. Esto es si el objetivo está
planteado a corto plazo luego la filosofía del sistema deberá ser defensiva. Mientras que si
el objetivo contenido en la estrategia está planteado a mediano largo plazo, la filosofía del
sistema deberá ser ofensiva o proactiva.
• Estructura. Se deberá conocer de manera puntual, cuáles son las tareas que llevan a cabo
todos los integrantes de la estructura, independientemente del nivel que sea. El motivo de
este alcance es que todos deberán recibir en su momento la información necesaria para
decidir teniendo en cuenta que el universo de las decisiones es la estructura.
• Procedimientos. No hay tarea sin formulario. A partir de las tareas, el objetivo de relevar los
procedimientos es saber cuáles son los formularios o documentos que utilizan los distintos
niveles de la estructura para cumplir con sus tareas.
• Pensamiento del usuario. Responde a una opinión vinculada con la tarea y los formularios
que le fueron asignados. La importancia radica en que se le está solicitando la opinión a
quienes están en la trinchera o en la línea de fuego, con lo cual nada mejor que escuchar
ese tipo de opinión.

2. El análisis. Se lleva a cabo a partir de las normas de control interno y consiste en comparar esas
normas con el resultado del relevamiento, es decir, con la realidad.

3. El diagnostico. Va a ser la resultante de comparar las normas con lo que se relevó, o sea que es
normal o habitual que luego de realizar el análisis existan claras diferencias entre lo que se debería
hacer (las normas) y lo que realmente se hace (la realidad).

4. Propuesta de solución administrativa. A partir de esa etapa surgen ciertas situaciones muy
importantes y que deben ser tenidas muy en cuenta. A saber, el objetivo de la propuesta de solución
administrativa consiste en informar al usuario cuáles son y cómo deben ser solucionadas las
 6

situaciones irregulares en materia administrativa, las cuales surgieron como consecuencia del
análisis y se encuentran documentadas en el diagnóstico. Otra cuestión es que es única, no presenta
alternativas. Es además incondicional y obligatoria (no negociable) respecto del usuario, en cuanto
al cumplimiento.

Que es lo que se puede suceder ? :

El usuario decida no proceder con esa solución.
• Continuar sin haberse solucionado esos problemas administrativos. Si el líder continúa, se
acabó el proyecto y la situación se transforma en sistematización. Lo que se obvia es la
cuestión administrativa. En este caso cabe que el líder abandone el proyecto con una razón
fundada. Si continua adelante, cuando llegue el final del proyecto se encuentra con una
situación de fracaso, con un sistema de información que va a dejar de funcionar en breve,
motivado por el hecho de que se trata de un sistema de información producto de una
sistematización, con la identificación del Líder.

5. Estudio de viabilidad. Consiste en analizar lo resultante como consecuencia de haber presentado la

propuesta de solución administrativa al usuario. Lo que Pudo haber ocurrido es que el usuario la
acepte y solucione lo propuesto. o bien que no solucione nada, con lo cual la consecuencia respecto
del líder y sus colaboradores es que se termine el proyecto. Si se llega a una solución favorable,
entonces el proyecto continúa y se abren dos caminos:
• Comprar un sistema (lo veremos después). ¿Es el momento para comprar? Si. para poder
decidir la compra de un sistema estándar se deben cumplir con todos las etapas anteriores
hasta llegar a este momento. Porque en este momento nos damos cuenta de qué es lo que
se necesita realmente, con lo cual estamos entonces en condiciones de salir a comprar un
sistema que sea útil que cumpla con los requerimientos del usuario en las mejores
condiciones.
• Hacer un sistema a medida. La próxima etapa entonces en este sentido, es proceder con la :

6. Propuesta del Sistema. La propuesta del sistema contiene 4 elementos:

I. Diseño global. El esquema administrativo acerca del cual en su momento se planteó
un ejemplo. es el diseño del sistema vinculado con un requerimiento en particular (la
solicitud de cotización (compras)). Ese esquema en su momento hoy se transforma
desde el punto de vista metodológico en el diseño global. Desde el punto de vista
conceptual. el Diseño es un dibujo o bosquejo.
II. La tecnología. Hay consideraciones:
a. Que tarea deberá realizar el ingeniero de tecnología, es sugerir u opinar a partir
del diseño global, cuál es la tecnología adecuada para que el sistema de
información pueda funcionar correctamente. El que decide es el líder. Hay dos
factores por lo cual el ingeniero no toma la decisión. Primero el presupuesto y
luego recursos técnicos puestos a disposición del proyecto (Estudio de
Factibilidad – Factores Económico y Técnico).
b. Se haya planteado primero el diseño global y luego la tecnología. Deben
responder a un orden lógico, por cuanto la tecnología deberá responder al
diseño global (el requerimiento del usuario). De lo contrario, que ocurriría si la
tecnología se plantea primero sin tener en cuenta el diseño global ?
Estaríamos en presencia de una situación en la que se pondera primeramente
la tecnología con relación al diseño, siendo que de ese modo que se estaría
perdiendo de vista el requerimiento.
III. Diagrama de procesos. Elaborado o construido por el analista de procesos. Construye
este diagrama con una visión de futuro, por cuanto se trata de una herramienta que
va a ser utilizada oportunamente por los operadores del sistema, una vez que haya
sido entregado al usuario para que sea utilizado.
 7

Observaciones :
− Dentro del Staff no se incluyen a los operados
− Los integrantes del Staff son pensantes
− Los Operadores tienen perfil autómata
− La participación de los operadores ocurre después de la implementación. Son
los que operan, ejecutan o procesan el sistema de información computarizado.
.
IV. El plan o bien los planes de mantenimiento.

Clase 10 – Jue 24.09 y Clase 11 – Lu 28.09

V. El plan o los planes de mantenimiento. Hay 1 plan asegurado, que no resiste ningún
tipo de condicionamiento : Es el plan de mantenimiento tecnológico o técnico. El otro
plan es el de plan de mantenimiento del sistema y depende o está condicionado por
el formato del sistema.
Formato Filosofía. La Filosofía puede ser Defensiva / Ofensiva o Proactiva y
en particular depende del objetivo planteado en la Estrategia de la Organización. El
Formato puede ser abierto o cerrado. El formato del sistema lo decide el usuario. Si
es cerrado, dicha decisión se sustenta en una cuestión de seguridad. El formato
cerrado se representa a través de un link o enlace, respecto del sistema escrito por el
programador (es una especie de documento escrito). Si es abierto el sistema escrito
por el programador se encuentra a disposición de todo el mundo. Mientras que si es
cerrado el documento escrito no se encuentra a disposición de todo el mundo y para
poder ser utilizado por el usuario, se cuenta con un link o enlace y no con el contenido.
Ejemplo de cerrado, es aquel que se compra (enlatado), el proveedor nos vende un
link o enlace, porque de ese modo se queda en su poder el documento escrito y de
esa manera se reserva el derecho o posibilidad, de que cuando hay que hacer alguna
modificación al sistema, lo pueda realizar solamente el, con el costo respectivo. Se
asegura la continuidad comercial del sistema. Luego, por el contrario, si el formato es
abierto contamos con el documento escrito de esa manera estamos en condiciones
de hacerle mantenimiento, o sea modificar aquello que fuera necesario.
¿Cuál es el objetivo del mantenimiento? Evitar la Entropía : La entropía respecto de
los recursos técnicos se trata de la obsolescencia prematura, mientras que en lo que
hace al sistema, es el envejecimiento prematuro. El objetivo concreto en cuanto a
evitar la entropía, es mantener operativo el sistema y los recursos operativos.
El plan de mantenimiento tecnológico lo plantea, lo presenta y lo ejecuta el ingeniero
en tecnología.
El plan de mantenimiento del sistema, lo plantea y presenta el líder y lo ejecuta el
programador.

• Desarrollo (Etapa). el protagonista de esta etapa es el programador, quien se encarga de

desarrollar los programas o las aplicaciones que conforman el sistema a partir del diseño
global, o bien sobre la base del diseño global. Técnicamente el programador desarrolla el
diseño global y lo convierte en diseño detallado. Convierte el dibujo o bosquejo en programas
o aplicaciones (los que conformarán el sistema). Las herramientas que utiliza el programador
para desarrollar los programas o aplicaciones son, su lógica personal (dado que cada ser
humano posee su propia lógica) y el lenguaje (idioma). Históricamente el lenguaje en general
no eran todos compatibles con las computadoras vigentes en esa época, con lo cual había
que seleccionar el idioma acorde con la computadora en la cual sería utilizado el sistema. En
la actualidad existe una amplia variedad de computadoras, todas con amplia compatibilidad
 8

en particular en materia de lenguajes, pero a pesar de ello, aún se seleccionan los lenguajes
que serán utilizados para cumplir con la tarea de desarrollar los programas o aplicaciones.
Son dos motivos :
a. es la practicidad en cuanto al desarrollo de las aplicaciones o programas
b. una vez desarrollado el programa y puesto a funcionar, se opta por los
lenguajes que proveen mayor velocidad de procesamiento

• Implementación. dos condiciones para considerar que el sistema le fue entregado al usuario
para que lo utilice :

I. Prueba. El sistema debe ser entregado al usuario probado (el usuario no debe probar).

Quiénes prueban y qué pruebas realizan ?

1) Prueba el programador realiza la prueba de escritorio o manual, utilizando los

papeles de trabajo, 2) luego el ingeniero en tecnología instala y prueba la tecnología,
3) a continuación el programador realizar la prueba funcional, utilizando la tecnología
y 4) por último el líder prueba todo.
El usuario puede acompañar/presenciar las pruebas y puede realizar alguna prueba
que no es obligatoria, es por su cuenta : la prueba de aceptación a través de la cual
el usuario certifica o intenta certificar, que el sistema funciona cumpliendo con el
requerimiento. El objetivo de la prueba : Evitar la “Brecha de Credibilidad” (Cuando
una persona no es confiable por diferentes motivos, en este caso la situación se puede
presentar cuando no haya probado convenientemente el sistema (una vez
desarrollado), luego el usuario lo pone en funcionamiento y se observa que no cumple
con las expectativas previas. No hay retorno, es un tema irreversible, de allí que la
prueba intenta evitar esta situación.

II. Documentación. está conformada por 4 Manuales :

1) manual con las normas de estructura,
2) manual con las normas de procedimiento
3) manual del sistema,
4) manual del usuario.

El Manual del Sistema contiene la vida del proyecto, incluyendo el análisis preliminar.
O sea, desde el Análisis Preliminar hasta la Implementación.
El Manual del Usuario contiene todo lo necesario como para que el usuario pueda
utilizar el sistema prescindiendo de nuestra presencia. Tres consideraciones :
i. se evita la dependencia
ii. no se obliga de modo alguno, que el usuario tenga que recurrir a la
capacitación (se parte de la base que la capacitación no es obligatoria).
iii. quien se encarga de esta documentación es el analista documentador
y se entrega con copia.

7. Implementación. Es una etapa que responde a una entrega formal del sistema al usuario para que lo
utilice. Esto significa que el sistema debió haber sido sometido a las pruebas correspondientes, para
certificar el cumplimiento con el requerimiento, evitando de ese modo la brecha de credibilidad.
Hay tipos de implementación (la característica común de los tipos de implementación es que algo se
particiona), y las formas de implementación.
 9

Tipos de Implementación : Modular : lo que se particiona es el sistema por una faltante o restricción
de recursos. Lo que hace que el sistema se vaya desarrollando, probando e implementando en
módulos. Por ejemplo: primero módulo de compras se desarrolla, se prueba y se implementa, y así
sucesivamente con los siguientes módulos. Se lleva a cabo a través de módulos, porque no se cuenta
con los recursos necesarios para poder hacerlo en forma integral.

Implementación en Fases. Se particiona la organización por una cuestión de ubicación geográfica de

los diferentes Sectores, Departamentos o Unidades de la Organización (Descentralizada).

Las formas de implementación son paralela : La condición para implementar en paralelo, es contar
con un sistema en producción (o sea vigente), con el cual el nuevo sistema deberá convivir durante
un determinado tiempo. La decisión de implementar de una forma u otra es patrimonio del usuario,
como también el tiempo que ambos sistemas deberán convivir en caso de ser paralela. El motivo de
la convivencia, y el tiempo a convivir, lo pauta el usuario, para lograr comparar el rendimiento del
nuevo sistema con relación al viejo.
directa : no tiene condicionamiento alguno. En el caso que exista un sistema anterior, cuando se
implementa el sistema nuevo, se desactiva o discontinúa automáticamente el viejo, y en el caso que
no exista un sistema anterior, entonces se implementa el nuevo directamente y continua con su
funcionamiento.

8. Capacitación. no es una etapa obligatoria para el usuario, pero si para nosotros en el caso que el
usuario la solicite (aun habiendo recibido la documentación). En el caso de que la solicite deberá
además aclarar, a qué niveles alcanza y cuál debería ser el contenido de la capacitación, es decir, a
cuál de los manuales se debe recurrir para llevarla a cabo. En caso de existir la capacitación, la
misma debe consistir solo en explicar el contenido de los manuales. Existen varias formas de
capacitación, pero nos vamos a centrar en las siguientes :
− Tutorial.
− En grupos.
La base sobre la cual se opta para llevar a cabo una determinada capacitación, son el presupuesto
disponible y el tiempo que será utilizado para concretarla. Tener en cuenta que la Capacitación
Tutorial es la más cara y lleva más tiempo para realizarse. O sea, que en el caso de no contar con
alguno de esos 2 factores, entonces deberá llevarse a cabo en Grupos o Grupal.

9. Mantenimiento. Si bien el proyecto termina con la implementación, la última etapa de la metodología

es el mantenimiento. Etapa que responde en forma directa al plan o a los planes presentados en la
propuesta del sistema según se trate. El mantenimiento del sistema es solo procedente cuando
estamos en presencia de un sistema con formato abierto. El mantenimiento tecnológico quién lo
plantea, presenta y ejecuta es el ingeniero en tecnología. En cuanto al mantenimiento del sistema,
quien lo plantea y presenta el plan es el líder, y quien lo ejecuta es el programador. Los tipos de
mantenimiento, partiendo de la base que el mantenimiento desde el punto de vista conceptual es
eminentemente correctivo, y puede llegar a responder a los siguientes tipos de mantenimiento:
− Preventivo. Responde a cuestiones basadas en la experiencia.
− Predictivo. Basada en cuestiones presente que hacen a la utilización del sistema.
− Evolutivo. Basada en cuestiones imaginarias o hipotéticas.
10