¿Qué necesita cambiar?
Describe la tarea, el problema o el objetivo, y qué parte de la operación depende de él.
Ingeniería de software aplicada
Entender el problema. Elegir cómo resolverlo.
Antes de escribir código reproducimos los fallos, medimos el sistema y estimamos lo que costará mantenerlo. Con eso construimos, rescatamos un proyecto detenido o corregimos.
01Ideas y sistemas evaluados
02Método acorde al contexto
03Evolución con criterios claros
Lo que aprendimos en terreno
Muchos fallos se arreglan dos veces porque nunca se reprodujeron.
Antes de tocar código hacemos que el problema ocurra a voluntad. Recién entonces una corrección se puede comprobar.
01
Evaluación de ideas y proyectos
Lo caro de un software rara vez es construirlo: es mantenerlo durante años. Estimamos ambas cosas antes de empezar.
02
Análisis de fallos
Reproducimos el problema, probamos hipótesis de causa y dejamos una prueba automática que avisa si vuelve a aparecer.
03
Desarrollo y mantenimiento
Un equipo de dos personas no necesita los procesos de uno de cincuenta. Ajustamos arquitectura, pruebas y entregas al tamaño real.
04
Requisitos y normativas
Seguridad y normativas cuestan poco al diseñar y mucho al final. Las incorporamos desde el principio.
Cómo evoluciona el software
Del diagnóstico a un sistema que puede evolucionar.
Entendemos el estado actual, diseñamos el cambio, lo construimos y validamos antes de llevarlo a operación. Cada etapa deja decisiones que el equipo puede revisar.
Diagnóstico
Contexto, requisitos y puntos de mejora
Diseño
Módulos, dependencias y decisiones
Validación
Construcción y comprobación del cambio
Evolución
Integración, operación y mantenimiento
Representación simplificada del proceso. El alcance y las etapas se ajustan a cada proyecto.
Cómo avanzamos
Un método claro para avanzar con criterio.
Acordamos qué significa terminado y quién cuida el software después.
- 01
Diagnosticar
Objetivo, sistema actual, fallos y restricciones.
- 02
Definir el enfoque
Riesgos priorizados, alcance y criterios de calidad.
- 03
Desarrollar y cuidar
Entregas por etapas, probadas, con ruta de mantenimiento.
Una pregunta práctica
¿Cómo comprobamos un cambio antes de incorporarlo al sistema?
Una entrega útil tiene un alcance comprensible y criterios para revisarla. Conectamos el cambio con sus dependencias, las pruebas necesarias y la forma de incorporarlo a la operación.
Qué podrás revisar con tu equipo
- 01
Diagnóstico y prioridades
Una lectura del problema, las restricciones y los riesgos, con un alcance inicial que el equipo pueda discutir.
- 02
Diseño y entregas verificables
Decisiones de arquitectura y desarrollo o corrección por etapas, con criterios de aceptación y comprobaciones acordadas.
- 03
Continuidad para el equipo
Documentación relevante, transferencia de contexto y una ruta de operación y mantenimiento acorde a lo construido.
Cuándo tiene sentido
Cuando el software necesita una decisión mejor informada.
Para decidir qué construir, recuperar un proyecto o dejar de apagar incendios.
- 01
Una idea necesita evaluación técnica y un plan realista
- 02
Un proyecto está detenido, creció sin dirección o acumula riesgos
- 03
Los fallos se repiten y hace falta investigar y priorizar correcciones
- 04
El desarrollo y mantenimiento requieren prácticas y responsabilidades claras
- 05
Hay requisitos de seguridad, calidad o regulación que considerar
Antes de conversar
Un buen punto de partida.
Puedes llegar con una idea, un sistema existente o un fallo que se repite. El primer objetivo es entender dónde tiene sentido intervenir.
¿Con qué estamos trabajando?
Identifica al equipo, los sistemas e integraciones existentes y la documentación disponible.
¿Cómo reconoceríamos una mejora?
Define un comportamiento esperado, una tarea que debería completarse o una falla que debería dejar de ocurrir.
Conversemos
Revisemos el problema detrás del software.
Cuéntanos qué quieren construir o qué está fallando.
Conversemos