Unidad 2

Desarrollo y
mantenimiento de
sistemas de
información

Sistemas de Información II
 Página 1 de 24

Introducción .......................................................................................................................................2
1. Realización de beneficios ..............................................................................................................3
1.1. Gestión de proyectos informáticos ................................................................................................5
2. Estructura de la gestión de proyectos........................................................................................... 10
3. Desarrollo de aplicaciones de negocios ........................................................................................ 13
4. Sistemas integrados de gestión (ERP) ........................................................................................... 17
4.1. ¿Qué son los sistemas ERP? ........................................................................................................ 17
4.2. Metodología de desarrollo de software ........................................................................................ 19
Conclusión........................................................................................................................................ 23
Referencias bibliográficas................................................................................................................... 24
 Página 2 de 20

Introducción

Los sistemas de información en la actualidad

pueden ser tanto desarrollados por una
entidad, como implementados a partir de la
adquisición de un paquete de software
preconfigurado. En las últimas tres décadas
en el mundo entidades de diversos sectores
o industrias, han ido sumándose a la decisión
de implementar paquetes preconfigurados
de sistemas aplicativos y es así como se ha
ido potenciando la adquisición e implementación de sistemas del tipo ERP (Enterprise
Resource Planning) o sistemas integrados de gestión.

La particularidad que tienen los sistemas ERP es que, al venir preconfigurados de acuerdo a
buenas prácticas de procesos, posibilita el hecho que las entidades puedan adaptar sus
procesos a estos estándares y así, maximizar el uso de los sistemas ERP incorporando mayor
eficiencia en sus procesos u operaciones. Otros ejemplos de este tipo de sistemas son los
CRM (Customer Relationship Management), que permiten potenciar y fidelizar la relación
con los clientes en un marco de gestión de marketing y de negocioización.

Ahora bien, respecto a los primeros sistemas que he hecho mención, es decir, los sistemas
desarrollados desde cero en las entidades, alrededor de hace tres a cuatro décadas atrás,
era lo que hacían las entidades, por lo que tenían que contar con equipos de tecnologías de
la información en las áreas de informática numerosos y con el consiguiente costo que
siempre tiende a ser más alto, desde el punto de vista del diseño, construcción, puesta en
operación y mantención con mejora continua.

En este contexto, en la presente unidad abordaremos estas temáticas desde una perspectiva
de gestión y del conocimiento que debe tener un profesional contador público y auditor,
considerando que estos sistemas poseen programados o configurados controles que son
susceptibles de identificar y monitorear continuamente en un marco de modelo de control
interno de las tecnologías de información o de sistemas.
 Página 3 de 20

1. Realización de beneficios
La realización de beneficios se refiere al hecho que los sistemas de información en las
entidades, siempre se deben adquirir o desarrollar alineado con las intenciones definidas en el
gobierno de las tecnologías de la información, tal como se abordó en la Unidad 1, por lo que es
importante que las áreas de tecnología, que son prestadoras de servicio en materia de TI,
siempre tomen decisiones en este ámbito alineadas con la estrategia de la entidad.

Figura 01: Opciones de sistemas de información

Sistema
desarrollado
a la medida

Sistemas de
Información

Sistema
adquirido y
configurado

Fuente: Elaboración propia

Es importante distinguir que, en materia de desarrollo y mantenimiento de sistemas de

información, se pueden dar las siguientes opciones:

Sistema de información programado y/o desarrollado a la medida

Estos sistemas son programados a partir de especificaciones funcionales
que entregan los usuarios finales, lo cual es modelado por arquitectos
Opción 1
de sistema y entregados a un programador para que lo desarrolle en
algún lenguaje computacional. A esto se le denomina también
desarrollo desde cero y a la medida.

Sistema de información adquirido preconfigurado e implementado a

la medida
Estos sistemas son adquiridos preconfigurados a un proveedor de
Opción 2
software y las licencias las de negocioizan de forma perpetua u on
demand. Las licencias perpetuas son por usuarios e incluyen el soporte
y mantenimiento del sistema. Los servicios on demand, se entregan en
 Página 4 de 20

una modalidad denominado SaaS o software as a service y se paga un

fee de arrendamiento mensual, lo cual también incluye el soporte y
mantenimiento del sistema y se paga en función de la cantidad de
licencias que posea o que necesite la entidad.

En este marco, siempre antes de tomar una decisión relativa a adquisición o desarrollo de
software, se debe considerar factores como:

• Costo
• Beneficio
• Desarrollo/Tiempo entrega
• Confiabilidad
• Calidad
• Dependencia entre estos factores

Lo anterior a fin de determinar el retorno sobre la inversión (ROI) que tendrá el hecho de llevar
a cabo un sistema de información determinado.

Costo: Esta relacionado con el hecho de que la inversión financiera que se realice para
desarrollar o implementar un paquete preconfigurado de sistema de información, debe ser
razonable y acorde al beneficio que reportará a la entidad en miras con la estrategia.

Beneficio: Desde la perspectiva de que el sistema de información debe contribuir al incremento

de valor de la entidad y alineado con las definiciones estratégicas.

Desarrollo/Tiempo entrega: Los sistemas de información ya sean desarrollados o configurados,

suelen demorar un tiempo determinado en estar listos para su uso, puesto que se deben
planificar, diseñar, construir/configurar, probar y luego ponerlos en operación, por lo que
desde la perspectiva de proyecto, se debe tomar en consideración el factor tiempo entrega
óptimo donde la gestión del proyecto y seguimientos de la misma, será fundamental.

Confiabilidad: El sistema de información ya sea desarrollado o configurado, debe cumplir con

