Cómo definir el alcance de un software a medida
Por Carlos Isidoro De Ayala Diaz ·
Procesos, datos y pruebas para preparar un desarrollo empresarial desde Murcia. Qué acordar antes de pedir presupuesto.
Empieza por una operación, no por una lista de pantallas
Una empresa pide un programa porque algo no funciona como necesita: un pedido se copia varias veces, los estados no coinciden o una aprobación depende de una persona. La primera tarea es describir una de esas operaciones de principio a fin. Quién la inicia, qué información utiliza, quién decide y qué resultado espera el siguiente equipo. Ese recorrido permite distinguir el problema de la solución imaginada.
Una lista de pantallas puede servir como apoyo, pero deja fuera reglas y excepciones. Si un pedido llega sin referencia, si cambia una tarifa o si falta una autorización, alguien debe decidir qué ocurre. Es mejor documentar estas situaciones antes de desarrollar que descubrirlas cuando la aplicación ya se utiliza. Los ejemplos pueden anonimizarse; no hace falta compartir datos personales para explicar una regla.
Decide qué datos y sistemas forman parte
Identifica dónde se crea cada dato y qué aplicación es la referencia. Si el ERP mantiene precios y la nueva herramienta registra pedidos, la propuesta debe explicar cómo se conectan y qué sucede cuando la comunicación falla. También quién puede autorizar el acceso y si el proveedor permite las operaciones necesarias. Una API anunciada no garantiza que exponga todos los campos o funciones requeridos.
La migración merece un apartado propio. Hay que decidir qué historial es útil, cómo se tratarán duplicados y cómo se comprobará que los registros conservan su significado. Una importación de prueba permite detectar problemas antes del cambio definitivo. El alcance debe distinguir esa preparación del intercambio cotidiano entre aplicaciones.
Escribe criterios que permitan aceptar una entrega
Un criterio útil describe una situación y un resultado observable: un perfil autorizado registra una operación, otro puede revisarla y el sistema conserva el estado acordado. También debe existir una respuesta comprensible ante un error. Aprobar solo el aspecto visual no demuestra que permisos, datos e integraciones funcionen.
Las pruebas se acuerdan con personas que conocen el proceso y pueden tomar decisiones. Si aparece una petición nueva, se compara con el alcance inicial y se documenta su impacto. Así se diferencia corregir una función contratada de ampliar el producto. La documentación ayuda a mantener esa conversación sin depender de recuerdos de una reunión.
Prepara la puesta en marcha y lo que viene después
La entrega debe aclarar accesos, documentación, derechos sobre el código y mantenimiento. También copia previa, comprobaciones y posibilidad de volver al sistema anterior si la publicación falla. No todas estas tareas están incluidas por defecto: deben figurar en la propuesta con responsables.
Para una empresa de Murcia o de cualquier otra provincia, una primera reunión puede centrarse en un proceso acotado y en las herramientas actuales. El objetivo no es redactar una especificación perfecta antes de contactar, sino aportar suficiente contexto para decidir qué analizar. Una inversión tecnológica resulta más comprensible cuando cada parte tiene una finalidad y una forma de comprobarse.