¿Cuáles son las medidas a tomar si se descubre un fallo en el sistema después de la aceptación?

En términos generales, el desarrollo de sistemas implica la implementación de programas de acuerdo con lo que se decidió en la fase de definición de requisitos. Finalmente, tanto el usuario como el proveedor verifican si el resultado final cumple con las especificaciones y, si pasa la aceptación, se considera terminado.

Sin embargo, en la práctica, es completamente posible que se descubran errores o problemas que no se detectaron durante las pruebas o la aceptación en fases posteriores de operación. Si se ha aceptado una entrega, ¿qué se puede solicitar legalmente?

No es sorprendente que aún queden errores después de la aceptación o las pruebas

Desde un punto de vista técnico, no es raro que se descubran varios errores y problemas después de completar las diversas etapas de prueba del proveedor y después de la aceptación por parte del usuario. Lo que los usuarios suelen hacer en el proceso de aceptación es principalmente verificar las entradas y salidas que se pueden confirmar desde la pantalla. Sin embargo, los sistemas de TI a menudo tienen una estructura compleja y detallada en la base de datos detrás de la apariencia de la pantalla que los usuarios pueden ver, y en las partes del programa que controlan varios cálculos y controles. Por lo tanto, hay un límite en lo que se puede investigar a partir de la verificación de las entradas y salidas en la pantalla desde la perspectiva del usuario. Por lo tanto, no es realista verificar exhaustivamente todas las posibilidades de problemas que pueden ocurrir en la fase de operación después de la verificación.

Las mismas circunstancias se aplican cuando se mira desde la perspectiva del proveedor que se encarga del desarrollo. Por ejemplo, el proceso de prueba es para verificar si hay errores o problemas en el contenido del programa implementado. Sin embargo, incluso en el proceso de prueba, no siempre es posible verificar exhaustivamente todas las posibilidades de errores y problemas. Incluso después de que el sistema desarrollado comienza a utilizarse en serio en los negocios, se requiere una excelente habilidad técnica para crear un sistema que continúe funcionando sin problemas, incluso cuando se realizan operaciones que el proveedor no anticipó, o cuando se comienza a registrar una gran cantidad de datos, o cuando varios usuarios comienzan a acceder al mismo tiempo.

Deberíamos entender primero que no es realista descubrir todos los errores y problemas en las etapas de aceptación y prueba, y que es posible que se descubran varios problemas después de comenzar a usar el sistema de TI.

Normalmente, se considera que la deuda en sí misma ya ha sido cumplida

Entonces, ¿cómo deberíamos manejar estos problemas cuando realmente surgen? Vamos a organizarlo de acuerdo con el orden legal.

Primero, si se han descubierto varios errores o problemas después del hecho, el usuario querrá responsabilizar de alguna manera al proveedor que ha estado encargado del trabajo hasta ahora. Sin embargo, normalmente, si la entrega ya se ha completado y ha pasado la inspección, es a menudo difícil responsabilizar al proveedor basándose en el incumplimiento de la deuda.

En primer lugar, a menos que se haya preparado algún acuerdo especial, las regulaciones sobre la implementación del programa en el contrato de desarrollo del sistema se extienden a las regulaciones del contrato de trabajo en el Código Civil japonés.

El camino para perseguir la responsabilidad basada en la garantía de defectos

Entonces, ¿qué y en qué orden deberíamos considerar cuando buscamos una respuesta del vendedor basada en la garantía de defectos? Vamos a verificarlo a continuación.

Primero, verifique el grado de gravedad y seriedad de los errores y defectos

Cuando se descubren errores y defectos después del hecho y se busca alguna garantía alegando que son “defectos” legales, la gravedad de los errores y defectos se convierte en un problema. Los problemas de defectos legales son, en primer lugar,

1. Aunque se puede decir que son errores y defectos, son solo menores y no se pueden considerar como “defectos” legales.
2. Corresponde a un “defecto” legal, pero aún es posible lograr el objetivo del contrato.
3. Corresponde a un “defecto” legal, y también es imposible lograr el objetivo del contrato.

Estos se dividen en tres patrones. Lo que distingue la posibilidad de perseguir la responsabilidad basada en la garantía de defectos es la línea entre 1 y 2, y lo que distingue la posibilidad de rescindir el contrato basado en la garantía de defectos es la línea entre 2 y 3.

A continuación, aclare lo que se debe solicitar al vendedor

Además, es necesario aclarar qué se debe solicitar a la otra parte. Si desea rescindir el contrato, no es suficiente demostrar que es un defecto, sino que debe ser algo que “no puede lograr el propósito del contrato”. En la determinación de este “propósito”, las actas de las reuniones realizadas al inicio del proyecto de desarrollo del sistema y los detalles de las especificaciones son pistas importantes. Dado que también es posible que se descubran errores y defectos después de la aceptación, se debe asegurar la conservación de varios documentos incluso después de la finalización del proyecto de desarrollo.

Además de la rescisión, lo que se puede solicitar como contenido de la garantía de defectos incluye reclamaciones de indemnización por daños y reclamaciones de reparación de defectos.

Otros puntos a tener en cuenta

Es importante prestar atención a cómo se llevan a cabo los actos legales, como la rescisión de contratos

Si se va a rescindir un contrato como parte de la responsabilidad por defectos, también debería aprender cómo llevar a cabo los procedimientos legales para la rescisión.

Es preferible resolver los problemas a través de negociaciones en lugar de disputas

Además, estos argumentos legales no sólo tienen sentido cuando se produce un juicio. La resolución de disputas a través de juicios es una gran carga para ambas partes. Por el contrario, estos conocimientos legales también son muy útiles en la etapa de negociación antes de llegar a juicio.

Deberíamos distinguir entre bugs y defectos, y la falta de funcionalidad

La discusión varía dependiendo de si hay bugs o defectos en las funciones y especificaciones que se han implementado, o si simplemente no están presentes. Si las funciones necesarias no están presentes, es posible que no se reconozca la “finalización del trabajo” en el contrato de subcontratación, y puede que no se reconozca el cumplimiento de la obligación.

Además, incluso si no se proporcionan las funciones y especificaciones necesarias, si el usuario no ha proporcionado información adecuada en la etapa de definición de requisitos, puede que sea inapropiado considerarlo como parte del contenido del contrato en primer lugar.

Resumen

Los problemas que surgen durante el proceso de un proyecto pueden manifestarse mientras el proyecto está en marcha o pueden revelarse posteriormente, como en la etapa de operación. Incluso si se ha completado con éxito todas las etapas del proyecto, la característica de los proyectos de desarrollo de sistemas que no necesariamente garantiza la tranquilidad parece estar simbolizada en el sistema de “responsabilidad por defectos”. Se considera importante comprender todo este proceso y asegurar una gestión de documentos exhaustiva que tenga en cuenta lo que sucede después de la finalización del proyecto de desarrollo del sistema.