Externalización y desarrollo por encargo de una app Windows: qué aclarar antes de solicitarlo

Al plantearse la externalización o el desarrollo por encargo de una aplicación Windows, lo primero que hay que decidir no es únicamente «con qué tecnología se va a construir».

En la práctica, son habituales consultas como estas:

• Queremos modificar un software Windows antiguo.
• No podemos hacernos cargo de la aplicación interna que creó la persona anterior.
• La comunicación con un dispositivo o instrumento de medición se detiene de vez en cuando.
• Están implicados 32 bits/64 bits, COM/ActiveX e integración con VBA.
• Dejó de funcionar al pasarla a Windows 11 o a un PC nuevo.
• Queremos aclarar también la distribución, la firma de código, la actualización automática y las advertencias de SmartScreen.
• Queremos investigar bloqueos o aumento de memoria tras un funcionamiento prolongado.

En otras palabras, la externalización o el desarrollo por encargo de una aplicación Windows no es solo «el trabajo de crear pantallas nuevas». Hay que entenderlo como un trabajo que abarca la investigación, la modificación y la sustitución de activos existentes, la integración con dispositivos, la distribución, el mantenimiento y la investigación de fallos.

En este artículo resumimos, desde el punto de vista de quien encarga el trabajo, los puntos que conviene aclarar antes de solicitar la externalización o el desarrollo por encargo de una aplicación Windows.

1. Áreas habituales de consulta en la externalización y el desarrollo por encargo de una app Windows

1.1 Desarrollo de una nueva aplicación de negocio

Es el caso de crear como aplicación Windows las pantallas de entrada de datos, las pantallas de búsqueda, la generación de informes, la integración con CSV, la integración de archivos o la integración con sistemas externos que sostienen el negocio interno.

Los motivos para elegir una aplicación Windows en lugar de una aplicación web suelen ser estos:

• Se quiere manipular con detalle archivos y carpetas del PC local.
• Se quiere integrar dispositivos USB, instrumentos de medición, PLC, cámaras, etc.
• Se quiere usar en un entorno sin conexión o en una red cerrada.
• Se quieren aprovechar activos existentes de Excel, VBA, COM o DLL.
• Se necesita usar teclado, lector de códigos de barras o pantalla táctil en el equipo del puesto de trabajo.
• Se necesita monitorización residente o procesamiento en segundo plano.

Incluso en un desarrollo nuevo, decidir desde el principio si conviene hacerlo como aplicación Windows, si basta con una aplicación web, o si solo una parte debe quedarse en el lado Windows, reduce los cambios de rumbo posteriores.

1.2 Modificación y mantenimiento de software Windows existente

En las consultas de externalización y desarrollo por encargo, es más habitual la modificación y el mantenimiento de software existente que un desarrollo completamente nuevo.

Por ejemplo, situaciones como estas:

• Existe el código fuente, pero no se sabe cómo compilarlo.
• Solo se puede abrir con una versión antigua de Visual Studio.
• Sigue detenido en VB6, MFC, WinForms o .NET Framework.
• La persona responsable se marchó y no queda nadie que conozca las especificaciones.
• El funcionamiento se volvió inestable tras una actualización de Windows o un cambio de PC.
• Los clientes o el personal de campo piden nuevas funciones.

En estos casos, en lugar de reconstruir todo de inmediato, primero se hace un inventario de la situación actual.

• Qué negocio sostiene.
• Qué funciones son imprescindibles.
• En qué entorno funciona.
• De qué dispositivos externos, DLL, bases de datos o carpetas compartidas depende.
• Si quedan registros o información de errores.
• Si se conserva el código fuente, el procedimiento de compilación, el instalador y los archivos de configuración.

Que un software existente siga funcionando ya es, en sí mismo, un valor. Por eso, en el desarrollo por encargo no basta con «desechar todo y reconstruir»: es importante el enfoque gradual de mantener, encapsular y reemplazar.

Cuando hay COM, ActiveX u OCX de por medio, conviene primero fijar la terminología y, después, decidir componente por componente si se mantiene, se encapsula o se reemplaza.

Artículos relacionados

• Diferencias entre COM, ActiveX y OCX explicadas a fondo — ordenar la terminología
• Tabla de decisión mantener/encapsular/reemplazar para ActiveX/OCX — decidir la estrategia de migración

