Descripción: Investiga y elabora un informe detallado sobre el desarrollo de los Sistemas de

información, basados en computadoras.

Requisitos:

Extensión: min 15 páginas

Formato: APA

Contenido:

 Introducción.

 1. Investigación preliminar.

 2. Determinación de los requerimientos del sistema.

 3. Diseño del sistema.

 4. Desarrollo de software.

 5. Prueba de los sistemas.

 6. Implantación y evaluación.

 Conclusión.

 Referencias

1. Investigación Preliminar

La fase de investigación preliminar en el desarrollo de sistemas de información consiste en evaluar

la viabilidad del proyecto y determinar si el sistema es necesario y cómo puede aportar valor a la
organización. Este proceso incluye el análisis de problemas actuales, la identificación de
oportunidades, y la evaluación de la viabilidad económica, técnica y operativa del proyecto.

Un sistema de información automatizado o basado en computadoras, es la integración de

hardware, software, personas, procedimientos y datos. Todos estos elementos se conjugan,
trabajando juntos, para proporcionar información básica para la conducción de la empresa. Esta
información hace posible que las empresas lleven a cabo sus tareas con mayor calidad y facilidad.

Los sistemas de información computarizados, además de llevar un seguimiento de las

transacciones y operaciones diarias, propias del negocio, sirven de apoyo al flujo de información
interno de la organización. La finalidad de los sistemas de información organizacionales es,
procesar entradas, mantener archivos de datos relacionados con la organización y producir
información, reportes y otras salidas para los usuarios que las necesitan. Puesto que los sistemas
de información dan soporte a los demás sistemas de la organización, los analistas de sistemas
tienen que estudiar primero el sistema organizacional como un todo y así entonces, poder precisar
cuáles son y cómo funcionan los sistemas de información de la organización.
1.1 Identificación del Problema o Necesidad

En esta etapa, se identifican los problemas existentes en el flujo de trabajo, los procesos o los
sistemas actuales que requieren mejorarse o reemplazarse. Para identificar estas áreas, se realizan
encuestas, entrevistas y análisis de documentos.

La identificación del problema o necesidad es el primer paso fundamental en el desarrollo de

sistemas de información. Esta fase establece el propósito del sistema, asegurando que se aborden
problemas específicos de la organización o que se aprovechen oportunidades que mejoren la
eficiencia operativa, competitividad o toma de decisiones.

1.1. Importancia de la Identificación del Problema

El éxito de un sistema de información depende en gran medida de su alineación con las

necesidades organizacionales. Si no se identifican adecuadamente los problemas o requerimientos
al inicio, el sistema desarrollado puede resultar inadecuado o insuficiente para resolver los
desafíos operativos. Las organizaciones suelen enfrentarse a procesos que son ineficientes, lentos,
costosos o vulnerables a errores. Estos problemas pueden estar relacionados con la falta de acceso
a la información en tiempo real, la duplicación de esfuerzos, errores manuales o la incapacidad
para adaptarse a las demandas del mercado.

La correcta identificación del problema proporciona una base sólida para todas las fases
subsiguientes en el desarrollo del sistema, ayudando a definir claramente los objetivos y el alcance
del proyecto.

1.2. Técnicas para la Identificación de Problemas o Necesidades

Existen varias técnicas para identificar problemas o necesidades en los sistemas actuales:

 Entrevistas con usuarios y stakeholders: Esta técnica permite obtener información directa
de las personas que interactúan con los sistemas y procesos diariamente. Los usuarios y
partes interesadas pueden proporcionar ideas sobre qué procesos son ineficientes, qué
tareas consumen más tiempo o dónde surgen errores frecuentes.

 Análisis de flujos de trabajo: Al mapear los procesos actuales, se pueden identificar

cuellos de botella, redundancias y áreas donde el uso de tecnología mejoraría la eficiencia.

 Estudios de factibilidad: Un estudio de factibilidad analiza si es posible desarrollar un

sistema que resuelva los problemas identificados desde un punto de vista técnico,
económico y organizacional.

 Encuestas y cuestionarios: A través de la recopilación de datos cuantitativos y cualitativos,

se pueden identificar tendencias y áreas de preocupación comunes entre los empleados o
usuarios de sistemas.

 Revisión de documentos y datos históricos: El análisis de informes de desempeño,

registros de auditoría y datos históricos puede proporcionar una visión clara de las áreas
problemáticas.
1.3. Tipos de Problemas o Necesidades

