Esta es una falsa dicotomía. El primer requisito del software es satisfacer las necesidades de sus clientes. Los problemas que el programa necesita resolver son los de los clientes.
La razón por la cual hay tantos no programadores involucrados en la programación es para asegurarse de que los programas resuelvan los problemas correctos de manera efectiva.
Típicamente el proceso consiste en
- ¿Por qué tenemos tantos tipos de datos elementales en lenguajes de programación?
- ¿Puede un estudiante de EEE obtener un trabajo de software?
- ¿Ha fallado Java a la altura de sus esperanzas desde que apareció en escena a principios de los 90?
- ¿Cuáles son los pros y los contras de la integración y el despliegue continuo alojados proporcionados a través de un modelo SaaS?
- ¿Dónde puedo encontrar información para crear software para un sistema de seguridad en el hogar?
- Descubrimiento: descubrir cuáles son las necesidades reales: el por qué
- Análisis: alcance de esas necesidades: el Qué
- Diseño: decidir cómo satisfacer esas necesidades: el Cómo
- Desarrollo – construyendo la cosa
- Pruebas: ¿logramos lo que nos propusimos hacer?
- Implementación: poner la cosa a disposición de los clientes
- Capacitación: el software es complicado y no satisface las necesidades de los clientes de manera obvia
Los proyectos de ingeniería complejos a menudo tienen una fase de puesta en servicio cuando todos los componentes se usan juntos por primera vez. A menudo hay interacciones inesperadas entre los componentes y estos deben resolverse. Con la programación, esto suele suceder durante el desarrollo y puede ser difícil cuando los programadores están trabajando en diferentes funciones simultáneamente. Esta es la razón por la cual las habilidades de los nuevos programadores rara vez se adaptan bien a las necesidades de las grandes organizaciones.
La tendencia es adoptar un enfoque ágil, de modo que los programadores se centren en una pequeña cantidad de funciones a la vez y tengan un tiempo limitado para hacer el trabajo. Al final de cada sprint, el producto se entrega a los clientes para su puesta en marcha (AKA User Acceptance Testing). Es importante que los clientes, con el asesoramiento del equipo de desarrollo, decidan sobre las características que se trabajarán en cualquier momento. El equipo decide cuál de esas características se puede entregar en el período de tiempo. Si no pueden, las características deben desglosarse en características más pequeñas y más enfocadas que se puedan entregar en el plazo.
Por supuesto, hay otras formas de hacerlo. Con el modelo de código abierto de gran comunidad, los clientes a menudo resuelven sus propios problemas y ofrecen soluciones a la comunidad. Por lo general, el propietario del proyecto decide si se aceptan estas soluciones y si los clientes no están contentos con la decisión, siempre pueden bifurcar el proyecto. A pesar del proceso anárquico, esto funciona muy bien.