1.3 Aplicaciones de integración con dispositivos y equipos externos

En manufactura, inspección, medición, entornos médicos periféricos o uso en investigación, es habitual que una aplicación Windows esté conectada a equipos externos.

Los destinos de integración más representativos son estos:

• Dispositivos de comunicación serie
• Dispositivos USB
• Cámaras industriales
• PLC
• Instrumentos de medición
• Lectores de códigos de barras
• Carpetas compartidas y NAS
• DLL nativas existentes
• SDK proporcionados por el fabricante

En este ámbito no basta con crear la pantalla: hay que diseñar también cómo se corta la comunicación, la reconexión, los tiempos de espera, los registros, el guardado de los datos en bruto y la indicación de estado.

La comunicación serie en particular es propensa a problemas de unidad de recepción, tiempos de espera, reconexión y bloqueo de la interfaz, por lo que conviene tener estos aspectos claros desde el principio.

Además, el estado de un dispositivo externo a veces no basta con distinguirlo entre «conectado» y «no conectado». Separar la presencia del dispositivo, su respuesta, la preparación de sus funciones, la frescura de los datos y la coincidencia de la configuración da lugar a pantallas que se malinterpretan menos en el terreno.

Artículos relacionados

• Trampas del desarrollo de aplicaciones de comunicación serie — unidad de recepción, tiempos de espera, reconexión
• Diseño de la visualización del estado de dispositivos externos — cómo separar el estado y mostrarlo en pantalla

1.4 Investigación de errores y análisis de causas

En el desarrollo por encargo de aplicaciones Windows, a veces la investigación de errores es necesaria antes que añadir funciones.

Son habituales consultas como estas:

• Se cae solo unas pocas veces al día.
• La memoria sigue creciendo tras un funcionamiento prolongado.
• No funciona solo en determinados PC.
• La comunicación con el dispositivo se detiene unos segundos.
• Se pierden datos en la integración de archivos.
• No se conoce el procedimiento de reproducción.
• Hay pocos registros y no se puede rastrear la causa.

Este tipo de problemas no se resuelve solo con mirar el código. Primero hay que diseñar los puntos de observación y recopilar registros, volcados de bloqueo, registros de comunicación, registros de eventos, uso de memoria y número de identificadores (handles).

En la investigación de bloqueos, la clave está en cómo dejar constancia del instante en que se produjo la caída.

En los problemas de crecimiento de memoria, hay que distinguir si se trata de una simple espera del recolector de basura (GC) o de una fuga de memoria real. En el caso de aplicaciones .NET, el procedimiento consiste en observar, comparar y demostrar.

Artículos relacionados

• Cómo registrar logs en el momento de un bloqueo de una app Windows — diseño de logs del instante de la caída
• Introducción a la recopilación de volcados de bloqueo〖WER/ProcDump/WinDbg〗 — cómo obtener los volcados
• Distinguir espera del GC de una fuga de memoria en .NET — separar las causas del crecimiento de memoria

1.5 Distribución, firma y actualización automática

Una aplicación Windows puede encontrar dificultades, una vez terminada, en «cómo distribuirla».

• ¿Se hace un instalador?
• ¿Basta con colocarla y que funcione?
• ¿Se puede instalar con una cuenta de usuario estándar?
• ¿Requiere privilegios de administrador?
• ¿Se distribuye por un recurso compartido interno?
• ¿Se hace descargar desde la web?
• ¿Habrá actualización automática?
• ¿Cómo se gestiona el certificado de firma de código?
• ¿Cómo se explica y se afronta la advertencia de SmartScreen?

Los métodos de distribución incluyen MSI, MSIX, ClickOnce, xcopy y actualizadores («updaters») propios. La elección no debe basarse en «cuál es más sencillo», sino en qué se registra en el sistema operativo y quién asume la responsabilidad de las actualizaciones.

Para una aplicación Windows .NET de uso interno, distribuida a usuarios estándar y con actualización automática ligera, ClickOnce es un buen candidato.

Por otro lado, en la distribución web o fuera de la empresa aparecen los problemas de la advertencia de SmartScreen y la firma de código.

Artículos relacionados

• Guía para elegir el método de distribución de una app Windows — comparativa de MSI/MSIX/ClickOnce/xcopy/updater propio
• Introducción a ClickOnce: distribución, actualización y criterios de selección — distribución a usuarios estándar y actualización automática
• Por qué aparece «Windows protegió su PC» en Windows — SmartScreen y firma de código