En nuestros días es preciso entender que la información es uno de los recursos más valiosos e
importantes, y para las organizaciones representa un papel determinante; por lo tanto, surgió la
necesidad de encontrar sistemas que permitieran organizar y almacenar la gran cantidad de datos
e información; es así como nacieron los sistemas de información manual y posteriormente los
sistemas de información computacionales, cada uno con atributos y características propias.

Los problemas que motivan el desarrollo de un sistema de información pueden ser diversos y
pueden clasificarse de varias formas:

 Problemas operativos: Incluyen la lentitud en la ejecución de tareas, la falta de

automatización, la duplicación de esfuerzos o la pérdida de información importante.

 Problemas de toma de decisiones: A veces, las organizaciones no pueden acceder a la

información crítica en el momento adecuado, lo que impacta la toma de decisiones. Los
sistemas de información deben poder generar informes y análisis en tiempo real.

 Problemas de seguridad: Las organizaciones pueden necesitar sistemas que protejan la

información sensible y garanticen la confidencialidad y la integridad de los datos.

 Problemas de escalabilidad: En algunas organizaciones, los sistemas actuales no son

escalables y no pueden adaptarse al crecimiento de la empresa, lo que afecta la eficiencia
a medida que la carga de trabajo aumenta.

1.5. Definición del Problema en Función de los Requerimientos del Negocio

Después de identificar las áreas problemáticas o las oportunidades de mejora, es esencial definir el
problema en función de los requerimientos del negocio. Esto implica traducir el problema
identificado en una declaración clara que guíe el desarrollo del sistema. Por ejemplo, si el
problema identificado es la pérdida de información en las transacciones, el requerimiento del
negocio puede definirse como la necesidad de un sistema que garantice la trazabilidad y registro
completo de todas las transacciones.

1.2 Análisis de Factibilidad

Aquí, se evalúa la factibilidad técnica, económica y operativa del sistema. La factibilidad técnica se
centra en determinar si la tecnología requerida está disponible, la económica analiza si los costos
son razonables en comparación con los beneficios, y la operativa examina si el sistema podrá
funcionar dentro de la estructura organizativa.

2. Determinación de los Requerimientos del Sistema

La determinación de los requerimientos es crítica, ya que define las especificaciones que debe
cumplir el sistema. Se consideran tanto los requerimientos funcionales (lo que el sistema debe
hacer) como los no funcionales (cómo debe hacerlo). Estos requerimientos deben ser detallados y
claros para asegurar que todas las partes interesadas estén alineadas.

La determinación de los requerimientos del sistema es una de las fases más cruciales en el
desarrollo de sistemas de información basados en computadoras. Esta etapa se centra en
identificar y documentar las funcionalidades y características específicas que el sistema debe
poseer para cumplir con las expectativas y necesidades del negocio. Los requerimientos bien
definidos actúan como la base sobre la cual se diseñará, desarrollará y probará el sistema,
asegurando su éxito a largo plazo.

2.1. Importancia de la Determinación de Requerimientos

La precisión en la recopilación y especificación de los requerimientos garantiza que el sistema final

responda a las necesidades del usuario y cumpla con los objetivos organizacionales. La falta de
claridad o la definición inadecuada de los requerimientos puede llevar a la construcción de un
sistema que no sea útil, resulte costoso o no resuelva los problemas inicialmente planteados.

Además, los requerimientos sirven como una guía para los equipos de desarrollo y como una
referencia para las fases posteriores del proyecto, tales como el diseño, la implementación y las
pruebas. Es esencial que todas las partes interesadas estén alineadas con respecto a los
requerimientos desde el principio.

2.2. Tipos de Requerimientos

Los requerimientos del sistema se dividen en dos grandes categorías: requerimientos funcionales
y requerimientos no funcionales.

2.2.1. Requerimientos Funcionales

Los requerimientos funcionales son las especificaciones de las funciones o actividades que el
sistema debe realizar para cumplir con los objetivos del negocio. Definen qué hará el sistema.

Ejemplos de requerimientos funcionales incluyen:

 Gestión de datos: El sistema debe permitir almacenar, actualizar, eliminar y recuperar

datos de los clientes.

 Generación de reportes: El sistema debe generar informes mensuales de ventas

detallados por producto y por región.

 Procesamiento de transacciones: El sistema debe ser capaz de procesar pagos en línea

mediante tarjetas de crédito o transferencias bancarias.

 Control de inventarios: El sistema debe actualizar automáticamente el inventario cuando

se realicen ventas.