las expectativas de usabilidad y funcionalidad que esperan los usuarios finales, a fin de que se
oriente a los objetivos para lo cual fue adquirido.

Calidad: El sistema de información debe cumplir con las expectativas funcionales que se
consideraron para la decisión en relación con la prestación, sea cualquiera de las opciones que
la entidad haya asumido para su puesta en operación.

Dependencia entre estos factores: Los factores antes descritos tienen dependencia entre ellos,
puesto que por ejemplo para que el sistema de información sea confiable, debe cumplir ciertos
 Página 5 de 20

requisitos de calidad y para que la entrega sea en tiempo, debe cumplirse con un equipo de
desarrolladores o ingenieros informáticos de calidad y que dominen los aspectos tanto
tecnológicos como funcionales para el éxito del proyecto y que dichas variables lleven a la
realización del beneficio y en el costo esperado.

1.1. Gestión de proyectos informáticos

La gestión de proyectos de TI es el proceso de planificación, organización y delimitación de
responsabilidades para la consecución de los objetivos específicos de tecnología de la
información (TI) de una organización.

La gestión de proyectos de TI incluye la supervisión de proyectos de desarrollo de software,

instalaciones de hardware, actualizaciones de red, implementaciones de computación en la
nube y virtualización, proyectos de gestión de datos y análisis empresarial e implementación de
servicios de TI.

Además, de los problemas normales que pueden provocar el fracaso de un proyecto, los
factores que pueden afectar negativamente el éxito de un proyecto de TI incluyen avances
tecnológicos durante la ejecución del proyecto, cambios en la infraestructura que afectan la
seguridad y la gestión de datos y relaciones dependientes desconocidas entre hardware,
software, infraestructura de red y datos. Los proyectos de TI también pueden sucumbir a la
penalización por primer uso, que representa el riesgo total que asume una organización al
implementar una nueva tecnología por primera vez. Debido a que la tecnología no se ha
implementado ni utilizado antes en la organización, es probable que haya complicaciones que
afectarán la probabilidad de éxito del proyecto.

1.1.1. Gestionar el proyecto

Estos cinco grupos de procesos comprenden el ciclo de vida de la gestión de proyectos y son
universales para todos los proyectos. Las fases específicas dentro de un proyecto, sin embargo,
son únicas para cada proyecto y representan el ciclo de vida del proyecto.
 Página 6 de 20

Figura 02: Ciclo de vida de la gestión de proyectos

Iniciación Planificación Ejecución

Monitoreo y
Cierre
control

Fuente: Elaboración propia

Iniciación: se identifica la meta, la necesidad o el problema del proyecto. El director del

proyecto se asigna al proyecto y se crea el acta de constitución del proyecto.

Planificación: el gerente del proyecto y el equipo del proyecto trabajan juntos para planificar
todos los pasos necesarios para llegar a una conclusión exitosa del proyecto. Los procesos de
planificación del proyecto son de naturaleza iterativa y se espera que la planificación ocurra
con frecuencia a lo largo del proyecto.

Ejecución: una vez que se ha creado el plan del proyecto, el equipo del proyecto se dedica a
ejecutar el plan del proyecto para crear los entregables del proyecto. El proyecto puede pasar a
la planificación del proyecto según sea necesario durante la ejecución del proyecto.

Monitoreo y control: a medida que el proyecto está siendo ejecutado por el equipo del
proyecto, el gerente del proyecto monitorea y controla el trabajo en cuanto a tiempo, costo,
alcance, calidad, riesgo y otros factores del proyecto. El seguimiento y el control también son
un proceso continuo para garantizar que el proyecto aborde sus objetivos para cada objetivo
del proyecto.

Cierre: al final de cada fase y al final de todo el proyecto, se produce el cierre del proyecto para
garantizar que todo el trabajo se haya completado, se apruebe y, en última instancia, se
transfiera la propiedad del equipo del proyecto a las operaciones.

1.1.2. Gestión de las áreas de conocimiento del proyecto

Hay diez áreas de conocimiento de gestión de proyectos. Estas diez áreas de conocimiento
segmentan diferentes acciones realizadas por el director del proyecto a lo largo del proyecto.
Las diez áreas de conocimiento de la gestión de proyectos son:

1. Gestión del alcance del proyecto: se define, documenta y aprueba el alcance del
proyecto. El alcance del proyecto está protegido contra cambios no autorizados,
editado con cambios aprobados y validado por las partes interesadas del proyecto para
su aceptación.
 Página 7 de 20

2. Gestión del cronograma del proyecto: el cronograma del proyecto se define primero
por las horas de trabajo del proyecto, los hitos del proyecto y, en última instancia, la
fecha límite del proyecto. La disponibilidad del equipo del proyecto a lo largo del
proyecto se documenta y planifica en consecuencia. El gerente del proyecto trabajará
con el equipo del proyecto para identificar las tareas del proyecto y las estimaciones de
duración de las tareas para crear un cronograma del proyecto.

3. Gestión de costes del proyecto: se estiman los costes del proyecto para poder asignar
un presupuesto al mismo. Los costos del proyecto incluyen materiales, servicios,
instalaciones, licencias de software y otros gastos atribuidos directamente al proyecto.

4. Gestión de la calidad del proyecto: lo que constituye la calidad en el proyecto se define

en métricas específicas y se acuerda entre las partes interesadas tan pronto como sea
posible en el proyecto. Los programas y políticas de garantía de calidad dirigen el
trabajo del proyecto, mientras que el control de calidad inspecciona el trabajo del
proyecto para confirmar que se ha determinado la calidad en el trabajo.

5. Gestión de recursos humanos del proyecto: el director del proyecto trabaja con el
equipo del proyecto para verificar que cada miembro del equipo esté completando sus
tareas, trabajando bien con los demás y que su participación y desempeño se informe a
sus respectivos directores.

