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

Al plantearse externalizar o encargar el desarrollo de una aplicación Windows, la primera decisión no se limita a “con qué tecnología construirla”.

En la práctica, recibimos con frecuencia consultas como estas:

• Queremos modificar un software Windows antiguo
• No podemos hacernos cargo de una aplicación interna creada por un predecesor
• La comunicación con un dispositivo o instrumento de medición se detiene de vez en cuando
• Están involucrados 32 bits / 64 bits, COM / ActiveX e integración con VBA
• Dejó de funcionar tras pasar a Windows 11 o a un PC nuevo
• Queremos aclarar todo, incluyendo distribución, firma de código, actualizaciones automáticas y avisos de SmartScreen
• Queremos investigar bloqueos o crecimiento de memoria tras un funcionamiento prolongado

Dicho de otro modo, la externalización y el desarrollo por encargo de una aplicación Windows no consisten solo en “construir nuevas pantallas”. Hay que considerarlo como un trabajo que abarca la investigación de activos existentes, la revisión, la sustitución, la integración de dispositivos, la distribución, el mantenimiento y la investigación de incidencias.

Este artículo resume, desde el punto de vista del cliente, los puntos que conviene aclarar antes de encargar la externalización o el desarrollo por encargo de una aplicación Windows.

Las áreas más consultadas a los desarrolladores por encargo de apps Windows

1. Desarrollo de una nueva aplicación de negocio

Son los casos en los que pantallas de entrada de datos, pantallas de búsqueda, generación de informes, integración con CSV, integración de archivos e integración con sistemas externos que dan soporte a las operaciones internas se construyen como una aplicación Windows.

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

• Se necesita manejar con detalle archivos y carpetas del PC local
• Se quiere integrar dispositivos USB, instrumentos de medición, PLC o cámaras
• Debe usarse en entornos sin conexión o redes cerradas
• Se quiere aprovechar activos existentes de Excel, VBA, COM y DLL
• Se necesita teclado, lector de códigos de barras o pantalla táctil en los terminales de planta
• Se necesita monitorización residente o procesamiento en segundo plano

Incluso en un desarrollo nuevo, decidir desde el principio si debe ser una aplicación Windows, si bastaría con una aplicación web, o si solo una parte debe permanecer en el lado Windows, reduce los cambios de rumbo posteriores.

2. Revisión y mantenimiento de software Windows existente

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

Por ejemplo, situaciones como estas:

• El código fuente existe, pero nadie sabe cómo compilarlo
• Solo se abre con una versión antigua de Visual Studio
• Se ha quedado estancado en VB6, MFC, WinForms o .NET Framework
• La persona responsable dejó la empresa y nadie conoce las especificaciones
• El funcionamiento se volvió inestable tras actualizaciones de Windows o un cambio de PC
• Socios comerciales o el personal de campo solicitan nuevas funcionalidades

En estos casos, en lugar de reconstruir de inmediato, empezamos por hacer un inventario de la situación actual:

• ¿Qué actividad de negocio da soporte la aplicación?
• ¿Qué funcionalidades son imprescindibles?
• ¿En qué entorno funciona?
• ¿De qué dispositivos externos, DLL, bases de datos y carpetas compartidas depende?
• ¿Se conservan registros e información de errores?
• ¿Se conservan el código fuente, las instrucciones de compilación, el instalador y los archivos de configuración?

Que un software existente funcione es en sí mismo un valor. Por eso, en el desarrollo por encargo, en lugar de limitarse a “desecharlo todo y reconstruir”, se vuelve importante un enfoque gradual: mantener, encapsular o reemplazar.

Si están involucrados COM / ActiveX / OCX, empiece por aclarar la terminología con Una explicación exhaustiva de las diferencias entre COM, ActiveX y OCX, y considere la estrategia de migración con perspectivas como la Tabla de decisión mantener / encapsular / reemplazar para ActiveX/OCX, para avanzar con más facilidad.

3. Aplicaciones de integración de dispositivos y equipos externos

En la industria manufacturera, la inspección, la medición, el ámbito médico relacionado y la investigación, las aplicaciones Windows suelen estar conectadas a equipos externos.

Los objetivos de integración típicos son:

• 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 construir pantallas: también hay que diseñar cómo se corta la comunicación, la reconexión, los tiempos de espera, el registro, el almacenamiento de datos en bruto y la visualización de estado.

La comunicación serie en particular tiende a generar problemas en las unidades de recepción, los tiempos de espera, la reconexión y el bloqueo de la interfaz, por lo que es prudente tener en cuenta desde el principio perspectivas como Las trampas del desarrollo de aplicaciones con comunicación serie.

