¿Cuál es la diferencia entre un prototipo y una solución de nivel de producción?

Esta pregunta es puramente para aprender y para intensificar mi comprensión técnica. Sé que no hay una solución perfecta y esta pregunta tiene una lista de soluciones sin fin, pero creo que es muy importante que cada arquitecto entienda la diferencia entre una demostración y un proyecto en vivo.

Creé muchas soluciones de demostración en .Net en el pasado. Ahora he sido asignado para diseñar e implementar una solución web de nivel de producción, así que quería preguntar, en un nivel muy alto, qué se requiere para convertir una demostración en una solución de nivel de producción. Según tengo entendido, esto requerirá (además de implementar funcionalmente los requisitos de los clientes):

1. Unidad de prueba de cada método
2. Asegurar que se logre ~ 100% de cobertura de código
3. Registro de todas las excepciones y posibles cortes de puntos, posible con AOP
4. Usando un patrón de diseño de interfaz, inyección de dependencia, posiblemente usando un marco, por ejemplo spring.net
5. Uso de contadores de rendimiento y perfiladores para instrumentación
6. Aplicar la seguridad adecuada, es decir, la autenticación de Windows (si eso es lo que requiere el cliente).
7. Gestión de transacciones en cada método
8. Copia de seguridad de los archivos de la aplicación web antes del nuevo despliegue de solución

¿Qué más?

Mi pregunta está más relacionada con el aspecto técnico en lugar de funcional / documentación porque de lo contrario iremos a otro camino :-)

Gracias.

Creo que la diferencia más importante es que el objetivo de un prototipo es:
1. Probar que un problema puede resolverse de cierta manera O
2. Dar al cliente / a la gerencia una idea de cómo se vería y cómo se sentiría el producto.

mientras que el objetivo de un sistema en vivo es:
1. Resolver un problema determinado / abordar un problema.

Tenga en cuenta que los objetivos de los dos son completamente diferentes .
Por lo tanto, en mi opinión, se debe tirar un prototipo antes de desarrollar un sistema en vivo .

Esto también se debe a que un prototipo suele ser un proyecto 'rápido y sucio', combinado sin ninguna de las consideraciones que ha señalado correctamente en su pregunta (como pruebas, rendimiento, seguridad y mucho más).
Por lo tanto, sería mejor comenzar un nuevo proyecto adecuado que tratar de mejorar un mal proyecto.

No se requieren todas esas cosas, según sus requisitos, o puede haber muchas más. Si sabe a qué me refiero;) Las pruebas unitarias y la cobertura del código son buenas cosas, pero dependiendo de cómo realice otras partes del proceso, puede no ser necesario. Algunos dirían que más importante que el perfil de rendimiento es un código bien documentado o un manual de capacitación. ¡Varía!

Me doy cuenta de que estás viendo el lado técnico, pero espero que entiendas mi punto, varía según el lado no técnico. O al menos debería.

El uso de contadores de rendimiento y perfiladores para la instrumentación ... podría ser adecuado, pero podría ser excesivo. Puede no ser requerido.

Lo que se está perdiendo aquí es no tener en cuenta el contexto, el alcance y los requisitos comerciales del proyecto.

Por contexto y alcance quiero decir: ¿estás creando algo para que una empresa lo use internamente? ¿Orientada al cliente? ¿Usado por los usuarios finales? ¿Es de hecho una versión jazzística de Notepad, o un nuevo RDBMS desde cero? Lo que debe incluirse variará enormemente (¡enormemente!) Según el proyecto que esté viendo.

Por requisitos comerciales no me refiero a los casos de uso del software, sino a los requisitos del proceso de gestión / producción del proyecto. Si insiste en que necesita todas esas cosas para un proyecto de producción, el costo se reflejará en consecuencia (muy alto). Eso podría significar que está por encima del presupuesto, tarde o incluso que no se le dio luz verde para comenzar el desarrollo.

Podría ser que más importante que tener un conjunto fijo de criterios ahora es simplemente tener un buen marco de producción / desarrollo, alta visibilidad y lanzamientos regulares para que la calidad se pueda evaluar de esa manera. Podría ser que nadie involucrado se preocupe por la cobertura del código.