6. Gestión de las comunicaciones del proyecto: las partes interesadas necesitarán

información del director del proyecto y deberán proporcionar información al director
del proyecto a lo largo del ciclo de vida del proyecto. Esta área de conocimiento crea un
plan de gestión de comunicaciones que aborda quién necesitará qué información,
cuándo se necesita la información y la mejor modalidad para las comunicaciones.

7. Gestión de riesgos del proyecto: los riesgos son situaciones, eventos, condiciones que
pueden amenazar y, en ocasiones, beneficiar los objetivos del proyecto de TI. Los
riesgos deben identificarse, analizarse y crearse una respuesta para el evento de riesgo.
La probabilidad y el impacto de cada evento de riesgo se evalúan para crear una
puntuación de riesgo que justifique los costos necesarios para gestionar el evento de
riesgo.

8. Gestión de adquisiciones del proyecto: si el proyecto necesita comprar bienes o

servicios, será necesario crear un proceso formal para la adquisición. El plan debe
abordar la selección del tipo de contrato del proyecto, la administración del contrato,
las auditorías de compra y el cierre del contrato. Muchos gerentes de proyecto no
administran las adquisiciones, sino que se remiten al departamento y los procesos
centralizados de adquisiciones o compras de la organización.
 Página 8 de 20

9. Gestión de las partes interesadas del proyecto: las partes interesadas son cualquier
persona que tenga un interés personal en el proyecto. La gestión de stakeholders es la
identificación, inclusión y comunicación con los grupos de stakeholders del proyecto.
Maneja las ansiedades y preocupaciones que los interesados pueden tener sobre el
trabajo del proyecto.

10. Gestión de integración de proyectos: esta área especial de conocimiento es la

coordinación de los eventos en todas las demás áreas de conocimiento. El desempeño
del gerente de proyecto en un conocimiento afecta directamente el desempeño de las
otras áreas de conocimiento. La gestión de integración de proyectos examina las
interacciones y contingencias entre las áreas de conocimiento para garantizar que el
proyecto se planifique, ejecute, controle y cierre adecuadamente.

Estas diez áreas de conocimiento se gestionarán de forma iterativa a lo largo del proyecto. Con
la excepción de las adquisiciones, un gerente de proyecto probablemente encontrará estas diez
áreas de conocimiento en cada proyecto. No hay un orden establecido en el que se deben
administrar las áreas, sino que el gerente del proyecto cambia a los conocimientos y procesos
apropiados en función de lo que está ocurriendo dentro del proyecto.

1.1.3. Ciclo de vida del proyecto de TI

Hay varios enfoques diferentes para administrar un proyecto de TI que afectan el ciclo de vida
del proyecto. Las organizaciones pueden seleccionar uno de estos enfoques populares para
ayudar a reducir el riesgo de reelaboración costosa, los riesgos de la tecnología que cambia
rápidamente o la planificación expansiva en el lanzamiento del proyecto. El ciclo de vida del
proyecto de un proyecto de TI típico se mueve a través de iteraciones de planificación,
ejecución y control hasta que el proyecto finalmente se cierra y se transfiere a operaciones. Sin
embargo, hay tres ciclos de vida de gestión de proyectos de TI distintos:

Ciclo de vida predictivo: este es el ciclo de vida del proyecto más común
y tradicional para proyectos de TI. En este enfoque, el gerente del
proyecto y el equipo del proyecto primero definen el alcance del
proyecto, el cronograma del proyecto y los costos esperados del
proyecto antes de que comience la ejecución del proyecto. Como parte
de la planificación del proyecto, es típico que se definan las fases del
proyecto (cada fase realiza un tipo específico de trabajo del proyecto).
Para que el proyecto avance desde su inicio hasta su cierre, cada fase
debe comenzar y completarse en el orden específico según lo planeado.
Este tipo de enfoque a veces se denomina enfoque en cascada ya que el
proyecto "cae en cascada" a lo largo de las fases del proyecto.
 Página 9 de 20

Ciclo de vida iterativo: este enfoque de la gestión de proyectos de TI

requiere que la gestión del proyecto se defina al principio del proyecto,
pero las estimaciones de costos y la estimación de la duración de la
actividad se planifican a un nivel superior al principio del proyecto. A
medida que ocurre la ejecución del proyecto, se crean costos y
estimaciones de duración para el trabajo más inminente a través de
iteraciones de planificación. El ciclo de vida iterativo también planifica
iteraciones de beneficios liberados para la organización. Por ejemplo, un
ciclo de vida iterativo puede crear un nuevo software con más funciones
con cada nueva versión como parte del proyecto.

Ciclo de vida adaptativo: este ciclo de vida del proyecto también utiliza
una iteración de planificación y ejecución, pero la planificación suele
durar dos semanas. Este enfoque utiliza una ola continua de planificación
y ejecución a través de breves ráfagas tanto de planificación como de
ejecución. Se espera un cambio en este enfoque del proyecto de TI y es
ideal para el proyecto de desarrollo de software. La gestión ágil de
proyectos y Scrum son ejemplos del ciclo de vida adaptativo.

Todos estos ciclos de vida utilizan el concepto de fases para hacer avanzar el trabajo del
proyecto. Una fase describe el tipo de trabajo que tendrá lugar en esa parte del proyecto. El
director del proyecto, los requisitos de la organización e incluso los requisitos del cliente
pueden influir en qué tipo de ciclo de vida del proyecto adaptará el director del proyecto en el
proyecto.

Figura 03: Ciclo de vida de la gestión de proyectos

Objetivo: Exitosa ejecución de

los proyectos