Además, el estado de un dispositivo externo a veces no queda suficientemente descrito solo con “conectado” o “no conectado”. Si se distinguen la presencia del dispositivo, su capacidad de respuesta, la disponibilidad de sus funciones, la actualidad de los datos y la coincidencia de configuración, se obtiene una pantalla más difícil de malinterpretar sobre el terreno. Para más detalles, véase Diseño de la visualización del estado de dispositivos externos.

4. Investigación de errores y análisis de causas

En el desarrollo por encargo de aplicaciones Windows, a veces se necesita una investigación de errores antes incluso de trabajar en nuevas funcionalidades.

Consultas frecuentes de este tipo:

• La aplicación se bloquea solo unas pocas veces al día
• La memoria sigue creciendo tras un funcionamiento prolongado
• No funciona únicamente en un PC concreto
• La comunicación con un dispositivo se detiene durante unos segundos
• Se pierden datos en la integración de archivos
• Nadie conoce los pasos para reproducir el problema
• Los registros son demasiado escasos para rastrear la causa

Este tipo de problemas no se resuelve solo mirando el código. Primero se diseñan puntos de observación y se recopilan registros, volcados de bloqueo, registros de comunicación, registros de eventos, uso de memoria, número de identificadores (handles), etc.

En la investigación de bloqueos, la clave está en cómo conservar la evidencia en el momento mismo del bloqueo, como se describe en Cómo registrar los bloqueos de una aplicación Windows y en Introducción a la recopilación de volcados de bloqueo (WER/ProcDump/WinDbg).

Ante un crecimiento de memoria, hay que distinguir si se trata simplemente de una espera del GC o de una fuga de memoria real. Para aplicaciones .NET, se sigue el procedimiento de observar, comparar y demostrar descrito en Distinguir la espera del GC de una fuga de memoria en .NET.

5. Distribución, firma y actualizaciones automáticas

Una aplicación Windows, una vez terminada, a menudo se atasca en “cómo distribuirla”.

• ¿Se creará un instalador?
• ¿O bastará con colocar los archivos para que funcionen?
• ¿Pueden instalarla los usuarios estándar?
• ¿Se necesitan privilegios de administrador?
• ¿Se distribuirá mediante recursos compartidos internos?
• ¿Los usuarios la descargarán desde la web?
• ¿Se necesitan actualizaciones automáticas?
• ¿Cómo se gestionará el certificado de firma de código?
• ¿Cómo se explicarán y abordarán los avisos de SmartScreen?

Los métodos de distribución incluyen MSI, MSIX, ClickOnce, xcopy y actualizadores propios. La elección no debería 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 más detalles, véase la Guía de selección del método de distribución de aplicaciones Windows.

Para una aplicación Windows .NET de uso interno que se quiera distribuir a usuarios estándar con actualizaciones automáticas ligeras, véase Introducción a ClickOnce: distribución, actualizaciones y criterios de selección.

Por otro lado, la distribución vía web o externa plantea problemas de avisos de SmartScreen y firma de código. El motivo por el que aparece el mensaje “Windows protegió su PC” se resume en Por qué Windows muestra “Windows protegió su PC”.

Cinco cosas que conviene aclarar antes de encargar la externalización o el desarrollo por encargo de una aplicación Windows

1. Qué no debe detenerse

Lo primero que hay que aclarar no es una lista de funcionalidades, sino “las actividades de negocio que no deben detenerse”.

• Se detiene el procesamiento de pedidos
• Se detiene la línea de inspección
• No se pueden emitir informes
• Se interrumpe la comunicación con el dispositivo
• El personal de campo vuelve al trabajo manual
• No quedan auditorías ni rastros

En el desarrollo por encargo, el diseño no se limita a construir pantallas y funcionalidades: también debe garantizar que la actividad no se detenga. Una vez claras estas prioridades, resulta mucho más fácil decidir qué funcionalidades construir, cuáles posponer y qué errores investigar primero.

2. La aplicación actual y su entorno

En la revisión y el mantenimiento de una aplicación existente se comprueba no solo la aplicación en sí, sino también su entorno.

La información que conviene tener clara es la siguiente:

• Nombre de la aplicación, propósito y departamentos que la usan
• Número de usuarios y número de equipos
• Versiones de Windows
• 32 bits / 64 bits
• Versiones de .NET Framework / .NET
• Versión de Visual Studio
• Bases de datos, carpetas compartidas, API externas
• Dispositivos, DLL y SDK integrados
• Procedimiento de instalación
• Ubicación de los archivos de configuración
• Ubicación de los registros
• Si existe el código fuente
• Si existen instrucciones de compilación
• Si existe documentación dejada por el predecesor