2. Cinco puntos que conviene aclarar antes de encargar la externalización o el desarrollo por encargo de una app Windows

2.1 Qué es lo que no puede detenerse

Lo primero que hay que aclarar no es la lista de funciones, sino «qué negocio causaría problemas si se detuviera».

• Se detiene el procesamiento de pedidos.
• Se detiene la línea de inspección.
• No se pueden emitir informes.
• Se detiene la comunicación con el dispositivo.
• El personal de campo vuelve al trabajo manual.
• No quedan registros de auditoría o de trazabilidad.

En el desarrollo por encargo, el diseño no consiste solo en crear pantallas y funciones, sino en llegar a evitar que el negocio se detenga. Al tener clara esta prioridad, resulta más fácil decidir qué funciones hay que construir, cuáles se pueden posponer y qué errores conviene investigar primero.

2.2 La aplicación actual y su entorno

En la modificación y el mantenimiento de una aplicación existente, se revisa no solo la aplicación en sí, sino también el entorno que la rodea.

La información que conviene tener clara es esta:

• Nombre de la aplicación, uso y departamento que la utiliza.
• Número de usuarios y número de equipos.
• Versión de Windows.
• 32 bits/64 bits.
• Versión de .NET Framework o de .NET.
• Versión de Visual Studio.
• Base de datos, carpetas compartidas y API externas.
• Dispositivos, DLL y SDK con los que se integra.
• Procedimiento de instalación.
• Ubicación de los archivos de configuración.
• Ubicación de los registros.
• Si existe el código fuente.
• Si existe el procedimiento de compilación.
• Si quedan documentos dejados por la persona responsable anterior.

Cuanta más información de este tipo esté disponible, mayor será la precisión del presupuesto y de la investigación. Al contrario, si falta información, es más seguro separar el primer paso como un «diagnóstico de la situación actual».

2.3 ¿Desarrollo nuevo, modificación o sustitución completa?

En las consultas sobre aplicaciones Windows, a veces es mejor no decidir desde el principio que se va a «reconstruir todo».

Si conviene seguir usando una aplicación .NET Framework o migrar a .NET depende del tipo de aplicación, de las bibliotecas de las que depende, de la integración COM y del método de distribución. Hacer primero un inventario de los puntos a comprobar antes de la migración facilita la decisión.

Artículos relacionados

• Lista de comprobación previa a la migración de .NET Framework a .NET — puntos del inventario previo a la migración

2.4 Distribución, actualización y privilegios

En las aplicaciones Windows, a veces el obstáculo no está en el desarrollo, sino en la distribución.

Los puntos que conviene comprobar especialmente son estos:

• Si se usará con un usuario estándar.
• Si hay procesos que requieren privilegios de administrador.
• Si se instala para todos los usuarios o basta con un usuario individual.
• Si se usará solo internamente o también se distribuirá fuera de la empresa.
• Si se necesita actualización automática.
• Si hay equipos sin conexión.
• Si se necesita firma de código.
• Si hace falta explicar Microsoft Defender SmartScreen.
• Si existen políticas de gestión como Intune, GPO o App Control.

Separar los procesos que requieren privilegios de administrador de los que no los requieren mejora la seguridad y la operabilidad del uso diario.

Artículos relacionados

• El límite entre lo que necesita y lo que no necesita privilegios de administrador en Windows — cómo distinguir el límite de los privilegios

2.5 Facilidad de mantenimiento

Lo importante en el desarrollo por encargo no es solo que funcione en el momento de la entrega. Conviene dejarlo en un estado en el que, años después, otra persona responsable pueda investigarlo, modificarlo y volver a distribuirlo.

Una aplicación Windows fácil de mantener tiene características como estas:

• Se conserva el procedimiento de compilación.
• Se conocen las bibliotecas de las que depende y sus versiones.
• Se conoce la ubicación y el significado de los archivos de configuración.
• Los registros se generan con un nivel de detalle útil para la investigación.
• Queda constancia en caso de bloqueo.
• Existe un procedimiento de distribución y un procedimiento de reversión.
• Las responsabilidades del código fuente están separadas.
• Los procesos que requieren privilegios de administrador están limitados.
• La información confidencial no se guarda en texto plano.