Comunicación
Alcance del Finanzas del Cronograma Ambiente del Organización
y cultura del
proyecto proyecto del proyecto proyecto proyecto del proyecto

Fuente: Elaboración propia

El ciclo de vida de la gestión de proyectos contempla desde el alcance hasta la organización del
mismo, pasando por el financiamiento, cronograma, ambiente de ejecución y comunicación,
factores que deben ser gestionados adecuadamente para alcanzar el éxito. Estos seis aspectos
que se mencionan en la Figura 03 están de una u otra forma implícitos en la gestión de las
áreas de conocimiento del proyecto descritas anteriormente.
 Página 10 de 20

Figura 04: Gestión de carteras, programas y portafolios de proyectos

Gestión de
carteras/programas Optimizar los
(Portafolios) resultados

Transferir Objetivos de Aprobación

conocimiento la gestión Priorizar y del BC ROI
de un calendarizar
proyecto a cartera de los proyectos Business
otro proyectos Case

Coordinar
recursos
Internos /
Externos

Fuente: Elaboración propia

2. Estructura de la gestión de proyectos

Una organización de proyecto es una estructura que facilita la coordinación e implementación
de las actividades del proyecto. Su razón principal es crear un entorno que fomente las
interacciones entre los miembros del equipo con una cantidad mínima de interrupciones,
superposiciones y conflictos. Una de las decisiones importantes de la gestión de proyectos es la
forma de estructura organizativa que se utilizará para el proyecto.

Cada proyecto tiene sus características únicas y el diseño de una estructura organizacional
debe considerar el entorno organizacional, las características del proyecto en el que operará y
el nivel de autoridad que se otorga al gerente del proyecto. La estructura de un proyecto puede
tomar varias formas y cada forma tiene sus propias ventajas y desventajas.

Uno de los principales objetivos de la estructura es reducir la incertidumbre y la confusión que

suele ocurrir en la fase de inicio del proyecto. La estructura define las relaciones entre los
miembros de la dirección del proyecto y las relaciones con el entorno externo. La estructura
define la autoridad por medio de una ilustración gráfica llamada organigrama.

Un organigrama del proyecto correctamente diseñado es esencial para el éxito del proyecto.
Un organigrama muestra dónde se ubica cada persona en la estructura del proyecto. Se dibuja
un organigrama en forma de pirámide donde las personas ubicadas más cerca de la parte
superior de la pirámide tienen más autoridad y responsabilidad que los miembros ubicados en
la parte inferior. Son las ubicaciones relativas de las personas en el organigrama las que
 Página 11 de 20

especifican las relaciones de trabajo, y las líneas que conectan las casillas designan la
supervisión formal y las líneas de comunicación entre las personas.

Figura 05: Las estructuras de gestión de proyectos

Gerente de
Proyecto

Jefe de Oficina Ges tión de

de Gestión de Ri esgos de
Proyecto Proyecto

Frente de
Ges tión del
Ca mbi o

Frente de Diseño Frente de

Frente de Frente de Frentes
o a rquitectura Des arrollo o Frente de Datos
Impl ementación Pruebas Funci onales
de s oftware progra mación

Fuente: Elaboración propia

La estructura de proyecto antes descrita, representa un estándar de organización para el

desarrollo o implementación de un sistema de información y como se puede apreciar,
contempla una oficina (Project Management Office) u oficina de gestión de proyectos, que
debe tener el control de todas las actividades, seguimientos continuos e incluso la gestión de
riesgos de este, que es primordial para alcanzar el éxito.

Crear la estructura es solo una parte de la organización del proyecto; es la implementación y l a

aplicación real lo que requiere el mayor esfuerzo. El organigrama del proyecto establece las
relaciones formales entre el director del proyecto, los miembros del equipo del proyecto, la
organización de desarrollo, el proyecto, los beneficiarios y otras partes interesadas del
proyecto. Esta organización debe facilitar una interacción e integración efectiva entre todos los
participantes principales del proyecto y lograr una comunicación abierta y efectiva entre ellos.

El director o gerente del proyecto debe crear una estructura de proyecto que satisfaga las
diversas necesidades en las diferentes fases de este. La estructura no puede diseñarse
demasiado rígida o flexible, ya que el propósito de la organización del proyecto es facilitar la
interacción de las personas para lograr los objetivos finales del proyecto dentro de las
restricciones especificadas de alcance, cronograma, presupuesto y calidad. El objetivo de
diseñar una estructura de proyecto es proporcionar un entorno formal que el director del
proyecto pueda utilizar para influir en los miembros del equipo para que hagan lo mejor posible
para completar su asignación y sus funciones. La estructura debe diseñarse para ayudar a
desarrollar la colaboración entre los miembros individuales del equipo; todo de una manera
rentable con un mínimo de duplicación de esfuerzos y superposiciones.
 Página 12 de 20

El organigrama tiene una funcionalidad limitada; solo muestra la relación jerárquica entre los
miembros del equipo, pero no muestra cómo funcionará la organización del proyecto, es por
ello que el diseño debe considerar factores que facilitarán el funcionamiento de la estructura;
estos incluyen comunicaciones, flujos de información, coordinación y colaboración entre sus
miembros.

2.1. Factores en el diseño de la estructura de un proyecto

Hay dos factores de diseño que influyen significativamente en el proceso de desarrollo de una
estructura de gestión de proyectos. Estos son el nivel de especialización y la necesidad de
coordinación. El gerente del proyecto debe considerar estos factores al momento de diseñar la
organización del proyecto para maximizar la efectividad de la estructura.

La especialización afecta la estructura del proyecto por el grado de