2.2.2. Requerimientos No Funcionales

Los requerimientos no funcionales especifican cómo debe funcionar el sistema en términos de
desempeño, seguridad, usabilidad, y otras cualidades del sistema. No describen funciones
específicas, sino las características y limitaciones que deben considerarse.

Ejemplos de requerimientos no funcionales incluyen:

 Rendimiento: El sistema debe ser capaz de procesar 1,000 transacciones por minuto.

 Seguridad: El sistema debe encriptar todos los datos sensibles de los usuarios y cumplir
con los estándares de seguridad internacionales.

 Escalabilidad: El sistema debe ser escalable para admitir hasta 10,000 usuarios
simultáneos sin degradación del rendimiento.

 Disponibilidad: El sistema debe estar disponible el 99.9% del tiempo durante horas
laborales.

 Compatibilidad: El sistema debe ser compatible con los navegadores web más populares y
dispositivos móviles.

2.3. Proceso de Recopilación de Requerimientos

El proceso de recopilación de requerimientos es una actividad colaborativa que involucra a varios

actores clave de la organización. A continuación, se describen las principales técnicas utilizadas en
esta fase:

2.3.1. Entrevistas

Las entrevistas con las partes interesadas (stakeholders), como usuarios finales, gerentes y
técnicos, son una de las técnicas más efectivas para obtener requerimientos. Las preguntas deben
centrarse en los problemas actuales que los usuarios enfrentan, sus expectativas y las
funcionalidades deseadas.

2.3.2. Reuniones de Grupo y Talleres

Los talleres de trabajo o sesiones de brainstorming permiten a diferentes grupos de usuarios

colaborar y compartir ideas sobre el nuevo sistema. Estas sesiones ayudan a identificar una
variedad de perspectivas y aseguran que se incluyan requerimientos desde distintos puntos de
vista organizacionales.

2.3.3. Análisis de Documentación

La revisión de documentos existentes, como manuales de usuario, especificaciones de sistemas

anteriores, informes de auditoría y procedimientos operativos estándar, proporciona información
valiosa para identificar los requerimientos del nuevo sistema.

2.3.4. Prototipos

El desarrollo de prototipos de baja fidelidad puede ser útil para visualizar de manera temprana las
funcionalidades del sistema. Los prototipos permiten a los usuarios interactuar con una
representación inicial del sistema y proporcionar retroalimentación valiosa antes de que comience
el desarrollo completo.
2.3.5. Observación Directa

La observación directa de cómo los usuarios interactúan con el sistema actual o ejecutan sus
tareas diarias ayuda a los analistas a entender los desafíos y las oportunidades de mejora. Este
enfoque es especialmente útil en entornos donde las operaciones no están bien documentadas.

2.4. Análisis y Priorización de Requerimientos

Una vez recopilados los requerimientos, es esencial analizarlos y priorizarlos para asegurar que se
implementen de manera eficiente y dentro del presupuesto y tiempo establecidos.

2.4.1. Validación de Requerimientos

Los requerimientos recopilados deben ser validados para asegurar que sean realistas, completos y
comprensibles. Es necesario que los usuarios y los desarrolladores revisen los requerimientos para
asegurar que se ajustan a las necesidades del negocio.

2.4.2. Priorización

No todos los requerimientos tienen la misma importancia. Es fundamental clasificarlos según su