La comprobación mínima de seguridad antes de la publicación se realiza desde los puntos de vista de los privilegios, la firma, la información confidencial, las comunicaciones, la entrada de datos, las DLL y los registros.

Cuando se guardan contraseñas o tokens en un archivo de configuración, hay que evitar el almacenamiento en texto plano y diseñar la protección usando los mecanismos de Windows.

Artículos relacionados

• Lista de comprobación de seguridad mínima para apps Windows — comprobación mínima antes de la publicación
• Cómo guardar de forma segura la información confidencial de los archivos de configuración — protección mediante DPAPI

3. Decisiones habituales sobre la elección de tecnología para una app Windows

3.1 ¿WinForms, WPF o WinUI?

En el desarrollo nuevo de una aplicación Windows, uno de los puntos a debatir es cuál usar entre WinForms, WPF y WinUI.

A grandes rasgos, la comparación queda así:

Las tres son exclusivas de Windows. Si existe algún requisito de querer llevarlo a varias plataformas en el futuro, hay que considerar opciones más allá de estas tres.

Sin embargo, la tecnología más nueva no siempre es la respuesta correcta. Hay que elegir teniendo en cuenta también la experiencia del equipo existente, el periodo de mantenimiento, el método de distribución, los requisitos de pantalla y las bibliotecas periféricas.

Artículos relacionados

• Guía de selección entre WinForms/WPF/WinUI — tabla de decisión por criterios

3.2 ¿Basta con C#/.NET, o hacen falta C++ o DLL nativas?

La mayoría de las aplicaciones de negocio se pueden construir de sobra con C#/.NET. Sin embargo, en casos como estos se puede plantear el uso de C++, DLL nativas, P/Invoke, C++/CLI o COM:

• El SDK del proveedor está orientado a C/C++.
• Es necesario invocar una DLL existente.
• Hay procesamiento de imágenes de alta velocidad o control de dispositivos.
• Es necesario usar un activo COM existente.
• Hay que cruzar el límite entre 32 bits y 64 bits.

En proyectos de este tipo, no basta con la facilidad de construcción de la interfaz: también hay que ordenar el límite entre procesos, la propiedad de la memoria, las excepciones, los hilos y la bitness.

3.3 ¿Aplicación Windows o aplicación web?

También hay consultas del tipo «queremos convertir a web una aplicación Windows antigua». En algunos casos migrar a web es adecuado, pero no siempre conviene llevarlo todo a la web.

Una aplicación Windows resulta adecuada, por ejemplo, en casos como estos:

• Se conecta directamente a un dispositivo o equipo local.
• Se usa sin conexión.
• Se manejan archivos locales grandes.
• Se usan activos existentes de COM, DLL o VBA.
• Se necesita una operación de alta velocidad en el equipo del puesto de trabajo.
• Se necesita monitorización residente o procesamiento en segundo plano.

Por otro lado, si se quiere consultar los mismos datos desde varias sedes, usar solo el navegador o reducir la gestión de equipos, migrar a web o a la nube puede ser adecuado.

En la práctica, en lugar de migrar todo a web de una vez, también existe la configuración de dejar solo la parte de la aplicación Windows que sea necesaria y sacar a la web la gestión y consulta de datos.

4. Cómo avanzar en el desarrollo por encargo

Es más seguro avanzar en la externalización o el desarrollo por encargo de una aplicación Windows de la siguiente manera:

flowchart TD
    accTitle: Las seis etapas del desarrollo por encargo
    accDescr: Diagrama de flujo que muestra las seis etapas del desarrollo por encargo, desde el diagnóstico de la situación actual hasta el mantenimiento y la mejora, en el que el diseño de puntos de observación precede a la decisión de la estrategia, y el mantenimiento retroalimenta al diagnóstico inicial
    S1["1. Diagnóstico de la situación actual<br/>Negocio, entorno, activos existentes, síntomas"]
    S2["2. Diseño de puntos de observación<br/>Logs / volcados / registros de comunicación"]
    S3["3. Decisión de la estrategia<br/>Modificación / prolongación / migración gradual / sustitución completa"]
    S4["4. Implementación y pruebas<br/>Casos normales y casos anómalos"]
    S5["5. Distribución y migración<br/>Distribución / actualización / reversión / funcionamiento en paralelo"]
    S6["6. Mantenimiento y mejora<br/>Corregir observando logs y consultas"]

    S1 --> S2 --> S3 --> S4 --> S5 --> S6
    S2 -.->|"Solo al poder observar<br/>se decide qué corregir"| S3
    S6 -.->|"Actualización de SO, cambio de PC,<br/>cambio de periféricos: se repite"| S1