Cuanta más de esta información esté disponible, mayor será la precisión de los presupuestos y las investigaciones. A la inversa, si falta información, es más seguro separar la primera fase como un “diagnóstico de la situación actual” independiente.

3. ¿Desarrollo nuevo, revisión o sustitución?

En las consultas sobre aplicaciones Windows, a menudo es mejor no decidir desde el principio “reconstruir”.

Que convenga seguir usando una aplicación .NET Framework o migrar a .NET depende del tipo de aplicación, las bibliotecas dependientes, la integración con COM y el método de distribución. Hacer primero un inventario de los puntos a verificar, como en la Lista de comprobación previa a la migración de .NET Framework a .NET, facilita mucho la decisión.

4. Distribución, actualizaciones y privilegios

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

Los puntos que conviene verificar en particular son estos:

• ¿La usarán usuarios estándar?
• ¿Hay operaciones que requieren privilegios de administrador?
• ¿Instalación para todos los usuarios o basta por usuario?
• ¿Solo uso interno o también distribución externa?
• ¿Se necesitan actualizaciones automáticas?
• ¿Hay equipos sin conexión?
• ¿Se requiere firma de código?
• ¿Hay que tener en cuenta Microsoft Defender SmartScreen?
• ¿Existen políticas de gestión como Intune, GPO o App Control?

Separar las operaciones que requieren privilegios de administrador de las que no los requieren mejora tanto la seguridad como la operatividad en el uso diario. El límite de privilegios puede verificarse con perspectivas como Cuándo se requieren privilegios de administrador en Windows y cuándo no.

5. Facilidad de mantenimiento

Lo importante en el desarrollo por encargo no es solo que la aplicación funcione en el momento de la entrega. Se desea que quede en un estado que, años después, permita a otra persona responsable investigarla, revisarla y volver a distribuirla.

Las aplicaciones Windows fáciles de mantener presentan estas características:

• Se conservan las instrucciones de compilación
• Se conocen las bibliotecas dependientes y sus versiones
• Se conocen la ubicación y el significado de los archivos de configuración
• Los registros se emiten con un nivel de detalle útil para la investigación
• En caso de bloqueo quedan evidencias
• Existen procedimientos de distribución y de reversión
• Las responsabilidades del código fuente están bien separadas
• Las operaciones que requieren privilegios de administrador están limitadas
• La información secreta no se almacena en texto plano

Para la revisión de seguridad mínima previa al lanzamiento, se verifican privilegios, firma, información secreta, comunicación, entradas, DLL y registro, como en la Lista de comprobación de seguridad de aplicaciones Windows.

Si se guardan contraseñas o tokens en archivos de configuración, hay que evitar el almacenamiento en texto plano y diseñar la protección usando los mecanismos de Windows. Para más detalles, véase Cómo almacenar de forma segura la información confidencial de los archivos de configuración.

Decisiones tecnológicas habituales para aplicaciones Windows

Elegir entre WinForms, WPF y WinUI

En el desarrollo de una nueva aplicación Windows, es habitual plantearse cuál de WinForms, WPF o WinUI utilizar.

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

Sin embargo, la tecnología más nueva no siempre es la respuesta correcta. La elección debe tener en cuenta la experiencia del equipo existente, el horizonte de mantenimiento, el método de distribución, los requisitos de pantalla y las bibliotecas relacionadas.

Para más detalles, véase la tabla de decisión en la Guía de selección WinForms/WPF/WinUI.

¿Basta con C# / .NET, o se necesitan C++ o DLL nativas?

La mayoría de las aplicaciones de negocio pueden construirse completamente en C# / .NET. Sin embargo, en casos como los siguientes a veces se plantean C++, DLL nativas, P/Invoke, C++/CLI y COM:

• El SDK del proveedor está orientado a C/C++
• Es necesario llamar a DLL existentes
• Hay procesamiento de imágenes de alta velocidad o control de dispositivos
• Es necesario usar activos COM existentes
• Es necesario cruzar el límite entre 32 y 64 bits

En proyectos de este tipo hay que aclarar no solo la facilidad de construcción de la interfaz, sino también los límites de proceso, la propiedad de la memoria, las excepciones, los hilos y la bitness.

¿Aplicación Windows o aplicación web?

También recibimos consultas del tipo “queremos convertir en web una vieja aplicación Windows”. A veces pasar a la web es lo adecuado, pero no todo debe convertirse necesariamente en web.

Las aplicaciones Windows son adecuadas, por ejemplo, en casos como estos:

• Conexión directa con equipos o dispositivos locales
• Uso sin conexión
• Manejo de archivos locales grandes
• Uso de activos COM / DLL / VBA existentes
• Necesidad de operación rápida en terminales de campo
• Monitorización residente y procesamiento en segundo plano