Curiosamente, creo que los puntos 1, 2, 4 y 7 ya deberían hacerse durante la concepción de su prototipo, excepto que no creo que deba probar todos los métodos en cada clase. Pruebe el código crítico, no si los métodos get / set se comportan correctamente.

Dependiendo del propósito de su aplicación, donde la seguridad es un gran problema, el punto 6 puede ser lo suficientemente crítico como para que lo necesite en el prototipo. Dependiendo del propósito de su aplicación, donde el rendimiento es la clave, el punto 5 puede ser crítico ... Sabes a lo que me refiero. Mi opinión es que los puntos 3, 5 y 6 pueden ser necesarios en el prototipo si se consideran críticos (el punto 8 es realmente válido para aplicaciones de producción)

Editar: parece que mi opinión difiere completamente de la de sJhonny porque implico que considero que el prototipo es la base / caparazón / esqueleto de sus futuros desarrollos, por lo que para mí el prototipo no se debe tirar.

Además de lo que ya se ha mencionado, en un proyecto de producción necesita lo siguiente (entre otros):

0-Elija una metodología de implementación

1-Finalizar y publicar los principales requisitos (incluidos los casos de uso, etc.)

2-Obtén la arquitectura correcta

3-Seleccione las herramientas correctas

Base de datos de 4 diseños para el rendimiento

5-Produzca su diseño de clase y diseño de flujo de trabajo

6-Determinar e implementar una estrategia para integrar bases de datos / fuentes de datos / feeds respaldados

7-Definir e implementar requisitos de seguridad

8-Organizar la implementación física (servidores, conectividad, licencias, etc.)

9-Planifique los requisitos de almacenamiento y determine las medidas de rendimiento

10-Produzca todos los artefactos e instálelos en un entorno de producción

11-prueba

12-Entregue la solución final e implemente la retroalimentación

La característica más importante de las soluciones de calidad de producción es, en mi opinión, la robustez .

Independientemente de lo que ocurra, la solución maneja la situación con sensatez, notifica a aquellos que necesitan saber y continúa (si el error es recuperable).

Hay dos tipos de prototipos:

• Aplicaciones de "prueba de concepto" rápidas y sucias que se "limpian" y se convierten en código de producción. La etapa de "limpieza" tiende a ser una pesadilla o es realmente una etapa de "barrer los problemas debajo de la alfombra", lo que resulta en una deuda técnica masiva.

• Prototipos de "maquetas" o "wireframes". Estos pueden ser bocetos de interfaz de usuario de papel y lápiz, o incluso maquetas interactivas realizadas en un idioma en el que puede unir rápidamente este tipo de cosas sin pensar mucho en cómo encaja. Debe usar datos falsos, no arquitectura real, etc. El punto es que les dan a los interesados ​​una idea de cómo será el sistema, para que pueda refinar sus requisitos, pero NO PUEDEN usarse como parte de su solución final .

Prefiero el segundo tipo. Los expulsan porque no hay realmente una opción.

Digo compilarlo como un proyecto sin demostración, pero ahora puede incluir en su diseño lo que aprendió de la demostración. La codificación inicial puede ser mala incluso una vez que comience la producción. Vas a tener que refactorizar gran parte de todos modos.

El verdadero problema a abordar es su restricción de tiempo. Cuando los tomadores de decisiones quieren que continúes trabajando en la demostración, tienen la impresión de que gran parte de la aplicación está lista, por lo que no tomará tanto tiempo. He oído que otros usan esta lógica sobre por qué prefieren mostrar bocetos a los clientes en lugar de maquetas demasiado realistas. Preste atención al código de demostración porque puede haber descubierto problemas que nunca pensó y que probablemente no documentó en este proceso. Ahora debe considerarlos (demasiado simplificado, pero sí, la base de datos puede no ser accesible, por ejemplo).

Todos los prototipos y demos no son iguales. Todo el código podría ser inútil o ciertas partes pueden haberse hecho muy bien. No importa si es una demostración, debe saber la diferencia. No solo tirarías una aplicación de legacay y comenzarías de nuevo, ¿verdad? Olvida lo que pregunté.