Figura 1: Las seis etapas del desarrollo por encargo y la relación en la que el diseño de puntos de observación precede a la decisión de la estrategia

Lo importante en el orden de las etapas es que la etapa 2, el diseño de puntos de observación, va antes que la etapa 3, la decisión de la estrategia. Si se decide «modificar» o «reconstruir» sin conocer la causa de los síntomas, es fácil que el resultado sea que lo que se creía corregido en realidad no lo estaba.

4.1 Diagnóstico de la situación actual

Primero se ordenan el negocio afectado, el entorno de uso, la aplicación existente, los equipos externos, el método de distribución y los síntomas que causan problemas.

Si existe una aplicación existente, se revisan el código fuente, el entorno de compilación, los archivos de configuración, los registros, el instalador y los documentos relacionados.

4.2 Diseño de puntos de observación

Cuando hay errores o inestabilidad, antes de corregir de inmediato, se hace posible rastrear la causa.

• Añadir registros.
• Obtener volcados de bloqueo.
• Conservar registros de comunicación.
• Registrar la memoria y el número de identificadores (handles).
• Conservar el historial de operaciones.
• Guardar capturas de pantalla o el estado en caso de anomalía.

Cuanto más difícil es reproducir un problema, más eficaz resulta el diseño de los puntos de observación.

4.3 Decisión de la estrategia

Tras observar la situación actual, se decide la estrategia: modificación, prolongación, migración gradual, sustitución completa o solo investigación de errores.

En esta etapa se deciden también, en conjunto, la elección de tecnología, el método de distribución, el método de actualización y el alcance del mantenimiento.

4.4 Implementación y pruebas

En la implementación, se separan y construyen la pantalla, la lógica de negocio, la integración con dispositivos externos, la integración de archivos, el manejo de errores, los registros, la configuración y la distribución.

En las pruebas se comprueban tanto los casos normales como los anómalos.

• El dispositivo no está conectado.
• La comunicación se corta a mitad de camino.
• El archivo está bloqueado.
• Faltan privilegios.
• La red es inestable.
• La configuración está dañada.
• La actualización falla.
• La aplicación termina de forma anómala.

4.5 Distribución y migración

Una vez terminada, se preparan el procedimiento de distribución, el procedimiento de actualización, el procedimiento de reversión, la configuración inicial y las explicaciones para los usuarios.

Si se migra desde una aplicación existente, el plan debe incluir también el funcionamiento en paralelo entre lo antiguo y lo nuevo, la vuelta atrás, la migración de datos y la formación de los usuarios.

4.6 Mantenimiento y mejora

Después de la entrega, se observan los registros y el contenido de las consultas para ir mejorando la aplicación hasta ajustarla a la operación real.

Una aplicación Windows se ve afectada por las actualizaciones del sistema operativo, los cambios de PC, los cambios de periféricos y los cambios en las políticas de seguridad. Por eso, un diseño y una documentación que asuman el mantenimiento como premisa son indispensables.

5. Información útil para tener lista antes del presupuesto

No es necesario tenerlo todo listo en el momento de la consulta. Sin embargo, si se dispone de la siguiente información, la conversación avanza más rápido:

• El propósito de la aplicación.
• Lo que preocupa actualmente.
• El número de usuarios y de equipos.
• La versión de Windows.
• Si existe una aplicación actual.
• Si existe el código fuente.
• El lenguaje de desarrollo o el framework.
• Los dispositivos, bases de datos, archivos o API con los que se integra.
• Las pantallas de error o los registros.
• El procedimiento de reproducción.
• El plazo de entrega deseado.
• El negocio que en ningún caso puede detenerse.
• Si la distribución es interna o también externa.
• Si también se necesita mantenimiento.

No hay problema si hay algún punto que no se conoce. Dejar claro qué se sabe y qué no se sabe es, precisamente, el primer trabajo del desarrollo por encargo.

6. Resumen