prioridad para el negocio. Existen varias técnicas de priorización, como MoSCoW (Must have,
Should have, Could have, Won't have) o la matriz Eisenhower, que clasifican los requerimientos en
función de su importancia y urgencia.

2.5. Documento de Especificación de Requerimientos

El resultado final de esta fase es la creación del Documento de Especificación de Requerimientos

del Sistema (SRS, por sus siglas en inglés), que actúa como un contrato entre el cliente y el equipo
de desarrollo. Este documento contiene una descripción detallada de todos los requerimientos
funcionales y no funcionales, así como cualquier restricción o limitación técnica.

El SRS debe ser claro y comprensible para todos los actores involucrados, desde los usuarios hasta
los desarrolladores. Asegurar una buena documentación reduce las posibilidades de
malentendidos y problemas durante las siguientes fases del proyecto.

2.6. Ejemplo de Requerimientos en Diversos Sistemas

 Sistema de Gestión Hospitalaria:

o Funcional: El sistema debe permitir la programación de citas médicas y la

generación automática de recordatorios para los pacientes.

o No Funcional: El sistema debe ser accesible desde dispositivos móviles y ofrecer

una autenticación segura de los usuarios.

 Sistema de Gestión Financiera:

o Funcional: El sistema debe gestionar y monitorear las transacciones en tiempo

real.

o No Funcional: El sistema debe cumplir con los estándares regulatorios como PCI-
DSS para el procesamiento seguro de pagos.
2.7. Retos en la Determinación de Requerimientos

La fase de determinación de requerimientos presenta varios desafíos. Uno de los principales es la

ambigüedad o falta de claridad en las descripciones proporcionadas por los usuarios, lo que
puede llevar a malentendidos. Otro desafío es la evolución de los requerimientos, ya que las
necesidades de la empresa pueden cambiar a lo largo del ciclo de vida del proyecto.

2.1 Requerimientos Funcionales

Los requerimientos funcionales describen las funciones específicas que debe realizar el sistema.
Estos se derivan directamente de las necesidades del usuario o de la empresa, como la capacidad
de generar informes, gestionar inventarios o realizar transacciones en línea.

2.2 Requerimientos No Funcionales

Incluyen aspectos como la seguridad, el rendimiento, la escalabilidad y la usabilidad del sistema.

Estos requerimientos, aunque no directamente relacionados con funciones específicas, son
esenciales para asegurar el correcto funcionamiento del sistema en diversas circunstancias.

3. Diseño del Sistema

El diseño del sistema es la fase en la que se conceptualiza cómo funcionará el sistema en términos
de su arquitectura, componentes y módulos. El diseño debe ser lo suficientemente detallado para
guiar el desarrollo y debe abordar tanto el diseño del software como la infraestructura de
hardware necesaria.

Desarrollo de los Sistemas de Información Basados en Computadoras: Diseño del Sistema

El diseño del sistema es una fase fundamental en el desarrollo de sistemas de información, ya que
es donde se define cómo se implementarán los requerimientos previamente establecidos. En esta
etapa se traduce la visión funcional y técnica en una arquitectura detallada que guiará a los
desarrolladores y permitirá la construcción del sistema. El diseño del sistema abarca tanto el
diseño de la arquitectura general, como el de los componentes individuales y la interfaz de
usuario, asegurando que todos estos elementos trabajen de manera coordinada y eficiente.

3.1. Objetivo del Diseño del Sistema

El objetivo del diseño del sistema es crear un plan detallado que describa la estructura, los
componentes, los datos y las interfaces del sistema. Este diseño debe ser lo suficientemente
preciso para guiar a los desarrolladores durante la etapa de codificación y lo suficientemente
flexible como para permitir futuros ajustes y mejoras. Además, el diseño del sistema busca
garantizar que las especificaciones técnicas cumplan con los requerimientos funcionales y no
funcionales definidos previamente.

3.2. Componentes del Diseño del Sistema

El diseño del sistema abarca varios componentes clave:

3.2.1. Diseño de la Arquitectura del Sistema

El diseño de la arquitectura del sistema se refiere a la organización estructural de los componentes

y módulos del sistema, así como a la manera en que interactúan entre sí. Esta arquitectura define
el marco de trabajo general, proporcionando una vista de alto nivel que incluye:

 Componentes del sistema: Se identifican los módulos principales del sistema, como los
módulos de procesamiento, almacenamiento y comunicación.

 Esquema de comunicación entre módulos: Se define cómo los componentes intercambian

información y qué protocolos de comunicación se usarán. Esto incluye la configuración de
servidores, bases de datos y redes.

 Distribución: Se decide si el sistema será centralizado, distribuido o basado en la nube. En

sistemas distribuidos, los datos y el procesamiento están repartidos entre varios
servidores, mientras que los sistemas centralizados dependen de un único servidor
central.

La elección de la arquitectura depende de varios factores, incluidos los requerimientos de

escalabilidad, seguridad y rendimiento.

3.2.2. Diseño de la Base de Datos

Uno de los componentes más críticos del diseño del sistema es el diseño de la base de datos, que
se encarga de estructurar cómo se almacenarán, organizarán y accederán los datos. Los
diseñadores deben definir:

 Modelo de datos: Un diagrama entidad-relación (ERD) que representa las entidades del
sistema (por ejemplo, clientes, productos, transacciones) y las relaciones entre ellas.

 Esquemas de base de datos: Las tablas, índices y procedimientos almacenados que

soportarán las operaciones del sistema.

 Políticas de integridad de datos: Reglas que garantizan la consistencia y validez de los

datos, incluyendo claves primarias y foráneas, restricciones y normalización.

3.2.3. Diseño de la Interfaz de Usuario (UI)

El diseño de la interfaz de usuario es fundamental para garantizar que los usuarios puedan
interactuar con el sistema de manera eficiente y sin errores. Esta parte del diseño del sistema
incluye:
  Diseño visual: Se desarrollan maquetas (wireframes) y prototipos que ilustran cómo se
verá la interfaz. Esto incluye la disposición de los menús, botones, formularios y otros
elementos de interacción.

 Experiencia del usuario (UX): Se considera cómo los usuarios interactuarán con el sistema,
garantizando que sea intuitivo y fácil de usar. La navegación debe ser clara, y el flujo de
trabajo debe permitir a los usuarios realizar tareas de manera eficiente.

 Accesibilidad: El diseño debe tener en cuenta la accesibilidad para todos los usuarios,
incluyendo aquellos con discapacidades físicas o sensoriales. Esto puede implicar el uso de
texto alternativo, teclas de acceso rápido y compatibilidad con tecnologías de asistencia.

3.2.4. Diseño de Seguridad

La seguridad del sistema es esencial para proteger la integridad y confidencialidad de los datos.
Durante esta fase, se desarrollan políticas y mecanismos de seguridad que se integrarán en el
sistema, tales como:

 Autenticación y autorización: Los mecanismos que aseguran que solo los usuarios
autorizados puedan acceder a ciertas áreas del sistema. Esto puede incluir la
implementación de contraseñas, autenticación multifactor (MFA), y roles basados en
permisos.

 Encriptación: Definición de los métodos de cifrado de datos, tanto en tránsito como en

reposo, para proteger la información sensible.

 Auditoría y monitoreo: Se establece cómo se realizará el monitoreo de las actividades

dentro del sistema para detectar accesos no autorizados y actividades sospechosas.

3.3. Diseño Detallado del Sistema

El diseño detallado se enfoca en describir cada componente en profundidad, especificando cómo

funcionará cada parte del sistema en términos de algoritmos, estructuras de datos y funciones
específicas.

3.3.1. Diseño de Algoritmos

Se diseñan los algoritmos que el sistema utilizará para procesar datos y realizar cálculos. Esto
puede incluir algoritmos de búsqueda, clasificación, toma de decisiones y procesamiento de
transacciones. El diseño debe garantizar que los algoritmos sean eficientes y que cumplan con los
requisitos de rendimiento del sistema.

3.3.2. Diseño de los Componentes de Software

Cada componente del sistema debe tener un diseño claro que incluya:

 Entrada y salida: Descripción de los datos que el componente recibe y genera.

 Lógica interna: Cómo el componente procesará los datos.

 Interfaces con otros componentes: Cómo se comunicará el componente con otros

módulos o servicios del sistema.
3.3.3. Diseño de Servicios Web y APIs

Si el sistema debe interactuar con otros sistemas externos o aplicaciones, se diseñan servicios web
o APIs (Application Programming Interfaces). Estos proporcionan un mecanismo para que el
sistema pueda compartir y recibir datos de manera segura y eficiente.

3.4. Herramientas y Enfoques de Diseño

Dependiendo del enfoque de desarrollo del sistema, el diseño puede seguir diferentes
metodologías:

3.4.1. Enfoque Orientado a Objetos

El diseño orientado a objetos organiza el sistema en torno a "objetos", que son representaciones
de entidades del mundo real o conceptual. Cada objeto tiene atributos (datos) y métodos
(comportamientos), y puede interactuar con otros objetos. Los diagramas de clase, secuencia y
colaboración se utilizan comúnmente en este enfoque.

3.4.2. Enfoque Modular

El diseño modular implica dividir el sistema en componentes o módulos independientes, cada uno
de los cuales puede desarrollarse y probarse de manera aislada. Este enfoque facilita la
reutilización de código y la escalabilidad, ya que los módulos pueden modificarse o reemplazarse
sin afectar al sistema completo.

3.4.3. Diseño Basado en Servicios (SOA)

En un enfoque basado en servicios, el sistema se organiza en torno a servicios independientes que

pueden interactuar entre sí a través de interfaces estándar. Este enfoque es útil cuando se
integran sistemas distribuidos o cuando se necesitan actualizaciones y expansiones frecuentes.

3.5. Validación del Diseño del Sistema

Antes de proceder con el desarrollo, es fundamental validar el diseño del sistema. Esta validación
puede incluir revisiones de diseño, simulaciones y la creación de prototipos funcionales. La
validación asegura que el diseño cumple con los requerimientos del sistema, identifica posibles
problemas de usabilidad y garantiza que se han seguido las mejores prácticas de desarrollo.

3.5.1. Revisión por Expertos

Se puede invitar a expertos en desarrollo de sistemas, seguridad o usabilidad a revisar el diseño,

proporcionando una evaluación objetiva de su solidez y viabilidad.

3.5.2. Prototipos Funcionales

Desarrollar prototipos puede ayudar a los usuarios finales y a los desarrolladores a tener una
visión práctica de cómo funcionará el sistema. Esto es especialmente útil para validar la interfaz de
usuario y la experiencia de uso antes de realizar la inversión completa en el desarrollo.
3.1 Diseño de la Arquitectura del Sistema

La arquitectura del sistema incluye la organización estructural de los componentes del sistema y
cómo interactúan entre ellos. Se decide, por ejemplo, si el sistema será centralizado,
descentralizado o distribuido, y se establecen los protocolos de comunicación.

3.2 Diseño de Interfaces de Usuario

En esta fase se determina cómo interactuarán los usuarios con el sistema. El diseño de la interfaz
debe ser intuitivo y fácil de usar, facilitando la interacción del usuario con el software. Las
herramientas modernas permiten prototipos rápidos para evaluar la efectividad de la interfaz
antes de la codificación.

4. Desarrollo de Software

El desarrollo de software es la fase en la que se codifican las funcionalidades del sistema.

Utilizando lenguajes de programación y herramientas de desarrollo, los programadores
transforman el diseño en un sistema operativo. Es crucial que en esta etapa se sigan las mejores
prácticas de codificación para evitar errores futuros y facilitar el mantenimiento del sistema.

4.1 Elección de Herramientas y Lenguajes

Dependiendo de los requerimientos del sistema y de la infraestructura, se eligen los lenguajes de

programación y las herramientas de desarrollo adecuadas. Por ejemplo, para sistemas web, se
podrían utilizar lenguajes como JavaScript, Python o PHP, mientras que para aplicaciones
empresariales complejas, Java o C# podrían ser más apropiados.

4.2 Implementación de Módulos Funcionales

El desarrollo se organiza típicamente en módulos o componentes que se codifican y prueban

individualmente antes de integrarse en el sistema completo. Esto permite una mayor organización
y facilita la detección de errores.

5. Prueba de los Sistemas

Las pruebas del sistema son esenciales para asegurar que el software desarrollado cumple con los
requerimientos especificados y que funciona correctamente bajo diversas condiciones. Esta fase
implica pruebas unitarias, de integración, de sistema y de aceptación por parte de los usuarios.

5.1 Pruebas Unitarias

Las pruebas unitarias consisten en verificar cada componente o módulo por separado, asegurando
que funcionen correctamente de manera independiente. Esta fase de pruebas permite identificar
problemas en el código antes de que se integren con otras partes del sistema.

5.2 Pruebas de Integración

Después de que los módulos individuales han sido probados, se integran y se prueban en conjunto
para asegurar que funcionan correctamente cuando interactúan entre sí. En esta fase, se suelen
detectar problemas relacionados con la comunicación entre módulos o con la infraestructura
subyacente.

5.3 Pruebas de Sistema y Aceptación

En esta fase se prueba el sistema completo en un entorno lo más cercano posible al de

producción. Los usuarios finales participan en la prueba de aceptación, donde se verifica que el
sistema cumple con las expectativas y necesidades.

6. Implantación y Evaluación

La implantación es el proceso en el que el sistema se transfiere al entorno de producción y

comienza a utilizarse por los usuarios finales. Esta fase incluye la capacitación de los usuarios, la
configuración de la infraestructura necesaria y el monitoreo inicial para asegurar que el sistema
funcione correctamente.

6.1 Capacitación de Usuarios

Una parte clave de la implantación es asegurar que los usuarios estén capacitados para utilizar el
sistema. Esto puede incluir manuales, cursos de capacitación o soporte técnico durante las
primeras semanas de uso.
6.2 Monitoreo y Evaluación Continua

Tras la implantación, es fundamental realizar un monitoreo continuo del sistema para identificar
posibles problemas. Además, se evalúa el desempeño del sistema y se comparan los resultados
con los objetivos iniciales. Las evaluaciones periódicas permiten mejorar el sistema a lo largo del
tiempo y asegurar su adaptabilidad a futuros requerimientos.