especialidad en áreas técnicas o enfoque de desarrollo; los proyectos
pueden ser altamente especializados y centrarse en un área específica
de desarrollo, o tener diferentes especializaciones amplias en muchas
áreas de desarrollo. Para proyectos grandes que tienen múltiples
especializaciones o áreas técnicas, cada área puede tener una
necesidad diferente; de las diferencias en objetivos, enfoques y
metodologías, todo lo cual influye en la forma en que el proyecto implementará sus
actividades. Un proyecto que tiene dos componentes, reconstrucción y educación, necesitará
manejar diferentes enfoques en función de la especialización de cada uno. En el componente
educativo, se necesita una estructura más abierta e informal, donde el horizonte temporal sea
más largo, con mayor énfasis en compartir y generar nuevas ideas para lograr la innovación y la
creatividad. En un componente de reconstrucción, hay objetivos específicos, una necesidad de
una estructura rígida y jerárquica, y hay un horizonte de tiempo definido con poco intercambio
de ideas. Si bien la especialización permite que cada componente del proyecto maximice su
productividad para lograr sus objetivos departamentales, las diferencias pueden generar
conflictos entre los miembros o líderes de cada componente. En general, cuanto mayores son
las diferencias, más problemas tienen los gerentes de proyectos para lograr que trabajen
juntos.

La coordinación es necesaria para dar unidad a los diversos elementos

que componen un proyecto. El trabajo del proyecto se organiza en
torno a una estructura de desglose del trabajo (EDT) que divide los
objetivos generales del proyecto en actividades o tareas específicas
para cada área o componente del proyecto; el director del proyecto
debe diseñar una estructura organizativa que asegure que los diversos
 Página 13 de 20

componentes estén integrados para que sus esfuerzos contribuyan a la meta general del
proyecto. La integración es el grado de colaboración y entendimiento mutuo requerido entre
los diversos componentes del proyecto para lograr las metas del proyecto. La mayoría de los
proyectos se caracterizan por la división del trabajo y la interdependencia de tareas, lo que crea
la necesidad de integración para cumplir con los objetivos del proyecto. Esta necesidad es
mayor cuando hay muchos componentes del proyecto que tienen diferentes especializaciones.
El objetivo de la estructura de gestión de proyectos es el logro de la armonía de los esfuerzos
individuales hacia el logro de los objetivos del grupo. La responsabilidad principal del director
del proyecto es desarrollar estrategias de integración para asegurar que un componente o
actividad en particular se organice de manera que todos los componentes, partes, subsistemas
y unidades organizacionales encajen como un todo funcional e integrado de acuerdo con el
plan maestro del proyecto.

3. Desarrollo de aplicaciones de negocios

Una aplicación de negocio es un programa de software o una colección de aplicaciones que
realizan diversas funciones de una entidad. Algunas de estas aplicaciones se utilizan para
mejorar y realizar un seguimiento de la productividad en toda la entidad, mientras que otras se
utilizan para registrar y procesar datos de gran tamaño. El desarrollo de estas aplicaciones de
software se conoce como desarrollo de aplicaciones de negocio. Como cualquier proceso de
desarrollo de software, el desarrollo de aplicaciones de negocio también pasa por el ciclo de
vida de 4 etapas: planificación, desarrollo, prueba e implementación. Al seguir estas prácticas
recomendadas para el desarrollo de aplicaciones de negocio, un equipo de desarrollo de
software puede garantizar un tiempo razonable y una entrega de calidad.

Figura 06: Ciclo de vida básico de desarrollo o implementación de sistemas de información

Implementación Planificación

Prueba Desarrollo

Fuente: Elaboración propia

 Página 14 de 20

Las aplicaciones desarrolladas, deben estar orientadas a:

• Automatizar tanto como sea posible.

• Garantice la máxima seguridad durante todo el proceso.
• Garantice la colaboración entre los equipos de ingeniería y de negocios.
• Proporcionar las mejores herramientas y establecer los mejores procesos para el
equipo.
• Establezca las expectativas correctas en términos de calidad y tiempo.
• Mantenga todas las versiones organizadas.
• Pruebe siempre la escalabilidad del producto final.
• Asóciese con una empresa experimentada con experiencia relevante en desarrollo
de software.

Al respecto también se puede mencionar otro ciclo de vida de desarrollo o implementación de

sistemas de información, que considera seis fases:

Fase 1: De estudio de factibilidad, la cual nace a partir de las necesidades de los usuarios finales
de una entidad y que luego en la medida que se da luz verde o aprobación por parte de la alta
dirección e incluso en ciertas situaciones, debe contar con la aprobación de un Directorio, en la
medida que la inversión sea por un monto significativo, como, por ejemplo, la adquisición de
un sistema de clase mundial ERP.

Fase 2: Cuando se pasa a la fase de definición de requerimientos, se debe hacer partícipe a los
usuarios claves que representan a los usuarios finales, a fin de que proporcionen las
especificaciones técnicas o funcionales de la forma más precisa posible, donde debe trabajar
mancomunadamente con los equipos de implementadores o desarrolladores, según sea el el
tipo de desarrollo o implementación que se esté realizando.

Fase 3: Esta fase contempla la selección y adquisición del software (Sistemas adquiridos o
Diseño-Desarrollo), lo cual ha pasado por una serie de estudios, análisis cualitativos
(funcionales) y cuantitativos (financieros), para seleccionar la opción más viable y que conlleve
al mejor ROI o retorno sobre la inversión para la entidad, tal como se menciona anteriormente.
Cabe señalar, que cuando se menciona el aspecto “funcional”, se refiere a que cumpla con las
especificaciones de procesos, a fin de que se pueda transaccionar de forma óptima por medio
del sistema de información.

Fase 4: Contempla la construcción, programación o configuración del sistema de información