Al encargar la externalización o el desarrollo por encargo de una aplicación Windows, con solo transmitir «queremos que nos hagan una aplicación» es difícil ver el alcance necesario.

Antes de hacer el encargo, conviene tener claros estos 5 puntos:

• Qué negocio no se quiere detener.
• Cómo están la aplicación actual y su entorno, incluyendo los activos existentes, los equipos externos, las DLL, COM y ActiveX.
• Si es un desarrollo nuevo, una modificación de lo existente o una sustitución completa (incluida la elección de tecnología entre WinForms, WPF, WinUI, migración a .NET, etc.).
• Cómo se van a tratar la distribución, la firma, la actualización automática y los privilegios de administrador.
• Cómo dejar, tras la entrega, un estado que se pueda mantener, incluyendo el diseño de la investigación con registros, volcados de bloqueo, memoria y comunicaciones.

Una aplicación Windows está estrechamente ligada al negocio del terreno, a los dispositivos, a los archivos, a los periféricos y a las limitaciones del propio sistema operativo Windows. Por eso, en la externalización y el desarrollo por encargo es importante diseñar no solo «crear», sino también «investigar», «corregir», «conservar», «distribuir» y «operar».

Si tiene dificultades con la externalización o el desarrollo por encargo de una aplicación Windows, con un desarrollo nuevo, con la modificación y el mantenimiento de software existente, con la integración de dispositivos, con la investigación de errores o con el diseño de distribución y actualización, empiece por consultarnos para ordenar la situación actual.

Consultar sobre el desarrollo de una app Windows

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Podemos consultarles aunque no tengamos el código fuente?

Sí, es posible. Sin embargo, sin código fuente lo que podemos hacer es limitado. En algunos casos es posible investigar a partir de la configuración, el entorno, los registros, las dependencias externas, los ejecutables, los instaladores y el contenido de las comunicaciones. Por otro lado, añadir funcionalidades o realizar correcciones de fondo suele requerir el código fuente, por lo que lo más realista es empezar por un diagnóstico de la situación actual.

¿Podemos consultarles incluso para una aplicación con VB6, VBA, COM o ActiveX antiguos?

Sí, es posible. En este ámbito, en lugar de reemplazarlo todo de golpe, es importante distinguir qué mantener, qué encapsular y qué reemplazar. En particular, los activos que aún funcionan en producción es más seguro migrarlos de forma gradual, vigilando los riesgos.

¿Deberíamos reemplazar nuestra aplicación Windows por una aplicación web?

Depende del objetivo. Las aplicaciones web son adecuadas para múltiples sedes, una gestión de dispositivos simplificada y el uso desde el navegador. Por otro lado, si hay integración de dispositivos, procesamiento de archivos locales, funcionamiento sin conexión o uso de DLL existentes, mantener una aplicación Windows puede ser más natural. En lugar de llevarlo todo a la web, también es una opción repartir las responsabilidades entre el lado Windows y el lado web.

¿Podemos encargarles solo una investigación de errores?

Sí, es posible. Ante bloqueos tras un funcionamiento prolongado, interrupciones de comunicación, crecimiento de memoria o fallos que solo ocurren en determinados PC, es importante primero hacer que la causa sea rastreable, en lugar de modificar el código de inmediato. Organizamos registros y volcados, acotamos las condiciones de reproducción y luego decidimos la estrategia de corrección.

¿Pueden desarrollar aplicaciones que requieran privilegios de administrador?

Sí podemos, pero un diseño que se ejecute siempre con privilegios de administrador debe considerarse con cuidado. Es más seguro ejecutar la parte de uso diario con una cuenta de usuario estándar y aislar solo las operaciones que requieren elevación. Para la instalación, el registro de servicios, la escritura en áreas protegidas, los controladores y la configuración para todos los usuarios, aclaramos primero el diseño de privilegios.

¿Pueden desarrollar por encargo pequeñas aplicaciones Windows de uso interno?

Sí. Incluso para aplicaciones pequeñas, pensar de antemano en la distribución, las actualizaciones, el registro, la configuración, las copias de seguridad y el relevo entre responsables las hace más fáciles de usar a largo plazo. En particular, pequeñas mejoras operativas como la automatización de trabajos en Excel, la conversión de CSV, la vigilancia de archivos, la generación de informes o la recopilación de datos de dispositivos suelen encajar bien con las aplicaciones Windows.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.