Por otro lado, si varias sedes necesitan consultar los mismos datos, si se desea un uso exclusivo desde el navegador, o si se quiere reducir la gestión de dispositivos, un enfoque web o en la nube puede ser más adecuado.

En la práctica, en lugar de llevarlo todo a la web de golpe, también existen estructuras que mantienen solo las partes que realmente necesitan una aplicación Windows, trasladando al lado web la gestión y consulta de datos.

Cómo avanza el desarrollo por encargo

La externalización y el desarrollo por encargo de una aplicación Windows avanzan de forma segura así.

1. Comprensión de la situación actual

Primero se organizan la actividad de negocio objetivo, 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 previa, se revisan el código fuente, el entorno de compilación, los archivos de configuración, los registros, el instalador y la documentación relacionada.

2. Diseño de puntos de observación

Ante errores o inestabilidad, antes de lanzarse a corregir, se hace que la causa sea rastreable:

• Añadir registro
• Capturar volcados de bloqueo
• Conservar registros de comunicación
• Registrar memoria y número de identificadores
• Conservar el historial de operaciones
• Guardar capturas de pantalla y el estado en el momento de la anomalía

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

3. Decisión del enfoque

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

En esta fase también se deciden la elección tecnológica, el método de distribución, el método de actualización y el alcance del mantenimiento.

4. Implementación y pruebas

En la implementación se desarrollan por separado las pantallas, la lógica de negocio, la integración con dispositivos externos, la integración de archivos, el manejo de errores, el registro, la configuración y la distribución.

En las pruebas se verifican no solo los casos normales, sino también los casos anómalos:

• El dispositivo no está conectado
• La comunicación se corta a mitad de camino
• Un archivo está bloqueado
• Los privilegios son insuficientes
• La red es inestable
• La configuración está dañada
• Falla una actualización
• La aplicación finaliza de forma anómala

5. Distribución y migración

Una vez terminado, se preparan los procedimientos de distribución, actualización, reversión, configuración inicial y explicaciones para los usuarios.

En caso de migrar desde una aplicación existente, se incluyen en el plan el funcionamiento paralelo entre lo antiguo y lo nuevo, el plan de vuelta atrás, la migración de datos y la formación de usuarios.

6. Mantenimiento y mejora

Tras la entrega, se mejora la aplicación observando registros y consultas recibidas, adaptándola a la operativa real.

Las aplicaciones Windows se ven afectadas por actualizaciones del sistema operativo, sustituciones de PC, cambios de periféricos y cambios de política de seguridad. Por eso, un diseño y una documentación pensados para el mantenimiento son indispensables.

Información útil para preparar antes de un presupuesto

No hace falta tenerlo todo listo en el momento de la consulta. Sin embargo, disponer de la siguiente información agiliza mucho la conversación:

• El propósito de la aplicación
• Lo que causa problemas actualmente
• Número de usuarios y equipos
• Versiones de Windows
• Si existe una aplicación previa
• Si existe el código fuente
• Lenguaje de desarrollo y framework
• Dispositivos, bases de datos, archivos, API integrados
• Pantallas de error y registros
• Pasos para reproducir el problema
• Plazo de entrega deseado
• Actividades de negocio que absolutamente no deben detenerse
• Distribución interna o externa
• Si también se necesita mantenimiento

No hay ningún problema si algunos puntos son desconocidos. Aclarar qué se sabe y qué no se sabe es, en sí mismo, el primer trabajo del desarrollo por encargo.

Resumen

Al encargar la externalización o el desarrollo por encargo de una aplicación Windows, decir simplemente “hagan una aplicación para nosotros” hace que el alcance necesario sea difícil de ver.

Estos son los 7 puntos que conviene tener claros antes de solicitarlo:

• ¿Desarrollo nuevo, revisión de lo existente o sustitución?
• ¿Qué actividades de negocio no deben detenerse?
• ¿Existen activos existentes, equipos externos, DLL, COM o ActiveX?
• Elección tecnológica: WinForms, WPF, WinUI, migración a .NET, etc.
• ¿Cómo gestionar la distribución, la firma, las actualizaciones automáticas y los privilegios de administrador?
• Diseño de la investigación de registros, volcados de bloqueo, memoria y comunicación
• ¿Cómo dejar la aplicación en un estado mantenible tras la entrega?

Las aplicaciones Windows están estrechamente ligadas a las actividades de campo, los equipos, los archivos, los periféricos y las restricciones del sistema operativo Windows. Precisamente por eso, en la externalización y el desarrollo por encargo es esencial diseñar no solo pensando en “construir”, sino también en “investigar”, “corregir”, “documentar”, “distribuir” y “operar”.

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

Consúltenos sobre el desarrollo de aplicaciones 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.