propiamente tal, considerando las especificaciones o insumos emanados de las fases
anteriores, lo cual debe venir claramente depurado y validado por los usuarios claves o key
 Página 15 de 20

users, que son los responsables de validar en representación de los usuarios finales. Es
importante tener en consideración que cuando se hace referencia a usuarios finales, se refiere
a los usuarios que transaccionan en los procesos, como, por ejemplo: bodegueros, contadores,
compradores, secretarias, gerentes, vendedores, etc.

Fase 5: Se lleva a cabo las pruebas tanto unitarias como integrales del sistema de información a
fin de asegurarse que todas las funcionalidades desarrolladas o configuradas, operen en
optimas condiciones y hagan lo que deben hacer, en forma exacta, valida y completa, es decir,
en forma íntegra. Las pruebas unitarias son ejecutadas por los consultores implementadores en
un ambiente de desarrollo de sistemas y las pruebas integrales, son ejecutadas por los usuarios
claves en conjunto con los consultores, donde se verifica la funcionalidad end to end, es decir,
con trazabilidades de extremo a extremo de una transacción o inicio a fin, asegurándose que
todo funcione de forma íntegra.

Asimismo, en esta fase se pone en operación o se realiza la salida en vivo o productivo como se
le denomina en jerga informática. Esta fase debe ser debidamente coordinada y monitoreada.
Se debe realizar salvaguardando aspectos de gestión del cambio, es decir, que los usuarios
finales estén debidamente capacitados, informados y que las comunicaciones abarquen a todo
el espectro organizacional que se verá tocado con el nuevo sistema que se comenzará a utiliza.
Las capacitaciones o entrenamiento son parte de los factores claves de éxito, al igual que las
pruebas, por lo que la PMO se debe asegurar que todos estos aspectos estén debidamente
coordinados y alineados.

Fase 6: En esta fase una vez que se cumple lo anterior, se procede a monitorear la puesta en
operación y se presta el soporte pertinente, a fin de que en caso de que algún usuario tenga
algún inconveniente, este sea resuelto de forma oportuna, de acuerdo con los niveles de
servicio que se hayan establecido para tal cometido. Esto último, es coordinado por una mesa
de soporte o help desk, que debe estar atenta a los requerimientos emanados de los usuarios
finales y se debe dejar trazabilidad y llevar a cabo un control de gestión de los tickets de
soporte que se van generando sistemáticamente, a fin de asegurarse que no existan
requerimientos que no hayan sido resueltos, porque se podría materializar un riesgo que suele
ser frecuente en algunas implementaciones, relacionado con la disconformidad de los usuarios
con el sistema, que suele también sumarse con la resistencia al cambio, riesgos que deben ser
gestionados y mitigados de forma oportuna.
 Página 16 de 20

Figura 07: Ciclo de vida estándar de desarrollo o implementación de sistemas de información

Fase 3:
Selección y Fase 6:
Fase 1: Fase 2: Adquisición del Fase 4: Fase 5:
Software Posterior a la
Estudio de Definición de Desarrollo o Prueba Final e
Requerimientos (Sistemas Configuración implementación
Factibilidad Implementación
adquiridos o
Diseño-
Desarrollo)

Fuente: Elaboración propia

A continuación, se presenta el road map estándar que utiliza SAP en las implementaciones de
dicho sistema ERP, el cual considera todas las fases que se han mencionado anteriormente:

Figura 08: Roadmap de implementación de SAP ERP

Fuente: SAP AG (2001)

 Página 17 de 20

4. Sistemas integrados de gestión (ERP)

4.1. ¿Qué son los sistemas ERP?
Son sistemas de información que integran en tiempo real las transacciones realizadas por los
usuarios en los distintos procesos de una entidad, por lo que pueden llegar a cubrir los
procesos de una entidad de extremo a extremo, dependiendo si se trata de un ERP de clase
mundial o no.

Los sistemas ERP de clase mundial, tienden a dar cobertura de extremo a extremo de los
procesos de una entidad e incluso actualmente existen ERP que cubren verticales
especializadas de industrias o sectores como, por ejemplo: Salud, Minería, Educación, Retail,
Consumo Masivo, Telecomunicaciones, Bancos, etc.

Los sistemas ERP de clase mundial que están dentro de los tres más preferidos por las grandes
entidades en el mundo son:

1. SAP
2. Oracle Financials
3. Microsoft Dynamics

Tabla 01: Tres sistemas ERP de clase mundial más preferidos en el mundo
ERP Origen

Fuente: Elaboración propia

Los sistemas ERP son aplicaciones que permiten automatizar los procesos de las entidades y
proporciona información y controles internos, basándose en una base de datos central que
recopila información de departamentos que incluyen contabilidad, fabricación, gestión de la
cadena de suministro, ventas, marketing y recursos humanos (HR).

Cada entidad debe completar un trabajo que requiere numerosas partes interesadas con
diversas responsabilidades. Pero eso es una lucha cuando la información necesaria para
 Página 18 de 20

ejecutar procesos y tomar decisiones clave se distribuye en sistemas desconectados. Ya sea que
los datos se almacenen en un software básico de gestión empresarial o en hojas de cálculo, los
empleados tienen dificultades para encontrar lo que necesitan y es posible que no tengan
acceso a él por completo. Por ejemplo, los equipos de contabilidad y finanzas podrían tener
diferentes hojas de cálculo con diferentes cifras para el seguimiento de gastos.

Estas fuentes de datos dispares hacen que sea muy difícil mantener a todos en la misma página
y dificultan la colaboración y la eficiencia, especialmente a medida que crece una organización.
El personal pierde el tiempo buscando documentos y posiblemente duplicando el trabajo
porque no hay un solo lugar para buscar información actualizada sobre todos los aspectos del
negocio relevantes para ellos. Esto también dificulta ver la causa y el efecto total de los
acontecimientos que afectan a su empresa.

Un sistema ERP resuelve este problema al recopilar información en una base de datos central
para otorgar a los gerentes y empleados visibilidad entre departamentos. También elimina los
problemas que surgen con las fuentes de datos en conflicto y les permite analizar varios
escenarios, descubrir mejoras en los procesos y generar importantes ganancias de eficiencia.
Eso se traduce en ahorro de costos y mejor productividad, ya que las personas dedican menos
tiempo a buscar los datos necesarios.

Los sistemas ERP diseñados para satisfacer las necesidades de una empresa individual tienden a
generar retornos sobre la inversión, lo que convierte a estos sistemas en una herramienta
fundamental para entidades de todos los sectores y de todos los tamaños. Muchas de las
empresas más conocidas y exitosas del mundo se han apoyado en ERP durante el último cuarto
de siglo.

Antes de la proliferación de los sistemas ERP, existían sistemas dispersos y desintegrados que
generaban muchos problemas de inconsistencias e inexactitud de la información para la toma
de decisiones, donde por ejemplo se podía encontrar una entidad que para darle cobertura a
sus procesos, podía tener perfectamente 25 o 40 sistemas distintos, desintegrados y
desarrollados en diversos lenguajes de programación, con problemas de controles,
proliferación de riesgos de errores e incluso de fraudes, por la ausencia de integración y de
controles centralizados.
 Página 19 de 20

4.2. Metodología de desarrollo de software

La metodología de desarrollo de software se refiere a los procesos estructurados involucrados
cuando se trabaja en un proyecto. Es una combinación de filosofías de diseño y realismo
pragmático que se remonta a los primeros días de la informática. El objetivo es proporcionar un
enfoque sistemático para el desarrollo de software.

A lo largo de los años, se introdujeron diversas metodologías de desarrollo de software para

capitalizar las tecnologías y los recursos disponibles. La metodología de desarrollo de software
proporciona una plataforma para que los desarrolladores trabajen juntos de manera más
eficiente como equipo. Formaliza la comunicación y determina cómo se comparte la
información dentro del equipo.

Hoy en día, muchas empresas de TI están de acuerdo en que emplear una metodología de
desarrollo de software es fundamental para su equipo. Sin embargo, el tema de qué método es
el mejor permanece en duda. Eso es porque no hay uno. Cada metodología tiene sus pros y sus
contras.

Obtener lo mejor de uno depende de la estructura, los requisitos y los objetivos del equipo.
También es posible utilizar diferentes metodologías de desarrollo de software para diferentes
proyectos.

4.2.1. ¿Por qué adherirse a la metodología de desarrollo de software?

Debe enfatizarse que es crucial elegir una metodología de desarrollo de software y aplicarla
con disciplina a lo largo del proyecto. Existen numerosos riesgos cuando se da por sentada la
metodología de desarrollo de software.

Sin una guía estructurada, los desarrolladores pueden verse afectados por las solicitudes en
constante cambio de los clientes (usuarios finales), y más aún cuando hay problemas de
comunicación. Esto conduce a una revisión frecuente del software sin considerar las
implicaciones generales del proyecto.

¿El resultado? Pérdida de tiempo, dinero y esfuerzo con el riesgo de producir una aplicación
mediocre que no aporta mucho a las intenciones de la administración y de los usuarios finales.

Las metodologías de desarrollo de software se desarrollan para beneficiar tanto al equipo de

desarrollo como a los clientes. Elegir el correcto garantiza que las discusiones se lleven a cabo
en los canales adecuados y que las decisiones se tomen después de evaluar todos los factores.

El uso de una metodología de desarrollo de software permite al equipo reducir la ineficiencia y

proporcionar un cronograma de entrega más preciso. Evita que el equipo reaccione a cada
 Página 20 de 20

entrada, sino que les permite ser más organizados y estructurados cuando se trata de cambios
espontáneos.

Algunos de estos métodos más utilizados son:

Figura 09: Métodos de desarrollo de software

Metodología de
Metodología de Desarrollo
desarrollo de
desarrollo ágil esbelto
cascada

Desarrollo rápido
Modelo prototipo
de aplicaciones

Fuente: Elaboración propia

Metodología de desarrollo ágil

La metodología ágil es posiblemente una de las metodologías de desarrollo de software más

populares en los últimos días. Se necesita un enfoque diferente del método lineal convencional.
Agile se enfoca en cómo satisfacer a los usuarios en lugar de enfatizar la documentación y los
procedimientos rígidos.

Con Agile, las tareas se dividen en sprints cortos que tardan entre 1 y 4 semanas en
completarse. Es un modelo iterativo que implica múltiples pruebas a medida que avanza el
desarrollo. Los desarrolladores buscan continuamente comentarios de los clientes y realizan
cambios en el software.

Metodología de desarrollo de cascada

A pesar de décadas desde que se utilizó por primera vez, la metodología de cascada sigue
siendo relevante en algunos proyectos en la actualidad. Es un método simple y lineal en el que
las etapas de desarrollo se organizan en procesos secuenciales en cascada.

La metodología de desarrollo en cascada se entiende fácilmente, lo que la hace popular entre

los equipos con menos experiencia en diseño. Cada etapa debe completarse antes de pasar a la
siguiente. Por ejemplo, todos los requisitos deben establecerse antes de que pueda comenzar
el diseño.

Al igual que una cascada fluye en una dirección, no hay vuelta atrás en este enfoque. Esto hace
 Página 21 de 20

que la cascada sea un método no flexible y que debe evitarse en proyectos con requisitos que
cambian rápidamente.

Desarrollo esbelto

El desarrollo esbelto nace de los principios de fabricación esbelta de Toyota. Se enfoca en

minimizar el desperdicio y aumentar la productividad. Con los principios rectores, los
desarrolladores evitan actividades no productivas mientras entregan calidad en sus tareas.

La metodología inspirada en Toyota también enfatiza el aprendizaje continuo y el aplazamiento

de la decisión. Permite a los equipos mantener una mente abierta durante el curso del
desarrollo y considerar todos los factores antes de tomar una decisión.

Con la metodología lean, los desarrolladores tienen la tarea de identificar los cuellos de botella
que podrían obstaculizar el proceso. El objetivo es establecer un sistema eficiente que funcione
a la perfección. La metodología también enfatiza el respeto humano, lo que significa que la
comunicación es clave para mejorar la colaboración en equipo.

Modelo prototipo

En lugar de desarrollar un software completo, el modelo prototipo permite a los

desarrolladores trabajar en la versión prototipo del producto final. Luego, el prototipo se pone
a disposición para las pruebas, la evaluación y la retroalimentación del cliente.

Según los comentarios recopilados, el prototipo pasa por varias iteraciones de refinamiento
hasta que el cliente lo considera satisfactorio. El atractivo del enfoque de prototipo es su
evaluación rigurosa que descubre posibles problemas antes de que comience el desarrollo real.

El éxito de este enfoque radica no solo en el equipo de desarrollo, sino también en qué tan bien
se comunican con los clientes al realizar la prueba. También vale la pena mencionar que los
desarrolladores a menudo asumen el costo de construir el prototipo.

Desarrollo rápido de aplicaciones

El modelo de desarrollo rápido de aplicaciones (RAD) se introdujo en 1991 y sirvió como base
para los marcos iterativos modernos. Se enfoca en obtener productos construidos en un marco
de tiempo mucho más corto sin comprometer la calidad.

RAD es un marco de 4 pasos, que defiende los requisitos del proyecto, la creación de
prototipos, las pruebas y la implementación. A diferencia de los modelos lineales, RAD enfatiza
la construcción de prototipos con los requisitos dados y probarlos con el cliente. Esto se hace a
 Página 22 de 20

través de múltiples iteraciones hasta que el cliente está satisfecho con los resultados.

Las pruebas rigurosas del prototipo dan como resultado una valiosa retroalimentación, lo que
ayuda a eliminar gran parte del riesgo del producto. El uso de RAD genera altas posibilidades de
lanzamiento exitoso del producto dentro del cronograma estipulado. RAD a menudo utiliza
herramientas de desarrollo que podrían automatizar y simplificar el proceso de desarrollo.
 Página 23 de 20

Conclusión
Los sistemas de información de información tienen un ciclo de vida y para cada una de las
etapas de este ciclo, es necesario tener en consideración lo que comprende, a fin de poder
examinar el origen de estos en las entidades, considerando que no son un fin en sí mismo,
sino más bien son un medio o herramienta para alcanzar los objetivos de las entidades de
forma mucho más eficiente en pos de cumplir con la estrategia que está sustentada por una
visión, misión y objetivos estratégicos.

Por otra parte, se ha podido distinguir que en materia de sistemas de información existen
dos caminos a seguir por las entidades. Uno de ellos es el desarrollo a la medida, por medio
de algún lenguaje computacional y el otro es la adquisición de un paquete de software
preconfigurado, pero en ambos casos es necesario llevar a cabo un proyecto de
implementación del sistema de información, con todas las consideraciones que se han
comentado en la presente unidad.

Es por esta razón que antes de llevar a cabo un proyecto de desarrollo o implementación de
un sistema de información, es necesario validar la necesidad emanada desde los usuarios de
procesos de la entidad, con los estudios de factibilidad pertinentes, los lineamientos
estratégicos, consideraciones de costo versus beneficio, entre otros, para luego comenzar a
preparar los equipos de trabajo en la medida que sea aprobado. Se debe tener especial
cuidado en los equipos implementadores o desarrolladores que podrían ser internos o
externos y en esa línea, se debe contar con las credenciales necesarias y habilitantes que
garanticen un sistema exitoso.

En la actualidad las grandes entidades tienden a preferir los paquetes de software

preconfigurados, porque son más eficientes de implementar, han sido previamente
probados y además, consideran buenas prácticas de los procesos que cubren, con especial
énfasis los llamados sistemas de información de clase mundial, como es el caso de los ERP y
los CRM.
 Página 24 de 20

Referencias bibliográficas

R.S. Pressman. "Software Engineering: A practitioner's approach". McGraw-Hill. Seventh Edition. New
York, EUA. 2010. ISBN: 978-0-07-337597-7. 3(1), 1-17.

PMI. "A Guide to the Project Management Body of Knowledge. (PMBOK® Guide)". Fifth Edition. Project
Management Institute. Pennsylvania, USA Inc. 2013. ISBN: 978-1-935589-67-9.

ISO. "NC-ISO 10006:2007. Sistemas de gestión de la calidad-Directrices para la gestión de la calidad en

los proyectos (ISO 10006:2003, IDT)". Oficina Nacional de Normalización (NC). 2007.

Dedeke. "A conceptual framework for developing quality measures for information systems". In
International Conference on Information Quality, pp. 126-128. Cambridge, Massachusetts, USA. 2000.

ISACA. (2014). Manual de preparación al Examen CISA 2014.

 Página 25 de 20

Este material fue desarrollado por el docente Mg. Pedro David Hernández Farías
para la Universidad Mayor y ha sido diseñado para su lectura en formato digital.
Última actualización Septiembre, 2022.